draft proposal for ref counting in D

[Michel Fortin]

On 2013-10-14 23:45:42 +0000, "deadalnix" <deadalnix at gmail.com> said:

> 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.

Very insightful. Thank you.


>> 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.

So as I understand it, your plan would then be:

- use concurrent GC using the page protection mechanism and COW to 
catch writes during collection
- add thread-local awareness to the GC so only shared and mutable 
memory needs COW

Makes sense. But adding thread-local awareness requires a couple of 
language changes. It won't work as long as people keep casting things 
around so you need to fix a lot of cases where casts are needed.

But otherwise, seems like a good plan.

I'm a little wary of the cost of doing COW during collection. Obviously 
the GC isn't pausing the program per-see, but it'll be slowing it down. 
By how much is probably dependent on what you're doing. At the very 
least the GC should allocate types with no pointers on separate pages 
from those with pointers.

Also, what are the calls required to implement page protection and COW 
on posix? I'd like to check whether those are allowed within the OS X 
and iOS sandbox. For instance fork() isn't allowed for sandboxed apps.

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca