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

David Holmes david.holmes at oracle.com
Wed Nov 29 11:33:21 UTC 2017

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<INCONCURRENTROOT | ONPHANTOMOOPREF>::oopload(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 ASNOKEEPALIVE decorator, a call to RootAccess<>::oopload() 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 ONWEAKOOPREF/ONPHANTOMOOPREF 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

More information about the hotspot-dev mailing list