www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - To switch GC from FIFO to LIFO paradigm.

reply MGW <mgw yandex.ru> writes:
GC cleans memory using the FIFO paradigm. Is it possible to 
switch GC to work using the LIFO paradigm?
Jan 15
next sibling parent 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
Jan 15
prev sibling next sibling parent 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
Jan 15
prev sibling parent reply 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.
Jan 15
parent "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
Jan 15