@icedquinn I thought about it for a bit and I think there is an argument that SATB does literally incrementally compute a snapshot by logging, though it’s more obvious in hybrid coalescing RC/SATB like Levanoni-Petrank and LXR where we’re logging the old values of fields/slots that we update. In pure SATB we only care for the old value to mark it before we update some location, so we mark it right before we update, processing the log entry immediately; coalescing RC needs to know both the old value and what location it came from in order to update refcounts, so we have to actually store the log.
@icedquinn there's a lot of incremental/copy-on-write systems which don't copy everything*, but that's possible. Maybe there's some cursed equivalence between SATB and CoW since tricolor and Cheney's algorithm have an equivalence in colours/cursors.
*e.g. persistent data structures, fork(), incremental backups
just checked with a book written by snooty compsci academics, snapshot at the beginning preserves objects that were live if you took a snapshot at the beginning
("D2/T2 mutations" refers to some examples of breaking concurrent GC earlier in the chapter, it makes sense in context)
@icedquinn@iska The IBM Recycler has cycle collection run concurrently. LXR does a concurrent full trace (necessary because it uses two bit saturating refcounts) too.