Disadvantages of ARC

[Johannes Pfau]

Am Thu, 06 Feb 2014 08:40:28 -0800
schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:

> >
> > 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.

That's true. I wonder how common these cases are but slices are
probably the bigger problem here. (OTOH if a function just slices the
input, we'd have to document it but there's no bigger issue)

> > [...] 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.

If we can make that work then I won't complain. As long as the default
allocator can't be changed at random a point in time most problems
should be solved for a global default allocator.
For per-thread allocators this is difficult: If you allocate in one
thread and free in another how do you make sure you use the correct free
function?

There are some interesting possibilities though: For example we could
add a delegate to object which points to the correct 'free' function.
But then things get complicated if we have to manage the lifetime of the
allocator as well....

> > This is the list of language features which allocate:
> [snip]
> 
> I think you forgot AAs.

I had AA literals in the list, but you're right some other AA features
allocate as well. Good you mentioned that, I'll have to detect these
cases in -nogc/-vgc code as well...

However, from a user point of view dcollections (and I hope at some
point std.container as well) provides a nice replacement for all these
operations, except for literals.

> 
> > 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.
> 

I'd guess that allocation is actually a bigger issue for those who
are unhappy with the GC right now, but I have no way to prove that ;-)
(Explicit manual freeing is annoying, but possible. But if a function
internally allocates with the GC it can't be used at all).

But you're of course right, getting reclamation right is probably more
difficult and also important.