On Nov 11, 2008, at 8:25 PM, Andreas Raab wrote:

> . The only requirement for this is a bit of extra headroom which we  
> have already (it is reserved for forwarding blocks in full GCs) and  
> it seems reasonable to take a small bite out of that reserved space  
> to trigger a GC after the primitive completes.
>
> Cheers,
>  - Andreas


In case anyone wonders I used this headroom as a *fix* for the low  
memory issue a couple of years back,  somewhere I've some code that
would creep young space into the forward block area as we ran out of  
memory.   However as Tim and I discovered
it's really hard to fix the low memory issue, this *fix* which didn't  
go into product would only delay the out of memory failure
by yet another few seconds, so it was quite worthless.

However as a solution to Oops memory allocation for primitives, versus  
a GC it's quite worthwhile.  I'd guess to
prevent changing every plugin to use some different allocator we could  
have a global switch that we turn on/off
when we enter/exit a plugin call, and if we actually do run out of  
memory based on young space/forwarding block area
then exit(42) if the flag is set?

Someone might want to check to see if  plugin memory allocation  
patterns are for small pieces. or does someone
allocate 100MB and that is enabled by doing the GC cycle?


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