www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.allocator: plea for contributions

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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/al
ocator/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
May 11 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
Tried to, couldn't get it to compile with git HEAD. Could you 
please post the dmd and druntime git hashes, or are those forks 
as well?

Atila

On Monday, 11 May 2015 at 19:41:36 UTC, Andrei Alexandrescu wrote:

 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/al
ocator/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
May 13 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/13/15 2:19 PM, Atila Neves wrote:

 Tried to, couldn't get it to compile with git HEAD. Could you please
 post the dmd and druntime git hashes, or are those forks as well?


Thanks for looking into it! Here's what I have:

dmd - acbe13ee54e024c0bba044d1146e244a5ea57502
druntime - 18d57ffe3eed8674ca2052656bb3f410084379f6

I haven't rebased phobos in a while, maybe that's the matter. What 
errors are you getting?


Thanks,

Andrei
May 14 2015
parent "Atila Neves" <atila.neves gmail.com> writes:
On Thursday, 14 May 2015 at 19:07:51 UTC, Andrei Alexandrescu 
wrote:

 On 5/13/15 2:19 PM, Atila Neves wrote:

 Tried to, couldn't get it to compile with git HEAD. Could you 
 please
 post the dmd and druntime git hashes, or are those forks as 
 well?


 Thanks for looking into it! Here's what I have:

 dmd - acbe13ee54e024c0bba044d1146e244a5ea57502
 druntime - 18d57ffe3eed8674ca2052656bb3f410084379f6

 I haven't rebased phobos in a while, maybe that's the matter. 
 What errors are you getting?


 Thanks,

 Andrei


Things like (snipped):

std/concurrency.d(1402): Error: 
'core.sync.condition.Condition.mutex' is not nothrow

std/regex/internal/parser.d(1159): Error: struct 
std.uni.InversionList!(GcPolicy).InversionList member add is not 
accessible from module parser

I checked out the hashes you gave but still got similar errors.

Atila
May 17 2015