If you set Smalltalk setGCBiasToGrow: 1
you may get different behavior, assume your vm supports that and you  
noted the issue with SLANG dropping the code I talked about last  
moth.  The code was fixed, not slang, although I don't think Tim has  
put the fix in to VMMaker yet (hint hint).

Really of course the VM must signal low space at some point if it  
can't grow, and the process must run instead of something else do  
whatever, then allow the process that is doing the memory allocation  
to run and try again.

I recall in VW it would attempt the allocation, if it failed it would  
mutter things to the memory policy to allocate this much more memory,  
with a % of extra slack, then retry with possible failure, the key  
being the process asking for the memory would be waiting for the VM  
to adjust the memory footprint. One failure case in the past was  
setting the % too low so that other processes would chew up the newly  
allocated memory leaving you without the memory you just asked for.  
Of course if the memory requested will push you over the memoryLimit  
set for the VM, nothing will help.

On Feb 10, 2007, at 10:40 AM, Andreas Raab wrote:

> Hi Guys -
>
> I am just being very confused about the current behavior of Squeak  
> in the case of memory allocation failure. In my use case I have  
> incoming network requests which are handled at high I/O priority  
> and need to allocate memory based on the size of the request. Given  
> a malformed request, this can easily lead to an allocation failure  
> which really should raise an error, be caught and be done with.
>
> However, there doesn't seem to be a way of handling low-space  
> conditions  by the client. In the case of an allocation failure,  
> all that appears to be happening is that the low-space semaphore is  
> being signaled with the obvious assumption that the low-space  
> watcher will preempt the running process, make some space and  
> continue. But equally obviously this just can't work if the running  
> process is at a higher priority than the low-space process and  
> since the running process recurses directly into #basicNew: again  
> this will bring your system to a screeching halt.
>
> Since I can't possibly be the first person who noticed that (or at  
> least I really don't hope I am) my question is, how do people deal  
> with that situation in their production systems? I have never seen  
> the issue discussed but I would expect that it has come up on some  
> Seaside or other network-related lists.
>
> Right now I'm just thinking to do something like signaling an  
> OutOfMemory error which as its default action would signal the  
> lowspace condition, leaving the client with the option to handle  
> the request differently if needed.
>
> Cheers,
>   - Andreas
>

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===