How does Shenandoah's Brooks pointer (forwarding pointer) enable concurrent compaction?

Every object managed by Shenandoah carries one extra native-word field - the Brooks pointer - that normally points to itself. When the collector decides to evacuate an object (copy it to a new region as part of compaction), it first creates the copy, then atomically compare-and-swaps the original object's Brooks pointer to point at that new copy instead of itself.

Because every read or write to the object goes through this single indirection first, it doesn't matter whether the access happens before, during, or after the collector's copy-and-swap - the mutator always lands on a consistent, current version of the object. This is what lets Shenandoah compact (physically move) live objects entirely concurrently with the running application, rather than requiring a stop-the-world pause to safely relocate them, which is exactly the same problem ZGC solves with colored pointers and load barriers instead of a per-object indirection word.