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

[Per Liden]

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.

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

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