RFR(s): 8178363: Incorrect check for nmethod re-registration in C1

Per Liden per.liden at oracle.com
Mon Apr 10 07:54:39 UTC 2017


Hi Stefan,

On 2017-04-10 09:31, Stefan Karlsson wrote:
> On 2017-04-10 09:05, Per Liden wrote:
>> Hi,
>>
>> When an nmethod is compiled, it's registered with the heap if
>> ScavengeRootsInCode is non-zero (which it always is). However, during
>> code patching in C1 we re-register the nmethod with the heap only if it
>> also has scavengable oops. This additional requirement is only valid for
>> calls to CodeCache::add_scavenge_root_nmethod(), and not for
>> CollectedHeap::register_nmethod(). This happens to work today since G1's
>> is_scavengable() basically always returns true.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178363
>> Webrev: http://cr.openjdk.java.net/~pliden/8178363/webrev.0/
>> Testing: jprt
>
> Looks good, from a GC perspective.

Thanks for reviewing!

>
> For non-G1 GCs, we now, unnecessarily, take the CodCache lock and call
> find_nmethod even when mirror and appendix are non-scavengable. Maybe
> this should be reviewed on hotspot-comp-dev as well?

Sure, adding comp-dev.

thanks,
Per

>
> Thanks,
> StefanK
>
>>
>> cheers,
>> Per


More information about the hotspot-gc-dev mailing list