[pizlonator]

Generational GC had nothing to do with moving objects. It’s possible to implement generational GC without moving anything. That’s how BDWGC, Edge’s GC, and JSC’s GC all work and there are probably others.

It’s true that those generational GCs that copy objects also sometimes use the address of the object to track the object’s generation. JSC’s GC uses a GC state byte in the object header to tell which generation an object is in.

[pcwalton]

> Generational GC had nothing to do with moving objects.

Eh, "nothing" is a strong word there. Technically you're right, but most generational GCs in practice use bump allocation in the nursery. The most common object copying occurs through minor collections, since compaction of the tenured generation is expensive and is done infrequently. So introducing generational GC in the usual way often does coincide with introducing copying.

[pizlonator]

Generational GC is a reusable concept. It’s very important for those who go to apply this concept to understand what you need to build a generational GC. My point is that you don’t need copying to do generational GC. The only thing that generational GC has to do with copying is that this is how the first generational GCs happened to be implemented and some people don’t know that there is another way, probably because people like you refuse to acknowledge that copying has nothing to do with generations.

You seem to be treating “generational GC” as a historical concept rather than an algorithmic concept. You’re right that from an historic perspective, generational GC and copying are related. But they are not technically or theoretically related.

[pcwalton]

> probably because people like you refuse to acknowledge that copying has nothing to do with generations.

Um, I'm well aware that generational GC doesn't require copying, and I mentioned this from the start. I don't even know what we're arguing about anymore.