Vm-dev February 2021

vm-dev@lists.squeakfoundation.org

17 participants
63 discussions

[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

regression: TestObjectsAsMethods crash in 4.19.5 (not in 4.16.7)
by stes＠PANDORA.BE 21 Mar '21

21 Mar '21

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 As can be seen in the screenshot at: http://docs.openindiana.org/handbook/community/squeak/index.html I'm deselecting the Tests-ObjectsAsMethods test (1 test), because it causes (reproducible) SIGSEGV on Solaris cc/OpenIndiana gcc. I think the segmentation fault is new in recent 4.19, I think it didn't happen a while ago in 4.16. I can test this as follows: when I install an older version squeak -version 4.16.7-3775 then I go into test runner: Tests-ObjectsAsMethods and select TestObjectsAsMethods that works in 4.16.7 Test Runner ... TestObjectsAsMethods 3 run, 3 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes But it stopped working in 4.19.x which is from I believe from: ContextInterpreter VMMaker-dtl.422 uuid: e72b95a0-204e-45a1-a4e4-3ac3c9e7a51a the interp.c file is automatically generated from VMMaker-dtl.422. It's reproducible in the sense that if I deselect all tests, and just select that one single test, I can repeatedly and reproducible SIGSEGV the VM. When I run the VM under a debugger: dbx: warning: Bad transition in runtime linker interface. CONSISTENT->CONSISTENT t@1 (l@1) signal SEGV (no mapping at the fault address) in interpret at line 9120 in file "interp.c" 9120 foo->freeContexts = longAt((newContext + (BASE_HEADER_SIZE)) + (0 << (SHIFT_FOR_WORD))); (dbx) where current thread: t@1 =>[1] interpret(), line 9120 in "interp.c" [2] main(argc = 1, argv = 0xfeffe250, envp = 0xfeffe258), line 1484 in "sqUnixMain.c" The above is from Solaris with cc/dbx but the same thing appears to happen for me on OpenIndiana with gcc/gdb. Unfortunately because the code of interp.c is automatically generated, it looks complicated to me and I don't see what's wrong with those " freeContext" code. The crash appears to be in: /* begin internalActivateNewMethod */ methodHeader = longAt((foo->newMethod + (BASE_HEADER_SIZE)) + (HeaderIndex << (SHIFT_FOR_WORD))); needsLarge = methodHeader & LargeContextBit; if ((needsLarge == 0) && (foo->freeContexts != NilContext)) { newContext = foo->freeContexts; /* begin setFreeContextsAfter: */ foo->freeContexts = longAt((newContext + (BASE_HEADER_SIZE)) + (0 << (SHIFT_FOR_WORD))); } else { /* begin externalizeIPandSP */ Has anyone seen this ? Also what is the test TestObjectsAsMethods actually doing please ? what is it testing ? Regards, David Stes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJgMnV5AAoJEAwpOKXMq1MafEgH/3EWQxaSaVm2g4r/2p99Wc21 P+U+ijqKpVTDfJ1smwV/GsgF0V8ZrZky0k7BzRDAyq3Gi/HGVm0e2bqOAKa1fo2Y MUS9JHOW4Lys+9qWgT0aLiWypjYlzThtYS0/Lfh013tsF1bBv2eppTceUyq/Zitv 6J0IFvDOspMN/zHwBw/ux3H6uR049boZ3mvk23sp3KIHDc2Yw2kF4TAXBwjZXmVO UFlIAC4EAahrtNZyLZSIBDbsXOl+wJGmQTsOIBG81pfSFpP6RBrIARcu6enZC3Wc bwsvWYADs49SKgVq3NBovfyzkZBIW30V82xlVKpOnp6A4FnOYXxQiVm9sNaOVXc= =34TJ -----END PGP SIGNATURE-----

5 20

unix SqueakSource socket 'too many open files' problem
by tim Rowledge 02 Mar '21

02 Mar '21

I've been running a squeaksource system on a 64bit linux server for a year or so and just started having odd problems. Talking with Chris about it, and looking into the assorted logs, lead to the theory that sometihng (unknown and I can't see how possible) caused the image to save and quit at some point when the expected behaviour is to *not* ever save. That lead to some complaints about Magma related details that don't matter here. I had much fun (the usual linux user names/permissions stuff) but eventually got a new copy of the squeaksource image running. Yay! Except after an indeterminate time (several hours, not a whole day) the webpage part of the sytem became unaccessible even though it had not actually crashed out. The log contained a bunch of lines like this - 3729ab18e70dac 2021-02-24T23:37:53.41687-05:00 CurrentEnvironment: @40000000603729ab18e71d4c 2acceptHandler: Too many open files @4000000060379f1127814ddc acceptHandler: aborting server 12 pss=0x14df900 @4000000060379f112782dc4c socketStatus: freeing invalidated pss=0x14df900 @400000006037b1ef0d99c214 acceptHandler: Too many open files @400000006037b1ef0d9a5e54 acceptHandler: aborting server 12 pss=0x7f2f8c8d4630 @400000006037b1ef0d9c7194 socketStatus: freeing invalidated pss=0x7f2f8c8d4630 ... which are errors from the VM socket handlers. I've not seen this happening before that I recall. Any ideas? Stuff to check? Solutions? tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Strange OpCodes: TDB: Transfer and Drop Bits

