[gclist] Baker's treadmill improvments.

[James McCartney]

At 2:15 PM +0000 1/31/97, Nick Barnes wrote:
>> At 09:55 AM 1/31/97 +0000, you wrote:
>> >> First applications that use the treadmill will be giving the collector
>> >> atoms of time when they are idle. This more than fills the collectors
>> >> needs for time and can be used to finalize and free objects instead of
>> >> having that work done when a header is needed.
>> >
>> >Many applications are never idle, or need to be able to run for hours
>> >or days at a time with no idle time. Should these applications not use
>> >the treadmill?
>>
>> Thats right. The treadmill trades lots of efficiency for extreme incremental
>> behavior where the largest collector delay is very small. If you don't need
>> that you are being very silly to use the treadmill.
>
>What if you do need that, and yet are never idle (or may run for hours
>without idle time)? The two are completely orthogonal.

No its not right. Programs which are never idle can use the treadmill
just fine. Its great for programs like mine which do need extreme
incremental behaviour. Audio processing does not tolerate a delay.
If an incremental GC does its work correctly it should not need to
use idle time to catch up. Idle time should be used to service other
threads.

The array implementation of the treadmill which I presented does not
have the finalization problem he mentions because all free objects
have an index >= the allocate index. Even the original algorithm
doesn't have the color problem with finalization that he mentions because
at the flip time it is easy to check the colors of objects which need
finalization. All newly freed objects are white. Only objects which have
been on the free list from previous cycles are multicolored.


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