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

[Doerr, Martin]

Hi Vladimir,

that must have been a good test. 

The function can_remove(..., false) is used for an heuristic answer without holding CompileThread_lock.
In this case, last_compiler can be NULL and we need to use the normal resolve function.

Changed that and added comment:
http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.04/

Best regards,
Martin


> -----Original Message-----
> From: hotspot-compiler-dev <hotspot-compiler-dev-
> bounces at openjdk.java.net> On Behalf Of Vladimir Kozlov
> Sent: Mittwoch, 30. Oktober 2019 17:33
> To: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR(M): 8230459: Test failed to resume JVMCI CompilerThread
> 
> tier1 test
> compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java failed:
> 
> #  Internal Error
> (t:\workspace\open\src\hotspot\share\runtime/jniHandles.inline.hpp:91),
> pid=16072, tid=25988
> #  assert(handle != 0LL) failed: JNI handle should not be null
> 
> V  [jvm.dll+0x40f2f1]  JNIHandles::resolve_non_null+0x31
> (jnihandles.inline.hpp:91)
> V  [jvm.dll+0x4a16e8]  can_remove+0xc8  (compilebroker.cpp:319)
> V  [jvm.dll+0x4a4a6e]  CompileQueue::get+0x12e  (compilebroker.cpp:435)
> V  [jvm.dll+0x4a4362]  CompileBroker::compiler_thread_loop+0x1b2
> (compilebroker.cpp:1818)
> V  [jvm.dll+0xc7af3e]  JavaThread::run+0x27e  (thread.cpp:1946)
> 
> I attached hs_err file to bug report.
> 
> Vladimir
> 
> On 10/30/19 8:24 AM, Vladimir Kozlov wrote:
> > Thank you guys for discussing and resolving this issue. The fix looks
> > reasonable to me.
> > I will submit several tiers testing to include Graal testing and let you
> > know results.
> >
> > Thanks,
> > Vladimir
> >
> > On 10/30/19 6:30 AM, David Holmes wrote:
> >> On 30/10/2019 9:35 pm, Doerr, Martin wrote:
> >>> 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.
> >>
> >> Ah I see - sorry I missed that.
> >>
> >> Thanks,
> >> David
> >>
> >>> 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
> >>>>>