Printing the compiler thread when the process gets a SIGQUIT

[Christian Thalinger]

[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