Vm-dev December 2009

vm-dev@lists.squeakfoundation.org

20 participants
32 discussions

Start a nNew thread

Access forbidden to download the latest .deb VM
by Germán Arduino 13 Dec '09

13 Dec '09

I can't access this address: http://www.squeakvm.org/unix/release/Squeak-3.11.3.2135-linux_i386.deb Cheers. Germán.

1 0

Slang browsing enabled for Squeak trunk images
by David T. Lewis 11 Dec '09

11 Dec '09

If you are using a Squeak trunk image and have VMMaker loaded, you can evaluate "VMMaker updateFromServer; initialize". Then open an inspector on e.g. ObjectMemory or FilePlugin, click the "source" button on the browser, and select "translate to C" or "translate inlined C". The translated C code for each method is displayed interactively. Dave

3 11

'Run object as method' is flawed in VM
by Igor Stasenko 09 Dec '09

09 Dec '09

I tried to play with this feature and found that if i install a smallinteger into method dictionary as a method and then try to invoke that method, my VM is crashing. testCrashWithSmallInt self class methodDict at: #answer10 put: 10. self should: [self answer10] raise: MessageNotUnderstood. self class basicRemoveSelector: #answer10. Wed Dec 09 07:32:43 2009 Exception code: C0000005 Exception addr: 0040C08F Access violation (read access) at 00000015 EAX:02ECD658 EBX:00000022 ECX:027FBAA8 EDX:00000015 ESI:02ECD570 EDI:00000000 EBP:01250004 ESP:0006FA48 EIP:0040C08F EFL:00010246 FP Control: FFFF027F FP Status: FFFF0120 FP Tag: FFFFFFFF VM Version: Squeak 3.11.2 (alpha) from Mar 27 2009 Compiler: gcc 2.95.2 19991024 (release) Current byte code: 209 Primitive index: 199 Loaded plugins: SocketPlugin 27 March 2009 (i) SoundPlugin 6 March 2009 (i) LargeIntegers v1.5 6 March 2009 (i) Matrix2x3Plugin 6 March 2009 (i) FloatArrayPlugin 6 March 2009 (i) B2DPlugin 6 March 2009 (i) BitBltPlugin 6 March 2009 (i) SecurityPlugin 6 March 2009 (i) FilePlugin 6 March 2009 (i) MiscPrimitivePlugin 6 March 2009 (i) Stack dump: 49085392 TestObjectsAsMethods>testCrashWithSmallInt 49085300 TestCase>executeShould:inScopeOf: -- Best regards, Igor Stasenko AKA sig.

4 5

An event driven Squeak VM
by Andreas Raab 08 Dec '09

08 Dec '09

Folks - I had an interesting thought today that I'd like to run by you because I think it might just work. I have been thinking for a long time how to make the Squeak VM be "truly event driven" that is invoke it in response to OS or other events instead of having the VM poll. There are lots of good reasons for this starting from not blocking when popping up an OS context menu or standard dialog, over being able to embed the VM into other apps (browser plugin etc), up to properly dealing with suspend/resume. There are various problems that could be dealt with more easily if the VM would be truly event driven. Today it occurred to me that there might be a relatively simple way to deal with that problem merely by having interpret() run until "there is no more work to do" and return from interpret() when it's all said and done. The trick is that instead of running the idle loop, the VM would determine that it has no more work to do when there is no runnable process, so when it finds that there is no runnable process it would return from interpret saying "my work's done here, there is no more code to run at this point, ask me again when an external event comes in". The changes would be fairly straight forward: First, nuke the idle loop and allow wakeHighestPriority to return nil when there's no runnable process. Second, have transferTo: do a longjmp to the registered vmExitBuf to leave interpret(). Third, have interpret register the vmExitBuf and wake up the highest priorty process like here: interpret "install jmpbuf for main interpreter" (self setjmp: vmExitBuf) == 0 ifTrue:[ self checkForInterrupts. "timers etc" "transferTo: longjmps if arg is nil so no need to check" self transferTo: self wakeHighestPriority. "this is the current interpret() implementation" self internalizeIPandSP. self fetchNextBytecode. [true] whileTrue: [self dispatchOn: currentBytecode in: BytecodeTable]. ]. At this point we can write a client loop that effectively looks like: /* run the interpreter */ while(!done) { /* check for new events */ ioProcessEvents(); /* run processes resulting from the events */ interpret(); } Now, obviously this is inefficient, we'd want to replace the ioProcessEvents() call with something more elaborate that reacts to the incoming OS events, takes the next scheduled delay into account, checks for socket handles etc. But I'm sure you're getting the idea. Instead of wasting our time in the idleProcess, we just return when there's no more work to do and it's up to the caller to run interpret() as often or as rarely as desired. I also think that this scheme could be made backwards compatible by ensuring that we never call interpret() recursively. In this case an "old" image with the idle process would run the way it does today, and a "new" image without the idle process would live in the shiny new event driven world and return as needed. What do you think? Any reasons why this wouldn't work? Cheers, - Andreas

