[gclist] trigger minor or major (generational) gc?
Pekka P. Pirinen
Tue, 29 Jun 1999 19:31:17 +0100
> The middle GC also condemns some (the older half) the the young
> regions, forwarding objects in them into the old generation.
Two buckets in the middle generation, that's nice. Try condemning the
nursery (birth region) at the same time: it'll be mostly dead, and
otherwise you'll probably end up scanning all those dead objects.
> The minor GC is called when the birth region is full.
> ask for a middle GC if the young space grews by more than 2 regions,
> and ask a major GC if the old space grew by more than 3 regions.
Since you do have a target application (unlike us language
implementors), you probably have the opportunity to tune the
parameters by trial and error -- there is no substitute for that.
The most important parameter is probably the size of the birth region,
since minor GCs do most of the work. Pick a plausible size and then
try four times that: if you can afford the memory, it pays to delay.
In higher generations, delaying can increase the cost of low
generation collections. Even so, if there's a lot of long-lived data
that even a major GC doesn't usually reclaim, major GCs should
probably be delayed as much as possible. It really depends on your
> The application could explicitly ask for such a GC in some
> critical points.
This can be useful: The application certainly knows more about the
future. But put in some checks that the application can't make the
collector thrash, especially if other, less GC-aware programmers are
going to be modifying it.
Pekka P. Pirinen
Adaptive Memory Management Team
Harlequin Group plc