[racket] garbage collection and process idling

I thought I saw a thread devoted to calling collect-garbage
periodically, when I browsed the web-server code before ... but I
can't seem to find it again now.

> Eventually, we should improve the collector (or replace it with a
> better one) to support incremental collection.

My recent (albeit limited) experience suggests this would be very
helpful. There are applications where it would be preferable to take
more frequent, shorter, and more-similar-duration hits. Even if there
were a trade-off that the total GC time were somewhat higher.

Instead of

...x...x.....x............xxxxx...xxxxxxxxx.................x...x.....x...x....x...x

More like

...x...x....xx....x...x...x....xx...xx....x...x......x...x...x...x.....x....x..x...x.x

(I didn't carefully count the Xs, but pretend both have the same, or
actually the latter has slightly more. And notice I'm NOT proposing
the latter Xs are exactly evenly spaced. Just much more evenly.)

In other words optimize for consistency and predictability, not solely
for speed. Ideally allow that optimization balance to be chosen at
runtime: How lumpy would you like your GCd potatoes.

On Sat, Oct 16, 2010 at 9:24 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> At Sat, 16 Oct 2010 13:40:43 -0400, Neil Van Dyke wrote:
>> Any thoughts on how, by default, timing of garbage collection cycles is
>> affected by whether the process is "idle".
>>
>> For example, if non-GC threads are all waiting on events, might the
>> thread with GC be more likely to trigger a GC at that idle time, rather
>> than when some threads are working?
>
> No.
>
> Eventually, we should improve the collector (or replace it with a
> better one) to support incremental collection. Then, it would be easy
> to use idle CPUs for GC work. Currently, though, if a GC is started,
> then the GC has to complete before anything else can happen, so a GC is
> triggered only by memory demand or explicit request.
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users
>