Linus with some good observations on garbage collection

[Andrei Alexandrescu]

On 04/24/2011 01:21 PM, Timon Gehr wrote:
> 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.

A class-specific freelist-based allocator in fact stands in the way of a 
good general-purpose allocator. At Facebook we did extensive 
measurements on a variety of applications and workloads and the best 
approach was to just disable all STL class-specific allocators (by 
defining GLIBCXX_FORCE_NEW) and let jemalloc take care of all 
allocations, to great effect.

Today's good general-purpose allocators are as good or usually 
considerably better than custom allocators. The one category of custom 
allocators that is still significantly better are regions, but they have 
quite specific and restricted semantics.

> 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

It is much better in very many ways, in particular in D. For one simple 
argument, consider:

auto obj = new Widget;

Simple modularity considerations would require this operator to have 
semantics independent of Widget, such that modular and generic code can 
use it properly. Custom class allocators ruin all that, because they 
would require the use of delete paired with new, whereas the general 
operator requires no action.

Memory allocation and object construction are difficult topics, 
particularly in high-performance settings. A seasoned engineer 
understands that and does not naively believe that a smattering of 
well-intended but very badly executed language support will make that 
all easier. (Contrast that with e.g. reference counting semantics using 
RAII, which relies on a much better part of the language and does offer 
reasonable guarantees.)

I am sorry, you simply have no case - each and every argument you put 
forth has no strength or is just wrong. We could spend time on debating 
each, but I suspect that would do little toward convincing you of what 
is after all a simple fact, but one with many subtle facets. It might 
not a good use of our time to further engage in a diatribe on this. The 
delete keyword will go, as will class-specific new and delete.


Andrei