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

[Y. Srinivas Ramakrishna]

Tom Rodriguez wrote:
> 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.

So, Tom, is my understanding correct that the criteria for unloading of 
the nmethod are not too
weak. Do you suggest that make_unloaded should just go unlink the 
nmethod from the osr list?
I'll give that a try tonight and update later on how that looks wrt the 
current test,
but let me know if i am misunderstanding and that would not  be the 
correct way to
fix this problem,

thanks!
-- ramki
>
> tom
>
> 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.
>>
>> 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
>>
>