Low-space signals in production environments

Andreas Raab andreas.raab at gmx.de
Sun Feb 11 10:08:29 UTC 2007


tim Rowledge wrote:
>> 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.
> 
> Exactly. I'm a bit surprised to read of any process - except possibly 
> the tick etc- running at a higher priority that the lowspace handler. 
> That seems a bit daft; any process that could possibly allocate memory 
> should be running at a lower process, unless perhaps one provides some 
> sort of process locking mechanism.

There seem to be two misunderstandings here. For one thing, the lowspace 
watcher runs at lowIOPriority and there are *plenty* of processes 
running at that priority or higher.

Secondly, even if when signaling the low space semaphore (which can be 
seen as a *hint* to the system that we're in trouble with respect to 
memory) the outcome of an allocation ought to be either that the memory 
was allocated, or that an error is raised. What sense does it make for 
Behavior>>basicNew: to signal the lowspace semaphore? The result is that 
you can lock up the system as simply as here:

    [Array new: SmallInteger maxVal] forkAt: Processor lowIOPriority.

And what's the point of that? At least I would expect if the allocation 
within basicNew: fails we get a proper error condition. But 
side-effecting by signaling the lowspace semaphore? What good does that 
do? In particular considering that the lowspace semaphore can't really 
do anything because it doesn't even know which process got interrupted! 
Sorry, but this seems Just Wrong(tm).

> Aside from in-image issues of policy to decide on whether to try to grow 
> or not, there are VM complications in the limit set in some cases as 
> well as a particularly egregious situation where the VM will steal a 
> substantial chunk of the memory that is thought to be available in order 
> to do a bit of gc work. It can go so far as to leave just a few bytes 
> for the allocator which typically isn't a happy place to end up.

Not really. Whether the VM is capable of allocating memory or not is a 
binary decision. There is nothing complicated about it. Whether it can 
recover from a failed allocation is of course a different question but 
that's why we have the red zone which triggers a low space condition 
when we enter it - the red zone is still sufficient to do a variety of 
things. But when allocation fails, it fails, there is no policy. It fails.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list