I'm trying to understand how ZGC works in detail. Let's consider a simple Java example:
var v = new Object[]{ new Object() };
Let's call
- a: the array object
- o: the object referenced by v[0]
- r: the reference to a
- s: the reference to o
The image below shows the artefacts graphically: 
Let's assume that the first gc cycle starts and a, o are relocated. Let's further assume that the app doesn't access the objects.
gc cycle 1:
a) Marking phase: at the end of the marking phase the marked0 bit is set in r, s.
b) Relocation phase: At first, the root object a is relocated, r is remapped to the new location and the remapped bit of r is set. Then, o is relocated and the new location of o is written into the forwarding table.
Note: References originating in the heap aren't remapped in the relocation stage (2 at 9:20) - they are remapped in the next marking phase (or by the load barrier, if the app loads a reference before the next marking phase). Hence - to my understanding - the marked0 bit is still set in s.
gc cycle 2:
a) Marking phase:
a1) The marked1 bit of r is set.
a2) Since the remapped bit of s is not set, gc looks into the forwarding table, sees the entry for o, remaps s to the new location of o and deletes the entry from the forwarding table.
Question: Which of the colour bits of s is now set?
Consideration: Since s has just been remapped, it would be natural to set the remapped bit. But gc is in the marking phase as well, so the mapped1 bit has to be set.
Why is this important: If in step a2) the marked bit is set, this means that generally, after the marking phase has finished, all references originating in the heap have set a marked bit. So, whenever an app loads a reference from the heap for the first time after a marking phase finished, the load barrier has to check by accessing the forwarding table if the reference has been remapped.
This is (i) a performance burden, and (ii) unnecessary, because the gc knows from the remapping step (step a2) in the example) that the reference has been remapped. So, either the algorithm is not optimal, or the colour bits are set in a different way than described above.
