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