RFR(s): 8213560: gtests might hang

[Erik Österlund]

+1

/Erik

On 2018-11-19 09:48, Robbin Ehn wrote:
> Hi Robin,
>
> On 11/19/18 9:14 AM, Robin Westberg wrote:
>> Hi Robin,
>
> Minor nit two b's :)
>
>>
>>> On 14 Nov 2018, at 11:35, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>>>
>>> Hi all, please review.
>>>
>>> The VM thread might interfere with the gtest, since the gtest don't 
>>> respect
>>> safepoint but needs e.g. Threads_lock. E.g. if the VM thread do a 
>>> safepoint the
>>> gtests can't create test JavaThreads and we deadlock.
>>>
>>> To handle this the VMThreadBlocker is used block the VM thread in a
>>> non-safepoint VM operation. The test is signaled to continue as we 
>>> queue up the
>>> blocking VM op, but leaves a window of opportunity for a real 
>>> safepoint to slip
>>> in and we deadlock.
>>>
>>> By letting the test wait until VMThreadBlocker's VM_StopSafepoint op 
>>> is actually called by VM thread we eliminate that window.
>>
>> Looks good, one minor stylistic comment:
>>
>> Line 52: perhaps drop the explicit initialization since it’s the same 
>> as the default? Doesn’t really matter of course but I actually find 
>> it less readable. :)
>
> I'll remove it before push, thanks!
>
> /Robbin
>
>>
>> Best regards,
>> Robin (not a Reviewer)
>>
>>>
>>> Webrev: http://cr.openjdk.java.net/~rehn/8213560/webrev/index.html
>>> Cr: https://bugs.openjdk.java.net/browse/JDK-8213560
>>>
>>> Tested with 10 iterations of gtest on release and fastdebug builds 
>>> on all our
>>> platforms (80 iterations total).
>>>
>>> Thanks, Robbin
>>