draft proposal for ref counting in D

Michel Fortin michel.fortin at michelf.ca
Mon Oct 14 14:25:29 PDT 2013


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

> On Monday, 14 October 2013 at 19:42:36 UTC, Michel Fortin wrote:
>> Indeed. The current garbage collector makes it easy to have shared 
>> pointers to shared objects. But the GC can also interrupt real-time 
>> threads for an unpredictable duration, how do you cope with that in a 
>> real-time thread?
>> 
>> I know ARC isn't the ideal solution for all use cases. But neither is 
>> the GC, especially for real-time applications. So, which one would you 
>> recommend for a project having a real-time audio thread?
> 
> If you don't want any pause, concurrent GC is the way to go. This type 
> of GC come at a cost of increased memory usage (everything is a 
> tradeoff) but exists.

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.

Unless of course you use "fork" and scan inside the child process… but 
that has its own set of problems on some platforms.

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:

1. make the codegen configurable -- which brings its own set of 
compatibility problems for compiled code but is good for 
experimentation, or

2. settle on something middle-ground performance-wise that can 
accommodate a couple of strategies, or

3. choose one GC strategy that ought to satisfy everybody and adapt the 
codegen to fit, or

4. keep everything as is.

We're stuck with 4 until something else is decided.

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



More information about the Digitalmars-d mailing list