SATB write barrier rationale

[Nilsen, Kelvin]

Thanks for the quick clarification.  My misunderstanding was with the behavior of the LRB.


From: Roman Kennke <rkennke at redhat.com>
Date: Monday, August 3, 2020 at 2:58 PM
To: "Nilsen, Kelvin" <kdnilsen at amazon.com>
Cc: Shenandoah Development <shenandoah-dev at openjdk.java.net>
Subject: RE: [EXTERNAL] SATB write barrier rationale


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


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<mailto: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.