6 14

[OpenSmalltalk/opensmalltalk-vm] c53f3e: Mac builds:
by Eliot Miranda 24 Feb '21

24 Feb '21

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: c53f3e77564d1f5c128aa30a01fc601568bc3470 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c53f3e77564d1f5c12… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2021-02-23 (Tue, 23 Feb 2021) Changed paths: M build.macos32x86/common/Makefile.app M build.macos64ARMv8/common/Makefile.app M build.macos64x64/common/Makefile.app Log Message: ----------- Mac builds: To reliably codesign xattr must be used to remove finder info etc. Also sign the bundles in both ARMv8 and x86. [ci skip]

1 0

MultiCore [response to: partially Squeak based OS]
by ken.dickey＠whidbey.com 21 Feb '21

21 Feb '21

Other useful idea mines: L4 microkernel and Genode UI: https://microkerneldude.wordpress.com/2019/03/07/how-to-and-how-not-to-use-… https://genode.org/about/index -- multiple concurrent window systems https://sel4.systems/ -- very fast message based IPC (think multiple VM spaces) Just thinking of making multicore more useful & robust.. I think Aarch64 and particularly RISC-V are more useful starting points, BTW. (BeagleV is coming soon.. https://beagleboard.org/beaglev :) $0.02, -KenD

1 0

Squeak VM update on OpenIndiana
by stes＠PANDORA.BE 21 Feb '21

21 Feb '21

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, Here's some news on Squeak on "OpenIndiana". OpenIndiana is an illumos based operating system derived from OpenSolaris; Current upgrades in the repository, http://pkg.openindiana.org/hipster/en/index.shtml squeak-4 : version 4.19.5 squeak-5 : version 5.0.2945 There are packages for 'headless' (-nodisplay) operation and with GUI. I've made up the version 5.0.2945 myself this corresponds roughly to VM Maker: VMMaker.oscog-eem.2945 This is because normally there is a 3 digit version number, but for OpenSmalltalk VM I just use the number 5.0.2945. Special thanks to everybody in the "Squeak" and "opensmalltalk-vm" team. Thanks, David Stes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJgKUmSAAoJEAwpOKXMq1MaVh4IAJtxIumLVPANaFvcq7EXuHtw 1VRYnkdlessPYq05efp3sl2PV5fRGXMINCB4ZQKHjrzppoisEtX2BNql5mEF6B+A n24lOWC0Df7C+4wjoXYaBosswLa3y6wzLh4l8nDjECLEaBM9MjE9kkmhUUt8Ap4R iEdwad+QfAHTQpey5AfNVWIxxdZuKPv5ym4PITlIH8y1XImSTxwjedLbcJvsmO2u DeRMz6mu0JFg29cNMbh4bszgn8kVQKRB546KTKuxMaHkoed5435W3od91iXjHmed j6Ykgxds7H0EU39BsBiElN3PH7Zbd1KmkVb0o9dVPHb8amGH5dPFuoDOEyFnhAQ= =Z4FX -----END PGP SIGNATURE-----

