[squeak-dev] Older VM's won't start the latest beta images

Jaromir Matas mail at jaromir.net
Sat Jun 25 17:38:10 UTC 2022

Hi Eliot,

> Jaromir, you should be able to run the vm turning on the send trace and see where an image starts to crap out.

The trouble with me is I’ve only ever run the VM by doubleclicking Sqeak.exe icon so far…  I’ll try my best though :D

I only wanted to verify the older VMs run with the new #suspend ok - which they do except one thing: #isTerminated only recognizes the process as terminated when the pc is at the end of the bottom context - which is not true if suspend uses the fallback code and builds another context on top of the bottom one and suspends there…

I don’t know if this is relevant or not to keep this level of compatibility with the older VMs but fixing #isTerminated seems easy in case anyone’s interested - see attached.


From: Eliot Miranda<mailto:eliot.miranda at gmail.com>
Sent: Saturday, June 25, 2022 18:45
To: The general-purpose Squeak developers list<mailto:squeak-dev at lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Older VM's won't start the latest beta images

Hi Dave, Hi Jaromir,

> On May 29, 2022, at 7:03 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> On Sun, May 29, 2022 at 08:06:59AM +0000, Jaromir Matas wrote:
>> Hi,
>> I wonder what?s changed that the images starting from Squeak6.0beta-21772-64bit on won?t start with the previous release VM (squeak.cog.spur_win64x64_202003021730) or even with pre-release new VMs (e.g. version 3154).
>> I?m on Win10, the process explorer (windows) shortly runs WerFault.exe and than the Squeak process is closed/disappears.
> The change is here:
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-May/220660.html
> The current release candidate image does not have this, but it will be
> applied as soon as you update that image, and it expected to be part of
> the final release. The update applies a new image format number to the
> saved image files (stored in the first 4 bytes of the image file) when
> multiple bytecode set support is required from the VM. Effectively, the
> means that the image is using the Sista bytecode set. Older VMs can
> run the Sista bytecodes but do not yet have the code for recognizing
> the additional image format number.
> Dave

I don’t think that’s the reason.  Older VMs have supported the Sista bytecode set fir several years.  However, older VMs lack the new suspend primitives.  These have only been in the vm for about three months.

Jaromir, you should be able to run the vm turning on the send trace and see where an image starts to crap out.  See the -trace argument.  The documentation on the flag bits is (alas) in a VMMaker.oscog method on Cogit. (This I should fix)

_,,,^..^,,,_ (phone)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220625/280fbed4/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Process isTerminated.1.cs
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220625/280fbed4/attachment.ksh>

More information about the Squeak-dev mailing list