GC cleans memory using the FIFO paradigm. Is it possible to switch GC to work using the LIFO paradigm?

On 1/15/21 7:39 AM, MGW wrote:
> GC cleans memory using the FIFO paradigm. Is it possible to switch GC to work using the LIFO paradigm?

I'm not sure what you mean. I don't think there's any guaranteed order for GC cleanup.

-Steve

On Friday, 15 January 2021 at 12:39:30 UTC, MGW wrote:
> GC cleans memory using the FIFO paradigm. Is it possible to switch GC to work using the LIFO paradigm?

AFAIK the GC just sweeps, and the only queue is for destructors (unreachable memory) iirc

On Friday, 15 January 2021 at 12:39:30 UTC, MGW wrote:
> GC cleans memory using the FIFO paradigm. Is it possible to switch GC to work using the LIFO paradigm?

As others already said, the current GC isn't FIFO; it just scans everything once in a while a frees whatever it can, new or old.

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.

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