[Vm-dev] questions about a couple of primitives

Florin Mateoc florin.mateoc at gmail.com
Tue Sep 1 16:03:48 UTC 2020


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.

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"


> 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/de58c129/attachment.html>


More information about the Vm-dev mailing list