== Quote from Steven Schveighoffer ([email protected])'s article > On Mon, 22 Aug 2011 09:02:02 -0400, dsimcha <[email protected]> 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.
