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

[David Holmes]

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