JVMCI compiler thread idle state is RUNNABLE

Christian Thalinger cthalinger at twitter.com
Wed Sep 7 17:59:32 UTC 2016


> On Sep 7, 2016, at 7:32 AM, Doug Simon <doug.simon at oracle.com> wrote:
> 
>> 
>> On 07 Sep 2016, at 19:19, Christian Thalinger <cthalinger at twitter.com> wrote:
>> 
>>> 
>>> On Sep 7, 2016, at 12:34 AM, Doug Simon <doug.simon at oracle.com> wrote:
>>> 
>>> 
>>>> On 06 Sep 2016, at 23:39, Christian Thalinger <cthalinger at twitter.com> wrote:
>>>> 
>>>> One thing we noticed here at Twitter is that JVMCI threads are not hidden (is_hidden_from_external_view) but at the same time they show up as always active.
>>>> 
>>>> I don’t know the history here but I’m speculating that since compiler threads were always hidden no-one bothered.  In the SIGQUIT thread dump compiler threads show up as RUNNABLE:
>>>> 
>>>> "C1 CompilerThread3" #8 daemon prio=9 os_prio=31 tid=0x00007fdcc2016800 nid=0x5103 waiting on condition [0x0000000000000000]
>>>> java.lang.Thread.State: RUNNABLE
>>>> 
>>>> "C2 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x00007fdcc2821800 nid=0x4f03 waiting on condition [0x0000000000000000]
>>>> java.lang.Thread.State: RUNNABLE
>>>> 
>>>> The specification of RUNNABLE is:
>>>> 
>>>>      /**
>>>>       * Thread state for a runnable thread.  A thread in the runnable
>>>>       * state is executing in the Java virtual machine but it may
>>>>       * be waiting for other resources from the operating system
>>>>       * such as processor.
>>>>       */
>>>>      RUNNABLE,
>>>> 
>>>> and that makes sense.  But this is very confusing to the user (as one of our internal users reported to me). Maybe JVMCI threads should just be hidden, too?
>>> 
>>> Why is this very confusing? All sorts of non-app threads show up in a SIGQUIT thread dump don’t they?
>> 
>> The confusing part is that JVMCI threads show up but C1/C2 threads don’t.  Oh, maybe I wasn’t clear enough.  I’m not talking about a SIGQUIT thread dump; I’m talking about the thread list you can get in Java code (JVM_GetAllThreads aka. “external view”).
> 
> I don’t know what exactly is meant by “external view” but I see that a bunch of JVMTI methods use is_hidden_from_external_view which, as you observed, returns false for JVMCI compiler threads. That seems to imply that changing the returned value for JVMCI threads will probably make such threads disappear in a Java debugger.

Yes, I’ve seen the code in JVMTI too.  We need a JVMTI expert.

> Maybe all uses of is_hidden_from_external_view need to make their own decision on whether or not to include CompilerThreads that can_call_java.

That would be suboptimal but from what I can see that might be the only way.  I think we need another method next to is_hidden_from_external_view that distinguishes between native compiler threads and JVMCI threads.  can_call_java might be that method but it has a horrible name.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160907/ec6633c1/attachment.html>


More information about the hotspot-compiler-dev mailing list