Hi David,

On Tue, Jul 7, 2015 at 4:33 PM, David T. Lewis <lewis at mail.msen.com> wrote:

> On Tue, Jul 07, 2015 at 02:34:48PM -0500, Chris Muller wrote:
> >
> > On Tue, Jul 7, 2015 at 1:31 PM, David T. Lewis <lewis at mail.msen.com>
> wrote:
> > > I am away and cannot follow up on this for a while.
> > >
> > > My guess would be that there is something wrong in the compiler, and
> that
> > > it needs to be fixed (but I cannot check now to find out). I don't
> know if
> > > this affects SqueakJS or other VMs.
> > >
> > > Dave
> >
> > Maybe the problem is in the image, the interpreter VM or the
> > TwosComplement package, we don't know.  Since it does not appear
> > likely anyone will be able to investigate it soon, and the nature of
> > both releases is about all-new VM(s) anyway, we probably should not
> > hold up the release over this.
> >
> > In fact, I could make another RC without the recompileAll.  Is it
> > really necessary?  I don't know any better about its purpose than why
> > it would be a problem.  I guess anyone could do it on their own if
> > they wanted..
> >
>
> OK, I'm back now.
>
> The problem was introduced in Compiler-eem.300, which does this:
>
>     Use the size/emitPushNClosureTemps: api in block generation.
>
> There are two affected methods:
>
>     BlockNode>>sizeCodeForEvaluatedClosureValue:
>     BlockNode>>emitCodeForEvaluatedClosureValue:encoder:
>
> Reverting these two methods fixes the problem.
>
> I don't know the background on this change but my guess would be that
> it is something that works on a stack interpreter but not on a context
> interpreter, so maybe the methods need to be tweaked to account for the
> difference.
>

It should make no difference to the code produced.  It adds a new way of
saying "push N nils" that allows the Sista bytecode set to use its
"pushNClosureNils" bytecode to push several nils in one bytecode.  But with
the standard encoder EncoderForV3PlusClosures exactly the same code as the
previous version should be produced.

How do the changes in the compiler cause the crash?


>
> I would suggest rolling back these two methods until after the 4.6
> release, see Compiler-dtl.303 in the inbox.
>
> Eliot, does that sound right?
>

No.  I don't see how the changes cause the crash.  The changes have no
effect in the Encoder in effect in the release image.  I'd like to
understand how the crash occurs before rolling back.


>
> Thanks,
> Dave
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150707/0ae3bed4/attachment.htm