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

Mandy Chung mandy.chung at oracle.com
Thu Jan 9 14:05:23 PST 2014

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 osprio=31 tid=0x00007fb9f5007000 nid=0x5403 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread2" #7 daemon prio=9 osprio=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::printon. Am I still missing something? Although I agree that this output is misleading: "VM Periodic Task Thread" osprio=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