[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR(S): 8173013: JVMTI tagged object access needs G1 pre-barrier
From:       David Holmes <david.holmes () oracle ! com>
Date:       2017-02-10 0:32:10
Message-ID: a90baf79-02d0-a178-cc50-ab37a3bf559d () oracle ! com
[Download RAW message or body]

On 10/02/2017 4:54 AM, sangheon wrote:
> Hi David,
> 
> If you don't have any other questions/comments, can I proceed to push?

Sorry - yes, of course.

> Kim, thank you very much for the all explanations.

Yes much appreciated!

Thanks,
David

> Thanks,
> Sangheon
> 
> 
> On 02/07/2017 11:00 PM, Kim Barrett wrote:
> > > On Feb 6, 2017, at 10:44 PM, David Holmes <david.holmes@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.
> > 
> > 
> 


[prev in list] [next in list] [prev in thread] [next in thread]