SATB write barrier rationale

[Roman Kennke]

Hi Kelvin,

The LRB doesn't mark anything. It has nothing to do with marking.

Yes, we could change that and do marking via LRB, we actually made a
prototype of it, but it did not work better than SATB (actually looked
worse).

What seems more interesting is the i-u mode. It does show improvements in
some workloads and generally no regressions, and has the additional
advantage that it can reclaim weakrefs that are accessed during marking.

Roman


Nilsen, Kelvin <kdnilsen at amazon.com> schrieb am Mo., 3. Aug. 2020, 23:51:

> I'm trying to understand the "theory of operation" for Shenandoah GC.
> It's not clear to me why it requires a SATB write barrier.
>
> Can anyone clarify?
>
> That I don't immediately appreciate the need for a SATB write barrier
> suggests that certain of my assumptions about Shenandoah behavior may be
> wrong.  If anyone sees errors in my assumptions below, please correct or
> clarify.  Thanks much.
>
> 1. At the start of GC, we stop the world to scan all root pointers,
> including native-method roots, and all thread stacks, marking every object
> referenced from this root set.
>
> 2. The load-reference barrier marks any object that is referenced from a
> heap fetch operation.
>
> 3. Newly allocated objects are considered live (essentially, marked on
> allocation) until the end of the current GC pass.
>
>
>
>