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

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Erik Österlund-2
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
Reply | Threaded
Open this post in threaded view
|

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

Roman Kennke-6
Am 24.11.2017 um 17:22 schrieb Erik Österlund:

> 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

Looks good.

There are many more places where G1SATBCardTableModRefBS::enqueue() is
callled from shared code that would require the same treatment. Are you
planning to take them one by one? Otherwise, maybe squeeze them all into
this patch too because it's related and similar?

Roman

Reply | Threaded
Open this post in threaded view
|

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

Erik Österlund-2
Hi Roman,

On 2017-11-24 17:25, Roman Kennke wrote:

> Am 24.11.2017 um 17:22 schrieb Erik Österlund:
>> 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
>
> Looks good.

Thanks for the review.

> There are many more places where G1SATBCardTableModRefBS::enqueue() is
> callled from shared code that would require the same treatment. Are
> you planning to take them one by one? Otherwise, maybe squeeze them
> all into this patch too because it's related and similar?

I think I would prefer to have a few small well contained RFEs compared
to one very large one, unless people prefer the large change approach.

Thanks,
/Erik

> Roman
>

Reply | Threaded
Open this post in threaded view
|

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

Roman Kennke-6

> Hi Roman,
>
> On 2017-11-24 17:25, Roman Kennke wrote:
>> Am 24.11.2017 um 17:22 schrieb Erik Österlund:
>>> 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
>>
>> Looks good.
>
> Thanks for the review.
>
>> There are many more places where G1SATBCardTableModRefBS::enqueue() is
>> callled from shared code that would require the same treatment. Are
>> you planning to take them one by one? Otherwise, maybe squeeze them
>> all into this patch too because it's related and similar?
>
> I think I would prefer to have a few small well contained RFEs compared
> to one very large one, unless people prefer the large change approach.

I am ok with whatever works best for you :-)

Roman
Reply | Threaded
Open this post in threaded view
|

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

Thomas Schatzl
In reply to this post by Erik Österlund-2
Hi,

On Fri, 2017-11-24 at 17:22 +0100, 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/

  looks good.

Thanks for providing such nice usage examples for the new Access klass
separately from the huge Access change :)

Thanks,
  Thomas

Reply | Threaded
Open this post in threaded view
|

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

Erik Österlund-2
Hi Thomas,

> On 24 Nov 2017, at 18:01, Thomas Schatzl <[hidden email]> wrote:
>
> Hi,
>
>> On Fri, 2017-11-24 at 17:22 +0100, 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/
>
>  looks good.

Thanks for the review!

> Thanks for providing such nice usage examples for the new Access klass
> separately from the huge Access change :)
>

No problem! :)

Thanks,
/Erik

> Thanks,
>  Thomas
>

Reply | Threaded
Open this post in threaded view
|

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

David Holmes
In reply to this post by Erik Österlund-2
Hi Erik,

Does "phantom" here have any relationship to PhantomReference?

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?

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
Reply | Threaded
Open this post in threaded view
|

Re: 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
Reply | Threaded
Open this post in threaded view
|

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

David Holmes
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?

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
Reply | Threaded
Open this post in threaded view
|

Re: 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
Reply | Threaded
Open this post in threaded view
|

Re: 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
Reply | Threaded
Open this post in threaded view
|

Re: 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
Reply | Threaded
Open this post in threaded view
|

Re: 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