RFR(s): 8213560: gtests might hang

[Robin Westberg]

Hi Robin,

> 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. :)

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