1
Fork 0
mirror of https://git.savannah.gnu.org/git/guile.git synced 2025-05-19 19:20:23 +02:00

More wording

This commit is contained in:
Andy Wingo 2022-05-11 22:29:37 +02:00
parent c39e26159d
commit 69d7ff83dd

View file

@ -39,13 +39,16 @@ in the mark byte table.
You might think this is a bad tradeoff, and perhaps it is: I don't know You might think this is a bad tradeoff, and perhaps it is: I don't know
yet. If your granule size is two pointers, then one mark byte per yet. If your granule size is two pointers, then one mark byte per
granule is 6.25% overhead on 64-bit, or 12.5% on 32-bit. Especially on granule is 6.25% overhead on 64-bit, or 12.5% on 32-bit. Especially on
32-bit, it's a lot! On the other hand, you don't need GC bits in the 32-bit, it's a lot! On the other hand, instead of the worst case of one
object itself, and you get a number of other benefits from the mark byte survivor object wasting a line (or two, in the case of conservative line
table -- you can also stuff other per-object data there, such as pinning marking), granule-size-is-line-size instead wastes nothing. Also, you
bits, nursery and remset bits, multiple mark colors for concurrent don't need GC bits in the object itself, and you get a number of other
marking, and you can also use the mark byte (which is now a metadata benefits from the mark byte table -- you can also stuff other per-object
byte) to record the object end, so that finding holes in a block can data there, such as pinning bits, nursery and remset bits, multiple mark
just read the mark table and can avoid looking at object memory. colors for concurrent marking, and you can also use the mark byte (which
is now a metadata byte) to record the object end, so that finding holes
in a block can just read the mark table and can avoid looking at object
memory.
Other ideas in whippet: Other ideas in whippet: