RFR (S): 8191567: Refactor ciInstanceKlass G1 keep alive barrier to use Access API.

[David Holmes]

On 29/11/2017 10:41 PM, Per Liden wrote:
> Hi David,
> 
> On 2017-11-29 12:33, David Holmes wrote:
>> Hi Per,
>>
>> Sorry one follow up ...
>>
>> On 29/11/2017 9:17 PM, Per Liden wrote:
>>> Hi David,
>>>
>>> On 11/28/2017 10:22 PM, David Holmes wrote:
>>>> Hi Per,
>>>>
>>>> On 28/11/2017 5:53 PM, Per Liden wrote:
>>>>> Hi David,
>>>>>
>>>>> On 2017-11-28 07:50, David Holmes wrote:
>>>>>> Hi Erik,
>>>>>>
>>>>>> Does "phantom" here have any relationship to PhantomReference?
>>>>>
>>>>> Yes, in the sense that this root oop has the same strength as the
>>>>> referent field in a PhantomReference. All non-strong root oops in the
>>>>> VM (StringTable, JNIWeakHandles, etc) are "phantom oops". Internally
>>>>> in the VM they are unfortunately sometimes referred to as "weak
>>>>> roots". With the access API, we're trying to move away from using
>>>>> "weak" for these since "weak" is the strength of the referent in a
>>>>> Soft/Weak/FinalReference.
>>>>
>>>> Ah I see. I hadn't realized we were mis-using "weak" that way.
>>>>
>>>>>>
>>>>>> Meta-question on access API: if
>>>>>>
>>>>>> RootAccess<IN_CONCURRENT_ROOT | ON_PHANTOM_OOP_REF>::oop_load(addr);
>>>>>>
>>>>>> keeps the value alive, what can cause the value to be allowed to go
>>>>>> dead
>>>>>> again?
>>>>>
>>>>> After a GC, if all existing pointers to this object are phantom oops,
>>>>> then the object is phantom-reachable and those phantom oops will be
>>>>> declared dead and cleared (i.e. same criteria as when a
>>>>> j.l.r.PhantomReference is enqueued).
>>>>
>>>> Sorry this is going OT wrt the actual code review but I'm a bit
>>>> confused. If the above RootAccess marks the oop as PhantomReachable 
>>>> then
>>>> GC can remove it and it wasn't kept alive after all ?? If the above
>>>> makes it stronger than PhantomReachable then GC won't be able to remove
>>>> it, but then how does it return to only being PhantomReachable?
>>>
>>> Unless the access has the AS_NO_KEEPALIVE decorator, a call to
>>> RootAccess<>::oop_load() will always make the object strongly
>>> reachable or return NULL.
>>
>> OKay, but for how long will it remain strongly reachable? Just till the
>> end of the current GC cycle, or the start of the next, or ... ?
> 
> The object will be considered strongly reachable until the start of the 
> next GC cycle. During the next GC cycle the reachability of the object 
> will be reevaluated again.
> 
> Does that clarify things?

Yes - thanks for your patience :)

David

> 
> /Per
> 
>>
>> Thanks,
>> David
>>
>>> The ON_WEAK_OOP_REF/ON_PHANTOM_OOP_REF tells that access barrier that
>>> this oop is subject to resurrection restrictions. This means that
>>> special care needs to be taken when loading this oop, because the
>>> object it points to might already have been declared weak- or
>>> phantom-reachable, but this oop has not yet been cleared (set to
>>> NULL). In this case, the access barrier will step in, detect the
>>> situation and return NULL anyway, essentially making it look like the
>>> oop has been cleared. At some point later, when the GC is doing
>>> weak/phantom reference processing, the logically dead oops will
>>> actually be cleared (set to NULL).
>>>
>>> /Per
>>>
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> cheers,
>>>>> Per
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>> On 25/11/2017 2:22 AM, Erik Österlund wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> When creating a ciInstanceKlass handle, G1 might need a SATB barrier
>>>>>>> to keep "peeked" weak klass pointers alive during marking.
>>>>>>> This should now be done with the Access API instead of manual
>>>>>>> calls to
>>>>>>> the G1 SATB barrier.
>>>>>>>
>>>>>>> Bug:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8191567
>>>>>>>
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~eosterlund/8191567/webrev.00/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> /Erik