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