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.
