[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Jun 7 15:06:29 2001 
Subject:Re: Incremental garbage collection 
From:Jonathan L Cunningham 
Volume-ID:1010607.07 

On Wed, 6 Jun 2001 18:25:49 +0000 (UTC), Aaron.Sloman.XX@cs.bham.ac.uk
(Aaron Sloman See text for reply address) wrote:

>(b) Any incremental garbage collection process slows everything down, so
>you have to be prepared to trade overall average or total speed for
>uniformity/smoothness of performance. I think John calculated that the
>extra checking for whether an item had or had not been moved from one
>space to another which has to be done on each reference could produce an
>overall reduction in performance of up to 50%. It would also double the
>*constant* space requirement of the heap, with possible consequential
>extra paging and swapping, whereas poplog now has its "heap" allocation
>increased only for the duration of the garbage collection, which is
>typically a small fraction of the total time (partly controllable by
>popgcratio).

I'm surprised that this is what was being considered. What about an
incremental GC which merely reclaimed garbage from the heap and put
it on a free list? If you already have a compacting GC, for when the
heap gets too fragmented, then your incremental GC doesn't need to
be compacting.

And if your garbage consists entirely of, say, list cells, the heap
won't get fragmented anyway.

The overhead now (apart from the time spent running the GC) is only
on store allocation, not on access, and if I recall, there is a
free list for list cells already, so the overhead for list allocation
would be zero.

If the incremental GC ran only in idle time, it need not affect
performance at all (in an interactive, or other real-time, program),
i.e. the idle loop could be an incremental GC, which would scan
the heap for garbage and put it on a free list. As long as there
is sufficient "idle" time, there is no danger that the system would
break a hard real-time constraint.

(This doesn't help with long, compute-bound processing tasks, but
it needn't interfere with them either: since the system would not
be in the idle loop, the incremental GC would not run, and the
system would run out of heap and do a normal GC in the normal way.)

Not that it would make a noticeable difference to most users, since
the GC is usually so fast on present-day machines.

Jonathan

-- 
Jonathan L Cunningham