Printing the compiler thread when the process gets a SIGQUIT

[Jeremy Manson]

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
>
>