What's the go with the GC these days?

Radu void at null.pt
Mon Jan 7 08:10:24 UTC 2019


On Saturday, 5 January 2019 at 22:05:19 UTC, Manu wrote:
> I'm somewhere between a light GC user and a @nogc user, and I 
> don't really know much about where we're at, or much about 
> start-of-the-art GC in general.
>
> I read comments like this: 
> https://www.reddit.com/r/programming/comments/acsg61/version_20840_of_dmd_the_d_reference_compiler_has/edbhgzi
>
> """
> And so we do nothing and D continues to languish as every 
> thread is
> filled with discussion about a poor implementation of a sorely
> outdated GC? Other languages in this domain get by just fine - 
> Go and
> Nim to name some off the top of my head (with the full 
> disclosure that
> the former isn't quite D performance and Nim uses a 
> thread-local GC).
> There are C / C++ libraries that provide a better GC. D's 
> tradeoff is
> basically having one of the worst GCs of any language I've used 
> this
> century to avoid a write barrier that causes a, what, 5%
> nigh-deterministic overall reduction in performance (assuming 
> we use
> fast barriers out of a cycle).
>
> And if a reasonably performant GC is fundamentally incompatible 
> and
> you think it will always be this way, then maybe D as a 
> language needs
> to make serious re-evaluations? D keeps saying "Don't Fear the
> Reaper", but D is one of the only languages where I actually do.
> """
>
> How much truth is in here?
> What is this business about write barriers making the GC fast? 
> Is that
> actually fact, or are there other hurdles?
>
> Is the claim that write-barriers generally slow your runtime
> performance significant? And if it is, is it 
> possible/reasonable to
> control the places where they are emit?
> Can @nogc be used to inhibit write barriers in code that we know
> doesn't interact with the GC, such that we have control over 
> that loss
> of perf?
>
> It's obvious that the quality of the GC implementation is a 
> mental barrier to entry for many... and D has a GC, which is 
> *attractive* to some users. Despite the fact that I don't care 
> about the GC much personally, we do need to care about this as 
> a group, and nobody seems to be making substantial progress.
>
> Is progress possible, or is the hard reality that the language 
> is just designed such to be resistant to a quality GC, while 
> the ecosystem sadly tends to rely on it?
>
> Where's the ARC stuff? What happened to opAddRef/opRelease?

There is this article [1] which covers some of the details and 
opportunities to get the D GC in a better shape.

For a while improvements on GC front were slow, I see that lately 
Rainer has submitted some PRs [2] for getting various GC issues 
sorted. My favorite one is the new precise GC [3].

I think a big improvement would be the use of thread local heaps 
and GC. But this requires a rethink of `shared`, which would be 
nice to be done anyhow.

1 - 
https://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html
2 - 
https://github.com/dlang/druntime/commits?author=rainers&since=2018-12-1&until=2019-01-07
3 - https://github.com/dlang/druntime/pull/2418


More information about the Digitalmars-d mailing list