2-nd round RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync")

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Thu Feb 27 00:25:00 PST 2014


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, serguei.spitsyn at oracle.com 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
>



More information about the serviceability-dev mailing list