request for review (m): 4957990: Perm heap bloat in JVM

[Tom Rodriguez]

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.

tom

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  
> _osr_nmethod_head
> 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.)
>
> thanks.
> -- ramki