Linus with some good observations on garbage collection

[Iain Buclaw]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> 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

I was thinking of where one implements an alternative runtime that may not
necessarily interface with a GC, or has different semantics on the use of the
keyword (the compiler, after all, doesn't know/care what exactly 'delete' does, it
just does it's job at emitting the correct action we expect from it). Though it
was late night and I perhaps didn't quite put it right anyway.

Having literally slept on it though, a runtime with a good GC is one that doesn't
offer a choice to 'delete' memory - so I am on your side.  Though reflecting from
my experience with the D2 GC (thinking from a compiler implementers POV), there
isn't much I can really praise about it.

Custom (de)allocators I can also see a very good point for removal too, however
much a stab in the back for those who can use them in the - perhaps 'one-and-only'
- case for a small amount of speed gain.

Iain