[gclist] When to collect.

Hans-Martin Mosner hmm@heeg.de
Thu, 20 Nov 1997 10:28:31 +0100


Charles Fiterman wrote:
> 
> The problem is what I call the collect or expand
> decision. Given a request that can't be filled
> without expand or collect which do I do.
> 
> I don't like any of the current algorithms and
> are trying to rethink from scratch.
> 
> First the idea is not to get by with as little
> memory as you can but to use as much as won't
> trigger paging. This simple program shows what
> I mean.
[...]
> This suggests that the system administrator suggest a top size.
> Collect or expand would prefer expand until this was reached.
> Then timeing would say if we are spending more than X% of our
> time in collect, expand otherwise collect. X should be substantial
> as exceeding the limit triggers paging which will be worse.
> 
> This has another advantage. Overhead in a conservative collector
> divides into three parts. Scaning, zeroing and allocation. All
> these tend to be tightly optomized. Keeping statistics on what
> was allocated since the last collection slows down allocation.
> 

The VisualWorks Smalltalk implementation has user-settable parameters
that decide when to expand versus collect, based on the total allocated
space. When the parameter is set to keep memory within physical memory
bounds allowable for the process, it behaves very nicely.
What the system does not automatically is to find out which memory size
is optimal. Our experience has been that for a given application on
given hardware, it is quite reasonable to set a fixed value.

Everybody interested in how a flexible garbage collector hierarchy can
be done should have a look at VisualWorks' ObjectMemory and MemoryPolicy
classes. Almost everything is run from within the Smalltalk application,
making it very malleable in case you need to (The only exception is the
newspace scavenger, which runs automatically).

The total effect is similar to that reported for Lisp Machines: I can
have my VisualWorks images running for weeks without getting into
thrashing behavior. And this is not just an application, it's a complete
development environment with all kinds of deleopment artifacts being
created and garbage collected all the time...

Hans-Martin