[KMag]

> The cost of a generational garbage collector is associated with living objects, not dead ones, so manually deleting doesn’t make sense.

This is true in the context of the discussion, and in general for copying garbage collectors, but it's not always true. Copying is the most common way (and the current .NET way) to implement at least the Eden generation of generational collection, but it could be implemented in other ways.

[kkokosa]

Just as a clarification, "Copying is the most common way (and the current .NET way)" is not the case - .NET GC is generational but it does not promote through generations by copying.

[Skinney]

True. Go, for instance, does not use a generational garbage collector. I also believe that Java’s Zgc is not generational, yet.

But I find it most helpful to instead focus on the current context, otherwise I’d be spending all typing.

[KMag]

I'm talking about generational non-copying collectors (possible, but certainly not common). Examples of non-generational collectors are non sequitur. You're talking the diagonally opposite corner of the square diagram. (What's the name of those 4-part square diagrams? I forget the name of the guy they're named after.)

For instance, you could have a mark-and-sweep collector that would mark everything and then first sweep just the most recently created arena, and only do a full sweep if not enough space was freed. It wouldn't be perfectly generational unless it was also compacting, but the youngest arena might be a decent heuristic. Or, for the cost of one pointer in every object header, the GC could keep a singly linked list of the youngest generation.

I don't think it's a great idea, but you can do a non-moving generational GC if you want to interact with C/C++ without forcing pinning/un-pinning of objects (or forcing C/C++ to only interact with GC'd objects via pinned handles).