Printing the compiler thread when the process gets a SIGQUIT

[Mandy Chung]

JavaThreads that are hidden from external view 
(is_hidden_from_external_view()) are currently excluded from JVM TI and 
java.lang.management API to obtain thread dumps and other access/control 
(e.g. thread start event, suspend/resume etc).   I think it'd be useful 
to allow getting thread dumps of all Java threads including the hidden 
ones for troubleshooting.   I don't see any issue for 
java.lang.management to expose hidden threads since it only provides 
monitoring information.  However, that would be inconsistent with JVM TI 
which may be worth some spec clarification/update w.r.t. these hidden 
threads (implementation-specific threads).

My 2 cents.

Mandy

On 1/9/2014 1:39 PM, Jeremy Manson wrote:
> You are completely right!  This change is a few years old, and I sent it as
> part of a plan to rid ourselves of patches I can offload on you guys.  What
> was missing on my end was forgotten context.
>
> So, I looked through my notes, and realized that this was part of a larger
> change I did to make it possible to export a list of non-Java threads in
> the JVM through a programmatic API.
>
> Right now, if you want a complete list of threads, you basically can call
> ThreadMXBean.dumpAllThreads for application threads, and you can cut a hole
> in the JVM and call the SIGQUIT code for the native threads.  However, if
> you do that, you don't get the compiler threads (because they aren't native
> threads and they aren't returned with the MXBean).  So, this was part of a
> subsequent attempt to be able to export only the compiler threads, and
> won't help anything a stock VM does at all.
>
> There were also subsequent bugfix patches I didn't add.  I think I need to
> go away and rationalize all of that code.  If there is any interest in
> providing an API to expose native/compiler thread info to users via an API
> (an MXBean, maybe?), let me know, and I can send it in.
>
> Jeremy
>
>
> On Thu, Jan 9, 2014 at 10:45 AM, Christian Thalinger <
> christian.thalinger at oracle.com> wrote:
>
>> [BCC’ing hotspot-runtime-dev]
>>
>> On Jan 9, 2014, at 10:01 AM, Jeremy Manson <jeremymanson at google.com>
>> wrote:
>>
>>> On Wed, Jan 8, 2014 at 9:41 PM, David Holmes <david.holmes at oracle.com
>>> wrote:
>>>
>>>> Hi Jeremy,
>>>>
>>>>
>>>> On 9/01/2014 8:45 AM, Jeremy Manson wrote:
>>>>
>>>>> Hi folks,
>>>>>
>>>>> We've found it useful to have a complete list of threads when we handle
>>>>> a SIGQUIT.  Hotspot currently prints out the VM thread and the GC
>>>>> threads, but not the compiler threads.  Follows a patch to make it do
>>>>> this.  Any interest, or was there a reason that compiler thread
>> printing
>>>>> was never implemented?
>> I’m confused.  Aren’t we already printing the compiler threads?
>>
>> "C1 CompilerThread3" #8 daemon prio=9 os_prio=31 tid=0x00007fb9f5007000
>> nid=0x5403 waiting on condition [0x0000000000000000]
>>     java.lang.Thread.State: RUNNABLE
>>
>> "C2 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x00007fb9f5006000
>> nid=0x5203 waiting on condition [0x0000000000000000]
>>     java.lang.Thread.State: RUNNABLE
>>
>> Compiler threads are Java threads:
>>
>> class CompilerThread : public JavaThread {
>>
>> so they use JavaThread::print_on.  Am I still missing something?
>>
>> Although I agree that this output is misleading:
>>
>> "VM Periodic Task Thread" os_prio=31 tid=0x00007fe39b00d800 nid=0x5803
>> waiting on condition
>>
>> Compiler thread printing unimplemented.
>>
>> JNI global references: 109
>>
>> Perhaps we should remove the CompileBroker printing logic.
>>
>>>> I think you'd need to ask the compiler folk rather than runtime folk so
>>>> cc'ing hotspot-dev to broaden the audience - and hopefully find a
>> sponsor
>>>> for this. :)
>>>>
>>> Thanks.  I assumed it was a runtime / serviceability issue, but it being
>> a
>>> compiler issue also makes sense.
>>>
>>> Basically, this is for users who get information (like CPU usage) about
>>> threads from other sources, and are trying to figure out what those
>> threads
>>> do in the JVM.  They can do a SIGQUIT and find out about application
>>> threads and VM threads and GC threads, but they then have these other,
>>> leftover threads with no visibility.  This patch clarifies matters, and
>> is
>>> relatively straightforward, so it has been worthwhile having it.
>>>
>>>
>>>
>>>
>>>> Looking at the patch you use:
>>>>
>>>> _name = NEW_C_HEAP_ARRAY(char, strlen(name) + 1, mtInternal);
>>>>
>>>> whereas NamedThread uses:
>>>>
>>>> _name = NEW_C_HEAP_ARRAY(char, max_name_len, mtThread);
>>>>
>>>> I don't know whether mtInternal or mtThread is the appropriate selection
>>>> here.
>>>>
>>> Presumably, the sponsor (or lack thereof) would know?
>>>
>>> (Not sure whether I should delete the associated memory or not...  There
>>>>> seems to be very little cleanup from compiler threads, or attempt to
>>>>> shut them down.)
>>>>>
>>>> I'd opt for doing the free in the destructor as NamedThread does.
>>>>
>>>>
>>> That was my inclination, but CompilerThread doesn't have a destructor.
>>> It's also been my experience that CompilerThreads are never shut down
>>> cleanly (JVMTI Compile events continue to be sent after JVM shutdown,
>> which
>>> has resulted in my removing a lot of cleanup code from my own code).
>>>
>>> Anyway, I'll wait for someone else to chime in.  (I can send the patch
>>> again, if people on hotspot-dev didn't get it the first time.)
>>>
>>> Jeremy
>>