On Sun 27 Nov 2011 22:25, l...@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/
