Vm-dev April 2022

vm-dev@lists.squeakfoundation.org

16 participants
71 discussions

Primitive 126 | Its problems and its future :-)
by Marcel Taeumel 28 Apr '22

28 Apr '22

Hi all -- Primitive 126 (#primitiveDeferDisplayUpdates) has a problem. It has no platform-specific code. So no platform-specific rendering backend (e.g., Metal) can communicate whether it actually supports deferred updates. Because of this, we are forced to guess at the image level how to best work with primitives 127 and 231. Why is this bad? Because we must somehow reconfigure images for specific VMs because those VMs do not tell whether primitive 126 has an effect or not. So we have to guess. Maybe via using the #platformName. This is bad. You can see the effects by Eliot's recent concern about Morphic's window-dragging feature, which can only work right if we know how to handle that extra video buffer in the image: http://lists.squeakfoundation.org/pipermail/vm-dev/2022-April/037887.html [http://lists.squeakfoundation.org/pipermail/vm-dev/2022-April/037887.html] Well, the damage is done. Primitive 126 has been around like forever. When the Metal support was introduced to the VM for macOS many years ago, it broke the decent performance for all macOS users. It overcommitted stuff to the video memory in primitives 127 and 231. As a Windows user, I was always surprised that macOS users had to experience such a sluggish Morphic performance. Well, after years of complaints from macOS/Squeak users, I couldn't take it anymore and fixed this regression in the recent OSVM. Of course you now have to tell your favorite image that it *really* has to use an image-side composition buffer. Recent images do that already automatically. Fine. I even backported that to Squeak 5.3. For older ones you do this: PasteUpMorph disableDeferredUpdates: true. Project allMorphicProjects do: [:ea | ea world canvas: nil]. Not that of an issue, one might think. But the VM is not fully backwards compatible either. At least when looking at Morphic and its window-dragging feature. I don't think that we can change the past. Using the current OSVM with older images would even require that simple in-image configuration if we would adapt primitive 126. The code in WorldState >> #displayWorld:submorphs: never really accounted for an actually working primitive 126. I am also not happy about this. I think that the original mistake was made when primitive 126 was implemented without connecting it to platform-specific code. But I do prefer a better performance over *not* having to "flip a switch" in your favorite (older) image. Then, again, I am a Windows user. Maybe other macOS users should share their thoughts on this. Backwards compatibility is hard. 99% might not be 100% but it is still good. Best, Marcel

4 7

Re: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Fixes issue #625, which makes --headless mode work again on Ubuntu/Linux. (2d7105d)
by Christoph Thiede 28 Apr '22

28 Apr '22

Could you tell me when will this change make it to http://files.squeak.org/trunk/? :-) -- Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/2d7105db755928fd90… You are receiving this because you are subscribed to this thread. Message ID: <OpenSmalltalk/opensmalltalk-vm/commit/2d7105db755928fd90823d264fc64e17b1c57ad4/72399051(a)github.com>

1 0

Re: [Vm-dev] [squeak-dev] [crash] segmentation violation on window resize
by Marcel Taeumel 28 Apr '22

28 Apr '22

Hi Lauren -- In the bytecodes, I can see: 46 <D0> popIntoTemp: 0 I don't suppose the JIT will ever drop this. Would be very dangerous regarding GC. Best, Marcel Am 28.04.2022 04:15:19 schrieb Lauren P <drurowin(a)gmail.com>: Hi Marcel, On Wed, Apr 27, 2022, 10:33 Marcel Taeumel <marcel.taeumel(a)hpi.de [mailto:marcel.taeumel@hpi.de]> wrote: Ha. I think I found something. See Graphics-mt.514. I am not 100% sure that this was the culprit but I will backport it to Squeak 5.3 just in case It'll be a bit difficult to test, but I'll try stressing the image to see if that does the trick. I do immediately see something that could become an issue... static analysis says priorBits is assigned to but then never accessed, so it's safe to optimize away. There are no function calls involved, just copying a pointer, so it isn't like there would be side effects. If I compiled it by hand I'd remove it entirely... which is why you have a comment specifically saying not to do just that. I've looked at Context and CompiledMethod hard enough to know the callee can access it... for fun I wrote a method that rewrites block closure temporary bindings... is that enough to keep it from being omitted?

1 0

new VM breaks window dragging in old images. that's not backwards compatibility in my book.
by Eliot Miranda 27 Apr '22

27 Apr '22

Hi Marcel, the issue of windows being invisible when dragged in the new VM is a major bug. The VM needs to be backwards compatible. It souldn't break old images. So we need to find a way of restoring the default behaviour in images that don't set the relevant preference. To reproduce take e.g. Squeak 6.0 alpha or the ;ast of the 5.x line and simply try and move a window about As soon as the window starts to move it disappears and then reappears when the mouse button is released. This must be fixed. _,,,^..^,,,_ best, Eliot

2 8

Object pinning vs. garbage collection
by Marcel Taeumel 27 Apr '22

27 Apr '22

Hi Eliot, hi all -- Can a pinned object get garbage collected at all? Do I have to ensure to have at least a single reference to that (pinned) object? My best answer would be: Yes. Otherwise, I could never get rid of that pinned object again. This has interesting implications also for an FFI programming interface. If you send out a pointer to object memory everything is fine if (a) that object is pinned an (b) that object does not get garbage collected. Pinning is easy. Keeping track of an object that gets collected but is actually pinned should raise a warning ... I suppose. Hmm... Best, Marcel

2 1

Re: [Vm-dev] [squeak-dev] [crash] segmentation violation on window resize
by Marcel Taeumel 27 Apr '22

27 Apr '22

Hi Lauren, hi all -- Okay, I give up on this for now. I cannot reliably reproduce the issue. My only hypothesis is that we do something wrong with freeing the current Metal texture in sqSqueakOSXMetalView.m:449. Maybe we should tell the Metal framework about this and not just free the pointer... Reading the Metal documentation might help... At least, the segfault always occurs in the same situation: 1. App window size changed. 2. Morphic ui process detects this via DisplayScreen class>checkForNewScreenSize 3. The next call to DisplayScreen(Form)>boundingBox triggers a vmIOProcessEvents() in the regular interpreter loop via checkForEventsMayContextSwitch(). 4. A display event will be processed ending up in sqSqueakOSXMetalView loadTexturesSubRectangle: 5. The texture update fails in sqSqueakOSXMetaView.m:439. Nothing of that is out of the ordinary. The tuple (displayBits, displayWidth, displayHeight) seems correct. This leaves the way we free the old texture and allocate a new one. Best, Marcel Am 27.04.2022 11:58:31 schrieb Marcel Taeumel <marcel.taeumel(a)hpi.de>: Hi Lauren -- Nope. It just happened by chance. And only in a -f build. Hmm... [ DisplayScreen setNewScreenSize: (1024@768) * 1.´ self currentWorld doOneCycle. DisplayScreen setNewScreenSize: (1024@768) * 2. self currentWorld doOneCycle. ] repeat. Maybe it is a (Metal) texture allocating/freeing issue ... Best, Marcel Am 27.04.2022 10:45:02 schrieb Marcel Taeumel <marcel.taeumel(a)hpi.de>: Hi Lauren -- Thanks for reporting this. I was able to reproduce the issue. I am looking into it right now. Best, Marcel Am 27.04.2022 07:12:41 schrieb Lauren Pullen <drurowin(a)gmail.com>: Hi List, What the subject line says. I had just toggled the UI scale between 200% and 300% and back again and the window had shrunk, so I resized it to maximize it again and the VM aborted. The the last call from the VM was in -[sqSqueakOSXMetalView loadTexturesSubRectangle:] -[sqSqueakOSXMetalView drawRect:]

1 1

[OpenSmalltalk/opensmalltalk-vm] `primitiveScreenScaleFactor` broken on headless Linux/X11 VMs (Issue #625)
by Christoph Thiede 27 Apr '22

27 Apr '22

For a few days, `primitiveScreenScaleFactor` fails on headless Linux/X11 VMs. Reprocase: 1. Download and extract the latest AiO bundle from today 2. ```bash $ cat << EOF > test.st TranscriptStream redirectToStdOut: true. Transcript showln: DisplayScreen actualScreenScaleFactor asString. EOF $ ./squeak.sh --headless "$(realpath test.st)" ``` 3. stack overflow: ``` DisplayScreen>>#actualScreenScaleFactor stack page bytes 8192 available headroom 5576 minimum unused headroom 6016 (Segmentation fault) Aborted (core dumped) ``` 8 days again, this still worked. See also: https://github.com/LinqLover/create-image/actions/workflows/test.yml @marceltaeumel Does this require a fix similar to 2a0e7851d0e057b06e77e64a58e155d9c7935e6a? PS: I noted a still existing typo here: https://sourcegraph.com/search?q=context:global+ioSceenScaleFactor+repo:%5E… -- Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/625 You are receiving this because you are subscribed to this thread. Message ID: <OpenSmalltalk/opensmalltalk-vm/issues/625(a)github.com>

2 16

[OpenSmalltalk/opensmalltalk-vm] vm-display-X11: Fix scale factor detection in headless and no-display mode (PR #626)
by Christoph Thiede 27 Apr '22

27 Apr '22

Closes #625. You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/626 -- Commit Summary -- * vm-display-X11: Fix scale factor detection in headless and no-display mode -- File Changes -- M platforms/unix/vm-display-X11/sqUnixX11Scale.c (7) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/626.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/626.diff -- Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/626 You are receiving this because you are subscribed to this thread. Message ID: <OpenSmalltalk/opensmalltalk-vm/pull/626(a)github.com>

2 3

[OpenSmalltalk/opensmalltalk-vm] 2d7105: Fixes issue #625, which makes --headless mode work...
by Marcel Taeumel 27 Apr '22

27 Apr '22

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 2d7105db755928fd90823d264fc64e17b1c57ad4 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/2d7105db755928fd90… Author: Marcel Taeumel <marcel.taeumel(a)hpi.de> Date: 2022-04-27 (Wed, 27 Apr 2022) Changed paths: M platforms/unix/vm-display-X11/sqUnixX11.c Log Message: ----------- Fixes issue #625, which makes --headless mode work again on Ubuntu/Linux.

1 0

[OpenSmalltalk/opensmalltalk-vm] unable to compile the 202112201228 pre-release on mac os 12.3.1 (m1, monterey, xcode 13.3.1) (Issue #623)
by Faried Nawaz 21 Apr '22

21 Apr '22

Steps: ``` git clone git@github.com:OpenSmalltalk/opensmalltalk-vm cd opensmalltalk-vm git checkout 202112201228 cd building/macos64ARMv8/squeak.cog.spur ./mvm -f ``` It chugs away for a while, and then fails with ``` ld: archive has no table of contents file 'build/vm/AsynchFilePlugin.lib' for architecture arm64 ``` Sometimes it's another plugin, but it's always one of the ones in the `plugins.int` file. I've tried both the Cog branch and the 202112201228 tag. -- Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/623 You are receiving this because you are subscribed to this thread. Message ID: <OpenSmalltalk/opensmalltalk-vm/issues/623(a)github.com>

3 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev April 2022