Printing the compiler thread when the process gets a SIGQUIT (original) (raw)

Christian Thalinger christian.thalinger at oracle.com
Thu Jan 9 10:45:57 PST 2014

[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 = NEWCHEAPARRAY(char, strlen(name) + 1, mtInternal); whereas NamedThread uses: name = NEWCHEAPARRAY(char, maxnamelen, 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

More information about the hotspot-dev mailing list