Linus with some good observations on garbage collection

[Timon Gehr]

Andrei Alexandrescu wrote:
> The point is that some naively believe "new" and "delete" are some
> simple do and undo actions and as such they somehow deserve the same
> level of support. In reality they have dramatically different issues and
> are profoundly asymmetric.


> The class-specific allocators are an exceedingly bad design carried over
> from C++. They will be deprecated from D as well.

Does that imply that the feature is going away after all?

> Even C++, where the features you are talking about have existed for many
> years, is shunning their use. Good applications make very sparingly use
> of "delete" and virtually none uses class-specific allocators.
> Experience with C++ is the best proof that the delete keyword and
> class-specific allocators have no place in the D programming language.
>
>
> Andrei

Virtually no good application uses them? The _DMD compiler implementation_ uses
them. Classes 'Token' and 'Scope' have class-specific optimized allocators. I
don't think Walter would have done that if it did not give quite good benefits. D
is a systems programming language after all. It is not Java or some scripting
language. I don't think D should/can get rid of class-specific allocators if there
is no good alternative for sane uses. Even if they are not used often and should
not be used often.

C++ is not garbage collected by default. Implementing a GC root class for example
is another legitimate use case for class-specific allocators. In D, things are
somewhat reverse, class-specific allocators would be used for manual memory
management. D should support that.

So if class-specific allocators go away, what is the alternative? Sure, it is
always possible to allocate using custom functions (for D structs, at least.) But
then, if allocations of one struct/class turn out to be a bottleneck somewhere
late in the development, the whole code will have to be changed instead of just
the addition of some simple custom class-specific allocator. (This is even worse
when developing a library). Also, just testing the impact of a custom allocator
will be a pain for the same reason. Why is that better?


Timon