Vm-dev January 2017

vm-dev@lists.squeakfoundation.org

30 participants
136 discussions

StackInterp/Cog>>transferTo: - assertValidExecutionPointe:r:s differences
by Ben Coman 06 May '18

06 May '18

Just curious about the difference in instructionPointer between these two... StackInterpreter>>transferTo: self assertValidExecutionPointe: instructionPointer + 1 r: framePointer s: stackPointer. CoIntepreter>>transferTo:from: self assertValidExecutionPointe: instructionPointer r: framePointer s: stackPointer. cheers -ben

3 8

Re: [Vm-dev] Freeze after Morph Activity
by Dan Norton 15 May '17

15 May '17

Hi Levente, I directed stdout to a file and prior to the freeze, did: pkill -USR1 -n -x squeak a few times and noticed "stack overflow" mentioned twice. After the freeze, pkill sent nothing else to stdout. Maybe something in stderr? I'll try again and concatenate stderr to the end of stdout. Meanwhile, the file with the stack overflows is attached. Thanks for the help. - Dan On Sat, 28 Jan 2017,*Levente Uzonyi* wrote: >Hi Dan, >You can send the USR1 signal to the VM process to make it write some debug >information to the console. With this information you can easily tell >what's happening. I suspect it's stuck in a long GC. >Levente >On Fri, 27 Jan 2017, Dan Norton wrote: >>//>>/On Debian8, CogSpur64 5.0-201612221637, Cuis 5.0 3043... />>//>>/after lots of user interaction, views opening and closing, and />>/animation, the image becomes unresponsive. Cmd+. does nothing and the />>/clock in the Cuis taskbar no longer updates. The length of time to />>/produce this varies from 5 to 20 minutes. />>//>>/There seems to be no dump and no log. 'Smalltalk garbageCollectMost' />>/reports 25550736 to 30517872 over 34 samples. />>//>>/Sorry to be so vague. This has occurred with several images - sometimes />>/scrolling through a senders list, or stepping through a debugger, but />>/repeatably with one of my images. I can supply this image, warmed up so />>/that it might not take so long to reproduce the problem if you would />>/like. Or give me a hint as to how to narrow down the problem /

10 65

Amazing ARM simulator experience
by Eliot Miranda 03 May '17

03 May '17

Hi All, just had to tell people about this morning's experience using the ARM simulator. I've been building Smalltalk VMs since 1983, so 33 years. My first on the Three Rivers PERQ was dog slow. My undergraduate project was done the the National Semiconductor 32016 based Whitechapel Computer Works workstation and its and 32032-based successor. This morning I was revamping register management in Cog's ARMv5/v6 back end, making more registers available by using two of the C argument registers for two of registers the Cogit assigns to various fixed tasks, and using store and load multiple instructions to save and restore concisely the registers around calls into the runtime. Remember the architecture here. The simulator generates ARM machine code into the ByteArray that re[resents the address space, holding all of generated machine code, a small C stack, and the Smalltalk heap. A plugin, derived from Gdb's ARM simulator written in C, interprets that machine code, running for a couple of milliseconds at a time in a loop, applying breakpoint calculations, and asserts on every call into the run-time, and that calls into the run-time and accesses of variables in the simulator is done by using illegal addresses in the generated machine code. Each illegal access causes the Gdb-derived machine code interpreter to return with an error, this error is turned into an exception, the handler for which maps the specific illegal address into a variable or message selector, accesses the variable or activates the message selector, providing the result, and allowing the execution to continue. In changing the register management I had a test case that worked, an image that prompted for an expression ands evaluated it, which worked both in the simulator and with the generated VM. But the real VM, crashed when used on a proper image. So to debug I started launching the real interactive image in the simulator. Well, the amazing experience is that that image, whose machine code is being _interpreted by a C program_ feels /faster/ than my 32016 based implementation back in 1984-ish. Quite amazing. I can open windows, type text, access source code (was playing with Message Names) etc. It's sluggish, but usable. Amazing how fast modern machines are. All on my 2012 vintage 2.2 Ghz Core i7 MacBook Pro. I'm blown away :-) _,,,^..^,,,_ best, Eliot

5 7

Unix heartbeat thread vs itimer
by Guillermo Polito 12 Apr '17

12 Apr '17

Hi, I was checking the code in sqUnixHeartbeat.c to see how the heartbeat thread/itimer worked. It somehow bothers me that there are different compiled artifacts, one per option. What do you think about having a VM that manages that as an argument provided when we launch the VM? This would add some flexibility that we don't have right now because we make the decision at compile time. The code in sqUnixHeartbeat.c is not a lot nor very complex, it should not be difficult to do... Also, what would be the drawbacks besides an increase on the vm size? Guille

11 35

