Vm-dev September 2006

vm-dev@lists.squeakfoundation.org

17 participants
18 discussions

Re: [ANN] 7061 = Squeak 3.9 final
by Adrian Lienhard 26 Sep '06

26 Sep '06

On Sep 25, 2006, at 21:11 , Brad Fuller wrote: > Brad Fuller wrote: >> tim Rowledge wrote: >> >> Wouldn't the VM Crash, that I and others reported, be a reason not to >> release until fixed? Mantis issue# 0005056 >> >> brad > No comment on my question? I think, the current VM issues would be a good reason to pospone the release. Unfortunately, as it seems to me, the VM is quite poorly maintained. Probably the main reason being that the maintainers don't have enough time (or, in other words, because they are not paid to fix the problems). Another difficulty is that there are only few people that actually work on the VM (why?). Apart from the bug you mention (http://bugs.impara.de/view.php? id=0005056) there are others. For example: - http://bugs.impara.de/view.php?id=4709 (VM blocks after memory consumtion exceeds ~120MB) - http://bugs.impara.de/view.php?id=4882 (VM lockup) Cheers, Adrian PS: cc to vm-dev

8 9

Strongtalk and Exupery
by Bryce Kampjes 24 Sep '06

24 Sep '06

Hi David, It's great to see that the Strongtalk VM has been open sourced. Hopefully, it will be an asset to the community. Does the Strongtalk mailing list have a publicly available archive? One that doesn't require a yahoo sign-on? It would make it much easier for interested outsiders to follow what's going on. How does Strongtalk compare with current Java Hotspot VMs? They are also available with source for study (though not open sourced). I'm the primary author of Exupery, another attempt at fast execution technology for Smalltalk. Exupery is written in Smalltalk. The original design was to combine Self's dynamic inlining with a strong optimising compiler. For that the goal, I don't think we can afford to write in anything less productive than Smalltalk. That is still the goal but it's a long way off, Exupery is currently moving towards a 1.0 without full method inlining and without a strong optimiser. All the needed high risk features are there. Compile time is not the key issue for a dynamic compiler, pauses are. Compile time only becomes critical if you are stopping execution to compile. Exupery doesn't. Being normal Smalltalk like everything else pausing execution to compile is tricky. The trade offs to allow Exupery to be easily written in Smalltalk are the same as those required to allow long compile times for high grade optimisations. If you, or other Strongtalkers are interested in talking about compiler design please feel free to join Exupery's mailing list. Don't worry if you don't have time to study the source or play with it. Sharing experience would be valuable. Exupery is now about 4 years old, revisiting the design decisions with knowledgeable people would be useful, especially in an archived list. Exupery is another chance to keep the ideas and vision alive, if not the C++. The Exupery mailing list is here: http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery Exupery's tiny benchmarks are: 1,176,335,439 bytecodes/sec; 16,838,438 sends/sec and with the interpreter: 228,367,528 bytecodes/sec; 7,241,760 sends/sec Which makes it currently much slower than Strongtalk for sends but the same speed for bytecodes. That's comparing against the numbers provided by Gilad via Dan's post to squeak-dev. Such a comparison is not fair as relative performance does vary greatly with architecture. Exupery is best on P4's, ok on Athlons, and least impressive on Pentium-Ms. The bytecode performance is the most interesting to me. Exupery does not yet do dynamic method inlining which explains Strongtalks strong send performance. Message inlining is not necessary for a 1.0. That the bytecode numbers are so close, and I know Exupery's weaknesses, is interesting. Exupery uses a colouring coalescing register allocator but also lives with Squeak's object memory and could do with a bit more tuning. I'm guessing Strongtalk's object memory is much cleaner and better designed for speed based on reading the Self papers. Did the Strongtalk team stop tuning for bytecode performance after they passed VisualWorks? Exupery has also recently been ported to Win 32 and Solaris 10 x86. Both ports were done by other people. Pre-built VMs will be available for both platforms in a few days. Bryce

2 4

Squeak VM crash
by Brad Fuller 22 Sep '06

22 Sep '06

> > Brad Fuller wrote: >> Reducing the array size to something like: >> >> | a b | >> a := FloatArray new: (16 * 1024*500). >> b := FloatArray new: (16 * 1024*500). >> [a += b] timeToRun. >> >> works fine. >> >> the only thing I can think of is that I'm running out of total memory >> (physical+swap). With my total physical memory of 512MB and swap of 1GB, >> I would run out of memory with the original test case. If this is the >> case, is there not a safe guard in Squeak to prevent this crash? > > I think it's got nothing to do with it (and you guys should really > change the subject line if you're discussing crashes and want people > to notice your discussion). Looking at the thread, there is a dead > giveaway of the problem in the stack trace right here: > > -2128068296 HandMorph>sendMouseEvent: > -2128068388 HandMorph>handleEvent: > -2128068768 MouseOverHandler>processMouseOver: > 2032428416 HandMorph>handleEvent: > 2032428116 HandMorph>processEvents > 2032428208 [] in WorldState>doOneCycleNowFor: > 2032428024 SequenceableCollection>do: > > Your memory was allocated partially in the lower and partially in the > upper half of the 32bit address range. Looks like by allocating "just > enough" you're tipping it over to the other half of memory and my > guess would be that this is what's killing it, e.g., some > signed/unsigned/pointer arithmetic problem. And some plugin might > cause that as well, possibly even the FloatArrayPlugin itself (I don't > think anyone has ever reviewed it for those kinds of issues). > > Sigh. We should have a debug option in the VM that allows allocating > the object memory at a specific address for testing this kind of > behavior. Any takers? I'm dumb... my apologies. <Bang Head> That's a serious issue. I don't see a FloatArrayPlugin. Is it the FloatMathPlugin? It has some cross platform code. So, if it is from this, it's a potential problem for all platforms. But, as you said it could be anywhere. Still, a serious issue. brad

2 2

RE: Strongtalk VM for Squeak?
by David Griswold 17 Sep '06

17 Sep '06

Hi Klaus, > [...] > > I think what Strongtalk VM and Squeak VM already have in common is demand > for a powerful ObjectMemory implementation (the superclass of Squeak's > interpreter). > > Would you say that this can be a good subproject to start with, all in > Slang. I haven't looked at Squeak's VM in detail, but from a quick look at ObjectMemory, I would say it seems to be exposing the guts of the VM implementation, and thus wouldn't be the right place for a common interface. Something like that might be the right thing as the low-level interface for the long term goal of rewriting the Strongtalk VM in Slang or something like that, but for a common interface, we would want something that hides all the details of heap structure, object structure, etc, i.e. abstracts the VM functionality. -Dave

2 1

Strongtalk VM for Squeak?
by David Griswold 17 Sep '06

17 Sep '06

Hi Squeak VMers, I would like to start a dialog about the possiblity of joining forces, perhaps with the goal of producing a version of the Strongtalk VM for Squeak. Our problem over here is that the release of the VM source isn't very well timed, since no one from the original Strongtalk team has the time or inclination to support a full-blown open source effort to get the whole Strongtalk system finished and usable as a separate version of Smalltalk. It may turn out that Gilad Bracha can get some Sun funding to get a few VM engineers going on it, but that is speculation at this point. Personally, I just want to follow the fastest path to getting an open-source Smalltalk with this VM technology out there. If there is enough interest from Squeak VM-land, I would prefer to refocus energy from the Strongtalk community towards helping get Squeak up and running on our VM, porting it, etc. What is the thinking in Squeak-land about this? Cheers, Dave

7 9

New Win32 build structure
by Andreas Raab 16 Sep '06

16 Sep '06

Hi Folks - This is just to let you know that I've checked in the changes for the new Win32 build structure. Updated instructions are available here: http://squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/win32/HowToBuild.tx… I'm interested in working out the remaining quirks so if someone is willing to try it out and make notes on what works and what doesn't I'd appreciate it. @Tim: We need a new Win32VMMaker to support this build structure. Could you please nuke the one currently in VMMaker and replace it with the attached version? Thanks, - Andreas

2 1

Re: [Enh][VM] primitiveApplyToFromTo for the heart of the enumeration of collections?
by Klaus D. Witzel 15 Sep '06

15 Sep '06

The previously missing #returnReceiver case is now solved and the new .cs posted to - http://bugs.impara.de/view.php?id=4925 The Mantis report also includes the overrides for #commonSend and #commonReturn. Andreas, #commonSend and #commonReturn are the same what I emailed you last night. It would be interesting to compare the performance figures for platforms other than win32. /Klaus

1 0

[Enh][VM] primitiveApplyToFromTo for the heart of the enumeration of collections?
by Klaus D. Witzel 15 Sep '06

15 Sep '06

Attached is #primitiveApplyToFromTo as it compiles and runs using the win32 Squeak 3.7.1 build environment here; I'm testing it with the 3.8 and 3.9 images. The performance is compared against plain #do: (apples v.s. apples) and #to:do: (apples v.s. oranges) further down below. Compared to #do: with block, #applyTo:from:to: with block is definitively faster (smaller hidden constants) and there also is at least one item waiting for optimization (and for me having time to do that). I'd say that the factor can arrive at about 2 (#do: v.s. #applyTo:from:to:). But the primitive will not outperform an inlined #to:do: this was clear from the beginning. As Jon wrote, the primitive is good for "fixing" the standard enumeration methods so they all have (more or less) identical performance. The current implementation is for non-Strings only (as dictated by an atCache parameter) but can of course be extended to work with Strings. Another item that's missing is returning self from the primitive, this is currently handled by falling into the shadow which then returns (and some superflous bytecode cycles are burned). Example method in SequenceableCollection applyTo: aBlock from: index to: limit <primitive: 164> [index <= limit] whileTrue: [aBlock value: (self basicAt: index). thisContext tempAt: 2 put: index + 1] The shadow code is exactly what is done by the primitive. As discussed ealier,the primitive can be called from #commonSend and from #commonReturn and in both cases might decide to exit with primitiveFail. The overrides for #commonSend and #commonReturn are not attached but if you want them ask me. Any questions? /Klaus -------------------- | time array sum | array := (1 to: 10565520) collect: [:none | 1]. Smalltalk garbageCollect. time := Time millisecondsToRun: [ sum := array sum]. sum. time => 9093 -------------------- | time array sum | array := (1 to: 10565520) collect: [:none | 1]. Smalltalk garbageCollect. time := Time millisecondsToRun: [ sum := 0. array do: [:each | sum := sum + each]]. sum. time => 4764 -------------------- | time array sum | array := (1 to: 10565520) collect: [:none | 1]. Smalltalk garbageCollect. time := Time millisecondsToRun: [ sum := 0. array applyTo: [:each | sum := sum + each] from: 1 to: array size]. sum. time => 3499 -------------------- | time array sum | array := (1 to: 10565520) collect: [:none | 1]. Smalltalk garbageCollect. time := Time millisecondsToRun: [ sum := 0. 1 to: array size do: [:index | sum := sum + (array at: index)]]. sum. time => 2089 --------------------

2 1

Re: [Vm-dev] Squeak-3.9-7.i686-pc-linux-gnu.tar.gz extract error
by piumarta＠speakeasy.net 14 Sep '06

14 Sep '06

Brad, The archive seems intact. There are no errors (only successful transfers) in the recent logs for that file. Maybe try a different browser or wget or curl? Cheers, Ian

2 1

Squeak-3.9-7.i686-pc-linux-gnu.tar.gz extract error
by Brad Fuller 14 Sep '06

14 Sep '06

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev September 2006