Garbage Collector

[deadalnix via Digitalmars-d]

On Wednesday, 15 June 2016 at 18:48:28 UTC, jmh530 wrote:
> On Wednesday, 15 June 2016 at 18:28:42 UTC, Edwin van Leeuwen 
> wrote:
>>
>> I think he meant that the .NET GC (and most GC designs) rely 
>> on write barriers, but D does not have write barriers, since D 
>> is meant to be a proper systems language.
>
> My reading of that LuaJIT GC document is that it requires write 
> barriers, but that they are very cheap.

Problem is, in D, many people want to NOT use a GC, and this is 
something we want to support. These people also do NOT want to 
pay for write barrier they do not use.

That being said, we can do write barrier leveraging MMU on 
immutable (it'd be too expensive to do it on mutable data) during 
collection only, so that people that do not want to use the GC do 
not pay for it. The technique is used successfully in the ML 
family of languages for ages now with great results.

Generally, I think the right path forward for D's GC is not to 
emulate managed language's GC as this clearly won't be acceptable 
for many users. On the other hand,
we should:
1/ Leverage D's type system as to get infos about 
mutability/thread locality and segregate the heap accordingly/use 
adapted technique for each.
2/ Make sure the GC can deliver malloc grade performance in an 
alloc/free scenario, as to enable hybrid approach and allow 
people to rely on the GC to the extent they are willing to pay 
for. jemalloc internal datastructures are very amendable to build 
a GC.

I started using this approach in SDC's GC. The only thing 
preventing me to move faster here is simply the time I can 
allocate to solve that problem.