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

[serguei.spitsyn at oracle.com]

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 
> is_thread_fully_suspended? ;-)

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