Hi, I recently poked some GC-related things in stable-2.0 and master.
One change was to make GC run more often when a process is growing, in terms of resident memory size. This seems to be a good idea in general. The other was to add a function that users can call to note non-gc-managed allocations -- allocations that may be freed when GC is run, but which the GC doesn't know about. That is scm_gc_register_allocation. This routine runs GC after allocated bytes exceed some limit, currently the GC-managed heap size, reset after every GC. This is to catch steady-state mallocation. We cannot deal well with steady-state mallocation, unknown to the GC. If the ratio between unknown and known allocation is small enough, the process image size won't grow too badly. But if it is large, your process will grow quite large. You have to let the GC know about allocation -- at least, about allocation that can be freed by GC. Otherwise it can't do its job. Those are my conclusions. It is midnight. Goodnight! ;-) Andy -- http://wingolog.org/
