News for hackers. Stuff that matters.

A comment on Inside D's GC.

Re:Inside D's GC by dawg on Tuesday June 20, 2017 @04:28AM (#14592954)
The D language is currently heading towards deterministic and safe memory management, making it possible to avoid the GC overall, hence further work on GC improvements was deprioritized. http://dlang.org/blog/2017/06/16/life-in-the-fast-lane/

The problems are known and indeed a full rewrite on this ancient GC would be in order. Since D 2.072.0 it's possible to link and use different GCs, so a faster one could be written as an external library which would be a very welcome effort. https://dlang.org/changelog/2.072.0.html#gc-runtimeswitch-ad...

I'd be interested in experimenting with a Connectivity-Based GC (https://www.cs.purdue.edu/homes/hosking/690M/cbgc.pdf), leveraging type information to do partial collections. Write barriers come with a performance penalty (~3-5%) that we don't want to impose on people using deterministic memory management, but most GCs capable of performing partial collections, e.g. generational GCs, do require write barriers, Connectivity-Based GCs do not.

For the time being the pragmatic advise is to replace major sources of GC allocations with deterministic memory management when the GC heap grows too big (~1GB) and performance becomes a problem.

So far this hasn't prevented various people from writing extremely fast D programs.

[ Parent | on HN ]
Re:Inside D's GC by amelius on Tuesday June 20, 2017 @11:32AM (#14595377)
> The D language is currently heading towards deterministic and safe memory management, making it possible to avoid the GC overall

Is this really true?

[ Parent | on HN ]
Re:Inside D's GC by WalterBright on Tuesday June 20, 2017 @03:53PM (#14597966)
Yes. I gave a presentation on this at DConf 2017.

http://dconf.org/2017/talks/bright.html

[ Parent | on HN ]
Re:Inside D's GC by amelius on Tuesday June 20, 2017 @04:00PM (#14598039)
But is it really possible to completely avoid the GC? I'm thinking of memory blocks with cyclic references, and stuff like that.
[ Parent | on HN ]
Re:Inside D's GC by mhh__ on Tuesday June 20, 2017 @12:57PM (#14596253)
Yes, but the D community isn't structured enough to have such a specific goal. The main effort that I can think of is dip1008, which aims to add reference counted exceptions (Thus eliminating one of the few truly difficult things to get around, e.g. @nogc exceptions require user cooperation else memory gets leaked)
[ Parent | on HN ]
Re:Inside D's GC by WalterBright on Tuesday June 20, 2017 @03:55PM (#14597985)
Write barriers are cost effective with a language that makes high use of heap storage allocation, like Java. It makes a lot less sense for D, because D uses a lot of stack allocation and embedded instances instead.
[ Parent | on HN ]
Re:Inside D's GC by rbehrends on Tuesday June 20, 2017 @04:06PM (#14598091)
Write barriers (or related techniques) are also important for incremental garbage collection.
[ Parent | on HN ]