RFR (S) 8034249: need more workarounds for suspend equivalent condition issue (original) (raw)

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Mon Feb 17 21:33:08 PST 2014

Thank you a lot, David!

On 2/17/14 9:02 PM, David Holmes wrote:

Hi Serguei,

This looks good to me. I wonder if we will reach a point where we can delete isthreadfullysuspended? ;-)

I know what you mean by this. :) There are still some space to improve safety with the safepoint mechanizm. Of course, the is_thread_fully_suspended() is still needed for external JVMTI/JDI purposes.

Thanks, Serguei

David On 14/02/2014 10:01 AM, serguei.spitsyn at oracle.com wrote: Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8034249

Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8034249-JVMTI-MON.1

Summary: This issue was identified in the review of the 8032223 and it is similar to the 8032223 but impacts different JVMTI functions: GetCurrentContendedMonitor, GetOwnedMonitorInfo, GetOwnedMonitorStackDepthInfo, GetStackTrace There is a general issue in the suspend equivalent condition mechanism: Two subsequent calls to the JvmtiEnv::isthreadfullysuspended() may return different results: - 1-st: true - 2-nd: false This suspend equivalent issue is covered by another bug: https://bugs.openjdk.java.net/browse/JDK-6280037 This fix is to work around the 6280037. It is more safe to collect the necesary information at a safepoint instead of relying on the suspension of the target thread. Testing: In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi Thanks, Serguei

More information about the serviceability-dev mailing list