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 <mfl...@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 > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
