JDK-8230459: Test failed to resume JVMCI CompilerThread

Doerr, Martin martin.doerr at sap.com
Wed Oct 16 13:09:17 UTC 2019


Hi David,

thanks for confirming.

So I suggest to fix it like this:
http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.00/

Best regards,
Martin


> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Mittwoch, 16. Oktober 2019 09:11
> To: Doerr, Martin <martin.doerr at sap.com>
> Cc: 'hotspot-compiler-dev at openjdk.java.net' <hotspot-compiler-
> dev at openjdk.java.net>; David Holmes <David.Holmes at oracle.com>
> Subject: Re: JDK-8230459: Test failed to resume JVMCI CompilerThread
> 
> Hi Martin,
> 
> On 15/10/2019 12:50 am, Doerr, Martin wrote:
> > Hi David,
> >
> >>> As C1 and C2 compiler threads are hidden, I still don't see any problems
> reusing the Thread objects.
> >
> >> They are not completely hidden. Those j.l.Thread objects are still part of
> the system thread group and can be found by other code.
> >
> > I know that they are part of the system thread group, but I thought they
> > should not be visible to Java.
> >
> > E.g.
> >
> >          ThreadGroup tg = new ThreadGroup("A");
> >          ThreadGroup stg = tg.getParent().getParent();
> >          Thread[] list = new Thread[100];
> >          stg.enumerate(list);
> >          System.out.println("Listing elements of " + stg);
> >          for (int i = 0; i < list.length; ++i) {
> >              if (list[i] != null) {
> >                  System.out.println(i + ": " + list[i]);
> >              }
> >          }
> >
> > Finds:
> >
> > Listing elements of java.lang.ThreadGroup[name=system,maxpri=10]
> >
> > 0: Thread[Reference Handler,10,system]
> > 1: Thread[Finalizer,8,system]
> > 2: Thread[Signal Dispatcher,9,system]
> > 3: Thread[main,5,main]
> >
> > I can't see any compiler threads.
> 
> Yes you are right. I had forgotten about this other quirk in this whole
> arrangement. Threads started directly by the VM, rather than via
> Thread.start, don't call ThreadGroup.add unless the VM explicitly makes
> that call - which it does for the Signal Dispatcher thread and a couple
> of others. The compiler threads aren't included so while they consider
> themselves to be part of the system ThreadGroup, from the group's
> perspective they are "unstarted threads" - something which is itself
> somewhat of an oddity. But that does mean they are not discoverable that
> way.
> 
> > Do you mean finding them by JVMTI agent?
> >
> > As I understand the Spec, compiler threads should be excluded for
> > GetAllThreads: "The threads are Java programming language threads"
> 
> They are hidden from JVMTI (unlike the JVMCI compiler threads)
> 
> > Or what did you mean by "other code" which can see C1 and C2 threads?
> 
> I did mean by enumerating the system ThreadGroup.
> 
> So for C1/C2 compiler threads we can probably get away with reusing the
> j.l.Thread object.
> 
> Thanks,
> David
> -----
> 
> > Best regards,
> >
> > Martin
> >


More information about the hotspot-compiler-dev mailing list