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

[Per Liden]

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.

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