RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier

sangheon sangheon.kim at oracle.com
Thu Feb 9 18:54:55 UTC 2017

Hi David,

If you don't have any other questions/comments, can I proceed to push?

Kim, thank you very much for the all explanations.


On 02/07/2017 11:00 PM, Kim Barrett wrote:
>> On Feb 6, 2017, at 10:44 PM, David Holmes<david.holmes at oracle.com>  wrote:
>>>> Does the SATB occur at a global safepoint?
>>> SATB is the approach G1 uses for a part of concurrent collection.  It
>>> defines the invariants that must be maintained by the mutator so that
>>> the collector can find all the live objects.  The barriers in question
>>> are executed by the mutator concurrently with the collector, in order
>>> to inform the collector of reachability graph modifications.
>> Is that a "no"? :) I don't understand how the barriers operate in relation to concurrent actions by the GC. To take the current case, what prevents the GC from deciding that the referent is garbage and can deleted, before the enqueue is called? I assumed a safepoint had to be involved somewhere so that the sequence of actions: extract, enqueue, store, was atomic with respect to the GC.
> To be more precise, the barriers in question are executed by the
> mutator concurrently with the marking phase of the collector.  Once
> marking is (mostly) complete, G1 safepoints and performs various
> tasks, including reference processing.  The barrier must be atomic
> wrto that safepoint (which is accomplished by not allowing any
> safepoints during the barrier execution).  So yes, the sequence of
> extract and enqueue are atomic wrto the relevant part of the GC.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20170209/016f59c5/attachment.htm>

More information about the hotspot-gc-dev mailing list