[squeak-dev] Backward image and VM compatibility
David T. Lewis
lewis at mail.msen.com
Thu Jan 12 02:03:53 UTC 2017
On Wed, Jan 11, 2017 at 05:10:24PM +0100, Bert Freudenberg wrote:
> On Tue, Jan 10, 2017 at 3:13 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> > Thanks Bert. It appears to be something related to MethodContext. Since it
> > is VM related, I initially guessed that it might be something related to
> > the method cache, but I was able to disable that in the VM and the symptoms
> > did not change. I'm thinking now that it might be a failure in primitive 61
> > when trying to copy a MethodContext, this based on the debugger stack
> > (although I cannot actually display anything useful in the debugger).
> > I'll report back if I end up figuring it out, meanwhile any and all
> > historical
> > clues are appreciated :-)
> Ah, slowly all the hacks I had to put in are coming back to me ;)
> Some early images fill the context stack before advancing its stack
> pointer. I have a flag to allow that, it's pretty certainly used in
> primitive 61. Normally the VM does not allow access beyond the SP because
> there is garbage there (stack pops do not nil out the context slot):
> But since the regular VM does not allow it, no image (except the really old
> ones) ever does it, so I just leave the flag enabled whenever "oldPrims" is
> in effect ;) Would be better if we could come up with a better way to
> identify these images.
Brilliant, thanks Bert.
I see several places where we check "fmt = 3 and: [self isContextHeader: hdr]",
including in #stObject:at:put: which is probably the immediate cause of the
failure that I was seeing. And #stSizeOf: does this:
(fmt = 3 and: [self isContextHeader: hdr])
ifTrue: [stSize := self fetchStackPointerOf: array]
ifFalse: [stSize := totalLength - fixedFields].
I'll try playing with it this weekend and see if I can get it working for the
But I have to ask ... how in the world did you figure this out?
More information about the Squeak-dev