Vm-dev May 2020

vm-dev@lists.squeakfoundation.org

39 participants
130 discussions

Start a nNew thread

Build completed: opensmalltalk-vm 1.0.2071
by AppVeyor 13 May '20

13 May '20

1 0

Re: [Vm-dev] [Pharo-dev] Pony for Pharo VM
by Shaping 13 May '20

13 May '20

Just to get in the right frame of mind, consider that because of the Blub Paradox (http://www.paulgraham.com/avg.html) you are going to have a hard time convincing people to "change to this language because of Feature X" just by saying so. You need to dig deeper. The Pony compiler and runtime need to be studied. I’m not trying to convince; I’m presenting facts, observations, and resources for study of the problem and its solution. Hardware constraints now are intensely multicore, and everyone knows this. The changing programming paradigm in apparent. Hardware structure is forcing that change. Convincing yourself will not be difficult when you have the facts. You likely do already, at least on the problem-side. The issue is not whether to use Pony. I don’t like Pony, the language; it’s okay, even very good, but it’s not Smalltalk. I like Smalltalk, who concurrency model is painfully lame. I like Orca because it works on many cores (as many as 64, currently) without a synchronization step for GC, and has wonderful concurrency abilities. Pony and Orca were co-designed. The deferred reference counts managed by Orca run on the messages between the actors (send/receive tracing). GCs happen in Pony/Orca when each actor finishes its response to the last received message, and goes idle. The actor then GCs all objects no longer referenced by other actors. The runtime scheduler takes this time needed for each actor’s GCing into account. No actor waits to GC objects. An actor’s allocated objects’ ref counts are checked at idle-time, and unreferenced objects are GCed in an ongoing, fluid way, in small, high-frequency bursts, with very small, predictable tail latencies, as a result. That’s very interesting if you need smoothly running apps (graphics), design/program real-time control systems, or process data at high rates, as in financial applications at banks and exchanges. The issue is how most efficiently to use Orca, which happens to be working in Pony. Pony is in production in two internal, speed-demanding, banking apps and in Wallaroo Labs’ high-rate streaming product. Pony is a convenient way to study and use a working implementation of Orca. Ergo, use Pony, even if we only study it as a good example of how to use Orca. Some tweaks (probably a lot of them) could allow use of dynamic types. We could roll our own implementation of Orca for the current Pharo VM, but that seems like more work than tweaking a working Pony compiler and runtime. I’m not sure about that. You know the VM better than I. (I was beginning my study of the Pharo/OpenSmalltalkVM when I found Pony.) Now I I took a quick look to see what I could learn about Pony and the main interesting thing is its "Reference Capabilities". Indeed, it seems Pony's purpose is the POC for that research. I watched two videos... [1] Øredev 2017 - Joe McIlvain - Pony - A Language for Provably Safe Lockless Concurrency https://www.youtube.com/watch?v=9NH4bVfbvYI [2] Sophia Drossopoulou - Pony for Safe, Fast, concurrent programs - Codemesh 2017 https://www.youtube.com/watch?v=e_bES30tFqI So my "quick" assessment is to consider Reference Capabilities not a Type System but a Meta-type System. Yes, ref-caps control sharing of both mutable and immutable objects. [2] says "They are not a property of an object, but define how I can look at an object." To summarize the videos... [1]@29:15... [2]@13:40... [2]@24:40... [2]@28:30... So you say... > I want to use the Pony concurrency model at the Smalltalk level. That’s the gist of it. > Otherwise, I want a Smalltalk, not a statically compiled language. I believe you have the wrong end of the the stick promoting that the VM needs to be redeveloped using Pony to get the Reference Capabilities at the Smalltalk level. See my recent response to Ken in vm-dev. After you Ahead-Of-Time compile the VM, the compiler is left behind. The features of the compiler don't automatically flow through to Smalltalk level. Yes. JIT and AOT are needed. Adjustments need to be made for dynamic typing, but such adjustments need not violate invariants needed to provide the ref-cap concurrency guarantees. A third option could be to extend to the existing "Immutability capability" of the VM. Ref-caps control access to both immutable and mutable objects. Pony ascertains at compile time that only one actor at a time can hold a reference to a mutable object at runtime. The six Reference Capabilities might be stored in the Spur Object Header using a re-purposed Immutability bit plus the two free "green" bits. https://clementbera.wordpress.com/2014/01/16/spurs-new-object-format/ We can’t use a single big system heap, and also use the actor model and many cores productively. The big heap must go. That’s the crux of what we need to learn at this juncture. I’m not sure everyone is getting this. I don’t need to convince you; you can do that for yourself. We don’t currently have a better choice of programming model or memory management, if we want maximum speed, and are paying attention to hard constraints. Multicore hardware is here to stay. If you know a way to use your multicore CPUs more efficiently than by use of actor-based programming and Orca memory management, please share your facts. Everyone needs to understand the big-heap problem in order to commit to fine-grain, actor-based (and therefore state-machine-based) programming. We won’t realize productive multicore programming without an actor model. We still need new tools to help, as mentioned, lest our state-machine programming be tedious and painful, causing us to default to old coding habits, and not make the needed state-machines. I’m working on one of those tools. Orca manages memory as fast as possible in an actor-based program/runtime, without any synchronization. The big-heap problem has been solved for the statically typed case in Pony. The lack of discipline/tools for building state-machines remains a broad problem. Such new tools are therefore essential during the change of programming model. I suggest studying the current Pony/Orca solution (see the Orca paper linked below), to see how it can be tweaked to accommodate dynamic types. I’ve not studied the Pony compiler and runtime enough to be certain, but they may be closer to what we need, even if the first rough implementation of a Smalltalk-with-Orca must be AOT, instead of JIT. We want both ultimately. We should do first whichever is easiest to implement and test in small steps. "Reference Capabilities for Dynamic Languages" could be a strong PhD project. It’s a good idea. Is this needed to make a Smalltalk that works with Orca? I don’t think so. Orca matters more than Pony. But both can be useful to us. Studying the Orca paper and its implementation in the Pony compiler and runtime is the easiest way to understand the constraints imposed by the current static type system in Pony—and how to change them to accommodate dynamic types. Everyone, please read and study https://www.ponylang.io/media/papers/orca_gc_and_type_system_co-design_for_… if you are interested in building a VM/runtime that guarantees no data-races, and fully uses all your machine’s cores, with the least programming effort. Then study Pony: https://www.ponylang.io/ And ask questions on Pony Zulip: https://ponylang.zulipchat.com/ (BTW, Zulip seems easier to use than Discord and e-mail. Has anyone considered using it for the Pharo/Squeak lists?) Shaping On Fri, 10 Apr 2020 at 17:56, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: > > Hi Ken. > > Not to discourage people, but I have not seen cases where a "strong > type system would be able to scale for _real_ Smalltalk applications. > > You’re right. It doesn't. I'm not suggesting that. > > The type safety is not for app-level Smalltalk development. It's for building the VM only. > > The six ref-cap ideas for sharing data reliably between actors are not hard to grasp, but they take some getting used to, and involve some mental load. I don't want that much (concurrency-related or any other) implementation detail in the domain layer, much in the same vein as: I don’t use Forth because I don’t want to see stack acrobatics (ROTs and DUPs, etc.) amidst domain-level state-changes (FirePhotonTorpedo). It’s distracting. It dilutes focus on the domain work/layer, and tends to cause mistakes there. > > > > The programmer’s domain logic and the concurrency-integrity provided by the ref-caps are different layers of thought and structure. The ref-caps are, however, mixed freely with domain logic in current Pony code. I think that’s a mistake. But that’s how it is now. I think of this layer mixing as an intermediate design stage of Pony. I want to abstract-out some or all ref-caps as the VM is built. > > Pony language is not the remarkable thing here. I see it as a better C or better Rust. It’s very good (as Algol-60-ish-looking crap-syntaxes go), but that’s not what this is about. It’s about the actor programming, the concurrency model, and the guarantees given by use of the ref-caps. We would still obviously need to respect the Pony compiler’s determination of where ref-cap use is correct or not. Your Pony program won’t compile if you don’t use the ref-caps correctly, and you don’t get the guarantees or a running program without the compile. Much easier, therefore, might be to go the other way by changing Pony to support dynamic types without violating the invariants that allow the ref-caps (under the hood, abstracted out) to make the concurrency guarantees. Work Smalltalk dynamism into Pony, instead of building a Smalltalk VM with Pony.

2 10

Build failed: opensmalltalk-vm 1.0.2070
by AppVeyor 13 May '20

13 May '20

1 0

[VM-dev] Terminated process with zero pc
by Denis Kudriashov 13 May '20

13 May '20

Hi. I encounter interesting behavior of process termination. I can't reproduce it locally but I have constantly failing test on Pharo CI (as part of full test suite) due to following conditions: ended := false. process := [ Processor activeProcess suspend. ended := true] forkAt: Processor activePriority + 1. self assert: process isSuspended description: 'should be suspended'. process resume. self assert: ended description: 'last statement is done'. self assert: process suspendedContext pc equals: 0 When I try to run it locally the pc is always greater than #startpc. On CI the test very rarely behaves same way. The process is always finished (#ended is true) but in most of runs the pc of #terminate context is somehow reset to zero (probably related to the order of overall test suite). . In Pharo succeed process ends here: terminate ........... self isActiveProcess ifTrue: [ thisContext terminateTo: nil. self suspend ] It seems that Context>>#terminateTo: can reset the pc to zero under some condition (jitter related?). So I wonder what could be the explanation? I would like to understand this behavior before I will propose the change for Pharo (#isTerminate implementation needs to be fixed). Best regards, Denis.

2 7

[OpenSmalltalk/opensmalltalk-vm] Removes support for Windows CE (#500)
by Marcel Taeumel 12 May '20

12 May '20

The existing support was maybe up to Windows Mobile 5. For a discussion see http://forum.world.st/Supporting-Windows-CE-tp5116478.html You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/500 -- Commit Summary -- * Removes support for Windows CE -- File Changes -- M platforms/win32/vm/sqConfig.h (4) M platforms/win32/vm/sqWin32.h (75) M platforms/win32/vm/sqWin32Directory.c (7) M platforms/win32/vm/sqWin32Heartbeat.c (8) M platforms/win32/vm/sqWin32Time.c (8) M platforms/win32/vm/sqWin32Window.c (88) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/500.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/500.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/500

2 1

[OpenSmalltalk/opensmalltalk-vm] 418b23: Removes support for Windows CE
by Nicolas Cellier 12 May '20

12 May '20

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 418b236367cc8ae9bdc111c63ff93900c6589a7f https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/418b236367cc8ae9bd… Author: Marcel Taeumel <marcel.taeumel(a)hpi.de> Date: 2020-05-12 (Tue, 12 May 2020) Changed paths: M platforms/win32/vm/sqConfig.h M platforms/win32/vm/sqWin32.h M platforms/win32/vm/sqWin32Directory.c M platforms/win32/vm/sqWin32Heartbeat.c M platforms/win32/vm/sqWin32Time.c M platforms/win32/vm/sqWin32Window.c Log Message: ----------- Removes support for Windows CE The existing support was maybe up to Windows Mobile 5. For a discussion see http://forum.world.st/Supporting-Windows-CE-tp5116478.html Commit: c1cdd0d88a1b937e2ca8dafd5e745da2407aacda https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c1cdd0d88a1b937e2c… Author: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> Date: 2020-05-12 (Tue, 12 May 2020) Changed paths: M platforms/win32/vm/sqConfig.h M platforms/win32/vm/sqWin32.h M platforms/win32/vm/sqWin32Directory.c M platforms/win32/vm/sqWin32Heartbeat.c M platforms/win32/vm/sqWin32Time.c M platforms/win32/vm/sqWin32Window.c Log Message: ----------- Merge pull request #500 from marceltaeumel/marceltaeumel/patch-2 Removes support for Windows CE Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/ee89a4dad044...c1…

1 0

help: VMMaker patch
by K K Subbu 12 May '20

12 May '20

Hi, I made a small fix (attached) in VMMaker InterpreterSimulator but couldn't save it to VMMakerInbox. It only has Cog-related projects. allowAccessBeyondSP is initialized in Interpreter but not in InterpreterSimulator. When the simulator is stared on Squeak32-3.8g-6548 image, this triggers an undefined reference in EshouldBoundAccessWithinStackFor:withFormat: Could someone please review this patch and help me propose it to VMMaker? Thanks and Regards .. Subbu

2 2

Supporting fBrowserMode on Windows ...
by Marcel Taeumel 12 May '20

12 May '20

Hi all! Vanessa told me there was once a time where the SqueakVM could be compiled as an ActiveX control as well as a Netscape plugin. Squeakland [1] used it to embed Etoys directly into a website. impara [2] built some games for the web browser. Can we remove the support for fBrowserMode (and thus browserWindow) from the Windows platform? Best, Marcel [1] http://squeakland.org/showcase/featured/ [http://squeakland.org/showcase/featured/] [2] http://web.archive.org/web/20071010010006/http://www.impara.de:80/index_eng… [http://web.archive.org/web/20071010010006/http://www.impara.de:80/index_eng…]

2 2

Supporting Windows CE ...
by Marcel Taeumel 12 May '20

12 May '20

Hi all! Looking at those sprinkled #ifdef _WIN32_WCE, I was wondering, whether there is value in supporting the Windows Embedded platforms. Here is some context: https://en.wikipedia.org/wiki/Windows_Embedded_Compact [https://en.wikipedia.org/wiki/Windows_Embedded_Compact] https://en.wikipedia.org/wiki/Windows_Embedded_Industry [https://en.wikipedia.org/wiki/Windows_Embedded_Industry] https://en.wikipedia.org/wiki/Windows_IoT [https://en.wikipedia.org/wiki/Windows_IoT] I think that the current level of support in the OpenSmalltalk VM dates back to 2007: http://wiki.squeak.org/squeak/2436 [http://wiki.squeak.org/squeak/2436] So, it seems to run on Windows Mobile 5. Has anybody tried that out recently? Looking at the efforts to maintain the Windows platform I think it might be reasonable to drop the existing support for Windows CE. Alternatively, we should make an effort to support Windows Embedded Compact 8, which is supported until October 10, 2023. What do you all think? Best, Marcel P.S.: Note that Windows Phone has a slightly different history even though rooted in Windows Embedded Compact 7: https://en.wikipedia.org/wiki/Windows_Phone#Versions [https://en.wikipedia.org/wiki/Windows_Phone#Versions] P.P.S.: Note that for supporting Windows 10 IoT, we would have to start afresh anyway. I suppose.

3 2

Interpreter simulator error
by K K Subbu 11 May '20

11 May '20

All, I stumbled upon the following error when simulating a copy of a 3.8.1 (6502) image (full log attached) : Bitmap(Object)>>error: Receiver: a Bitmap of length 5499668 Arguments and temporary variables: aString: 'Improper store into indexable object' Receiver's instance variables: a Bitmap of length 5499668 The simulator loads the image correctly and both validate and validateActiveContext tests pass. But when I try to run test, it throws this error. VM version is: 4.16.7-3775 #1 XShm Tue May 5 22:44:20 IST 2020 /usr/bin/cc Linux s400 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux The simulator works fine with 2.2 image but gives error on a 3.8.1 image with VMMaker loaded in it. Has anyone seen this error before? Any help in tracing this bug is appreciated. Regards .. Subbu

3 7

← Newer
1
...
6
7
8
9
10
11
12
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev May 2020