Disadvantages of building a compiler and library on top of a specific memory management scheme

[Andrei Alexandrescu]

On 2/6/14, 9:54 AM, Frustrated wrote:
> Any time you hard code code something you are also creating
> constraints.  If people build something on top of what you have
> built they inherit those constrains.

Nice thought.

> So, why not create a design pattern that allows one, at compile
> time, to use any specific memory management technique they want
> for the runtime and library(and user code)?

We have a very powerful mechanism for what could be called "statically 
deferred committal": templates. Phobos did a great job at not committing 
to e.g. range representation or string representation. It seems to me we 
have a clean shot at applying the wealth of knowledge and experience we 
accumulated with that, to deferring approaches to allocation.

> e.g., switches could be used to recompile the source when a
> different pattern is desired or libraries could be created that
> use different methods. e.g., phobos64GC.lib.

That won't even be necessary with templates. It would be necessary if we 
have some sort of global flag dictating a fundamental fork.

> To make any of this work, and work efficiently, one must abstract
> what is common between all memory management techniques.
>
> Since allocation is always explicitly defined, it is easy to
> handle. Which every  memory management technique is used, it
> would be called/notified on allocation. The deallocation is the
> tricky part. (reallocation is another potential issue)

Yah, std.allocator aims at formalizing that (in an untyped manner).

> For manual memory management the deallocation is explicitly
> called by the user. This in and of itself is significant and
> either allows the compiler to know that manual memory management
> is used or to replace it with automatic management if desired.
>
> e.g.,
>
> {
> auto a = new!strategy A;
>
> release a; // <- explicit deallocation: replaced with
> strategy.explicitDeallocation(a);
> }
>
> vs
>
> {
> auto a = new!strategy A;
>
> // implicit deallocation: compiler inserts
> strategy.scopeDeallocation(a);
> }

I don't think this works. The scope of "strategy" and "a" may be 
unrelated. More importantly a may be escaped (e.g. by passing it to 
functions etc) unbeknownst to "strategy", which in fact suggests that 
the strategy must be somehow known by "a" independently.

(Stopped reading here.)


Andrei