G1 Full GC Write Barrier Mechanism

[Ofir Gordon]

Thank you for the clarification.
I have a couple of followup questions -

1. Is the G1 Full collector not concurrent? Which algorithm does it use?
How is it different from the Serial Full GC?

2. The young/mixed G1 gc is the only concurrent gc available? And again,
which algorithm does it use?

Thanks again,
Ofir

‫בתאריך יום א׳, 28 בפבר׳ 2021 ב-20:15 מאת ‪Kim Barrett‬‏ <‪
kab.conundrums at verizon.net‬‏>:‬

> > On Feb 27, 2021, at 11:04 AM, Ofir Gordon <ofirg6 at gmail.com> wrote:
> >
> > Hi all,
> >
> > I'm currently working on the JDK 14 version source code.
> > I'm trying to understand the process of a full collection using the G1
> gc.
> > specifically, I can't follow the write barrier mechanism--where is it
> being
> > activated? what exactly happens in the write barrier? (I see that there
> are
> > both remember set and card tables, are they both being used for tracking
> > changes in the heap during the collection?)
> >
> > Can anyone help me understand the basic flow of this gc in the code?
> > I can see that the marking phase begins in
> > G1FullCollector::collect()->phase1_mark_live_objects(), is this part
> > running concurrently with the program? is the barrier being activated
> > beforehand? (where?)
>
> G1FullCollector and related classes (in files g1Full*) are for the G1 STW
> full GC,
> which doesn’t use the write barriers.
>
> The write post-barrier is used by G1 young/mixed STW collections to track
> locations
> that might contain inter-region references that need to be updated when
> objects
> are moved by those collections.  This is what uses the card table and
> remembered
> sets.
>
> The write pre-barrier is used by the G1 concurrent oldgen collector to
> track values
> that were reachable at the start of the concurrent collection but might no
> longer
> be so because references have been overwritten before the concurrent
> collector
> gets around to examining the location.  This is needed to maintain the SATB
> invariant.  This doesn’t involve the card table and remembered sets.
>
> > In addition, is there a way to verify that the barrier is being executed
> > during the marking? which code is supposed to run for this part?
>
> The barrier implementations are part of the interpreter/compilers.  The
> interpreter invokes relevant functions, and the compilers insert barriers
> in the
> generated code.  This is all managed through the Access API, which provides
> an abstraction over the various GCs for use by non-GC code that needs to
> read or write object locations while maintaining whatever information the
> selected GC requires.
>
> > I know that this are a lot of questions, I'm just trying to figure out
> the
> > basic flow of the process so if someone can give me an explanation that
> > will help me start I'll be really thankful.
> >
> > Thanks a lot,
> > Ofir
>
>
>