RFC: moving forward with @nogc Phobos

[via Digitalmars-d]

On Thursday, 2 October 2014 at 06:29:24 UTC, Jacob Carlborg wrote:
> @gc a = foo(); // a contains an instance of Foo allocated with 
> the GC
> @rc b = foo(); // b contains an instance of Foo allocated with 
> the RC allocator

That would be better, but how do you deal with "bar(foo())" ? 
Context dependent instantiation is a semantic challenge when you 
also have overloading, but I guess you can get somewhere if you 
make whole program optimization mandatory and use a 
state-of-the-art constraint solver to handle the type system. 
Could lead you to NP-complete type resolution? But still doable 
(in most cases).

I think you basically have 2 realistic choices if you want 
easy-going syntax for the end user:

1. implement rc everywhere in standard libraries and make it 
possible to turn off rc in a call-chain by having compiler 
support (and whole program optimization). To support manual 
management you need some kind of protocol for traversing 
allocated data-structures to free them.

e.g.:

define memory strategy @malloc = 
some…manual…allocation…strategy…description;

auto a = bar(foo()); //  use gc or rc based on compiler flag
auto a = @rc( bar(foo()) ); // use rc in a gc context
auto a = @malloc( bar(foo()) ); // manual management (requires a 
protocol for traversal of recursive datastructures)


2. provide allocation strategy as a parameter

e.g.:

auto a = foo(); // alloc with gc
auto a = foo!rc(); // alloc with rc
auto a = foo!malloc(); // alloc with malloc

But going the C++ way of having explicit allocators and 
non-embedded reference counters (double indirectio) probably is 
the easier solution in terms of bringing D to completion.

How many years are you going to spend on making D ref count by 
default in a flawless and performant manner? Sure having RC being 
as easy to use as GC is a nice idea, but if it turns out to be 
either slower or more bug ridden than GC, then what is the point?

Note that:

1. A write to a ref-count means the 64 bytes cacheline is dirty 
and has to be written back to memory. So you don't write 4 bytes, 
  you write to 64 bytes. That's pretty expensive.

2. The memory bus is increasingly becoming the bottle neck of 
hardware architectures.

=> RC everywhere without heavy duty compiler/hardware support is 
a bad long term idea.