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

[Igor Veresov]

On Jun 16, 2013, at 10:42 PM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:

> 
> 
> 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.

See John's detailed answer. Basically compilers allocate objects and put references to them in nmethods. In some cases these can be the only references to the objects. 
> 
> 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 method.

May be it's time to introduce another reloc type to distinguish weak vs strong references in the code. There are already relocInfo::oop_type and relocInfo::metadata_type that distinguish object refs from class refs.

igor