On 10-Feb-07, at 9:05 PM, John M McIntosh wrote:

> 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).

Money for time, 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.

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.

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.

It *is* possible to make a memory resilient system. The ancient  
ActiveBook system built from Eliot's BHH was routinely tested by  
running it down to a few hundred bytes of free memory and a dozen or  
so free oops (this was an OT system) and it always recovered cleanly.

It takes tim, which takes money.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: OI: Vey