lowspace signalling and handling issues

[Tim Rowledge]

So having the VM provide the oop of the Process that asked for the allocation
which passed the threshold is ok as a start.

I think we need to set the lowSpaceThreshold much higher for a realistic chance
of surviving the alert - several Mb seems to be much safer. Even without the GC
code occasionally stealing a large chunk from the memory we're just declared is
in short supply it doesn't seem smart to wait until memory is seriously tight
before telling the user.  Opening a debugger and doing anything meaningful in
morphic takes a good chunk of space. The current code in the VM pretty much
relies upon there being some more memory to add via sqExpandMemory but
a) not all platforms do that, so it crashes
b) every platform will run low eventually and then see a) above.
Having a threshold of 200kb when the VM may very well demand an extra 200kb as
part of trying to clean up to handle the fact that you don't have 200kb free is
not very safe.

Has anyone ever done any testing to see just how many passes of compacting can
be survived? If we checked the actual free space (perhaps the lowSpaceSignal
state is better) and refused to give any to the fwdBlock table would we simply
be thrashing a bit more, or doomed?  Or should I just give up because nobody
can be bothered to actually think about how to do things right for a change?


tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
"Bollocks," said Pooh being more forthright than usual