[Cuis-dev] Changes to unwind logic and termination
Juan Vuletich
juan at cuis.st
Thu Nov 20 04:25:40 PST 2025
Hi Jaromir,
On 2025-11-20 5:33 AM, Jaromir Matas via Cuis-dev wrote:
> Hi Juan,
>
> I've patched the previous test to avoid the VM crash. Indeed the problem
> was it forced the VM resume "inside" a quick return.
This is great! Is it ready to add to the Tests package?
> Unlike Squeak, you
> allowed the Debugger to step into quick returns.
Yes. This is good for consistency. And it was done by folks doing TDD +
coding in the debugger. They found it annoying that you could not step
into a quick return method, edit it in the debugger, save and restart. I
believe the main authors were Francisco Javier Gelatti and Hernán
Wilkinson, during the FAST 2024 conference at Mar del Plata.
> What still confuses me
> is when you debug
>
> `true not`
>
> then step into #not and explore thisContext: what's the meaning of the
> pc counter relative to the method? It doesn't point to an existing
> bytecode (there's none actually) - is it ok? Why 25? It's confusing...
Well, it is a primitive method, the first (and only) bytecode there is
the 3 byte "Call Primitive" bytecode, at position 25. Maybe some
clarification is needed somewhere.
>
> Anyway, the test now passes.
The test looks perfect to me.
> If you remove the line:
>
> `ctx tempAt: 2 put: #unwindComplete`
>
> from #unwindAndResume:evaluating:, the test will fail because of the
> suspension point on the backward branch of the #whileFalse loop,
> demonstrating the reason for adding the additional #ensure:
> completionStatus variable value.
>
> Best regards,
> Jaromir
Yes. This is really great stuff. I'll just push the test now.
Thank you!
> On Nov 19 2025, at 8:19 pm, Jaromir Matas via Cuis-dev
> <cuis-dev at lists.cuis.st> wrote:
>
>> Hi Juan,
>>
>> I wanted to add an interesting test by Christoph testing that
>> termination works correctly at each step of the computation. This was
>> the test that discovered some treacherous suspension points in the
>> unwind mechanism and the motivation for adding the third value to the
>> #ensure: complete temp var.
>>
>> However, while it works flawlessly in Squeak, it crashes the VM in Cuis
>> immediately. Both for the new VM you've just uploaded as well as for the
>> previous one. And also regardless whether the latest unwind update
>> you've just integrated is applied.
>>
>> Please see for yourself: Using the latest image (new VM, updated unwind)
>> the crash happens at step 526. I'm enclosing the test with a halt at
>> this step for you to explore the process suspendeContext: you see the
>> problem happens when terminating inside `true not` evaluation which is a
>> quick return. I'm not familiar with how quick return is supposed to work
>> precisely here but it looks suspicious to me the Debugger shows pc = 25
>> but the method code has no such instruction. In Squeak this doesn't seem
>> to be a problem but I'm still not sure where exactly the problem is.
>> Maybe, but I'm speculating here wildly, it has something to do with the
>> fact that the quick return may not be a VM resumption point and in real
>> time (not simulation) the computation would never be stopped (preempted)
>> at this particular point, i.e. "inside a quick return", and hence the VM
>> crashes when forced to resume in such an undefined point.
>>
>> Question: does the quick return evaluate in a separate frame (context)
>> or is it inlined or executed similarly like a primitive?
>>
>> In an older image the problem happens at a different step but always
>> when inside True>>#not.
>>
>> I'm hoping you might spot a problem right away being familiar with quick
>> returns :)
>>
>> Best,
>> Jaromir
>>
>> On Nov 19 2025, at 1:18 pm, Juan Vuletich via Cuis-dev
>> <cuis-dev at lists.cuis.st> wrote:
>>
>>> Hi Jaromir,
>>>
>>> On 2025-11-19 6:15 AM, Jaromir Matas via Cuis-dev wrote:
>>>
>>>> Hi Juan,
>>>>
>>>> On Nov 18 2025, at 10:33 pm, Juan Vuletich via Cuis-dev
>>>> <cuis-dev at lists.cuis.st> wrote:
>>>>
>>>>
>>>>
>>>>> Hi Jaromir,
>>>>>
>>>>> Apologies for the delayed answer. We were midst the FAST Smalltalks
>>>>>
>>>>> conference in Argentina and a wonderful course on VM internals by
>>>>> Eliot
>>>>>
>>>> What a treat! I just regret Buenos Aires is so far away from Prague :)
>>>>
>>> Well, we need to find out how to make it possible for you to join us
>>> next year! You'd have a great time. I promise. BTW do you usually
>>> attend ESUG conference? Maybe we can meet there next year too.
>>>
>>>
>>>
>>>
>>>> I know Eliot had a presentation at Smalltalks 2025; any chance the
>>>> presentation was recorded?
>>> Yes. There were several other really good presentations, and all of
>>> them were recorded. They will be published on YouTube, like those of
>>> rpevious years.
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>> and I didn't have any brains left for anything else for a while.
>>>>>
>>>>> I just reviewed your changes. These are welcome and important enhancements.
>>>>>
>>>>> Thank you for keeping us updated and sinc'ed with Squeak! This is
>>>>> most
>>>>> valuable!
>>>>>
>>>>>
>>>> All pleasure's mine; Cuis is an invaluable source of feedback and
>>>> inspiration. Thank you!
>>>>
>>>>
>>>>
>>>>> When I loaded your changes, I found that in #unwindTo:safely: the
>>>>> old
>>>>> version had a guard against (ctx tempAt: 1) being nil. Your new code
>>>>>
>>>>> doesn't include that guard, and #testTerminateWithNiledUnwindBlock
>>>>> will
>>>>> fail. You can also see this with your 'Workspace example' included
>>>>> at
>>>>> that test:
>>>>>
>>>>> Workspace example:
>>>>> p := [[Processor activeProcess suspend] ensure: nil] newProcess.
>>>>> p resume.
>>>>> [p terminate] fork
>>>>>
>>>>> I found that adding a simple #ifNotNil: appears to solve the issue.
>>>>>
>>>>>
>>>> I originally added the nil check and the test but we have discussed this
>>>> issue with Christoph Thiede recently and decided to remove the check.
>>>> There's no point to guard against nil in place of an unwind block as
>>>> it's apparently just a user error and should show up. Only a block
>>>> should be allowed as an unwind block. Potentially, the nil check could
>>>> even obscure a user's error and make debugging harder (perhaps). This
>>>> way the user should be able more quickly identify the error in the Debugger.
>>>>
>>>> On the other hand we have a slight inconsistency here: if you run
>>>>
>>>> [] ensure: nil
>>>>
>>>> nothing happens, because we have `Object >> #value` returning self :)
>>>>
>>>>
>>>> So frankly, I don't have a strong opinion here. A guard is ok too or you
>>>> could even use the nil check to raise an explicit error if you
>>>> prefer.
>>>>
>>>> In such case one should probably add the same guard to
>>>> #unwindAndResume:evaluating: too.
>>> I think the analysis you did with Christoph makes total sense. It is
>>> better this way. So, I just pushed your code.
>>>
>>>
>>>> I'm surprised I forgot to add the test to Squeak :) So depending on your
>>>> decision it might want to be moved to expected failures.
>>> I just removed that test, and replaced it with a possibly redundant
>>> #testTerminateWithEmptyUnwindBlock, just to document all this a bit.
>>>
>>>
>>>>
>>>> Thanks again and best regards,
>>>> Jaromir
>>>>
>>> Thank you. Cheers!
>>>
>>> --
>>> Juan Vuletich
>>> www.cuis.st
>>> github.com/jvuletich
>>> researchgate.net/profile/Juan-Vuletich
>>> independent.academia.edu/JuanVuletich
>>> patents.justia.com/inventor/juan-manuel-vuletich
>>> --
>>>
>>> Cuis-dev mailing list
>>>
>>> Cuis-dev at lists.cuis.st
>>>
>>> https://lists.cuis.st/mailman/listinfo/cuis-dev--
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
--
Juan Vuletich
www.cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
More information about the Cuis-dev
mailing list