Vm-dev May 2021

vm-dev@lists.squeakfoundation.org

21 participants
56 discussions

(no subject)
by Florin Mateoc 20 May '21

20 May '21

thinking some more about it, I think the implementation should respect the comment. Clearly, as it is, we can put the same process on multiple lists, which seems very wrong. Also, a process that stopped executing by waiting on a semaphore has started executing again without the semaphore being signalled, and with the process still on the semaphore's list. | evaluationProcess result sema testProcess | sema := Semaphore new. testProcess := Processor activeProcess. result := OrderedCollection new. evaluationProcess := [ result add: testProcess isBlocked. testProcess resume. result add: testProcess isBlocked. result add: (sema includes: testProcess). ] fork. sema wait. result

1 0

[OpenSmalltalk/opensmalltalk.github.io] the opensmalltalk.org web site no longer works (#1)
by Alan Zimmerman 19 May '21

19 May '21

It goes to a github "site not found" page -- 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.github.io/issues/1

4 5

VM build seems to be broken
by tim Rowledge 17 May '21

17 May '21

I was going to try making a debug vm to dive into gdb and hunt the `2 raisedTo: 63` bug recently discussed but the latest source download off git simply will not build. I think either Dave or Bruce noticed this recently. The error I see starts with complaining about build/config.h being included to late. That breaks everything later. I seem to remember reading some mail going by a while ago that might have related to this but I didn't have time to pay much attention. If the people that have been changing things here could please examine their memories and consider what might solve this I would be most grateful. There's two issues needing work (2 raisedTo: 63 & Ben's bitblt speedups) that can't be done without a fix. tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Throughout history, every mystery solved has turned out to be… *not magic*

2 1

Question on VM for Apple's M1
by Rafael Ignacio Matías Sniechowski 16 May '21

16 May '21

Hi, Hope you are all well, Just subscribed to the list. I mostly use Cuis-Smalltalk which uses the same VM as Squeak. I was wondering if there are plans to release a VM specifically for the new Apple M1 arm64 chip. I read somewhere that they were experimenting on one for Pharo 9. Thanks in advance Cheers Nacho *Ignacio Sniechowski*

2 2

ARMv8 BitBLT speedups provided by RPi/Ben Avison
by tim Rowledge 12 May '21

12 May '21

Our friends in Cambridge (Real Cambridge, not Backup Cambridge) have spent a nice chunk of money to bring the ARM32 bitblt speedups they provided in '14/5/6 into the ARMv8 world. Quite a few microbenchmarks covering the tests Ben did (and he wrote a testing framework that ran some 10s of thousands of tests) are improved by an order of magnitude, some by 30X and one by 57X ! All the code to date is pushed to https://github.com/bavison/opensmalltalk-vm/tree/Ben with the latest version of the test harnesses at https://github.com/bavison/SqueakBitBltTest Look for items changed in the last few days ie 25th april or later. I haven't had a chance to do more than glance as yet. I *suspect* Ben has manually edited the generated BitBltPlugin.c file, which will mean doing some diffing and back-porting into Slang. Maybe. I, for one, welcome our new v8 blit overlords. tim tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim "#define QUESTION ((bb) || !(bb)) - Shakespeare."

3 4

VM Maker: VMMaker.oscog-eem.2958.mcz
by commits＠source.squeak.org 11 May '21

11 May '21

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2958.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.2958 Author: eem Time: 10 May 2021, 7:19:28.320827 pm UUID: 972e62ae-ea8b-4399-8619-b0e9e01d83de Ancestors: VMMaker.oscog-eem.2957 spelling in a comment only. this is not the commit you're looking for. =============== Diff against VMMaker.oscog-eem.2957 =============== Item was changed: ----- Method: Spur32BitMemoryManager>>objectAfterMaybeSlimBridge:limit: (in category 'object enumeration-private') ----- objectAfterMaybeSlimBridge: objOop limit: limit "Object parsing. 1. all objects have at least a word following the header, for a forwarding pointer. 2. objects with an overflow size have a preceding word with a saturated numSlots. If the word following an object doesn't have a saturated numSlots field it must be a single-header object. If the word following does have a saturated numSlots it must be the overflow size word. This variation on objectAfter:limit: allows for a single (64-bit) word bridge which may be needed + to bridge from an almost full pastSpace to eden. It is only used in the flat enumerators that use - to bridge from an almost full pastSpace to eden. It is ony used in the flat enumerators that use startAddressForBridgedHeapEnumeration and enumerate over pastSpace, eden and oldSpace in that order. Note that the order for allObjects, and allInstances enumerates over oldSpace first. This hack is cheap. It increases the size of the objectAfter code, but saves two extra copies of the inner loop, since the inner loop now enumerates over all of pastSpace, eden and oldSpace. The test for a slim bridge is only performed if applied to an overflow header, and typically only 1 in 400 objects have overflow headers in 32-bits, 1 in 500 in 64-bits." <inline: true> | followingWordAddress followingWord | followingWordAddress := self addressAfter: objOop. (self oop: followingWordAddress isGreaterThanOrEqualTo: limit) ifTrue: [^limit]. self flag: #endianness. followingWord := self longAt: followingWordAddress + 4. ^followingWord >> self numSlotsHalfShift = self numSlotsMask ifTrue: [1 = (self longAt: followingWordAddress) "i.e. the raw overflow slots in the overflow word" ifTrue: [followingWordAddress + self baseHeaderSize + self baseHeaderSize] ifFalse: [followingWordAddress + self baseHeaderSize]] ifFalse: [followingWordAddress]! Item was changed: ----- Method: Spur64BitMemoryManager>>objectAfterMaybeSlimBridge:limit: (in category 'object enumeration-private') ----- objectAfterMaybeSlimBridge: objOop limit: limit "Object parsing. 1. all objects have at least a word following the header, for a forwarding pointer. 2. objects with an overflow size have a preceding word with a saturated numSlots. If the word following an object doesn't have a saturated numSlots field it must be a single-header object. If the word following does have a saturated numSlots it must be the overflow size word. This variation on objectAfter:limit: allows for a single (64-bit) word bridge which may be needed + to bridge from an almost full pastSpace to eden. It is only used in the flat enumerators that use - to bridge from an almost full pastSpace to eden. It is ony used in the flat enumerators that use startAddressForBridgedHeapEnumeration and enumerate over pastSpace, eden and oldSpace in that order. Note that the order for allObjects, and allInstances enumerates over oldSpace first. This hack is cheap. It increases the size of the objectAfter code, but saves two extra copies of the inner loop, since the inner loop now enumerates over all of pastSpace, eden and oldSpace. The test for a slim bridge is only performed if applied to an overflow header, and typically only 1 in 400 objects have overflow headers in 32-bits, 1 in 500 in 64-bits." <inline: true> | followingWordAddress followingWord | followingWordAddress := self addressAfter: objOop. (self oop: followingWordAddress isGreaterThanOrEqualTo: limit) ifTrue: [^limit]. self flag: #endianness. followingWord := self longAt: followingWordAddress. ^followingWord >> self numSlotsFullShift = self numSlotsMask ifTrue: [(followingWord bitAnd: 16rFFFFFFFFFFFFFF) = 1 ifTrue: [followingWordAddress + self baseHeaderSize + self baseHeaderSize] ifFalse: [followingWordAddress + self baseHeaderSize]] ifFalse: [followingWordAddress]! Item was changed: ----- Method: SpurMemoryManager>>objectAfterMaybeSlimBridge:limit: (in category 'object enumeration-private') ----- objectAfterMaybeSlimBridge: objOop limit: limit "Object parsing. 1. all objects have at least a word following the header, for a forwarding pointer. 2. objects with an overflow size have a preceding word with a saturated numSlots. If the word following an object doesn't have a saturated numSlots field it must be a single-header object. If the word following does have a saturated numSlots it must be the overflow size word. This variation on objectAfter:limit: allows for a single (64-bit) word bridge which may be needed + to bridge from an almost full pastSpace to eden. It is only used in the flat enumerators that use - to bridge from an almost full pastSpace to eden. It is ony used in the flat enumerators that use startAddressForBridgedHeapEnumeration and enumerate over pastSpace, eden and oldSpace in that order. Note that the order for allObjects, and allInstances enumerates over oldSpace first. This hack is cheap. It increases the size of the objectAfter code, but saves two extra copies of the inner loop, since the inner loop now enumerates over all of pastSpace, eden and oldSpace. The test for a slim bridge is only performed if applied to an overflow header, and typically only 1 in 400 objects have overflow headers in 32-bits, 1 in 500 in 64-bits." ^self subclassResponsibility!

1 0

Re: [Vm-dev] [squeak-dev] 2 raisedTo: 63 on Pi returns 0 ? (was Re: how to determine available RAM?)
by Vanessa Freudenberg 10 May '21

10 May '21

I think we really ought to move the discussion over to the experts at vm-dev. CC’ed. –Vanessa– On Mon, May 10, 2021 at 03:55 Bruce O'Neel <bruce.oneel(a)pckswarms.ch> wrote: > Hi, > > So, um, kind of good news but maybe not. > > So I built a collection of different VMs on ARM64 and the most recent > build is below. The stack VM gives the right answer, the cog one not. > The dates are the dates of the most recent commit from the git repository. > > 2020/03/24 - Cog VM does not build, stack vm builds with the right answer. > 2021/01/09 - Both stack and cog VMs build. Stack VM gives the right > answer. > 2021/03/24 - Both stack and cog VMs build. Stack VM gives the right > answer. > > All of this on a Ubuntu 18.04 based system with Gcc 7.5.0 on an NVIDIA > Jetson Nano which has A57 cores. > > I also in all cases with the cog VMs I tested the debug build as well in > hopes that it was a GCC optimization problem, but, alas, no luck there. > > Tim, is it possible to try a stack build and see if that gives the correct > answer for you? > > Thanks. > > bruce > > > > > > [image: image.png] > > > > *09 May 2021 19:56 tim Rowledge <tim(a)rowledge.org <tim(a)rowledge.org>> > wrote:* > > > > > On 2021-05-09, at 7:31 AM, David T. Lewis wrote: > > > > > If the primitive is failing for 16r80000000 squared, then I wonder if we > > may be looking at a signed/unsigned arithmetic problem somewhere in the > > plugin. > > Ah, but that is the extra-weird bit. It *sometimes* gives the right > answer. The only thing I can think of that could explain that & that might > be ARM64 code specific is something to do with the address of the LPI, > which obviously is sometihng that varies with each test. If there is some > code expecting base addresses to always match some requirement and that is > not always being met, subsequent code might be reading the wrong values. > > Another possibility is that the compiled result of the LI plugin has a > bug; it's not like C compilers never get it wrong. > > Another possibility must be that I screwed up somewhere and the 'correct' > result I saw was not actually with the prim enabled - but I'm fairly sure I > did that in a different image anyway. Grr. > > And now I do more testing, and I haven't yet got the right answer again > for 16r80000000 squared. > 16r80000001 squared always seems to be ok. 16r[9ABCDEF]0000000 squared > always seems to be ok. And 16r[7654321]0000000 squared always seems to be > right. > > Also 16r40000000 squared * 4 seems always ok. So we're rather pointed to > some peculiarity of the 16r80000000 bit-pattern? My brian hurts. > > tim > -- > tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim > Strange OpCodes: SG: Show Garbage > > > > > >

1 0

[OpenSmalltalk/opensmalltalk-vm] [Win10] [Squeak] High CPU usage in different images for a few minutes after resume from sleep (#537)
by Christoph Thiede 08 May '21

08 May '21

I noticed this a few times, and today I observed it a bit: After resuming my Win10 message from sleep, my two open Squeak.exe processes both made up each ~14% CPU load. I suspect this performance gap is caused by the VM because, in one image, a nearly empty Morphic world was open (two non-stepping windows only) and in the other one, a completely empty MVC world; both images were responsive; and according to Squeak's CPU watcher, only ~20% of time were spent in the UI process but 80% in idle. After a few minutes, both VM instances fall back to ~0.1% of total CPU usage. Is there any chance to find an explanation for this behavior in the VM implementation, are there any hidden background operations (maybe certain WM_MESSAGES) that are triggered after resuming from sleep? Does anyone else notice similar behavior? For sake of completeness, I should mention that my RAM and disk usage are chronically near maximum (90% of RAM in use, 25 GB on SSD free. Squeak images are so large 😐). But this does not change after a few minutes so I don't think it explains the observed slowdown completely. VM build 202010232046; but I could already have experienced similar issues a few months ago. -- 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/537

2 2

[OpenSmalltalk/opensmalltalk-vm] fc4b69: MacOS builds: get applications built under a newer...
by Eliot Miranda 07 May '21

07 May '21

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: fc4b69a7c16899244a3cfde95297d140d9889fc8 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/fc4b69a7c16899244a… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2021-05-06 (Thu, 06 May 2021) Changed paths: M build.macos64ARMv8/common/Makefile.flags M build.macos64ARMv8/common/Makefile.vm M build.macos64x64/common/Makefile.flags M build.macos64x64/common/Makefile.vm Log Message: ----------- MacOS builds: get applications built under a newer version (e.g. 11.x) to run on the version specified by TARGET_VERSION_MIN. Previously they were being compiled with TARGET_VERSION_MIN specified, but not linked. [ci skip]

1 0

[OpenSmalltalk/opensmalltalk-vm] Fix UDP binding in Windows sockets (#563)
by jdougan 05 May '21

05 May '21

Changed sqSocketListenOnPortBacklogSizeInterface() to match general behavior of Unix socket version. Previously was always incorrectly binding UDP sockets to INADDR_ANY instead of the specified IPv4 address. You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/563 -- Commit Summary -- * Changed sqSocketListenOnPortBacklogSizeInterface() to match general -- File Changes -- M platforms/win32/plugins/SocketPlugin/sqWin32NewNet.c (2) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/563.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/563.diff -- 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/pull/563

4 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev May 2021