• MGW (2/2) Jan 15 2021 GC cleans memory using the FIFO paradigm. Is it possible to
• Steven Schveighoffer (4/6) Jan 15 2021 I'm not sure what you mean. I don't think there's any guaranteed order
• Imperatorn (3/5) Jan 15 2021 AFAIK the GC just sweeps, and the only queue is for destructors
• tsbockman (9/11) Jan 15 2021 As others already said, the current GC isn't FIFO; it just scans
• H. S. Teoh (24/30) Jan 15 2021 Also note that generational GCs are designed to cater to languages like

MGW <mgw yandex.ru> writes:

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

Steven Schveighoffer <schveiguy gmail.com> writes:

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

Imperatorn <johan_forsberg_86 hotmail.com> writes:

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

tsbockman <thomas.bockman gmail.com> writes:

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.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

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

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