Ian and I were talking today about simple storage management schemes and realized that Squeak's current garbage collector is "so wonderful" that it has shielded us completely from a useful piece of information.
We were specifically curious how a non-moving garbage collector would perform. For such a beast, when an object is freed it is maintained in a structure from which it can later be reallocated. Most such approaches use some form of "buddy" system to coalesce adjacent free blocks but, inevitably there is some fragmentation of memory.
So here's the instrumentation challenge: Write a log of all the allocation and release operations from running Squeak through, say, the macro benchmarks.
There's a pretty simple place to find all the allocations in the VM. Then at each GC, each unmarked object that the compactor steps over should cause an effective release operation to be logged.
Such a log could then be fed to any number of block management algorithms to get a sense of what kind of fragmentation to expect. This, in turn, would tell us what kind of trade-off exists between the memory footprint used and the time between catastrophic reorganization (ie when you have to do a full compaction).
Partial credit: If you have real experience with a Squeak-like system that worked this way, give some report on the fragmentation behavior experienced.
References to papers with practical results in the area would also be of interest.
Thanks
- Dan