draft proposal for ref counting in D

[deadalnix]

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.