Prim error returns (was Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article)

tim Rowledge tim at rowledge.org
Wed Jul 2 06:46:39 UTC 2008


On 1-Jul-08, at 3:07 PM, Eliot Miranda wrote:
>
> The compiler is modified to recognise <primitive: integer errorCode:  
> identifier> and <primitive: identifier module: identifier errorCode:  
> identifier> and convert this into one additional temp

Yup, that's what we did...

> and generate a long storeTemp as the first instruction of the method.
>
> The VM is modified to, on primitive failure, check for the  long  
> storeTemp and stores the error code if it sees it.
>
> Old images lack the storeTemp so the VM does not store the value.   
> Old VMs do perform the storeTemp, but because the storeTemp is  
> storing into the stack top it is effectively a noop.  e.g. if the  
> primitive looks like:

...but that is very clever as a way of handling back-compat. We didn't  
have to care about  that at all so it got no attention.

>
>> I'm going to guess that "work I'm doing right now on eliminating  
>> pushRemappableOop:/popRemappableOop" relates to getting allocations  
>> out of primitives as much as possible, right?  That would be nice.
>
> No.  This relates to not having to use pushRemappableOop:/ 
> popRemappableOop because it is extremely error-prone.  For example  
> can you spot the bug in this:
>
> primitivePerform
[snip]
>
> A doesNotUnderstand: may cause a GC in createActualMessage as it  
> creates the message argument for doesNotUnderstand:.  So this bug  
> only bytes if a perform is not understood when memory is on the  
> verge of exhaustion.
Ouch! What fun.
>
>
> In the context-to-stack-mapping VM I'm working on the VM may do up  
> to a page worth of context allocations on e.g. trying to store the  
> sender of a context.  Rather than try and plug all the holes it is  
> much safer to restrict garbage collection to happening between  
> bytecodes (probably on sends and backward branches).  To do this the  
> GC has to maintain a reserve for the VM which is about the size of  
> two stack pages, or probably 2k bytes, and the VM has to defer  
> incremental collections from allocations until the send or backward  
> branch following.


OK; be aware that there is a pathological case that might impact your  
code in this area, mostly restricted to non-virtual memory systems.  
Somewhere in the GC code it will try to grab more memory for  
forwarding blocks and if none is provided by the OS (as in RISC OS for  
example) then some of the reserved space will be stolen *without*  
proper checks and notifications. This can result in the system trying  
to handle a lowSpace with only a few hundred bytes of free memory. It  
doesn't go so well after that.... I've been trying to find relevant  
emails to illustrate better but no luck so far. I'm reasonably sure we  
never came up with a good solution but the problem surfaced about 4  
years ago and just possibly got fixed somewhere.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
"Bother" said Piglet, as Pooh smeared him in honey.





More information about the Squeak-dev mailing list