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

[Vladimir Kozlov]

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