RFR(M): 8230459: Test failed to resume JVMCI CompilerThread

[Doerr, Martin]

Hi David,

> I don't think factoring out CompileBroker::clear_compiler2_object when
> it is only used once was warranted, but that's a call for compiler team
> to make. Otherwise changes seem fine and I have noted the use of the
> MutexUnlocker as per your direct email.
I did that because _compiler2_objects is private and there's currently no setter available.

Thanks for your review.

Best regards,
Martin


> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Mittwoch, 30. Oktober 2019 07:27
> To: Doerr, Martin <martin.doerr at sap.com>; 'hotspot-compiler-
> dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>; David
> Holmes <David.Holmes at oracle.com>
> Subject: Re: RFR(M): 8230459: Test failed to resume JVMCI CompilerThread
> 
> Hi Martin,
> 
> Sorry I missed the part about the new RFR thread and replied to the old
> one first :(
> 
> On 30/10/2019 1:17 am, Doerr, Martin wrote:
> > Hi,
> >
> > after some discussions with David and Kim, I think we have a direction
> > to go forward.
> >
> > The discussion in the bug and on the mailing list is pretty long:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8230459
> >
> > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-
> October/035462.html
> >
> > To make long story short, I suggest to create new j.l.Thread objects
> > only for JVMCI threads when (re)starting more threads on demand.
> >
> > This avoids such issues with observable thread state transitions etc.
> >
> > This is my current proposal:
> >
> >
> http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webr
> ev.03/
> 
> I don't think factoring out CompileBroker::clear_compiler2_object when
> it is only used once was warranted, but that's a call for compiler team
> to make. Otherwise changes seem fine and I have noted the use of the
> MutexUnlocker as per your direct email.
> 
> Thanks,
> David
> -----
> 
> > Please review.
> >
> > Best regard,
> >
> > Martin
> >