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

Jeremy Manson jeremymanson at google.com
Thu Jan 9 13:39:55 PST 2014

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