review for 6996747: SIGSEGV in nmethod::cleanup_inline_caches / CompiledIC::verify

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu May 12 15:41:43 PDT 2011


Memory leak since possibly_sweep() could be called several time. You need to 
free or reset previous ring buffer. Missing _sweep_index initialization.

SweeperRecord::kind is not printed.

Should it be assert/guarantee? :

+    if (m != nm->method()) {
+      tty->print_cr("method oop changed during lock acquire: " INTPTR_FORMAT " 
!= " INTPTR_FORMAT, m, nm->method());
+    }

Vlaidmir

Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/6996747
> 149 lines changed: 149 ins; 0 del; 0 mod; 10537 unchg
> 
> 6996747: SIGSEGV in nmethod::cleanup_inline_caches / CompiledIC::verify
> Reviewed-by:
> 
> When the sweeper is processing an nmethod it's possible for a
> safepoint to occur while acquiring locks to clean the inline caches.
> This can allow the nmethod to be unloaded in the middle of processing
> it which can result in assertion failures or crashes.  I considered
> modifying the locks to skip the safepoint check but it would require
> changing CompiledIC_lock, InlineCacheBuffer_lock and VtableStubs_lock
> which seems risky.  Instead I keep track of the currently nmethod in
> the CompiledThread and scan it when a GC occurs.  I also included some
> sweeper logging code that I wrote while debugging this.  Tested with
> failing test from report though we'll need big apps runs to confirm
> that there aren't other issues.
> 


More information about the hotspot-compiler-dev mailing list