2-nd round RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync")
Daniel D. Daugherty
daniel.daugherty at oracle.com
Thu Feb 27 11:09:06 PST 2014
On 2/27/14 1:25 AM, serguei.spitsyn at oracle.com wrote:
> Please, review the fix for:
> Open webrev:
JvmtiEventController::set_frame_pop() is called by
JvmtiEnvThreadState::set_frame_pop() which is called by
The "MutexLocker mu(JvmtiThreadState_lock)" in
JvmtiEventController::set_frame_pop() protected the work
done by JvmtiEventControllerPrivate::set_frame_pop():
Since multiple threads can call JVM/TI NotifyFramePop() on the
same target thread, what keeps the threads from messing with
the list of frame pops simultaneously or messing with the
thread enabled events bits in parallel?
I suspect that this might also be an issue for
> 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
> 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
> functions: set_frame_pop(), clear_frame_pop() and clear_to_frame_pop().
> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi
> On 2/25/14 12:43 PM, serguei.spitsyn at oracle.com wrote:
>> Please, review the fix for:
>> Open webrev:
>> 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
>> which is not adequate from the reliability point of view.
>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi
More information about the hotspot-dev