RFR(XS) 8252521: possible race in java_suspend_self_with_safepoint_check

Reingruber, Richard richard.reingruber at sap.com
Thu Sep 3 08:40:12 UTC 2020


  > This fix looks good to me.

Thank you, David.

The fix passed nightly regression testing @SAP: JCK and JTREG, also in Xcomp
mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, SAP specific tests with
fastdebug and release builds on all platforms.

Thanks, Richard.

-----Original Message-----
From: David Holmes <david.holmes at oracle.com> 
Sent: Donnerstag, 3. September 2020 00:14
To: Reingruber, Richard <richard.reingruber at sap.com>; Hotspot dev runtime <hotspot-runtime-dev at openjdk.java.net>
Subject: Re: RFR(XS) 8252521: possible race in java_suspend_self_with_safepoint_check

Hi Richard,

This fix looks good to me.

Thanks,
David

On 3/09/2020 1:15 am, Reingruber, Richard wrote:
> Hi,
> 
> please help review this fix for a race condition in
> JavaThread::java_suspend_self_with_safepoint_check() that allows a suspended
> thread to continue executing java for an arbitrary long time (see repro test
> attached to bug report).
> 
> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8252521/webrev.0/
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8252521
> 
> The fix is to add a do-while-loop to java_suspend_self_with_safepoint_check()
> that checks if the current thread was suspended again after returning from
> java_suspend_self() and before restoring the original thread state. The check is
> performed after restoring the original state because then we are guaranteed to
> see the suspend request issued before the requester observed that target to be
> _thread_blocked and executed VM_ThreadSuspend.
> 
> Thanks, Richard.
> 


More information about the hotspot-runtime-dev mailing list