I did some simple memory profiling of the testsuite wrt the Gz module.
Before testing Gz:
[...]
001CC000 64576K read/write/exec [ heap ]
[...]
total 116856K
After tests with constant strings, before tests with random strings:
[...]
001CC000 64576K read/write/exec [ heap ]
[...]
total 116856K
After all Gz tests:
[...]
001CC000 95936K read/write/exec [ heap ]
[...]
total 148216K
The last randomness test uses about 32 megs, so it's natural for the
heap to grow to 96M if all the 64M that made up the previous heap is
actually used. Question is, why would there be 64M used heap space at
the entry to the tests? A freshly started pike has only 2.5M of heap,
so the previous tests must have left 61M of now unused data still
referenced somehow. (Some of it can be attributed to internal
fragmentation of course, but considering the size of the block we
shouldn't have _that_ much fragmentation.)
I'm going to try it again with some gc()'s sprinkled through the
tests.