Earlier quoted context omitted.
> 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 oth…
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.
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).