[Gc] PRINT_STATS kind, and free_space_divisor

Boehm, Hans hans.boehm at hp.com
Mon Nov 22 15:35:22 PST 2004

I think this is a bit better in 7.0alpha1, since the meaning of
GC_free_space_divisor changed.  It's now a fraction of 
2*pointer-containing-live + pointer-free-live + roots
instead of the heap size.  (This was always the goal.  But
the old algorithm didn't normally compute live data sizes.)

This avoids some instability due to changes in fragmentation.

This should make a value of one usable with a stable heap size.
And I think a value of 2 will behave much better than it does now.

It may still be a good idea to scale the value, but I'm not
sure it will be necessary anymore.

I'm trying to avoid fp computation in critical places in the collector,
to deal with (embedded?) processors without an fpu.  I have no idea
whether that's a useful goal or not.


> -----Original Message-----
> From: Bruce Hoult [mailto:bruce.hoult at gmail.com]
> Sent: Monday, November 22, 2004 3:07 PM
> To: Boehm, Hans
> Cc: gc at napali.hpl.hp.com
> Subject: Re: [Gc] PRINT_STATS kind, and free_space_divisor
> On Mon, 22 Nov 2004 10:37:10 -0800, Boehm, Hans 
> <hans.boehm at hp.com> wrote:
> > A large free_space_divisor setting will have the effect you 
> describe.
> Just a thought for the future.
> I've found consistently for a number of years, on everything from 200
> MHz to 3+ GHz machines, that the Gwydion Dylan compiler and generated
> programs run the fastest with as large a free_space_divisor as
> possible.  I know some people are more RAM-constrained but I always
> set the divisor to 2, which results in d2c compiling itself getting up
> to about 100 - 120 MB peak instead of as little as 60 MB (but much
> much slower) with a higher divisor setting.
> The problem is that the settings are *very* coarse at that end of the
> scale.  The jump from 3 to 2 is huge, and 1 means "never GC at all". 
> It would be really nice to have more intermediate settings at that end
> of the scale, perhaps a float instead of an integer?  Or maybe
> introduce an integer scaling factor, so that 2 or 3 becomes 20 or 30?
> (or a binary scaling factor...)

More information about the Gc mailing list