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

Daniel D. Daugherty daniel.daugherty at oracle.com
Fri Feb 14 07:45:49 PST 2014


On 2/13/14 5:01 PM, 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 
>

src/share/vm/prims/jvmtiEnvBase.hpp
     line 360 and 446 are a bit long

src/share/vm/prims/jvmtiEnv.cpp
     No comments.

Thumbs up.

Dan



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



More information about the serviceability-dev mailing list