[gclist] trigger minor or major (generational) gc?

[Pekka P. Pirinen]

> 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.

Sounds plausible.

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
application.

> 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