9 30

Re: [squeak-dev] stdio
by Eliot Miranda 06 Dec '09

06 Dec '09

Hi Bert, David, Ian, John, On Sat, Dec 5, 2009 at 3:36 PM, Bert Freudenberg <bert(a)freudenbergs.de>wrote: > On 04.12.2009, at 18:28, David T. Lewis wrote: > > > > On Fri, Dec 04, 2009 at 11:58:28AM -0500, Jason Rogers wrote: > >> Would it be possible to have Xtreams on STDIN, STDOUT, STDERR? Of > >> would that require use of OSProcess? > > > > On most unix boxes you should be able to use /dev/stdout as if it > > were a file, thus OSProcess should not be necessary. You'll need > > OSProcess if you want to set stdin for non-blocking reads to prevent > > blocking the VM. > > Unfortunately, this does not work as reliably as actually using FDs 0, 1, > and 2. I encountered at least one production system where I had to work > around the issue on the VM level (*). > > Since the VM maintainers didn't like my hack (which I can understand), > maybe we could finally add the necessary primitives. There have been a > couple proposals already. I'm not quite sure why none made it into the VM. > > - Bert - > > (*) http://dev.laptop.org/ticket/8194 FWIW here's the code in the Teleplace VM, and some code to use them for StandardFileStream. In sqFileStdioHandles-ccode are implementations of sqFileStdioHandlesInto: for platforms/Cross/plugins/FilePlugin/sqFilePluginBasicPrims.c and platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c In primitiveFileStdioHandles.st is the VMMaker code for the FilePlugin and the UnixOSProcessPlugin that uses sqFileStdioHandlesInto:. In stdioHandles.st is code for StandardFileStream that allows the creation of streams on stdin stdout & stderr (untested on Win32). HTH Eliot

2 1

[piumarta@speakeasy.net: Re: [Vm-dev] Re: [squeak-dev] 64bit VMs some thoughts.]
by David T. Lewis 05 Dec '09

05 Dec '09

