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.
