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

[David Holmes]

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

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