> In GNU Emacs, with tagged pointers, you can know an object is a cons simply by looking at the pointer.
Another thing is that these objects don't need type words. In a conventional GC-adaptation of Emacs (e.g. the igc branch, or this article) one models cons cells, floats, and so on as regular objects consisting of a type word followed by the object payload. A cons cell is only two words long, so when you model it as a regular object, the type word makes it 50% larger!
The regular Emacs GC, for all its faults, densely packs cons cells and other small object types in specialized blocks, avoiding the need to pay the per-object type word overhead and thereby getting better space use and cache locality.
It'd be nice to get a modern GC with specialized heaps just for cons cells, floats, and other small objects
I saw that headerless cons patch too! [1] It's quite exciting to see what a customizable GC is able to do, and I agree a GC with targeted object types (combined with tagged pointers) have quite some room for optimization compared to generic GCs in JVM.
> In GNU Emacs, with tagged pointers, you can know an object is a cons simply by looking at the pointer.
Another thing is that these objects don't need type words. In a conventional GC-adaptation of Emacs (e.g. the igc branch, or this article) one models cons cells, floats, and so on as regular objects consisting of a type word followed by the object payload. A cons cell is only two words long, so when you model it as a regular object, the type word makes it 50% larger!
The regular Emacs GC, for all its faults, densely packs cons cells and other small object types in specialized blocks, avoiding the need to pay the per-object type word overhead and thereby getting better space use and cache locality.
It'd be nice to get a modern GC with specialized heaps just for cons cells, floats, and other small objects