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

[Per Liden]

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?

/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