On 2/11/14, 6:32 AM, Jakob Ovrum wrote:
On Tuesday, 11 February 2014 at 10:29:58 UTC, thedeemon wrote:
On Tuesday, 11 February 2014 at 04:36:28 UTC, Adam Wilson wrote:
The GC itself is an orthogonal issue to the compiler. The way I see
it, once the compiler can output precise information about the heap,
stack, and registers, you can build any GC you want without the
compiler requiring any knowledge of the GC.
If you want a fast GC it needs to be generational, i.e. most of the
times scan just a portion of heap where young objects live (because
most objects die young), not scan whole heap each time (as in current
D GC). However in a mutable language that young/old generation split
usually requires write barriers: compiler must emit code differently:
each time a pointer field of a heap object is mutated it must check
whether it's a link from old gen to young gen and remember that link
(or just mark the page for scanning). So to have a generational GC in
a mutable language you need to change the codegen as well. At least
this is how most mature GCs work.
D code has different allocation patterns from Java and C#. In idiomatic
D, young GC-allocated objects are probably much fewer.
I agree this is a good hypothesis (without having measured). My
suspicion is a good GC for D is different from a good GC for Java or C#.
Andrei
