Please, review the fix for:
https://bugs.openjdk.java.net/browse/JDK-6471769
Open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.2
Summary:
It is the 2-nd round of review because the JTREG com/sun/jdi tests
discovered a regression
in the first round change. The issue was in the
JvmtiEventController::clear_frame_pop()
lock synchronization that is not allowed at safepoints.
As a result I've changed the JvmtiEnv::NotifyFramePop to use a VM
operation for safety.
Also, I've removed the lock synchronization from the 3 impacted
JvmtiEventController::
functions: set_frame_pop(), clear_frame_pop() and clear_to_frame_pop().
Testing:
In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi
Thanks,
Serguei
On 2/25/14 12:43 PM, [email protected] wrote:
Please, review the fix for:
https://bugs.openjdk.java.net/browse/JDK-6471769
Open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1
Summary:
This is another Test Stabilization issue.
The fix is very similar to other JVMTI stabilization fixes.
It is to use safepoints for updating the PopFrame data instead of
relying on the
suspend equivalent condition mechanism
(JvmtiEnv::is_thread_fully_suspended())
which is not adequate from the reliability point of view.
Testing:
In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi
Thanks,
Serguei
