[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