Thinking about ways to shrink the VM footprint even further:
1) Scheme48 uses stop & copy GC, which allocates two heaps, but only
uses both of them during GC.
Most UNIX systems now support mmap(). If you unmap the "old" heap
when you're done with GC, then re-map it with anonymous pages at the
start of the next GC, GC becomes much nicer to the system, since while
you're copying you don't need to page the "old" data back in before
overwriting it with new data -- allocating a new, zeroed page is much
faster than paging in a page that has data the *system* thinks we
might care about.
The risk of this, of course, is that the VM might not be there when
you need to GC -- but if you're running 20 scheme48 processes on a
system, you'll only need 21 or 22 heaps worth of VM rather than 40, so
you're less likely to bump into this limit.
I looked at doing this once and decided that it looked easy but you
would really need to rebuild the vm for it, so I gave up since it
wasn't clear that the right version of prescheme was available.
2) Be more agressive about putting more "really" constant data into
the read-only part of a static heap... I got the impression from
playing with static heaps a while back that maybe only 50% of the data
was constant enough to go into the pure space. That seems too small..
most compiled C code seems to be about 90/10 pure/impure preallocated
data, and I suspect that most of the preinitialized data in the heap
is the same way.
I suspect that many scsh programs will typically only have about
100K-200K or less of actual data, so you could start with a very small
heap by default and grow it on demand...