RFR 6471769: Error: assert(_cur_stack_depth == count_frames(),	"cur_stack_depth out of sync")
    Daniel D. Daugherty 
    daniel.daugherty at oracle.com
       
    Tue Feb 25 14:57:20 PST 2014
    
    
  
On 2/25/14 1: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 
>
src/share/vm/runtime/vm_operations.hpp
     No comments.
src/share/vm/prims/jvmtiEnvBase.hpp
     No comments.
src/share/vm/prims/jvmtiEnv.cpp
     No comments.
src/share/vm/prims/jvmtiEnvThreadState.cpp
     No comments.
src/share/vm/prims/jvmtiThreadState.cpp
     line 66:   _cur_stack_depth = UNKNOWN_STACK_DEPTH;
         This looks like the key piece of this fix with respect to the
         assert() in the bug report. I suspect that the first call to
         JvmtiThreadState::cur_stack_depth() is racing with another
         thread that happens to do something else that inits or sets
         _cur_stack_depth to an acceptable value.
     line 251:     "must be current thread or at safepont");
     line 284:     "must be current thread or at safepont");
         typo: 'safepont' -> 'safepoint'
Thumbs up! No need to re-review the typo fixes.
Dan
>
> 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 hotspot-dev
mailing list