Linus with some good observations on garbage collection

[Andrei Alexandrescu]

On 04/24/2011 08:08 PM, Iain Buclaw wrote:
> == Quote from Timon Gehr (timon.gehr at gmx.ch)'s article
>> Andrei Alexandrescu wrote:
>>> 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
>
> Is it correct that the current D GC implementation puts delete'd allocations into
> a freelist (or bucket) to be reused when 'new' is invoked again?

I don't know. If it does, an additional level of freelists only hurts.

>> Ok, lets stop. Custom allocators and delete should probably be removed from D:
>> Some of my facts:
>> * freelist is faster if most allocation and deallocation concentrates on only one
>> class. (see attachment) I think this is also the reason it increases DMDs speed.
>> Token and Scope are quite obvious bottlenecks..
>> * such bottlenecks will most of the time only be detected when development is
>> almost finished. (Almost never for library code, so I don't get why STL uses
>> custom allocators at all.)
>> * premature optimization is evil (see STL custom allocators)
>> * late optimization: it is easy if there are custom allocators. In C++ it is even
>> trivial. Nice design. Still no clue why STL is abusing it.
>> * that form of custom allocators does not play nicely with Ds Garbage collector
>> though, because it changes the semantics of 'new', ergo builtin custom allocators
>> should probably indeed be removed from D.
>> * this makes this form of optimization painful in D without custom allocators.
>> This is what I was instinctively scared about. Fact is: it is also painful with
>> them, because you don't get the 'delete's for free as in C++. I was somewhat
>> inconsiderate on this.
>> * it is possible that hinting the GC is only about twice as bad (again, see
>> attachment).
>> And some notes:
>> * the fact that you think all my points were worthless or wrong implies that you
>> either did not read all of them or have not considered them yourself when making
>> your decision. I think that is scary.
>
> I find it nuts that someone considers blaming/shunning language features just to
> mask bad runtime semantics they refuse to fix - but maybe it's just my ignorance
> on the subject that professes that view.

I'd appreciate if you provided more detail on that. Far as I can tell 
the problem is with the feature under discussion, not some alleged 
unwillingness to do work.


Andrei