On Mon, Apr 13, 2009 at 2:22 PM, John M McIntosh <johnmci@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@smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================