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

[David Holmes]

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