Hi Serguei,

This looks good to me.

I wonder if we will reach a point where we can delete is_thread_fully_suspended? ;-)

David

On 14/02/2014 10:01 AM, [email protected] 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::is_thread_fully_suspended() 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

Reply via email to