Escaping the Tyranny of the GC: std.rcstring, first blood

[Andrei Alexandrescu via Digitalmars-d]

On 9/14/14, 9:50 PM, deadalnix wrote:
> I don't want to be the smart ass that did nothing and complains about
> what other did, but I'll be it anyway.
>
> It doesn't look very scalable to me to implement various versions of
> modules with various memory management schemes. Inevitably, these will
> have different subtle variation in semantic, different set of bugs, it
> is twice as many work to maintain and so on.

I've got to give it to you - it's rare to get a review on a design that 
hasn't been described yet :o).

There is no code duplication.

> Have you tried to explore solution where an allocator is passed to
> functions (as far as I can tell, this wasn't very successful in C++, but
> D greater metaprogramming capabilities may offer better solutions than
> C++'s) ?
>
> Another option is to use output ranges. This look like an area that is
> way underused in D. It looks like it is possible for the allocation
> policy to be part of the output range, and so we can let users decide
> without duplication bunch of code.

I've been thinking for a long time about these:

1. Output ranges;

2. Allocator objects;

3. Reference counting and encapsulations thereof.

Each has a certain attractiveness, particularly when thought of in the 
context of stdlib which tends to use limited, confined allocation patterns.

Took me a while to figure there's some red herring tracking there. I 
probably half convinced Walter too.

The issue is these techniques seem they overlap at all, but in fact the 
overlap is rather thin. In fact, output ranges are rather limited: they 
only fit the bill when (a) only output needs to be allocated, and (b) 
output is produced linearly. Outside these applications, there's simply 
no use.

As soon as thought enters more complex applications, the lure of 
allocators becomes audible. Pass an allocator into the algorithm, they 
say, and you've successfully pushed up memory allocation policy from the 
algorithm into the client.

The reality is allocators are low-level, unstructured devices that 
allocate memory but are not apt at managing it beyond blindly responding 
to client calls "allocate this much memory, now take it back". The many 
subtleties associated with actual _management_ of memory via reference 
counting (evidence: http://dpaste.dzfl.pl/817283c163f5) are completely 
lost on allocators.

I am convinced that we need to improve the lot of people who want to use 
the stdlib without a garbage collector, or with minimal use of it (more 
on that later). To do so, it is obvious we need good alternative 
abstractions, and reference counting is an obvious contender.

> Finally, concepts like isolated allow the compiler to insert free in the
> generated code in a safe manner. In the same way, it is possible to
> remove a bunch of GC allocation by sticking some passes in the middle of
> the optimizer (

)


Andrei