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. > Might ultimately be untenable, of course. On the other hand, the code > infrastructure 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. 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. 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. We can configure with --gc=libc or --gc=malloc but we have to be sure, that either the system malloc is fast enough or that the supplied malloc.c is portable and thread-safe. The latter isn't the case for the LEA implementation. [1] experiments, patches, benchmarks are always welcome of course leo
