Allocators in Phobos

[dsimcha]

== Quote from Steven Schveighoffer (schveiguy at yahoo.com)'s article
> On Mon, 22 Aug 2011 09:02:02 -0400, dsimcha <dsimcha at yahoo.com> wrote:
> > On 8/22/2011 7:07 AM, Steven Schveighoffer wrote:
> >> Take a look at dcollections' chunk allocator, which is under boost
> >> license. It implements a free list + efficient allocation/deallocation
> >> by dividing up a large block. It might be a fit for this, or at least a
> >> starting point.
> >>
> >> One difference from this allocator vs. the generic ones you are
> >> implementing is that it's templated on the type being allocated. It's
> >> intended to be used for a collection, which only allocates one type (a
> >> node). Does this kind of thinking belong in phobos? I'm not sure. But I
> >> think we can at least reuse the free list implementation.
> >>
> >>
http://www.dsource.org/projects/dcollections/browser/branches/d2/dcollections/DefaultAllocator.d#L41
> >>
> >
> > Hmm, your chunk allocator looks like a generalization of
> > FreeListAllocator.  If I get around to implementing FreeListAllocator,
> > I'll add support for allocating chunks instead of one element per heap
> > allocation.
> Well, I think the GC already uses free lists...  What would be the point
> of one on top of that, especially if the "block size" is constant?
> https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gcx.d#L505
> https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gcx.d#L927
> -Steve

They'd be thread-local, that's the main advantage.  W.r.t. your other post, it
would make sense to do it on top of the GC, because the free lists would be
completely thread-local.  Allocating would never require any synchronization as
long as there's a node on the free list and freeing would never require require
synchronization, period.