lowspace signalling and handling issues

John M McIntosh johnmci at smalltalkconsulting.com
Wed May 4 02:56:09 UTC 2005

I've taken it down to 32K on a 512MB image via that code that allocates  
Grinds away until freespace goes under 98 bytes (can't allocate a  
context record).

On May 3, 2005, at 6:54 PM, Tim Rowledge wrote:

> 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
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com

More information about the Vm-dev mailing list