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

[serguei.spitsyn at oracle.com]

On 2/14/14 7:45 AM, Daniel D. Daugherty wrote:
> 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

I'll split the lines.


>
> src/share/vm/prims/jvmtiEnv.cpp
>     No comments.
>
> Thumbs up.

Thank you for review!
Serguei
>
> 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
>