3 5

Build failed: opensmalltalk-vm 1.0.2407
by AppVeyor 19 Feb '21

19 Feb '21

1 0

[OpenSmalltalk/opensmalltalk-vm] 692fb7: Implement the old named primitive API for window t...
by Eliot Miranda 18 Feb '21

18 Feb '21

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 692fb729691e9e7c8f68e41710c1e416224e94e4 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/692fb729691e9e7c8f… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2021-02-18 (Thu, 18 Feb 2021) Changed paths: M platforms/iOS/vm/Common/Classes/sqSqueakNullScreenAndWindow.h M platforms/iOS/vm/Common/Classes/sqSqueakNullScreenAndWindow.m M platforms/iOS/vm/Common/Classes/sqSqueakScreenAPI.m M platforms/iOS/vm/Common/Classes/sqSqueakScreenAndWindow.m Log Message: ----------- Implement the old named primitive API for window title on Mac iOS.

1 0

[OpenSmalltalk/opensmalltalk-vm] 40ce4b: HostWindowPlugin: Generalize ioSetTitleOfWindow on...
by Eliot Miranda 17 Feb '21

17 Feb '21

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 40ce4b725bf37fabc61e25f5051a40fa1ca1df45 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/40ce4b725bf37fabc6… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2021-02-17 (Wed, 17 Feb 2021) Changed paths: M platforms/iOS/plugins/HostWindowPlugin/sqMacHostWindow.m Log Message: ----------- HostWindowPlugin: Generalize ioSetTitleOfWindow on Mac to be the same as Windows. [ci skip] cuz not a significant change for other than Terf.

1 0

Building UnicodePlugin on ARM64
by tim Rowledge 15 Feb '21

15 Feb '21

I swear this worked a couple of weeks ago, but who knows? I'm building a nice clean AARCH64 VM for NuScratch - which means it needs the UnicodePlugin working for the pango font rendering. I'm sure this was ok a couple of weeks ago when I tested it... but I can't see any way it could have changed. So maybe I was hallucinating. The problem is that the glib-2.0 package is in a different path than on the 32bit ARM OS - no big surprise there , though I am surprised that the machine specific directory isn't linked to a generic path to, you know, make life less stupid. But then this is unix, where the entire idea is to make people feel stupid. At first I thought I hadn't' installed the glib stuff properly, and indeed there are plenty of google-hits for the error message. After faffing around with that I spotted the opensmalltalk-vm/platforms/unix/plugins/UnicodePlugin/acinclude.m4 file that simply lists the (hopefully) releveant paths. Ah-Hah! thought I, add the path here and away we go. It even says that in the opensmalltalk-vm/platforms/unix/plugins/UnicodePlugin/README.UnicodePlugin Nope. It's also explicitly listed in opensmalltalk-vm/platforms/unix/plugins/UnicodePlugin/Makefile.inc for some reason - so let's add it there as well. Nope. When one examines the config.log the command to run a test prog to find out if the glib/pango/cairo stuff is there looks like this - configure:15962: gcc -c -Wall -march=armv8-a -mtune=cortex-a72 -g -O2 -DNDEBUG -DDEBUGVM=0 -DMUSL -D_GNU_SOURCE -DUSEEVDEV -DCOGMTVM=0 -DDUAL_MAPPED_CODE_ZONE=1 -pthread -DLSB_FIRST=1 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/lib/i386-linux-gnu/glib-2.0/include conftest.c >&5 Notice how it does not have the -I/usr/lib/aarch64-linux-gnu/glib-2.0/include path I've now added to acinclude.m4 Makefile.inc And now, for added excitement, the actual opensmalltalk-vm/platforms/unix/config/configure script, which seems to also have the paths hard coded, is edited to add the new path explicitly. And at last the damned thing builds properly and even runs NuScratch. The obvious question is what the 'proper' way to solve this is. I had the vague idea floating around the back of my skull that the 'configure' script stuff built itself from things like the acinclude.m4 fragments - and it certainly seems to include exactly the text from the original acinclude file. tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Useful random insult:- In serious need of attitude adjustment.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev February 2021