[squeak-dev] Re: Getting back to push/pop remappable oop

Andreas Raab andreas.raab at gmx.de
Wed Nov 12 04:25:54 UTC 2008


Hi Igor -

I think it's worthwhile to step back a bit and think about what you're 
actually trying to achieve here. While it may be possible to replace 
push/popRemappableOop with just push/pop it seems to me that you are 
just replacing one set of obscure rules with an even more obscure set of 
rules. Considering that such a change would also require rewriting every 
single plugin it strikes me as being of little practical relevance.

If you are trying to simplify the programming model and improve the 
robustness of plugins the better approach is to make 
push/popRemappableOop be effective no-ops by disabling GCs in 
primitives. This way you don't need to remap oops (except in places 
where you may want to run an explicit GC such as primitiveNew) and can 
keep all existing plugins with no change. 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

Igor Stasenko wrote:
> 2008/11/11 Igor Stasenko <siguctua at gmail.com>:
>> btw, concerning failures to allocate memory (and therefore primitive
>> failure when building up the complex oop).
>> An allocation followed by  #storePointer:ofObject:withValue: .
>> If you take a look, there is no checks if object is valid or having
>> enough slots for storing value at given offset.
>> So, in case if allocation fails, and return invalid object (or
>> non-object), there is 100% guarantee that it will corrupt object
>> memory.
>> So, what the difference between corrupting object memory and
>> corrupting the stack?
>> Btw the latter case can be detected much faster than first one.
>>
>>
> oh, wait, i just checked: allocation never fails.
> If it fails, VM is bailing out immediately. :)
> In this case, i insist that, if carefully written, primitives could
> use the argument/receiver slots in stack for building up thier complex
> oops as response.
> 




More information about the Squeak-dev mailing list