Thanks Ian. Forwarding to the list - John, the GCC 4.3 comments will be of interest. ----- Forwarded message from Ian Piumarta <piumarta(a)speakeasy.net> ----- X-Sent-To: <lewis(a)mail.msen.com> From: Ian Piumarta <piumarta(a)speakeasy.net> To: "David T. Lewis" <lewis(a)mail.msen.com> In-Reply-To: <20091204014908.GA61467(a)shell.msen.com> Subject: Re: [Vm-dev] Re: [squeak-dev] 64bit VMs some thoughts. Date: Fri, 4 Dec 2009 15:28:40 -0800 X-Mailer: Apple Mail (2.936) Hi Dave, >I think you can expect the 64 bit image (SQ_VI_BYTES_PER_WORD 8) to be >relatively slow. Entirely aside from address calculation issues, the >image >is going to be full of 64-bit integer arithmetic in places where 32- >bit >arithmetic would normally be happening, and that is bound to take a >toll. My experience with em64t has been entirely positive. Programs consistently run faster in 64-bit mode than in 32-bit mode. Much of the improvement is probably due to the 8 additional registers and the passing of the first few arguments in registers rather than on the stack. The Squeak VM likely does not benefit the way most other programs do because of the aggressive inlining of methods in the C code generator, eliminating entirely the impact of a better argument passing convention. I have to say I am disgusted at gcc 4.3 though. Maybe replacing all the -O/-f options with '-Os -fno-cse-follow-jumps -fomit-frame- pointer' would help? It has worked wonders for me on (non-Squeak) bytecode interpreters; the Core2 in particular seems hypersensitive to locality and alignment of loops/jumps at the start of cache lines. (Attempts to manually allocate machine registers to VM registers always reduce performance with gcc-4.3, but I haven't experimented with explicit register assignments in the Squeak VM on 64-bit hardware.) Cheers, Ian ----- End forwarded message -----

1 0

Re: [Pharo-project] squeak VM 5.0
by David T. Lewis 05 Dec '09

05 Dec '09

Hi, (cc to vm-dev list) The 64-bit image that I provided is a direct descendent of the original one that was produced by Dan and Ian. Original 64-bit image: http://squeakvm.org/squeak64/dist3/Squeak64-3.8g-6548.image.tar.gz My update: http://squeakvm.org/squeak64/sq64-dtl.zip The original one was produced with a specialized system tracer, the code for which is here: http://squeakvm.org/squeak64/dist3/ChangeSets/System-Tracing.2.cs I did *not* use the system tracer to produce the updated image. Instead, it is the original image with various updates that I made over the years to keep up with VM developments (which were not entirely backward compatible). The original image will not run on a current VM, and that is the reason that I posted my update. The system tracer (including the specialized 64-bit one) does not work on little-endian machines. Somebody (tm) should fix this one of these days. There are a couple of Mantis reports related to this: http://bugs.squeak.org/view.php?id=5240 http://bugs.squeak.org/view.php?id=5239 As far as producing a 64-bit Pharo image, I think there are two things that could be tried: 1) Fix the system tracer to work on little-endian boxes (probably not too difficult), then try tracing some Pharo and Squeak images into 64-bit format. 2) Find somebody who has a big-endian Mac available, and have them try tracing some images. I can think of no reason why the newer images with closure support could not be traced into 64-bit formats, but I guess the only way to find out is to try it and see what happens. Dave On Fri, Dec 04, 2009 at 01:39:28PM -0800, John M McIntosh wrote: > I think David Lewis made the last one, let's cc him. > > Perhaps the process would be > > Examine the squeak image. > take the required source that does the system tracing > someone make a MC project (no idea if one exists?) > > a) file that into a Pharo image. > b) Correct things like references to Smalltalk, versus SmalltalkImage current > c) run it. > d) place 64bit image on pharo server. > > I note to run the system tracer you need to run it either on a PowerPC. > Or on a MacIntel using a 4.x series macintosh VM, make a copy, do a get info on the VM > check "Open using Rosetta" > > If "Open using Rosetta" is not an option and you are running 10.6 then it is likely you did > not install Rosetta when you upgraded/installed 10.6. You need to find your 10.6 DVD > and lookup how to install Rosetta after installing 10.6 > > PS yes you could use a 10.5 series VM for this too. > > > However to complicate things I don't think anyone has done a Closure based image > and I don't know if that will be a problem. You could take a pre-closure Pharo image > and try it just to get past the point where having the SystemTracer code in a MC is done. > > > On 2009-12-04, at 1:23 PM, Laval Jannik wrote: > > > Hi Alex, > > > > PharoCore is a 32bits image. > > So it works on Squeak.5.0.0.b9.64*32.app. > > > > I see that Squeak has a 64bits fork image, is it possible to have a Pharo one? > > What is the process to do this ? > > > > Cheers, > > Jannik > >

1 0

Re: [squeak-dev] 64bit VMs some thoughts.
by David T. Lewis 05 Dec '09

05 Dec '09

On Thu, Dec 03, 2009 at 03:03:48PM -0500, David T. Lewis wrote: > > I would guess that the difference I am seeing now is due to compiler version. > Ian's VM was compiled with gcc 4.3.3 and I am using an older gcc 4.1.2 compiler. > > The results I got were: > > For a 64-bit VM that I compiled locally, installed in /usr/local: > CPU: AMD Turion(tm) 64 Mobile Technology ML-34, 1600 MHz > OS: Linux version 2.6.18.2-34-default > Compiler for VM: gcc 4.1.2 > Results: > > 0 tinyBenchmarks ==> 154031287 bytecodes/sec; 5145368 sends/sec > 0 tinyBenchmarks ==> 153201675 bytecodes/sec; 5183202 sends/sec > 0 tinyBenchmarks ==> 151658767 bytecodes/sec; 5268426 sends/sec > > For a 32-bit VM from Ian's site, running the same image from a local directory: > CPU: AMD Turion(tm) 64 Mobile Technology ML-34, 1600 MHz > OS: Linux version 2.6.18.2-34-default > Compiler for VM: gcc 4.3.3 > Results: > > 0 tinyBenchmarks ==> 62135922 bytecodes/sec; 3330746 sends/sec > 0 tinyBenchmarks ==> 62256809 bytecodes/sec; 3425013 sends/sec > 0 tinyBenchmarks ==> 62317429 bytecodes/sec; 3346096 sends/sec > After installing a prodigious number of 32-bit libraries on my 64-bit Linux, I can now build a 32-bit VM for comparison. Here are the results of a 64-bit versus 32-bit VM using the same compiler, operating system, and hardware: Compiled in 64-bit mode: 0 tinyBenchmarks '155339805 bytecodes/sec; 5304104 sends/sec' 0 tinyBenchmarks '155812538 bytecodes/sec; 5393385 sends/sec' 0 tinyBenchmarks '155151515 bytecodes/sec; 5272367 sends/sec' Compiled in 32-bit mode: 0 tinyBenchmarks '136679124 bytecodes/sec; 4652907 sends/sec' 0 tinyBenchmarks '135521439 bytecodes/sec; 4659058 sends/sec' 0 tinyBenchmarks '135665076 bytecodes/sec; 4690056 sends/sec' So overall I see about a 14% speed advantage for the 64-bit VM versus the 32-bit VM on this platform. Again, this is with the older gcc 4.1.2 compiler. Dave

3 4

Re: [squeak-dev] macintosh cocoa 32/64bit & 64/64bit VM goes BETA
by John M McIntosh 04 Dec '09

04 Dec '09

On 2009-12-04, at 10:24 AM, Miguel Enrique Cobá Martinez wrote: >> The VM currently runs on 10.5.x and 10.6.x Support for 10.4.x might happen, we will see. > > So this is only for macs. Is that right? yes > When the code is integrated with the squeakvm svn code there will be any > chance of having it run on other OS (GNU/Linux is my own). Or this will > only work for Macs? > > Anyway, thanks. Ok, there are a number of issues on the table (a) confirming the base VM and internal plugins work. For example sound, the jpeg2readwriter, etoys security, did not work because it looked like people wanting to compile as 64bit didn't care if it did sound or rendered jpegs. Typically I think they just wanted a 64bit platform for Seaside server usage. (b) Making it all work on external plugins, ie for example rome and freetype2 (c) Some people have asked can you take the code base and run on Gnu/Linux using the GNU Objective-C environment? Well the code base *is* tied to platform specific technology for the iPhone & OSX for sound, display, and sensor input. However you can subclass override all that behaviour with code that does the right thing for sound, display, and sensor input. I have to do that anyway to provide variations between os-x and iPhone. But really I think the question here is reuse of the common code base, lots of that, Sockets for example is generic unix code so yes the goal is to make the *entire* common code base 64bit clean compile-able on various unix like platforms, versus just the minimum required to run Seaside > > -- > Miguel Cobá > http://miguel.leugim.com.mx > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

1 0

Re: [squeak-dev] 64bit VMs some thoughts.
by David T. Lewis 03 Dec '09

03 Dec '09

On Wed, Dec 02, 2009 at 05:28:33PM -0800, John M McIntosh wrote: > So you sit there smug about the fact you built a 64bit VM, likely for hosting on your 64bit Linux OS. > {Or the unix one for Darwin, or that new fangled cocoa one} > > However it's possible that it's running 1/3 the performance of the 32bit VM. > Did you check? Thought not... > > So let's talk. > > Are you using the gnuifed version of interp.c? If you don't know, well go check. > Are you using GCC 4.1 or higher? > > The interpreter loop is highly tuned monster that suffers from compiler optimization issues. With > careful tuning parms as found in the macintosh xcode build project for the carbon VM using gcc 4.0 > you'll get the most optimum performance. > > GCC 4.2+ ? > > Michael Rueger and I spent a few days attempting to get good performance out of GCC 4.2 > WITHOUT success. I think that can account for at least a 33% slowdown. > > So where does the other 33% slowdown come from? > > Well when we compile the VM in 64bit to use a 32bit image each reference to an oops requires us > to add a 64bit memory start address to the 32bit oops number to resolve to a 64bit memory address. > Unfortunately GCC 4.2 growls, and produces the lousiest code possible to do this. > Maybe higher versions of GCC are better? Anyone care to test? > > So some solutions. > > (a) Ensure the squeak oops memory block loads within the 0-4GB address space. > See pagezero size for Darwin. Then alter the logic a bit so that sqMemoryBase is zero > and that the squeak memory accessors don't do the add of sqMemoryBase=0 to the oops address. > Although you might have to use GCC 4.2 you'll run 100% faster. > > (b) Use the (non-free) Intel compiler > Hi John, I get very different results, but they certainly support your observation that newer GCC compilers are a problem. If I compare a 64-bit VM built on my computer to a 32-bit VM downloaded from Ian's site, running both on the same hardware and OS (AMD Turion, 64 bit Linux), the 64-bit VM is running about twice as fast as the 32-bit VM. In the past (over several years), I have never measured this carefully, but I have the general impression that 64-bit and 32-bit VMs run at similar speeds on my hardware and OS (I guess I should figure out how to compile in 32-bit mode so I can really find out). I would guess that the difference I am seeing now is due to compiler version. Ian's VM was compiled with gcc 4.3.3 and I am using an older gcc 4.1.2 compiler. For the record, here are the results I got (copied from CommandShell windows in a Squeak trunk image). For a 64-bit VM that I compiled locally, installed in /usr/local: $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 36 model name : AMD Turion(tm) 64 Mobile Technology ML-34 stepping : 2 cpu MHz : 1600.000 cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow up pni lahf_lm bogomips : 3203.59 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc $ cat /proc/version Linux version 2.6.18.2-34-default (geeko@buildhost) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #1 SMP Mon Nov 27 11:46:27 UTC 2006 $ /usr/local/bin/squeak -version SQUEAK_ENCODING=UTF-8 SQUEAK_PATHENC=UTF-8 SQUEAK_PLUGINS=/usr/local/lib/squeak/3.11.9-2145 + exec /usr/local/lib/squeak/3.11.9-2145/squeakvm -version 3.11.9-2145 #1 XShm Thu Dec 3 10:54:44 EST 2009 gcc 4.1.2 Linux linux-6xfc 2.6.18.2-34-default #1 SMP Mon Nov 27 11:46:27 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux plugin path: /usr/local/lib/squeak/3.11.9-2145 [default: /usr/local/lib/squeak/3.11.9-2145/] $ strings /usr/local/lib/squeak/3.11.9-2145/squeakvm | grep gcc gcc 4.1.2 $ 0 tinyBenchmarks 154031287 bytecodes/sec; 5145368 sends/sec $ 0 tinyBenchmarks 153201675 bytecodes/sec; 5183202 sends/sec $ 0 tinyBenchmarks 151658767 bytecodes/sec; 5268426 sends/sec $ For a 32-bit VM from Ian's site, running the same image from a local directory: $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 36 model name : AMD Turion(tm) 64 Mobile Technology ML-34 stepping : 2 cpu MHz : 1600.000 cache size : 1024 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow up pni lahf_lm bogomips : 3203.59 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc $ cat /proc/version Linux version 2.6.18.2-34-default (geeko@buildhost) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #1 SMP Mon Nov 27 11:46:27 UTC 2006 $ pwd /home/lewis/squeak/VMM-Ian/Squeak-3.11.3.2135-linux_i386/lib/squeak/3.11.3-2135 $ ls -l squeakvm -rwxr-xr-x 1 lewis users 2376017 2009-09-16 17:46 squeakvm $ strings squeakvm | grep gcc gcc 4.3.3 $ ./squeakvm -version 3.11.3-2135 #1 XShm Wed Sep 16 14:25:10 PDT 2009 gcc 4.3.3 Linux ubuntu 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux plugin path: /usr/local/lib/squeak/3.11.9-2145 [default: /home/lewis/squeak/VMM-Ian/Squeak-3.11.3.2135-linux_i386/lib/squeak/3.11.3-2135/] $ 0 tinyBenchmarks 62135922 bytecodes/sec; 3330746 sends/sec $ 0 tinyBenchmarks 62256809 bytecodes/sec; 3425013 sends/sec $ 0 tinyBenchmarks 62317429 bytecodes/sec; 3346096 sends/sec $ Dave

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev December 2009