RFR(s): 8213560: gtests might hang

[Robbin Ehn]

On 11/19/18 11:52 AM, Erik Österlund wrote:
> +1

Thanks Erik!

/Robbin

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