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