Analysis of D GC

Dmitry Olshansky via Digitalmars-d digitalmars-d at puremagic.com
Sat Jun 24 11:12:43 PDT 2017


On Saturday, 24 June 2017 at 15:31:21 UTC, Martin Nowak wrote:
> On Monday, 19 June 2017 at 22:35:42 UTC, Dmitry Olshansky wrote:
>> My take on D's GC problem, also spoiler - I'm going to build a 
>> new one soonish.
>>
>> http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html
>>
>> ---
>> Dmitry Olshansky
>
> FYI, we've tried to improve the binary pool search, but there 
> aren't many pools and it's quite hard to beat.
> A hashtable for a pages in the address range is too big.

Doesn't have to be for pages. Pool granularity is 256k, aligning 
the pools at this boundary is enough. On x64 pool granularity 
could be enlarged.


> I'd like to replace all of those separate pools types with a 
> single page heap, similar to what TCMalloc is using.
> http://goog-perftools.sourceforge.net/doc/tcmalloc.html
> http://jamesgolick.com/2013/5/19/how-tcmalloc-works.html
>

I still think that separate pool types is better, see eg jemalloc.




More information about the Digitalmars-d mailing list