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

[Vladimir Kozlov]

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