Request for reviews (XXS): 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations

[Y. Srinivas Ramakrishna]

Ah, good point. Yes this should be possible without too much trouble [1]
(both the automatic promotion and/or the pruning) because the scavangable
nmethods list seems to be processed as a separate root-set, so we can
for example send it a special "always promote" scanner and/or tell the scanner
to drop nmethods that (no longer) have any young refs, the
latter kinda like we do for card scanning.

Christian or Tom, could one of you please open a CR to track this work so it isn't
forgotten?

thanks.
-- ramki

[1] famous last words?


On 04/02/10 11:12, Tom Rodriguez wrote:
> That looks good.  We still need logic to prune the list of scavengeable nmethods since over time the oops should move out of eden and we can then stop scanning those nmethods.  Additionally we may want GC to automatically promote oops referenced by nmethods since they are pretty much guaranteed to be long lived.  I don't know if there's any easy way to do that.
> 
> tom
> 
> On Apr 2, 2010, at 5:39 AM, Christian Thalinger wrote:
> 
>> http://cr.openjdk.java.net/~twisti/6940520/webrev.01/
>>
>> 6940520: CodeCache::scavenge_root_nmethods_do must fix oop relocations
>> Summary: ScavengeRootsInCode can lead to unfixed code-embedded oops.
>> Reviewed-by:
>>
>> During testing of JSR 292's SPARC C2 port I found a couple of crashes
>> which came from unfixed code-embedded oops.
>>
>> This can be triggered with ScavengeRootsInCode={1,2}.
>>
>> The fix is to call fix_oop_relocations in
>> CodeCache::scavenge_root_nmethods_do after oops may have been updated.
>>
>> src/share/vm/code/codeCache.cpp
>>
>>
>