review (S) for 6974176: ShouldNotReachHere, instanceKlass.cpp:1426

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Aug 11 12:13:39 PDT 2010


Tom,

Should the next code be in own scope {} ?:

       // zombie only - if a JVMTI agent has enabled the CompiledMethodUnload event
       // and it hasn't already been reported for this nmethod then report it now.
       // (the event may have been reported earilier if the GC marked it for unloading).
+     Pause_No_Safepoint_Verifier pnsv(&nsv);
       post_compiled_method_unload();

       MutexLockerEx mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);
       flush_dependencies(NULL);
+ #ifdef ASSERT
+     // It's no longer safe to access the oops section since zombie
+     // nmethods aren't scanned for GC.
+     _oops_are_stale = true;
+ #endif

Thanks,
Vladimir

Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/6974176
> 
> 6974176: ShouldNotReachHere, instanceKlass.cpp:1426
> Reviewed-by:
> 
> The changes for 6965184 reordered the flush_dependencies and
> post_compiled_method_unload which allowed a safepoint to happen in
> between.  Zombie nmethods don't have their oops scanned so when
> flush_dependencies was run it was reading stale oops.  If the oops
> didn't move then it would work as intended but otherwise you might get
> various weird failures.  The fix is to restore the original order.  I
> also added a No_SafePoint_Verifier and some logic to mark the oops as
> potentially stale.  Tested with failing test on SQE machine that
> reproduced it reliably, plus nsk suites with -XX:+DeoptimizeALot
> -XX:CompileThreshold=100.


More information about the hotspot-compiler-dev mailing list