Vm-dev January 2007

vm-dev@lists.squeakfoundation.org

10 participants
7 discussions

Re: [ANN] new development snapshot of muO available
by Brad Fuller 25 Jan '07

25 Jan '07

Stéphane Rollandin wrote: > hello list, > > a new development snapshot of muO is available: > http://www.zogotounga.net/comp/squeak/sqgeo.htm > > it can be installed in a 3.8 or 3.9 image (use fresh images for safety > and convenience) > > muO is an experimental environment for musical composition Great! I've been looking at it in 3.8 and I'm eager to move to 3.9. BTW: is anyone working on completing the Linux MIDI plugin? Ian: what do you think it would take to make the MIDI plugin talk to ALSA MIDI? I have no experience with this, but since you did the ALSA audio plugin, you might have come across ALSA's MIDI. -- brad fuller www.bradfuller.com

1 0

[Vm-dev] saving window top/left in the image, and what does it mean?
by John M McIntosh 24 Jan '07

24 Jan '07

For reasons lost in time, although one of the readers might now, the vm stores the window width/height in the image file, but not the top/ left. Now Eliot Miranda asked me about launching Squeak on his mac and having it show up as full screen on the secondary display. Which of course does not happen since it opens on the main display and goes to full screen there. To do this I would need to know that I have to place the window on the secondary display, or elsewhere in the coordinate system which would be the secondary display, then go to full screen. I'd like to propose that we grab another 4 bytes (8 bytes?) out of the header and store the top/left in mmm macintosh quickdraw coordinate systems values. Then on main window open a VM would need to see if the window created based on the top/left be visible, if so to open it at those coordinates, otherwise fall back to the historical code. I realize of course this might not work for Xwindows or Windows (no clue) but even just having the ability to position a squeak window at startup at a given location is more useful than our fall back position of 44 & 8. Perhaps even suggesting a number (2) meaning use the secondary screen or something, mm and top/left being 0/0 of top/left of 2nd screen. Thoughts? Well one part is do we need this? The second is how to implement in a manner that all VMs would do the right thing based on some magic numbers. -- ======================================================================== === John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

3 3

Re: Linux: My computer is so fast ...
by Bert Freudenberg 23 Jan '07

23 Jan '07

Well, that wouldn't turn back the clock a hundred times in 5 seconds, would it? But something is causing it. I logged the value of "Time millisecondClockValue" in a process parallel to the latency test. It frequently jumps back one or two milliseconds. It is *not* jumping back if instead of running the socket I/O tests, I just calculate something for five seconds. This sounds very much like a VM problem, I'm taking this to the VM- Dev list. Reply-To set. - Bert - Am Jan 23, 2007 um 21:41 schrieb Ken Causey: > Perhaps a time correction through an NTP daeomon or the like? > > Ken > > P.S. Of course that only makes sense if the clock used is the actual > time and not something like a clock time independent value like > milliseconds since program start. Maybe. I'm not sure how that is > calculated either, truth be told. > > On Tue, 2007-01-23 at 20:43 +0100, Bert Freudenberg wrote: >> ... that it finishes before it even started. >> >> I just ran Croquet's tests on a MacBook Pro with Ubuntu Linux in the >> Parallels PC emulator: >> >> CroquetVMTests new quickLatencyTest >> >> results in >> >> #(2.451390797266446e6 1073741822 0.023 3) >> >> which is a test failure. The first value is supposed to be the >> average number of milliseconds for a local network roundtrip, the >> second the maximum. Strange values. Looking at the actual test runs, >> here are the results sorted by occurrence, values in hex: >> >> a SortedCollection(63481->'16r0' 4374->'16r1' 131->'16r2' 61- >>> '16r3FFFFFFE' 45->'16r3FFFFFFD' 44->'16r3' 29->'16r4' 20- >>> '16r3FFFFFFC' 10->'16r7' 3->'16r6' 3->'16r5' 2->'16r8' 1- >>> '16r3FFFFFFB') >> >> The method to measure the runtime is [...] timeToRun. How could that >> possibly answer a negative amount?! Only if the millisecond clock >> turns backwards. The new Apple machines indeed are very fast, but >> *that* fast? >> >> - Bert - >> >> >> >>

1 0

An issue with Slang, the interpreter & the VM, and a period in biasToGrow.
by John M McIntosh 23 Jan '07

23 Jan '07

