[Vm-dev] Root bit on active context? Closure VMs and thoughts on flushExternalPrimitives.

Eliot Miranda eliot.miranda at gmail.com
Mon Apr 13 21:29:26 UTC 2009


On Mon, Apr 13, 2009 at 2:22 PM, John M McIntosh <
johnmci at smalltalkconsulting.com> wrote:

> Er I think my question was why is
>
>       ((self longAt: activeContext) bitAnd: RootBit) = 0 ifTrue:[
>
> always false if the comment implies 1 3.8 shouldn't  have the RootBit set?


Since the initial context shouldn't have the root bit set all the context
manipulation in initialClanup is redundant if this is a new closure image.
 If it isn't you need to keep it for loading older images.  So in our
sources the root bit code is still there in the ordinary closure
interpreter, but gone in the Stack VM (which only runs closure images).


and
>
> flushExternalPrimitives then grinds thru all the objects to do self
> flushExternalPrimitiveOf: oop
> but snapshotCleanUp  does the same work (or so it appears), which would
> mean the flushExternalPrimitiveOf: would be pointless at startup time.


Right, which was why I said "Good point".  In the Stack VM therefore
initialCleanup is just

initialCleanup
"This used to cope with issues with images written by VMs earlier than
3.6/3.7.
 Since we won't be loading such images (being a closure only VM) we only
have to
 deal with external primitives.  Since references to external plugins in
methods are
 cleaned up in snapshotCleanUp only initialize the tables, not visit each
method."
self flushMethodCache.
self flushAtCache.
self flushExternalPrimitiveTable


>
> On 13-Apr-09, at 2:09 PM, Eliot Miranda wrote:
>
>  --
>>
>
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20090413/961bec0e/attachment.htm


More information about the Vm-dev mailing list