Dan Sugalski <[EMAIL PROTECTED]> wrote:
Having all the objects of a generation in a single pool does make life significantly easier, to be sure, but you don't need to have the objects *themselves* in a single pool -- just have a quick way to identify all the objects in a generation. We could do that with a separate generation pool if we wanted, at the cost of a pointer per PMC plus overhead for the pool segmentation, much the way that we have the freelist for PMCs.
The freelist is located inside of unused PMCs, it doesn't take up extra memory. An additional generation pointer needs additional memory. For changing the generations a double linked list could be necessary.
The freelist used to be an array that held free PMC pointers. I presume this changed?
> Might ultimately be untenable, of course. On the other hand, the codeinfrastructure and APIs needed for a generational collector are the same as the ones for incremental and concurrent collectors, so we may well just jump to an incremental collector instead if it turns out to be more worthwhile or less hassle.
Incremental collectors are generally slower, but can provide RT capabilities. The stopping-the-world time is bounded. Generational GCs have a signifant overhead too, but depending on workload, this can be outweighed by not scanning old generation pools each time.
The not scanning part is where generational GC systems get their wins. Properly done (depending on workload) a generational system will have less gc overhead because it does less work.
We can achieve a similar effect without much overhead, by remembering a previous-live-objects-count per arena and skip "almost all live arenas" each second time or so.
Well... maybe. I'm not sure we can, since those arenas need to be looked at for pointers to other arenas. If you work around that then you *have* a generational collector.
But anyway, we don't need[1] different schemes for PMCs: The copying collection of variable sized Buffer memory is the problem for multi-threading.
No, it isn't. For several reasons, not the least of it is the fact that we're going to have to shift to a non-copying collector in the threaded case. The bigger problem is tracing the live set in the face of multiple simultaneous mutators, which the incremental gc systems handle much more pleasantly and with less overall impact on the system.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
