[gclist] Baker's treadmill improvments.

[James McCartney]

At 9:37 AM -0600 1/31/97, Charles Fiterman wrote:

>If the treadmill is the right algorithm for your application than you
>are right, forcing frees and finalization into idle time is wrong for you.
>But maybe there is a simple work around where atoms of collection are
>associated with various mutator actions like allocation. You reach a steady
>state by having say three atoms of collection for every allocation. Maybe
>the number can be tuned at run time by some heuristic.

Doing the increments at allocation is what I do. Determining how much
collection to do is easy to calculate. I think Paul Wilson's big
survey paper or either Johnstone & Wilson's paper on their real time
GC discuss how to calculate this. Basically it is based on the ratio
of live/free. The less free you had last GC cycle, the faster you
need to collect. It is the programmer's reponsibility not to fill
the heap to a point where the GC has to throttle way up. The GC
could post a warning if the program begins to use too much heap space.
You could fix the collection rate to keep the workload constant, but this
would mean you would do too much collection work if the heap usage was
small.


   --- james mccartney     james@clyde.as.utexas.edu   james@lcsaudio.com
If you have a PowerMac check out SuperCollider, a real time synth program:
ftp://mirror.apple.com//mirrors/Info-Mac.Archive/gst/snd/super-collider-demo.hqx