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

[Srinivas Ramakrishna]

Haven't looked at this webrev or the specifics of the code under
discussion, but we want to scan roots from active nmethods (i.e. those
with activations on thread stacks) as strong and from all other
nmethods in the code-cache as weak. At least that's my recollection of
how it used to be (many years ago). I don't think we'd really want to
make an explicit distinction between objects and classes. But of
course having not looked at or thought about this code in a long
while, I could be quite wrong.

-- ramki

On Sun, 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.
>
> 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
>>
>>
>