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