I was chasing a problem with Sophie where the VM would suddenly grow by 800MB. In looking I discovered a problem with how Slang interprets the following code. Background: When an incremental garbage collection is done and the free space is less than the grow head room and the bias to grow is turned on, then we call biasToGrow. I'll note normally the gcBiasToGrow would be false unless you turn it on so few users have seen this problem. The problem is that Slang converts the "growSize := growHeadroom*3/2 - (self sizeOfFree: freeBlock)" to nothing. In the past I know this worked because I had worked on choosing the magic 3/2 number. ObjectMemory>>incrementalGC ... (((self sizeOfFree: freeBlock) < growHeadroom) and: [gcBiasToGrow > 0]) ifTrue: [self biasToGrow. weDidGrow := true]. youngStart := freeBlock]. ... ObjectMemory>>biasToGrow | growSize | growSize := growHeadroom*3/2 - (self sizeOfFree: freeBlock) self growObjectMemory: growSize ObjectMemory>>growObjectMemory: delta "Attempt to grow the object memory by the given delta amount " | limit | statGrowMemory := statGrowMemory + 1. limit := self sqGrowMemory: memoryLimit By: delta. limit = memoryLimit ifFalse: [memoryLimit := limit - 24. "remove a tad for safety" self initializeMemoryFirstFree: freeBlock] --------------------------------------------------- But the C code that Slang generates looks like so: if ((((longAt(foo->freeBlock)) & AllButTypeMask) < foo- >growHeadroom) && (foo->gcBiasToGrow > 0)) { /* begin biasToGrow */ /* begin growObjectMemory: */ foo->statGrowMemory += 1; limit = sqGrowMemoryBy(foo->memoryLimit, growSize); if (!(limit == foo->memoryLimit)) { foo->memoryLimit = limit - 24; initializeMemoryFirstFree(foo->freeBlock); } weDidGrow = 1; } The C compiler is happy (mostly) and depending on what it sticks in the growSize memory location, perhaps it's perhaps zero, perhaps not, we might as I did some odd behaviour. How clever, and if you've come this far, you've like seen the missing period. at the end of "growSize := growHeadroom*3/2 - (self sizeOfFree: freeBlock)" Helpfully Slang doesn't complaint about the missing period and forges onward creating in-valid C code, without the proper meaning. Hopefully people writing Slang code are muttering, gee I wonder if I have some code that isn't quite what I think it is? With the period of course the code becomes if ((((longAt(foo->freeBlock)) & AllButTypeMask) < foo- >growHeadroom) && (foo->gcBiasToGrow > 0)) { /* begin biasToGrow */ growSize = (((sqInt) (foo->growHeadroom * 3) >> 1)) - ((longAt(foo- >freeBlock)) & AllButTypeMask); /* begin growObjectMemory: */ foo->statGrowMemory += 1; limit = sqGrowMemoryBy(foo->memoryLimit, growSize); if (!(limit == foo->memoryLimit)) { foo->memoryLimit = limit - 24; initializeMemoryFirstFree(foo->freeBlock); } weDidGrow = 1; } Mostly likely in working with Tim I managed to copy/paste some code and missed the '.' Lastly I'll note the biasToGrow logic is there because there is a problem when Squeak reaches the boundary point where it must decide to grow, before doing that it does an incremental GC, the issue is that if the incremental GC can recover just enough few bytes the grow will not happen, but we will do another GC really really soon, thus you see Squeak at 100% CPU in the GC logic, yet not quite growing, at some point you will go over the boundary and grow, solving the problem. The bias to grow logic then ensures the VM will grow in increments up to a certain threshold before forcing a full GC, thus avoids the particular problem. -- ======================================================================== === John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

3 2

Linux 3.9 VM and Plugins
by Brad Fuller 20 Jan '07

20 Jan '07

I'm using the 3.9-8 version of the VM from http://squeakvm.org/unix/. It does not contain all the plugins, only: AioPlugin PseudoTTYPlugin UnixOSProcessPlugin XDisplayControlPlugin vm-display-X11 vm-display-fbdev vm-display-null vm-sound-ALSA (yeah!) vm-sound-OSS vm-sound-null Must I build the VM to get all the plugins available for *nix? Or are they available somewhere else? -- brad fuller www.bradfuller.com

2 2

Updated callbacks
by Andreas Raab 16 Jan '07

16 Jan '07

Hi Guys - Just FYI, I found a major bug in the callback support I posted earlier. The problem occurs if one fails a primitive *after* a callback has been invoked like here: Squeak -> (primitive) -> Plugin Plugin -> (callback) -> Squeak Plugin <- (return) <- Squeak Squeak <- (failure) <- Plugin In such a case, the method being activated by the primitive failure is not the method originally invoking the primitive but rather the one that returned from the callback. More technically speaking, the interpreter's newMethod isn't preserved which causes the effect described above. The attached version fixes the problem by preserving newMethod across callback enter/return. Cheers, - Andreas

1 0

GCC 4.1
by Philippe Marschall 15 Jan '07

15 Jan '07

Hi I'm seeing significant improvements when compiling a VM with GCC 4.1 over the stock Unix VMs. They are almost too good to be true. stock 3.9-9 vm, GCC 4.0.3: 56437389 bytecodes/sec; 2609047 sends/sec compiled with GCC 4.1.1: 113676731 bytecodes/sec; 4011617 sends/sec That is about twice as many bytecodes/sec and about 50% more sends/sec. Can that be? Cheers Philippe

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev January 2007