[Vm-dev] questions about a couple of primitives

Florin Mateoc florin.mateoc at gmail.com
Tue Sep 1 18:37:00 UTC 2020


On Tue, Sep 1, 2020 at 1:58 PM Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
>
>
> On Sep 1, 2020, at 9:04 AM, Florin Mateoc <florin.mateoc at gmail.com> wrote:
>
> 
> Hi Eliot,
>
> On Tue, Sep 1, 2020 at 11:12 AM Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
>>
>> Hi Florin,
>>
>> On Aug 31, 2020, at 8:32 PM, Florin Mateoc <florin.mateoc at gmail.com>
>> wrote:
>>
>>
>> On Mon, Aug 31, 2020 at 8:25 PM Eliot Miranda <eliot.miranda at gmail.com>
>> wrote:
>>
>>>
>>> On Mon, Aug 31, 2020 at 6:29 PM Florin Mateoc <florin.mateoc at gmail.com>
>>> wrote:
>>>
>>>>
>>>> On Mon, Aug 31, 2020 at 6:00 PM Eliot Miranda <eliot.miranda at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On Mon, Aug 31, 2020 at 2:00 PM Florin Mateoc <florin.mateoc at gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> I think this is especially confusing since the comment says that the
>>>>>> primitive always fails, and then the expectation is that the Smalltalk code
>>>>>> that follows is executed instead. But that code does not do what the method
>>>>>> actually does
>>>>>>
>>>>>
>>>>> I disagree.  It does exactly what the method does (it *is* the
>>>>> implementation of the method) unless the stack is unwound.  Yes, the
>>>>> comment could point the reader to Context>>#resume:through: which
>>>>> runs the ensure: & ifCurtailed: blocks on unwind.  Bit
>>>>> otherwise ifCurtailed: is not somehow magically not executed.  It is what
>>>>> it is ;-)
>>>>>
>>>>> As I said earlier,  ifCurtailed: only evaluates its argument if a
>>>>> non-local return or exception return is taken and the normal return path is
>>>>> not taken.  See Context>>#resume:through: which runs the ensure: &
>>>>> ifCurtailed: blocks.
>>>>>
>>>>> Can I confirm that your dissatisfaction is with the comment?  Or do
>>>>> you really think the ifCurtailed: method does not execute verbatim in the
>>>>> absence of unwinds?  If the former, you're welcome to submit an improved
>>>>> comment.  If the latter, you're mistaken.
>>>>>
>>>>>
>>>> Of course I agree that the ifCurtailed: method does execute verbatim in
>>>> the absence of unwind. But the method does not only execute in the absence
>>>> of unwinds. So my "dissatisfaction" is not just with the comment. While it
>>>> could be somewhat be addressed by a comment, I think this is an instance
>>>> where the vm is caught cheating. The shown Smalltalk code is not what gets
>>>> executed in the presence of unwinds (as opposed to the code shown in
>>>> #ensure: ). The execution of the argument block is hidden inside the vm
>>>>
>>>>
>>> To be more pedantic, neither #ensure: nor #ifCurtailed: disclose what is
>>> really happening on the unwind path, but at least #ensure: shows some code
>>> that conceptually matches its semantics.
>>> In both cases, there is magic happening inside #valueNoContextSwitch,
>>> which, although it does not take any arguments, it knows how to (call a
>>> method that knows how to) invoke, if necessary, its caller's argument.
>>> Yes, by walking the stack and peeking inside the contexts' temps and
>>> then acting upon them anything is possible, but the resulting code is
>>> anything but readable.
>>>
>>> I would argue for passing the #ensure: and #ifCurtailed: arguments to
>>> the #valueNoContextSwitch method/primitive, thus making it possible to
>>> avoid #resume:through: - I think such methods are fine for
>>> simulation/debugger, but not for runtime.
>>>
>>>
>>> -1. Putting this in the vm adds a whole level of execution suspension &
>>> resumption which isn’t there.  Since Smalltalk has first class activation
>>> records it can (and does) elegantly implement a number of very complex
>>> control structures (such as unwind protect evaluation, and exception
>>> delivery) above the vm.
>>>
>>
>> Sorry, I disagree.
>>
>>
>> There is no need to apologize.  We disagree.  That is clear.
>>
>> And I would not put exception delivery in the same boat - that one does
>> exactly what you say, it implements something in the image, above the vm,
>> not just elegantly, but also putting more power in the hands of the
>> developer. But everything is out there in the open, browsable, readable,
>> debuggable and easily understandable.
>> In this case we have a message sent to a context by the vm, which is not
>> what I would call above the vm.
>>
>>
>> Your criticism doesn’t make sense to me. aboutToReturn:to: is the result
>> of the VM detecting a non-local return attempting to return past and unwind
>> protect frame.  [Fabio, this is not described by the blue book because
>> Smalltalk-80 prior to the late 80’s didn’t have unwind protect; I think I’m
>> right in saying that Peter Deutsch added it to ObjectWorks v5; I don’t know
>> when it was added to Smalltalk-V].  Similarly cannotReturn: is the result
>> of an attempt to return to a nil sender.  cannotResume: is the result of an
>> attempt to result a process with an invalid suspendedContext.
>>  doesNotUnderstand: is the result of an attempt to send a message that is
>> not understood. attemptToAssign:to:withIndex: is the result of an attempt
>> to assign to the inst var of a read-only object.
>>
>> So aboutToReturn:to: is one of several send-backs from the VM made when
>> errors occur.  There is nothing unusual about it.  It is in house style,
>> harmonious with the overall system architecture.  And that the response,
>> just like the response to the other send-backs, is implemented in Smalltalk
>> does indeed lift things above the vm.
>>
>>
> While I was not initially aware about #aboutToReturn:to:, it is not so
> much about the fact that the vm sends a message (as you say, that part is
> in house style), it is what we do with it. You are right, we are doing it
> on the image side. Except the in-image part of this whole uses, as I
> mentioned, simulation/debugger kind of code, which might as well have been
> done in the vm. It is this one-two punch that makes it different than the
> other vm sent messages that you listed.
>
>
> And as I already explained, putting this in the vm would necessitate
> adding a whole new level of execution suspension/return while the vm
> remembers the continuation of the return as it evaluates the unwinds, which
> can themselves raise errors.  Putting this in the vm adds significant
> complications there while all the required mechanism is already available
> above the vm.  Do, as I already stayed, putting evaluation off winds in the
> vm does not make (sound engineering) sense to me.
>
>

Sorry, i wasn't clear: I only meant that the code is obscure enough that,
from a readability point of view, it might as well have been hidden away in
the vm, not that it should have been implemented there.

>
>
If one browses the code, reads the code and the comments, of both
>> #ifCurtailed: and #valueNoContextSwitch, nothing makes sense, there is no
>> indication whatsoever of what is happening under the hood, no mention of
>> the message that the vm sends to the context. Nor is anything visible in
>> the debugger. Maybe this is indeed all justified for performance reasons,
>> and since I am not the one who implemented it or who would implement an
>> alternative, you can of course ignore my opinion. It is but a tiny corner
>> of the image. But I think it is an important one, and you seem to deny that
>> there is even any readability problem with these methods. Oh, well
>>
>>
>> I invited you to submit an improved comment.  I pointed you to the
>> implementation of the evaluation of the unwinds.
>>
>
> How about adding something like:
>
> "The abnormal termination is detected by the vm and signalled as an
> #aboutToReturn:to: message sent to a reified current context, with the
> context of the #ifCurtailed: invocation as an argument.
> The current context then walks the stack to unwind and execute any unwind
> blocks (including the one protected by the #ifCurtailed: invocation) - see
> Context>>#resume:through"
>
>
> Sounds good.  Are you going to submit to inbox?
>

Will do. Thank you


>
>
>> Anyway, I only now noticed that the discussion is off list - if I did
>> that, it was unintentional, I just clicked reply without checking that it
>> goes to list or not
>>
>>
>> The discussion is on list.  I hit reply all.  Perhaps I shouldn’t have.
>>
>
> The messages had suddenly stopped appearing on the list for me - although
> it was still August at the time in my timezone, the list had already moved
> on to September :)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200901/3a7bcca4/attachment-0001.html>


More information about the Vm-dev mailing list