[Issue 18441] New: Add comments to GC page about tradeoffs in design and impl of GC (garbage collector)
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Thu Feb 15 07:08:01 UTC 2018
https://issues.dlang.org/show_bug.cgi?id=18441
Issue ID: 18441
Summary: Add comments to GC page about tradeoffs in design and
impl of GC (garbage collector)
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: dlang.org
Assignee: nobody at puremagic.com
Reporter: jgabriele at fastmail.fm
I regularly hear complaints online about D's GC being slow or not decent, but
those complaints rarely include details.
I've twice seen Walter explain some tradeoffs that were made in the design and
implementation of the D GC. [One was on the forum]. [Another on reddit], where
he wrote:
"You can make a moving GC with D, it's called a "mostly copying" collector. The
trick is to not move things that may have a pointer to them."
and
"Certain GCs instrument the generated code with write gates which notify the GC
when memory writes are being made. GC-focused languages rely on this to make
the GC better, at the cost of lower performance in the native code.
D has a GC, but is not a GC focused language. The performance cost of write
gates is an unacceptable compromise in the context of D."
***
The [D GC page](https://dlang.org/spec/garbage.html) may need a section
describing these tradeoffs that were made in the design and implementation of
the GC so people can easily see why it is the way it is. That may help avoid
regurgitated complaints of "it's too slow" and provide a link to point those
folks to.
[One was on the forum]:
https://forum.dlang.org/post/p5i3j9$1uv6$1@digitalmars.com
[Another on reddit]:
https://www.reddit.com/r/programming/comments/7xih66/the_expressive_c17_coding_challenge_in_d/
--
More information about the Digitalmars-d-bugs
mailing list