std.allocator: plea for contributions

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Mon May 11 12:41:35 PDT 2015


As some might have inferred from my recent posts, there is good progress 
on std.allocator.

I have come to think that this is going to be significant. This is hard 
to put in words but I'm sure many others understand the feeling of 
having found the "right" design, where all parts seems to fit and add to 
a greater whole.

Worst case, std.allocator will be a reasonable collection of today's 
typical patterns in memory allocation, and an obscure library available 
to D users. Best case, it will be a zeitgeist of today's thinking about 
memory allocation, a compelling reason to use D, and a compelling reason 
to link applications written in other languages with D.

Code in the dedicated branch in my repo 
(https://github.com/andralex/phobos/tree/allocator/std/experimental/allocator) 
has gotten near 9KLOC. At this size, any significant work by one person 
requires quite a bit of maneuvering, which slows me down.

It would be great if I could get some help with this on one specific 
topic that is parallelizable: test coverage. Running

make BUILD=debug std/experimental/allocator.test

produces a bunch of .lst files in the current directory that show which 
code is covered (or not). Pull requests that increase test coverage 
would be of great help to the project. They're also a meaningful way to 
get into std.allocator and learn about memory allocation techniques for 
anyone interested.

There's another, more advanced, topic: defining a SharedFreeTree, i.e. a 
thread-shared version of 
https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/free_tree.d. 
If a lock-free or almost-lock-free abstraction could be defined for 
that, then we'd have at our disposal a battery of adaptable freelists 
that we can front the standard GC allocator with, to great effect.

There is of course the matter of better documentation, but as I'm 
working actively on it please hold off on that for now.

So, to any and all who'd want to contribute - fork that branch, get it 
working, and send me PRs for it!


Thanks,

Andrei


More information about the Digitalmars-d mailing list