To switch GC from FIFO to LIFO paradigm.

[H. S. Teoh]

On Fri, Jan 15, 2021 at 08:19:18PM +0000, tsbockman via Digitalmars-d-learn wrote:
[...]
> However, generational GCs are somewhat closer to LIFO than what we
> have now, which does provide some performance gains under common usage
> patterns.  People have discussed adding a generational GC to D in the
> past, and I think the conclusion was that it requires pervasive write
> barriers (not the atomics kind), which leadership considers
> inappropriate for D for other reasons.

Also note that generational GCs are designed to cater to languages like
Java or C#, where almost everything is heap-allocated, so you tend to
get a lot of short-term allocations that go away after a function call
or two and become garbage.  In that context, a generational GC makes a
lot of sense: most of the garbage is in "young" objects, so putting them
in a separate generation from "older" objects helps reduces the number
of objects you need to scan.

In idiomatic D, however, by-value, stack-allocated types like structs
are generally preferred over heap-allocated classes where possible, with
the latter tending to be used more for longer-term, more persistent
objects.  So there's less short-term garbage, and it's unclear how much
improvement one might see with a generational GC.  It may not make as
big of a difference as one might expect because usage patterns differ
across languages.

(Of course, this assumes idiomatic D... if you write D in Java style
with lots of short-lived class objects, a generational GC might indeed
make a bigger difference. But you'd lose out on the speed of
stack-allocated objects.  It's unclear how this compares with modern
JVMs with JIT that optimizes away some heap allocations, though.)


T

-- 
"I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly