What happens as objects are eventually removed from an older-generation
space?
Presumably some explicit compaction has to happen _somewhere_.
I think older generations are compacted when they're collected too.
They're just not collected as often.
.NET achieves the same thing simply by putting compaction off until it's
really needed.
I don't think it does. Everything i've read makes me think that .NET uses
a compacting generational collector, like every other advanced GC.
In .NET, the memory manager simply keeps track of the boundary between
the generations (if I recall correctly, the current implementation has
just two generations: young and old). Either generation can become
fragmented, but what normally happens is that at the same time the young
generation is collected, anything left winds up in the old generation by
virtue of the boundary pointer being moved. So the old generation
inherits whatever fragmentation existed in the young generation.
Yeah, this sounds really, really wrong. Could you by any chance cite some
references on this?
Certainly there's an automatic compaction that would occur if references
actually are _copied_ from one generation to another, but that comes at
a cost: the memory manager is effectively required to compact with
_every_ collection that updates the generations (and presumably that's
every collection?). And no matter when compaction is happening (during
all collections or less frequently, on an "as-needed" basis), it's
expensive both because of all the data that has to be touched, and
because it requires threads to be suspended so that their references can
all be updated.
The key thing is that you're only doing this frequently to the
nursery/eden/zero generation, which is relatively small, and contains few
live objects, so the amount of copying and pointer updating is also fairly
small. Plus, the majority of references to objects in that generation are
from other objects in that generation (or so says the generational
hypothesis), so you can update them while you're copying them, almost for
free. You also have to update the roots, of course, but that's fairly
cache-friendly; the point is that you won't have to do much to the older
generations.
As for stopping threads - there are tricks to do some of this stuff
without having to stop the rest of the world. It's called concurrent
collection, and i have absolutely no idea how it works.
Now, the reason for doing all this is simple: most objects die young.
Like, seriously, >90% of objects are dead when their first collection
comes round. If you actually did use your move-the-border-don't-compact
strategy, what you'd be annexing to the older generation would be mostly
garbage. It would grow like mad, you'd run out of memory, and then you'd
have to do a painful full collection. Whereas if you compacted when
promoting objects from the nursery, the rate of growth would be
dramatically smaller, and you'd have to do a full collection far less
often.
Indeed, i'm not sure how just moving the boundary pointer constitutes
garbage collection at all: you find your roots, you sweep the live
objects, you mark them, and then ... what? Do nothing with that
information? Just move live objects and garbage together into the next
generation? How does that collect any garbage?
tom
--
Imagine a city where graffiti wasn't illegal, a city where everybody
could draw wherever they liked. Where every street was awash with a
million colours and little phrases. Where standing at a bus stop was never
boring. A city that felt like a living breathing thing which belonged to
everybody, not just the estate agents and barons of big business. Imagine
a city like that and stop leaning against the wall - it's wet. -- Banksy
)