Re: [Vm-dev] [Pharo-dev] Problem with OSSubprocess / signals / heartbeat ?
by Guille Polito 02 Apr '17

02 Apr '17

Ok, so following a bit on this. I'll summarize some of our findings, some of them maybe obvious for some people in this list. I saw that there are actually two different kind of VMs for *nix [1] : - threaded heartbeat - itimer + signal heartbeat Specially, I'd like to cite the following paragraph for the lazy: A distinction on linux is between VMs with an itimer hearbeat or a threaded heartbeat. VMs with an itimer hearbeat use setitimer to deliver a SIGALRM signal at regular intervals to interrupt the VM to check for events. These signals can be troublesome, interrupting foreign code that cannot cope with such signals. VMs with a threaded heartbeat use a high-priority thread that loops, blocking on nanosleep and then interrupting the VM, performing the same function as the itimer heartbeat but without using signals. These VMs are to be preferred but suport for multiple thread priorities in user-level processes has only been available on linux in kernels later than 2.6.12. So, I downloaded the heartbeat squeak VM from bintray [2]. This VM requires so deploy some configuration files in /etc/security [2]. Under this configuration OSSubprocess worked like a charm (or I did not found the issue again so far). Now, this heartbeat threaded VM is the recommended in the README file, and we see that OSSubprocess generates the exact issue stated. The main problem remains for the moment since Pharo's default download includes not this VM but the itimer one. I talked with Esteban about it and he was aware of these two VM flavours, and the reason why we are using the itimer one is the need to deploy those permission files in /etc, which makes installation a bit less automatic. Cheers, Guille [1] https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/e17db79411cfec767e04… [2] https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_linux32x86… [3] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux -------- Original Message -------- > > >> I asked Santa an OSSubprocess that won't hang :) >> > > > I really appreciate to see such not so small polar elfves helping santa :) > > > > Stef > > > > > > > >> Thanks, >> >> Guille >> >> >> >> >> >> -------- Original Message -------- >> >>> >>> >>>> On 19 Dec 2016, at 14:41, Mariano Martinez Peck >>>> <marianopeck(a)gmail.com> wrote: >>>> >>>> >>>> >>>> Hi guys, >>>> >>>> >>>> >>>> Guille Polito kept one of these images if someone can give us a >>>> hand. He also proposed the great idea of using `strace` to see what >>>> was going on. He (together with Pable Tesone) suspected that the >>>> heartbeat could be interrupting the `clone()` function which is (I >>>> think) called internally by the 'posix_spawn()' which is the one >>>> used by OSSubprocess. >>>> >>>> >>>> >>>> When these images are "hung" they found at a infinitive loop like this: >>>> >>> Okay, how many child processes do you have at that point? How many >>> processes does the system have? >>> >>> >>> >>> >>> >>>> [pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- >>>> >>>> [pid 17477] gettimeofday({1482152630, 593498}, NULL) = 0 >>>> >>>> [pid 17477] sigreturn() (mask []) = 120 >>>> >>>> [pid 17477] clone(child_stack=0, >>>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, >>>> child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted) >>>> >>>> [pid 17477] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- >>>> >>>> [pid 17477] gettimeofday({1482152630, 600126}, NULL) = 0 >>>> >>>> [pid 17477] sigreturn() (mask []) = 120 >>>> >>>> [pid 17477] clone(child_stack=0, >>>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, >>>> child_tidptr=0xf7578768) = ? ERESTARTNOINTR (To be restarted) >>>> >>> so above.. 7ms between the two gettimeofday calls? Nothing else? Set >>> a breakpoint on clone/fork in gdb and look at the c-stack at this >>> point? Could you strace with timestamps to see how much time is >>> spent? Is the process suspicious in other ways? >>> >>> >>> >>> So yes.. sounds like clone doesn't complete.. the question is why? >>> Is it out of resources? Is something in the VM blocking longer than >>> the heartbeat, is the heartbeat more frequent than expected? >>> >>> >>> >>> >>> >>>> As you can see, there is a SIGALARM involved. It also looks like >>>> the `gettimeofday` is used by the heartbeat ? Could it be that >>>> someone the heartbeat is interrupting the `clone()` ? >>>> >>>> >>>> >>>> Guille also showed me the `strace` output with a regular / working >>>> image: >>>> >>>> >>>> >>>> >>>> >>>> [pid 18647] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- >>>> >>>> [pid 18647] gettimeofday({1482152829, 481014}, NULL) = 0 >>>> >>>> [pid 18647] sigreturn() (mask []) = -1 EINTR (Interrupted >>>> system call) >>>> >>>> [pid 18647] getitimer(ITIMER_REAL, {it_interval={0, 2000}, >>>> it_value={0, 1917}}) = 0 >>>> >>>> [pid 18647] recvmsg(3, 0xff7b0734, 0) = -1 EAGAIN (Resource >>>> temporarily unavailable) >>>> >>>> [pid 18647] select(4, [3], [], [3], {0, 1000}) = 0 (Timeout) >>>> >>>> [pid 18647] getitimer(ITIMER_REAL, {it_interval={0, 2000}, >>>> it_value={0, 797}}) = 0 >>>> >>>> [pid 18647] recvmsg(3, 0xff7b0734, 0) = -1 EAGAIN (Resource >>>> temporarily unavailable) >>>> >>>> [pid 18647] select(4, [3], [], [3], {0, 1000}) = ? ERESTARTNOHAND >>>> (To be restarted if no handler) >>>> >>>> [pid 18647] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- >>>> >>>> >>>> >>>> >>>> >>>> Does anyone have any hint here? >>>> >>> Get timestamps in there. How long does it take to fail/end in this >>> situation? >>> >>> >>> >>> holger >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> > > > > > >

7 18

Ideas on cheap multi-threading for Squeak / Pharo ? (from Tim's article)
by Clément Bera 15 Mar '17

15 Mar '17

Hi all, Tim's just shared this lovely article with a 10,000+ core ARM machine. With this kind of machines, it's a bit stupid to use only 1 core when you have 10,000+. I believe we have to find a way to introduce multi-threading in Squeak / Pharo. For co-processors like the Xeon Phi or the graphic cards, I guess it's ok not to use them because their not general purpose processors while the VM is general purpose, but all those 10,000 cores... For parallel programming, we could consider doing something cheap like the parallel C# loops (Parallel.for and co). The Smalltalk programmer would then explicitly write "collection parallelDo: aBlock" instead of "collection do: aBlock", and if the block is long enough to execute, the cost of parallelisation becomes negligible compared to the performance boost of parallelisation. The block has to perform independent tasks, and if multiple blocks executed in parallel read/write the same memory location, as in C#, the behavior is undefined leading to freezes / crashes. It's the responsibility of the programmer to find out if loop iterations are independent or not (and it's not obvious). For concurrent programming, there's this design from E where we could have an actor model in Smalltalk where each actor is completely independent from each other, one native thread per actor, and all the common objects (including what's necessary for look-up such as method dictionaries) could be shared as long as they're read-only or immutable. Mutating a shared object such as installing a method in a method dictionary would be detected because such objects are read-only and we can stop all the threads sharing such object to mutate it. The programmer has to keep uncommon the mutation of shared objects to have good performance. Both design have different goals using multiple cores (parallel and concurrent programming), but in both cases we don't need to rewrite any library to make Squeak / Pharo multi-threaded like they did in Java. What do you think ? Is there anybody on the mailing list having ideas on how to introduce threads in Squeak / Pharo in a cheap way that does not require rewriting all core/collection libraries ? I'm not really into multi-threading myself but I believe the Cog VM will die in 10 years from now if we don't add something to support multi-threading, so I would like to hear suggestions. Best, Clement Phd Student Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*

9 17

[OpenSmalltalk/opensmalltalk-vm] 195d84: makes squeak.cog.spur compile on OpenBSD 6.0
by GitHub 26 Feb '17

26 Feb '17

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 195d848e927ea2fc5434f94d9b724c73849c62b3 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/195d848e927ea2fc54… Author: Gerardo Santana <geardo.santana(a)gmail.com> Date: 2016-10-09 (Sun, 09 Oct 2016) Changed paths: M build.linux64x64/squeak.cog.spur/build/mvm M platforms/Cross/plugins/SqueakFFIPrims/sqFFIPlugin.c M platforms/unix/vm/sqUnixMain.c M platforms/unix/vm/sqUnixVMProfile.c M src/plugins/UnixOSProcessPlugin/UnixOSProcessPlugin.c M src/plugins/VMProfileLinuxSupportPlugin/VMProfileLinuxSupportPlugin.c Log Message: ----------- makes squeak.cog.spur compile on OpenBSD 6.0 Commit: e427da4d72804b99b58fb58c5db320111d6cccc7 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e427da4d72804b99b5… Author: Gerardo Santana <geardo.santana(a)gmail.com> Date: 2016-10-09 (Sun, 09 Oct 2016) Changed paths: M platforms/unix/config/bin.squeak.sh.in M platforms/unix/config/squeak.sh.in Log Message: ----------- adds OpenBSD support to Squeak's shell script wrapper Commit: ab77774ff8eedd7a7de9814ef1961f20bf1fbeab https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ab77774ff8eedd7a7d… Author: Fabio Niephaus <code(a)fniephaus.com> Date: 2016-10-15 (Sat, 15 Oct 2016) Changed paths: M build.linux64x64/squeak.cog.spur/build/mvm M platforms/Cross/plugins/SqueakFFIPrims/sqFFIPlugin.c M platforms/unix/config/bin.squeak.sh.in M platforms/unix/config/squeak.sh.in M platforms/unix/vm/sqUnixMain.c M platforms/unix/vm/sqUnixVMProfile.c M src/plugins/UnixOSProcessPlugin/UnixOSProcessPlugin.c M src/plugins/VMProfileLinuxSupportPlugin/VMProfileLinuxSupportPlugin.c Log Message: ----------- Merge pull request #78 from santana/openbsd2 OpenBSD support Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/3c2c39d92cb8...ab…

5 5

pb with primitive #primitiveScreenDepth on Linux ?
by Christophe Demarey 03 Feb '17

03 Feb '17

Hello, With Pavel, we discovered a strange behavior of the primitive #primitiveScreenDepth on Linux. It returns a value of 24 bits per pixel (True colors) that looks valid but not supported (at least by Pharo). DisplayScreen actualScreenDepth "(calling the primitive screenDepth)" => 32 on OS X [OK] => 24 on Linux [KO] Also, it is not consistent with the primitive 91 DisplayScreen new supportsDisplayDepth: DisplayScreen actualScreenDepth => true on OS X => false on Linux There are some safeguard image-side but it would be great if someone could check that vm side. Christophe.

2 4

[OpenSmalltalk/opensmalltalk-vm] 0adb5b: Deploy to Bintray
by GitHub 31 Jan '17

31 Jan '17

Branch: refs/heads/krono/highdpi-v2 Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 0adb5b7bed12c2e67f9a63e4c3a36208447fd789 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/0adb5b7bed12c2e67f… Author: Fabio Niephaus <code(a)fniephaus.com> Date: 2017-01-31 (Tue, 31 Jan 2017) Changed paths: M .travis_deploy.sh Log Message: ----------- Deploy to Bintray (must be reverted before merging in `Cog`/`master`)

1 0

[OpenSmalltalk/opensmalltalk-vm] e67f8d: Cope for a special XCode argument
by GitHub 31 Jan '17

31 Jan '17

Branch: refs/heads/krono/highdpi-v2 Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: e67f8dc97fc56c3d7346f37eebb86bc17220e2aa https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e67f8dc97fc56c3d73… Author: Tobias Pape <tobias(a)netshed.de> Date: 2017-01-31 (Tue, 31 Jan 2017) Changed paths: M platforms/iOS/vm/OSX/sqSqueakOSXApplication.m Log Message: ----------- Cope for a special XCode argument Commit: 77b57ad8decb1a5835baa23405057b72bdf39db7 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/77b57ad8decb1a5835… Author: Tobias Pape <tobias(a)netshed.de> Date: 2017-01-31 (Tue, 31 Jan 2017) Changed paths: M build.win32x86/newspeak.cog.spur/nsvm.exe.manifest M build.win32x86/newspeak.stack.spur/nsvm.exe.manifest M build.win32x86/squeak.cog.spur/Croquet.exe.manifest M build.win32x86/squeak.cog.spur/Squeak.exe.manifest M build.win32x86/squeak.cog.v3/Croquet.exe.manifest M build.win32x86/squeak.cog.v3/Squeak.exe.manifest M build.win32x86/squeak.stack.spur/Croquet.exe.manifest M build.win32x86/squeak.stack.spur/Squeak.exe.manifest M build.win32x86/squeak.stack.v3/Croquet.exe.manifest M build.win32x86/squeak.stack.v3/Squeak.exe.manifest M platforms/iOS/vm/Common/Classes/sqSqueakScreenAPI.m M platforms/iOS/vm/Common/Classes/sqSqueakScreenAndWindow.m M platforms/iOS/vm/OSX/Newspeak-Info.plist M platforms/iOS/vm/OSX/Pharo-Info.plist M platforms/iOS/vm/OSX/Squeak-Info.plist M platforms/iOS/vm/OSX/sqSqueakMainApplication+screen.m M platforms/iOS/vm/OSX/sqSqueakOSXApplication+events.m M platforms/iOS/vm/OSX/sqSqueakOSXCGView.h M platforms/iOS/vm/OSX/sqSqueakOSXCGView.m M platforms/iOS/vm/OSX/sqSqueakOSXOpenGLView.h M platforms/iOS/vm/OSX/sqSqueakOSXOpenGLView.m M platforms/iOS/vm/OSX/sqSqueakOSXView.h M platforms/iOS/vm/iPhone/Classes/SqueakUIView.h M platforms/iOS/vm/iPhone/Classes/SqueakUIView.m M platforms/win32/vm/sqWin32Window.c Log Message: ----------- HighDPI awarenes. Second try Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/e67f8dc97fc5^...7…

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev January 2017