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

Eliot Miranda eliot.miranda at gmail.com
Mon Nov 17 18:42:23 UTC 2008


On Tue, Nov 11, 2008 at 8:25 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

> 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


This is the way to go.  I've done some of this for the Stack interpreter.
 It doesn't disable GC in the new and new: primitives, but it does disable
GC at all other points, such as allocating a context or closure during
normal execution, or when flushing a stack page's frames to heap contexts to
make the page available.  These "system" allocations will not GC, but
instead set a flag saying GC is needed when an allocation exceeds a
threshold.  The GC will then occur at the next frame-building
(non-primitive) send.  The VM uses the stack page limit as an event check
flag.  Every frame build must check the stack limit for overflow.  Events
such as GC needed or IO poll needed simply smash the stack limit and the one
test for stack overflow also serves for breaking out to do a GC or poll for
IO.

VisualWorks has always worked this way.  It works well.


>
> 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.
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081117/351158b0/attachment.htm


More information about the Squeak-dev mailing list