[squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article

John M McIntosh johnmci at smalltalkconsulting.com
Wed Jul 2 06:58:39 UTC 2008


On Jul 1, 2008, at 5:06 PM, Eliot Miranda wrote:

> Any other allocation can exceed VM reserve start but not fwd block  
> reserve.  Exceeding fwd block reserve is an internal fatal error  
> that should not happen if VM reserve is large enough.
>
> Any allocation that pushes free start/eden beyond scavenge threshold  
> sets a flag that will cause the VM to perform an incrementalGC on  
> the next send or backward branch.
>
> The net result is that pointers only move during primitives that do  
> substantial allocations (primitiveNewWithArg, anything that  
> allocates lots of objects) and only these primitives need to use  
> pushRemappableOop:/popRemappableOop.
>
> The details can vary but the essentials are to arrange that for  
> allocations in the course of execution (e.g. creating a  
> block,creating the message argument of a doesNotUnderstand:,  
> creating a primitive failure value, flushing a stack page to heap  
> contexts, etc, etc) the garage collector will not run and so the VM  
> does not need to manage pointers in local variables.  It can assume  
> these values will not change and remain valid until the next send or  
> backward branch.


Back when Tim and I looked at allocation failures a few years back I  
had built a VM where it would slide the end of young space into the  
forwarding block reserve area. That worked quite nicely
and you could chew memory  right below the number of bytes for needed  
for the next MethodContext at which point the VM would crash.  However  
that never went into VMMaker. The real issue is deciding how to stop  
the process that is fatally consuming memory.  But that's a different  
issue.

As for the set a flag for an IGC, also see
forceTenureFlag
via primitiveForceTenure
which some memory policies use to solve the problem with excessive  
slot scanning via the root table.

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





More information about the Squeak-dev mailing list