On Monday, 14 October 2013 at 21:25:29 UTC, Michel Fortin wrote:
I'm not an expert in GCs, but as far as I know a concurrent GC
also requires some bookkeeping to be done when assigning to
pointers, similar to ARC, and also when moving pointers, unlike
ARC. So it requires hooks in the codegen that will perform
atomic operations, just like ARC.
Usual strategy include :
- When you JIT, change the function itself, to write pointers
through a function that mark the old value as live.
- When AOT, always go throw that function, which make a test and
mark alive the old value if this is done during a collection.
This basically add a read to a global and a test for each pointer
write.
- Use the page protection mechanism and do regular write. This
can be done via fork, but also via remapping the GCed memory as
COW. The tax is then more expensive, but you only pay it once per
page you actually write and only when actually collecting.
The good news, is that this tax is only required for object that
contains shared mutable pointers. In D, most data are thread
local or immutable. D's type system is really friendly to
concurrent GC, and we definitively should go in that direction.
The only consensus we'll reach is that different projects have
different needs. In theory being able to swap the GC for
something else could bring everyone together. But to be able to
replace the GC for another with a strategy different enough to
matter (concurrent GC or ARC) you need the codegen to be
different. So we can either:
ARC like system need a different codegen, but you can do this
with regular codegen if you use page protection to detect writes.
1. make the codegen configurable -- which brings its own set of
compatibility problems for compiled code but is good for
experimentation, or
Bad, we will end up having different incompatible binaries.
