RFR(M/L): 7145569: G1: optimize nmethods scanning

Mikael Gerdin mikael.gerdin at oracle.com
Mon Jun 17 05:42:20 UTC 2013



On 2013-06-16 22:30, Igor Veresov wrote:
>
> On Jun 14, 2013, at 5:27 AM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
>
>>
>> Just to make sure I understand this change, for the G1 class unloading work I don't want the nmethods to act as strong roots. So I guess I'll need to remove the call to mark_strong_code_roots.
>> In the class unloading case only nmethods on the execution stack should be treated as strong roots and they are taken care of by Threads::possibly_parallel_oops_do (from process_strong_roots).
>>
>
> I think references to the _objects_ from nmethod must be strong, otherwise these objects will be only weakly referenced most of the time and will be collected (since they are usually only referenced by that particular nmethod) and you'll be forced to kill nmethod pretty much every collection to stay consistent. References to _classes_ on the other hand should be weak, I think.. Right?

How do you mean?
I'm not entirely clear on when an object is _only_ reachable from an 
nmethod. Is that a common case? I don't see how this is different in G1 
than in any of the other collectors.

Anyway we are unable to make the distinction between objects and classes 
referenced from nmethods now since we use the ClassLoader java object to 
reference the Klass*/Method* from an nmethod.

/Mikael

>
> igor
>
>



More information about the hotspot-gc-dev mailing list