RFR(s): 8213560: gtests might hang

[Robbin Ehn]

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
>