[gclist] The old container problem

[Nick Barnes]

At 1998-09-21 16:26:51 UT, David Gadbois writes:

> 2. Allocate the containers in a special "pre-natal" area that is
>    younger than the youngest normal generation.  Collect this area by
>    doing a straight non-generational GC at fairly infrequent
>    intervals.  The downsides to this approach are that it requires
>    what amounts to an extra, special-purpose collector and that it
>    complicates already fragile storage system invariants.

Something like this is a good technique if your collector is
sufficiently flexible to make it possible.  You shouldn't have to have
an extra collector; in particular note that collection policy (when
and how often a given part of the heap is collected), promotion policy
(when and whether parts of the heap are promoted to older
generations), and maintaining graph invariants are theoretically
independent of each other, and a good GC will offer the client total
control over the first two, while having a number of approaches to the
last.

In other words, the mutator should be able to say dynamically "give me
a new allocator whose objects are never promoted and infrequently
collected", and that would do the job.  If you want to help the GC
along even further, you could add "by the way, these objects are going
to be a rich source of inter-generational pointers", but the GC could
learn that for itself without difficulty.

This isn't rocket science; I suggest that all GC implementors consider
how best to achieve this sort of flexibility.  Hard-wiring collection
and promotion policies is as unnecessary and inflexible as hard-wiring
the number of generations or the maximum heap size.

Nick B