request for review (m): 4957990: Perm heap bloat in JVM
Thomas.Rodriguez at Sun.COM
Wed Aug 5 19:57:01 PDT 2009
After I wrote this I realized that this is a natural out growth of
your fix. Without profiling information an nmethod should only refer
to types which are statically reachable. Having the MDO act as a
strong root would keep the nmethod from getting unloaded when using
predicted call sites. Once the MDO is a weak root then the nmethod
could want to be unloaded. I guess without your fix CHA could produce
a case where an OSR nmethod would be unloaded without being unlinked
from the OSR nmethod list but I'd have to think about that more.
On Aug 5, 2009, at 6:15 PM, Tom Rodriguez wrote:
> 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