On Mon, Dec 7, 2020 at 9:12 PM Eliot Miranda <eliot.miranda at gmail.com>
wrote:

> nil == thisContext pop
>
> I guess this is fine, because what alternatives would the execution
> machinery have? It could terminate the whole VM or we could introduce
> something like #cannotReturn: for invalid stack frame objects. Probably the
> current implementation is the best despite an invalid position in
> the context stack has been addressed.
>
>
Well, one pop is almost "fine" because there still is an object on the
stack (the receiver). But if you were to do 2 pops then we would fetch from
the void.

[image: image.png]

after stepping over #pop it looks like this

[image: image.png]

... when there really should be 2 nils on the stack (in slots 6 and 7).
After stepping once more:

[image: image.png]

... it actually replaced the receiver slot, going "below" the stack.

> However, the simulation machinery treats the same snippet differently, and
> it throws:
>
> Error: subscript is out of bounds: 0
>
> If we did bounds checking for stack access in SqueakJS (which I used for
the above screenshots) then yes we could produce an error. But that would
be really expensive.

> I wonder whether it is acceptable to have diverging behaviors for such an
> ill-defined edge case between simulation and production (btw did I choose
> the right terms for them? :)). Might it a better alternative to raise
> a Warning (#notify:) only and then return nil such as the VM appears to do?
>
> It’s a very good question.  I’m going to provide a very lazy and pragmatic
> answer, forced by lack of resources to address the issue properly.  It’s
> clear that the behaviour is at best undefined.  It is good that the
> simulation produces an error. The only regrettable thing is that what is
> reported is a low-level error rather than a high-level one that says, fir
> example, “undefined behaviour encountered”.  Achieving a specification
> which states that this is undefined behaviour allows the JIT to get away
> with not dealing with the issue, and that’s important because dealing with
> the issue such that the JIT could detect this as an error would likely
> destroy lots of performance gains it is able to make by assuming it is
> given valid defined execution sequences.
>
> That’s a long winded way of saying that, given limited resources, I’m
> giving the same response as a doctor that when told by a patient that it
> hurts when the patient does X says “then stop doing X”.
>

Exactly.

Dr. Vanessa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210105/b5f7b6cb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 35776 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210105/b5f7b6cb/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32071 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210105/b5f7b6cb/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 29750 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210105/b5f7b6cb/attachment-0005.png>