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@sumeru.stanford.edu, http://sumeru.stanford.edu/tim "Bollocks," said Pooh being more forthright than usual