[gclist] GC triggering strategies

[Paul R. Wilson]

>From majordom@iecc.com Tue Mar 19 13:24:17 1996
>Subject: Re: [gclist] GC triggering strategies
>Precedence: bulk
>
>> > Anybody know of others?
>> 
>> Well, you can give the user a procedure to call, which means "Now is a
>> good time."  Perhaps with a parameter saying *how* good.  Seems like a
>> better approach than totally automatic systems with fancy heuristics.
>
>The best time to collect is when the mutator is idle and waiting.
>
>We have a 
>  gcAttemptCollection(gcIdleFunction funptr);
>
>This is meant to be called when the calling program is waiting for
>an event. If there was a reasonable amount of allocation since the
>last collection a collection is started. It various points the
>passed function is called. It should return a 1 if the calling
>program has no work and a 1 if something like a key press or a
>mouse click has happened. The caller determines what that is.
>
>We find this usually completes in the real world.

Yes, I should have mentioned this.  That's one of the things my Opportunistic
GC did, and it turned out others had done something similar before.

At least one version of Interlisp did this.  Oddly, it was a deferred reference
counting GC, and the main effect was to do the recursive freeing all
at once when the user didn't mind.  (This moved the overhead from the
compute time to the pause time, which was all to the good.  Later versions
of Interlisp used better GC's; I don't know if they were opportunistic.)

Our scheme was hooked to the read-eval-print loop by default.  It tended
to GC at the ends of computational pauses, "hiding" the GC pause in
the computation.  (This avoided pauses during typing, i.e., during
"read" in our system.  It was a fairly simple Scheme system.)

I also fiddled with a version that attempted to hide GC's in the user's
pauses.  Rather than GC'ing immediately when waiting for user input, it
would pause to see if the user would respond.   It would wait, and if the
user didn't respond for "a while", it would try to sneak a quick small-scale
GC.  If the user paused long enough, it would try to sneak a GC of more
generations.  This can be viewed as a generalization of Ungar's strategy
of trying to put off full GC's until the system is idle, with a relativized
notion of "idle" for a system with more generations.

This seemed to work great, but since I was the only serious user of our
system, and the system was small, I didn't think it would be very persuasive
data.  (I thought about making analytic argument from published distributions
of user pause times for some non-GC'd systems, but never got around to it.)