request for review (m): 4957990: Perm heap bloat in JVM
Thomas.Rodriguez at Sun.COM
Wed Aug 5 18:15:09 PDT 2009
My understanding was that OSR nmethods could/should only be reclaimed
once the klass of their holder was unloaded. The reason for this is
that the normal not_entrant sweeping logic isn't implemented safely
for OSR methods so the sweeper can't safely reclaim them. If the
klass itself is being reclaimed then it should be safe to reclaim the
OSR nmethods. It's possible that we have a hole in the logic which
doesn't account for dealing with unloaded OSR methods properly and you
changes just make it more likely to happen. We either need to close
the not_entrant hole for OSR nmethods, which isn't that hard, and then
correct nmethod::make_unloaded to unlink the OSR nmethod or we have to
make do_unloading disallow unloading for OSR nmethods is the methodOop
is strongly reachable.
On Aug 5, 2009, at 4:57 PM, Y.S.Ramakrishna at Sun.COM wrote:
> Can there be a situation where an osr nmethod associated
> with a method oop gets unloaded while the method and its
> class are still alive? I see that happening with my workspace
> with the changes for 4957990 (yet to figure out why the osr
> nmethod was unloaded).
> Shortly after said unload, the sweeper flushes the nmethod,
> but the nmethod is still left linked off of the klass's
> list, and a subsequent invocation counter overflow at a bci does
> an osr nmethod lookup and falls foul of the flushed nmethod left
> in the instanceKlass's osr nmethod head.
> So I have two questions:
> (a) can an osr nmethod be unloaded while its klass is still alive ?
> (b) if the answer to (a) is yes, then we need to take special steps
> (not present in current code) to unlink said nmethod from the
> list of osr nmethods in its klass.
> Am I making sense? Otherwise i can provide more direct detail.
> (I am still digging to find out why we decided to unload the
> nmethod and will have more follow-up info in a subsequent email.)
> -- ramki
More information about the hotspot-compiler-dev