Here is a draft.
-----------
How to make a new RC of the OSVM:
1. Tag specific commit with its UTC timestamp, e.g., 202205110711 for May 11, 2022 at 7:11
2. Run all "Build for*" workflows manually for that tag
3. Verify that a pre-release was created for that tag, containing all build artifacts
How to make a new release of the OSVM:
1. Do a new RC (see above)
2. Edit that GitHub pre-release to be an actual release
3. Change the description to have some release notes on the changes
How to make use of OSVM-RC in squeak-app bundles:
1. Maybe do a new RC (see above)
2. In any branch's bundle.yml, set VM_RC_TAG in prepare-bundles job to the RC tag
How to make use of a new OSVM release in squeak-app bundles:
1. Maybe make a new VM release (see above)
2. Update the files in http://files.squeak.org/base/ for the Squeak versions of your choice
3. :warning: Watch out for minor differences between OSVM packaging and what vm-*.zip expects. For example, Linux has an extra indirection that needs to be removed. And those macOS .dmg packages have to be converted to .zip for squeak-app.
--
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/637
You are receiving this because you are subscribed to this thread.
Message ID: <OpenSmalltalk/opensmalltalk-vm/issues/637(a)github.com>
Hi all!
We just released the next version of the OpenSmalltalk VM.
Please find the binaries here:
https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202205110711 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202205110711]
(see VMMaker.oscog-mt.3184 and update.oscog-mt.6.mcm)
That version will be used in the upcoming Squeak 6.0 and also updated
bundles for Squeak 5.3. And probably in upcoming Cuis releases. :-)
Here is an attempt of a change log (since 2020):
- Adds ARMv8/Aarch64/ARM64 JIT incl. support for Apple M1
- Adds "fast C primitives" via #FastCPrimitiveFlag
- Adds support for catching exceptions in FFI callouts
- Adds #primitiveScreenScaleFactor (for DPI-aware images)
- Adds primitives 568 and 578 complementing 88 (primitiveSuspend)
- Adds #primitiveMultipleBytecodeSetsActive to update image format for SistaV1
- Adds VectorEnginePlugin
- Fixes regressions in ARMv6 support
- Fixes performance regressions of -metal and -opengl backends on macOS
- Fixes -core-graphics backend on macOS
- Fixes Retina scaling on macOS, i.e., support "backing scale factor"
- Fixes primitive 126 to fail on graphics backends w/o composition buffer
- Fixes regressions in vm-display-fbdev on Linux
- Fixes time sync (e.g., for DST) on Windows
- Fixes UDP binding on Windows
I am sure that I forgot something especially in plugin code. Please expand on this.
BIG THANKS to everybody who has worked on this release! Personally, I would like
to thank Eliot, who is a great software architect who keeps on making the OSVM
faster with every commit. Thank you!
Best,
Marcel (on behalf of the OSVM core dev team)
This I what I get in the VS2022 debugger. Of course, at the moment I do not understand the code there, but maybe hopefully Eliot can see something interesting in it. I leave VS open and look tomorrow at the code, maybe I understand a bit of it :-)
Seems there is something wrong with the forward pointers. I assume the longAt(referent) fails? I guess it is a macro, but VS could not find the definition.
########## Code area - the --> line is failing with access violation ###########
/* begin literalCountOfMethodHeader: */
assert((((header) & 7) == 1));
numLiterals = ((header >> 3)) & AlternateHeaderNumLiteralsMask;
numSlots = numLiterals + LiteralStart;
l9: /* end numStrongSlotsOf:format:ephemeronInactiveIf: */;
for (i = 0; i < numSlots; i += 1) {
referent = longAt((referrer + BaseHeaderSize) + (((sqInt)((usqInt)(i) << (shiftForWord())))));
if ((!(referent & (tagMask())))) {
/* a forwarding pointer could be because of become: or scavenging. */
--> if ((!((longAt(referent)) & ((classIndexMask()) - (isForwardedObjectClassIndexPun()))))) {
/* begin followForwarded: */
assert(isUnambiguouslyForwarder(referent));
/* begin fetchPointer:ofMaybeForwardedObject: */
referent1 = longAt((referent + BaseHeaderSize) + (0U << (shiftForWord())));
while (((!(referent1 & (tagMask()))))
&& ((!((longAt(referent1)) & ((classIndexMask()) - (isForwardedObjectClassIndexPun())))))) {
/* begin fetchPointer:ofMaybeForwardedObject: */
referent1 = longAt((referent1 + BaseHeaderSize) + (0U << (shiftForWord())));
}
referent = referent1;
########## Call stack ############
Squeak.exe!scavengeReferentsOf(__int64 referrer) Zeile 42680
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\src\spur64.cog\cointerp.c (42680)
Squeak.exe!scavengeRememberedSetStartingAt(__int64 n) Zeile 42760
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\src\spur64.cog\cointerp.c (42760)
Squeak.exe!scavengeLoop() Zeile 42542
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\src\spur64.cog\cointerp.c (42542)
Squeak.exe!doScavenge(__int64 tenuringCriterion) Zeile 47599
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\src\spur64.cog\cointerp.c (47599)
Squeak.exe!scavengingGCTenuringIf(__int64 tenuringCriterion) Zeile 57959
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\src\spur64.cog\cointerp.c (57959)
Squeak.exe!sufficientSpaceAfterGC(__int64 numBytes) Zeile 58691
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\src\spur64.cog\cointerp.c (58691)
Squeak.exe!checkForEventsMayContextSwitch(__int64 mayContextSwitch) Zeile 62762
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\src\spur64.cog\cointerp.c (62762)
Squeak.exe!handleStackOverflowOrEventAllowContextSwitch(__int64 mayContextSwitch) Zeile 66037
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\src\spur64.cog\cointerp.c (66037)
Squeak.exe!ceStackOverflow(__int64 contextSwitchIfNotNil) Zeile 15593
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\src\spur64.cog\cointerp.c (15593)
[Externer Code]
Squeak.exe!ioInitHeartbeat() Zeile 420
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\platforms\win32\vm\sqWin32Heartbeat.c (420)
Squeak.exe!interpret() Zeile 2875
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\src\spur64.cog\cointerp.c (2875)
Squeak.exe!sqMain(int argc, char * * argv) Zeile 1761
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\platforms\win32\vm\sqWin32Main.c (1761)
Squeak.exe!WinMain(HINSTANCE__ * hInst, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Zeile 1851
unter C:\Users\joerg\Persoenlich\Entwicklung\Squeak\vmssource\trunk\platforms\win32\vm\sqWin32Main.c (1851)
[Externer Code]
########## Locals ############
classFormat 662660168776 __int64
contextSize 72198296718755736 __int64
fmt 2 __int64
foundNewReferentOrIsWeakling 0 __int64
header 140698790658008 __int64
header1 140698758633160 __int64
i 37029628 __int64
newLocation 811789632 __int64
numLiterals 64 __int64
numSlots 167772160 __int64
numSlots1 255 unsigned __int64
numSlots2 167772160 unsigned __int64
objOop1 72057594139401638 __int64
referent 139599658561184 __int64
referent1 0 __int64
referrer 140700938141704 __int64
sp 72058702004626295 __int64
############## Second try ##################
I needed to restart it again, here are my new local values in debugger
classFormat 973468582328 __int64
contextSize 72198310804720808 __int64
fmt 2 __int64
foundNewReferentOrIsWeakling 0 __int64
header 140699864399832 __int64
header1 140698758633160 __int64
i 81749860 __int64
newLocation 2070121416 __int64
numLiterals 64 __int64
numSlots 335544320 __int64
numSlots1 255 unsigned __int64
numSlots2 335544320 unsigned __int64
objOop1 72057594296693111 __int64
referent 139620721982368 __int64
referent1 0 __int64
referrer 140711869546504 __int64
sp 72058702004626295 __int64
numSlots seems to me very wrong. If I do some calculations I get also not the same value that the debugger says me. Here is the code
numLiterals = ((header >> 3)) & AlternateHeaderNumLiteralsMask;
numSlots = numLiterals + LiteralStart;
AlternateHeaderNumLiteralsMask seems to be 0x7fff
LiteralStart seems to be 1
For me is:
numLiterals = ((140699864399832 >> 3)) & 0x7fff = 32763 —> does not match the debugger local, where is the 64 coming from
Seems to me somebody has overridden already the „header“ variable, which seems to be wrong. Could it be that some other thread is writing in the wrong memory area and override my values?
Jörg
########## System Information ##############
Gerätename timemachine
Prozessor AMD Ryzen 9 3900X 12-Core Processor 3.80 GHz
Installierter RAM 32,0 GB
Geräte-ID F6FA897B-DDB1-44D6-9BF3-8BD1110AA754
Produkt-ID 00326-10048-08575-AA867
Systemtyp 64-Bit-Betriebssystem, x64-basierter Prozessor
Stift- und Toucheingabe Für diese Anzeige ist keine Stift- oder Toucheingabe verfügbar.
Edition Windows 10 Home
Version 20H2
Installiert am 23.03.2021
Betriebssystembuild 19042.1526
Leistung Windows Feature Experience Pack 120.2212.4170.0
Visual Studio 2022
win64x64\squeak.cog.spur
VM version ??? I ask Eliot how i can see that on my current local github clone and post it later
############# Code for reproducation ##############
Simply execute the following Smalltalk code. Maybe you need to run it multiple times, for me the crash happens sometimes at the 3rd or 4th try.
| oc |
oc := OrderedCollection new.
400000000 timesRepeat: [oc add: Object new]
--
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/614
You are receiving this because you are subscribed to this thread.
Message ID: <OpenSmalltalk/opensmalltalk-vm/issues/614(a)github.com>
With libevdev, mouse and keyboard are bound to devices in /dev/input with names like "event0" and "event1".
Different keyboard/mouse hw binds to different numbers, so it is important to allow overrides via shell variables.
E.g.
SQUEAK_MSDEV=/dev/input/event1
SQUEAK_KBDEV=/dev/input/event0
vs
SQUEAK_MSDEV=/dev/input/event0
SQUEAK_KBDEV=/dev/input/event1
Mouse rebinding works, but not keyboard rebinding.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/575
My download folder looks pretty cluttered with names such as `squeak.cog.spur_win64x64 (3).zip`. I think it is a best practice to include the version/timestamp name of a build into the asset names. Could we maybe change the asset names to something like `osvm_202112201228_squeak.cog.spur_win64x64.zip`?
--
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/610
You are receiving this because you are subscribed to this thread.
Message ID: <OpenSmalltalk/opensmalltalk-vm/issues/610(a)github.com>
Hi Jaromir,
> On May 11, 2022, at 5:49 AM, Jaromir Matas <mail(a)jaromir.net> wrote:
>
>
>
> Hi Eliot,
>
> > > On Tue, May 10, 2022 at 1:36 PM Jaromir Matas <mail(a)jaromir.net> wrote:
> > > Hi Eliot,
> > >
> > > Thanks a lot for your answers.
> > >
> > > One last question: what about Process >> #signalException:? You wrote a fix (enclosed) – is it ok to merge it when the #suspend method is updated (Nicolas’s way)?
> > >
> >
> > Yes, I think so. We have to test it but it seems right. And we can go even simpler, just have the first clause as guarded by processSuspensionUnblocks ifFalse:, once we're ready to release on VMs with the new primitive.
> >
>
> Thanks again; this brings me to another question: if you go simpler, i.e. with the ifFalse clause only, it would mean the method wouldn't work correctly with older VMs with the older prim 88 suspend semantics. I was under the impression to keep compatibility with older VMs but maybe it's a nonsensical assumption on my part (The reason I'm asking is the #terminate I wrote is compatible with both the new and old VMs - but could be simplified a bit if the old VMs were not supposed to be used with the new images).
That’s the way backwards compatibility works, with images and VMs in the same way as binaries and processors. A VM is expected to be backwards compatible with all older images of the same basic version (eg the Spur format, the V3 format). So all Spur 4.6, 5.x & current 6.x images should run on the current tip VM. But a new image may expect a feature added to a contemporary VM that is absent in previous versions of the VM.
This is analogous to, for example, binaries compiled against newer instructions added to the x86 such as mmx, sse 1, 2 & 3. We expect that the new processor can run older binaries; we do not expect new binaries to run on older processors unless we compile them specially.
Now, at a major release we may decide to remove VM features, but at that point we would change the VM’s image format number so that older images do not load. Since this effectively introduces a new VM variant it is not something we do lightly and do only when compelling, as the performance and functionality improvements obtained from the Spur architecture are over V3.
We’re currently thinking about this with high dpi support. Can we afford to provide backwards compatibility with older “high dpi unaware” (HDU) images or not? We can either freeze Spur VM support for older images at around March this year, and drop support for HDU images in the platform sources, or we can add a flag bit to the image flags in the latest VMs which if set identifies an image as “high dpi aware” (HDA), and set the bit, eg in a Monticello package load script. And then the VM can remain backwards compatible by testing the HDA bit, behaving like older VMs if unset.
It is desirable to maintain backwards compatibility if we can afford the engineering effort. But note that considerable engineering effort must be extended either way. For example, the Virtend application would require considerable work to migrate to HDA, being HDU currently.
This is a structural issue. Putting the effort into the HDA VM to provide backwards compatibility with HDU images supports all older HDU applications. Not putting the effort means that all older HDU applications must put effort in to move forwards. (This is because the VM is the platform supporting applications above it, just as the trunk image is a platform that supports applications built within it). Hence it’s my preference to put the effort into the VM (selfishly as I’m committed to keeping the Virtend application running).
What kinds of effort are we talking about? It’s not just having a flag to test and having the VM answer/respond appropriately for HDU if unset and for HDA if set. The flag needs to be tested very early in start up, potentially in the current sources before the image has been loaded. Eg on Linux one can supply a command line argument specifying the display subsystem to use which comes before the image name. So command line parsing must be able to make a pass through the arguments to find the image, locate the flags in the header, determine the value of the HDA flag, and then go back and actually process the command line arguments. Tedious work ;-)
>
> Thanks,
>
> Jaromir
>
> --
> Jaromír Matas
> mail(a)jaromir.net
>
> From: Eliot Miranda
> Sent: Tuesday, May 10, 2022 23:21
> To: The general-purpose Squeak developers list
> Subject: Re: [squeak-dev] SIGTRAP when Proceeding from BlockCannotReturn
>
>
>
> On Tue, May 10, 2022 at 1:36 PM Jaromir Matas <mail(a)jaromir.net> wrote:
> Hi Eliot,
>
> Thanks a lot for your answers.
>
> One last question: what about Process >> #signalException:? You wrote a fix (enclosed) – is it ok to merge it when the #suspend method is updated (Nicolas’s way)?
>
> Yes, I think so. We have to test it but it seems right. And we can go even simpler, just have the first clause as guarded by processSuspensionUnblocks ifFalse:, once we're ready to release on VMs with the new primitive.
>
>
> Thanks again,
> Jaromir
>
> --
>
> Jaromír Matas
>
> +420 777 492 777
> mail(a)jaromir.net
>
>
> From: Eliot Miranda
> Sent: Tuesday, May 10, 2022 21:17
> To: The general-purpose Squeak developers list
> Subject: Re: [squeak-dev] SIGTRAP when Proceeding from BlockCannotReturn
>
> Hi Jaromir,
>
> On Tue, May 10, 2022 at 8:31 AM Jaromir Matas <mail(a)jaromir.net> wrote:
> Hi Eliot, Nicolas,
>
> > > > (Eliot) Apologies for not responding sooner. It seems to me the semantics must remain as they are, and it be left up to the image to bind suspend to the primitive most convenient. Then backwards compatibility can be provided for cases such as DelayWaitTimeout by providing a renamed suspend which accesses the old primitive.
> > >
> > > (Nicolas) Yes, I propose the selector
> > Process>>suspendAndUnblock <primitive: 78> snip...
> > Process>>suspend would call the new primitive, and fallback to suspendAndUnblock in case of failure (for example if new primitive is absent).
> > The question remaining is if we really need two new primitives 578 (V1) and 588 (V2).
> > It seems like signalException: would require V1, while Jaromir terminate logic would require V2...
> >
> > (Eliot) +1. Works for me. Having both 578 & 588 available in the VM is fine. I agree that surfacing only one of them is best.
>
> Thank you, I wasn't sure how to proceed with this :) Do I understand correctly #suspend will have the new suspend semantics (either V1 or preferably V2) in new images (new release) and the previous semantics (via prim 88) will be available for backward compatibility (or special usage)?
>
> Yes, exactly.
> In that case the tests I submitted in KernelTests-jar.421 should work without changes...
>
> Cool!
>
> The next question is what to do with:
> Process >> suspendPrimitivelyOrFail
> "Test support. Execute primitive 88, or fail."
>
> <primitive: 88>
> ^self primitiveFailed
>
> Change it or remove it? Replace with Nicolas’s Process>>suspendAndUnblock ?
>
> Well it appears to be used only in testAtomicSuspend. So I would change it to use the same primitive number as suspend, which I guess is 578, primitiveSuspendBackingUpV2, which has the more consistent semantics.
>
>
> Thanks!
>
> Best,
>
> Jaromir
>
> From: Eliot Miranda
> Sent: Monday, May 9, 2022 23:23
> To: The general-purpose Squeak developers list
> Subject: Re: [squeak-dev] SIGTRAP when Proceeding from BlockCannotReturn
>
>
>
>
> On May 9, 2022, at 1:04 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote:
>
>
>
> Hi Eliot,
> Le lun. 9 mai 2022 à 20:36, Eliot Miranda <eliot.miranda(a)gmail.com> a écrit :
> Hi Jaromir, Hi Nicolas,
>
> On Sun, May 8, 2022 at 8:17 AM Jaromir Matas <mail(a)jaromir.net> wrote:
> Hi Nicolas,
>
> >> About the latest VM, (Smalltalk processSuspensionUnblocks) answers about the behavior of primitiveSuspend (#88).
> > Err, wrong wording (Smalltalk processSuspensionUnblocks) does not describe the behavior of primitiveSuspend #(88).
> > It answers whether the VM has primitives #578 and #588 (see #getCogVMFeatureFlags in VMMaker)...
> >
> Yes, thanks, well that was the original idea for Smalltalk processSuspensionUnblocks to answer about the behavior of the primitiveSuspend #88; which was before the primitives #568 and #578 were introduced. (And which was when I wrote the tests using this original logic). However that approach ran into problems with some existing implementations (e.g. Virtend) and as a result the two new primitives were introduced (#568 and #578) - and apparently the logic of what Smalltalk processSuspensionUnblocks answers about changed. Since then I haven't heard from Eliot about his plans how to proceed with the new suspend semantics or whether this is it :)
>
> Apologies for not responding sooner. It seems to me the semantics must remain as they are, and it be left up to the image to bind suspend to the primitive most convenient. Then backwards compatibility can be provided for cases such as DelayWaitTimeout by providing a renamed suspend which accesses the old primitive.
> Yes, I propose the selector
> Process>>suspendAndUnblock <primitive: 78> snip...
> Process>>suspend would call the new primitive, and fallback to suspendAndUnblock in case of failure (for example if new primitive is absent).
> The question remaining is if we really need two new primitives 578 (V1) and 588 (V2).
> It seems like signalException: would require V1, while Jaromir terminate logic would require V2...
>
> +1. Works for me. Having both 578 & 588 available in the VM is fine. I agree that surfacing only one of them is best.
>
>
>
> Sorry about not renaming processSuspensionUnblocks. This should be something like Smalltalk hasExtendedProcessSuspensionSemantics or some such.
>
> It's not too late, there are not many usages, except inbox experimentations.
>
>
>
>
> In case this is still WIP I'd quite like an approach similar to Smalltalk processPreemptionYields - you'd set Smalltalk processSuspensionUnblocks true or false depending on how you want the VM to behave and the VM would use the right semantics (unless this is too naive :) ).
>
> Regarding the tests failing with the newest VM:
> testAtomicSuspend - we can remove this updated version and leave the existing one for the moment
> testRevisedSuspendExpectations - we can leave this one out too
> testTerminateBlockedInNestedEnsure1 - I'll take a look at these two and try to adjust the logic
> testTerminateBlockedInNestedEnsure2
>
> All remaining test in KernelTests-jar.421 work as intended.
>
> Thanks again,
> Jaromir
>
> --
>
> Jaromír Matas
>
> mail(a)jaromir.net
>
>
> From: Nicolas Cellier
> Sent: Sunday, May 8, 2022 16:22
> To: The general-purpose Squeak developers list
> Subject: Re: [squeak-dev] SIGTRAP when Proceeding from BlockCannotReturn
>
>
>
> Le dim. 8 mai 2022 à 15:59, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> a écrit :
>
>
> Le dim. 8 mai 2022 à 14:16, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> a écrit :
> Hi Jaromir
>
> Le sam. 7 mai 2022 à 14:45, Jaromir Matas <mail(a)jaromir.net> a écrit :
> Hi Marcel, Nicolas, Eliot,
>
>
> > (Nicolas) I have merged Kernel-jar.1446 which is trivial (re-signal an Exception).
>
> Thanks!
>
> > (Marcel) Hmm... #testSimpleResignalVsOuter1 is still failing.
>
> In my latest trunk image it passes ok (5/7/22)
>
> >> (Marcel) I will also take a look at KernelTests-jar.421 to check whether any new semantics are okay.
> >>
> > (Nicolas) Yes, I did that and got two failing tests
> > testTerminateTerminatingProcess
> > testResumeTerminatingProcess
> >
> > both failures look the same, in second self assert: terminator isSuspended.
>
> Yes, they are supposed to fail at the moment so I suggest to make them expected failures/feature requests. However there's a stupid bug in both I’ve fixed now: they were indeed supposed to fail the following assertion:
> ``` self should: [terminatee terminate] raise: Error. ```
>
> Apologies for the confusion - an updated changeset is enclosed.
>
>
> However, there's another issue regarding the revised #suspend semantics Eliot has been working on. I've updated the process tests in KernelTests-jar.421 to test both the old and the new #suspend semantics. The two semantics should be distinguishable via Smalltalk processSuspensionUnblocks flag answering true in case of the old semantics and false in case of the revised one; my updated tests use this logic. However, unfortunately the latest VM answers "false" but uses the OLD suspend semantics in #suspend prim 88.
>
> So I'm surprised you haven't observed more tests failing due to the new suspend semantics... What VM have you used – an older one? I'm on the latest trunk's VM 3183. And what is the answer of Smalltalk processSuspensionUnblocks? :) I'm utterly confused...
>
> Hi Eliot - I may be confused here but if the current VM uses the old #suspend prim 88 semantics, shouldn't ```Smalltalk processSuspensionUnblocks``` answer true?
>
>
> Indeed, I can confirm that the latest VM does answer false to (Smalltalk processSuspensionUnblocks).
> Though, process suspension still unblocks as shown by the example at
> https://github.com/pharo-project/pharo/issues/10669
>
> A bit more simply, this answers false - it shouldn't:
>
> s := Semaphore new.
> p := [s wait] newProcess.
> p resume.
> 100 milliSeconds wait.
> p suspend; resume.
> 100 milliSeconds wait.
> p isTerminated = Smalltalk processSuspensionUnblocks.
>
> technically, this answers false - it shouldn't:
>
> s := Semaphore new.
> p := [s wait] newProcess.
> p resume.
> 100 milliSeconds wait.
> p suspend == s = Smalltalk processSuspensionUnblocks
>
>
> About the latest VM, (Smalltalk processSuspensionUnblocks) answers about the behavior of primitiveSuspend (#88).
> Err, wrong wording (Smalltalk processSuspensionUnblocks) does not describe the behavior of primitiveSuspend #(88).
> It answers whether the VM has primitives #578 and #588 (see #getCogVMFeatureFlags in VMMaker)...
>
> The new Behavior is implemented by primitiveSuspendBackingUpV1 (#578) and primitiveSuspendBackingUpV2 (#588).
> V1 always answers the old list (even if a Semaphore/Mutex), V2 answers nil in case of Semaphore/Mutex.
>
> So, only ((Process>>#suspend) primitive) can give you a clue about the behavior, assuming that the primitive in question is implemented...
>
> So it depends if we want to make it a Preference, or make the image compatible with some less capable VM...
>
> we could implement
> Process>>primitiveSuspendAndUnblock as <primitive: 88>
> Process>>primitiveSuspend as <primitive: 588>
> test the VM flag in suspend
> Process>>suspend
> ^(VMHasPrimitiveSuspendBackingUp ifNil: [VMHasPrimitiveSuspendBackingUp := Smalltalk processSuspensionUnblocks not])
> ifTrue: [self primitiveSuspend]
> ifFalse: [self primitiveSuspendAndUnblock]
> Then arrange to reset VMHasPrimitiveSuspendBackingUp to nil at snapshot...
>
> I will tell next week about the status of the VM which I used for testing, it's possibly a few months old.
>
> > (Nicolas) I would also consider 1445 1421 and most importantly 1447.
>
> Regarding 1421: alternatively, you might consider a newer version 1415 where the only difference is #return:from: passes a block instead of nil to #resume:through: to cause a fresh search for the first unwind context; otherwise they are equivalent.
>
> OK, I will check again.
>
> > (Marcel) Maybe we can just merge
> >
> > KernelTests-jar.393
> > KernelTests-jar.418
> > KernelTests-jar.421
> >
> > And go from there? Or are there any objections?
>
> KernelTests-jar.393 is just a special case of a more general KernelTests-jar.418 test…
>
> In my image all tests are green provided Smalltalk processSuspensionUnblocks answers true and the two above tests Nicolas mentioned are marked expected failures :)
>
> Thanks very much for your feedback,
> Jaromir
>
> --
>
> Jaromír Matas
>
> mail(a)jaromir.net
>
>
>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
The return value of `primitiveImageFormatVersion` is hard-coded and does not consider the value of `multipleBytecodeSetsActive`, which is indeed important when trying to open a particular image with a particular VM.
See:
- Interpreter >> #imageFormatVersion
- StackInterpreter >> #imageFormatVersion
- ObjectMemory >> #imageFormatVersion
- Spur32BitMemoryManager >> #imageFormatVersion
- Spur64BitMemoryManager >> #imageFormatVersion
Note that this can be fixed on the image-side by checking primitiveMultipleBytecodeSetsActive.
--
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/638
You are receiving this because you are subscribed to this thread.
Message ID: <OpenSmalltalk/opensmalltalk-vm/issues/638(a)github.com>