Disadvantages of ARC

[Andrei Alexandrescu]

On 2/6/14, 7:47 AM, Johannes Pfau wrote:
> Am Thu, 6 Feb 2014 14:37:59 +0300
> schrieb Max Klyga <max.klyga at gmail.com>:
>
>>
>> My point is that we should not ruin the language ease of use. We do
>> need to deal with Phobos internal allocations, but we should not
>> switch to ARC as a default memory management scheme.
>
> What's with all this finger pointing and drawing battle lines in the
> last few days? GC-crowd vs ARC-crowd? Can we please all calm down?
[snip]

Nice. An interspersed point:

> I don't think there's anything wrong with the obvious solution: All
> phobos functions which allocate take an optional Allocator parameter,
> defaulting to GC. The little extra typing won't harm anyone and if you
> want to use things like stack-based buffers you'll have to write extra
> code and think about memory allocation anyway.
>
> auto gcString = toUpper("test");
> auto mallocString = toUpper!Malloc("test");
> ubtye[64] sbuf;
> auto stackString = toUpper(sbuf[], "test");
>
> What's so bad about this?

The issue here is that Phobos functions need to document whether e.g. 
they return memory that can be deallocated or not. Counterexamples would 
be returning static strings or subslices of allocations.

I'm not saying it's not solvable, but it'll take some thinking and some 
work.

> It works for most of phobos, doesn't require
> language changes and it's easy to realize what's going on when reading
> the code. Having an 'application default allocator' or 'thread local
> default allocator' or 'per function default allocator' will actually
> hide the allocation strategy and I bet it would cause issues.

I think a crack should be given to the user to install their own 
allocator (per thread and/or shared). Perhaps we can limit that to the 
startup stage, i.e. before any allocation takes place.

> So the question then is: what about language feature which allocate
> using the GC? Wouldn't we want these to work with any kind of
> allocator? Answer: no, because:
>
> This is the list of language features which allocate:
[snip]

I think you forgot AAs.

> We just have to provide everyone with a way to choose their favorite
> implementation. Which means we provide public APIs which allow any kind
> of memory allocation and internally do not rely on automatic memory
> management (internal allocation in phobos should be done on the stack/
> with malloc / made configurable, but not with a GC).

I agree that's a nice goal. But I don't think it's easily attainable. 
The "choose the allocator" part is easy. The harder is choosing the 
reclamation method. There are differences between GC and RC that are 
very difficult to unify under a common API.


Andrei