SATB write barrier rationale
Nilsen, Kelvin
kdnilsen at amazon.com
Mon Aug 3 21:48:16 UTC 2020
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.
More information about the shenandoah-dev
mailing list