GC behavior and Allocators

safety0ff via Digitalmars-d digitalmars-d at puremagic.com
Thu Jul 3 15:06:10 PDT 2014


On Thursday, 3 July 2014 at 21:53:25 UTC, Brian Schott wrote:
> I think that the only sane way to solve this is to define in 
> the specs for core.memory that GC.addRange will only ever store 
> one entry per pointer, and that the length will be the value of 
> "sz" from the most recent call to addRange.
>
> Thoughts?

Easy to change the behaviour of the 2.066 GC, just force update 
instead of ignoring duplicates:
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/util/container/treap.d#L138

I feel there are instances where core.memory is underspecified.
When I was implementing the update for addRange from array to 
treap it was considered "undefined behaviour" to addRange twice 
with the same base pointer without first removeRange'ing the 
second. That's why the code currently ignores dups.

Boehm GC on the other hand uses an array similar to the previous 
version of the D2 GC, except that it has code for properly 
merging duplicates (this has performance implications though.)

Please keep sharing your insight into practical use of these 
APIs. :)


More information about the Digitalmars-d mailing list