Re: [PATCH] Configure GMP to use GC allocation functions, remove bignum finalizers

[Andy Wingo <wingo@pobox.com>]

On Sun 27 Nov 2011 22:25, ludo@gnu.org (Ludovic Courtès) writes:

> The problem is that this measurement doesn’t allow us to differentiate
> between a growing heap with objects that may be freed as a result of
> running the GC, and a growing heap just because the application needs
> more malloc’d objects.

This is true, but typically the heap stabilizes at some point.

Here is the problem: if you are allocating at a GC-managed heap size H,
garbage collection will tend to limit your process image size to H*N.
But if at the same time you are mallocating at a rate M bytes per
GC-allocated byte, then your process stabilizes at H*N*M -- assuming
that collecting data will result in malloc'd data being freed.  It
doesn't take a very large M for this to be a bad situation.  If you
would like to limit your image size, you should GC more often -- the
bigger the M, the more often.

The original iterative factorial case that Mark gave is pessimal,
because M is an increasing function of time.

Now, what happens if the process is not growing because of GC, but for
other reasons?  In that case M will be estimated as artificially high
for a while, and so GC will happen more often on the Guile side.  But
when it stabilizes, we can ease back the GC frequency.

The key is to measure process image growth, not mallocation rate.

I'm going to give this a try and see what happens.

Andy
-- 
http://wingolog.org/