Vm-dev May 2009

vm-dev@lists.squeakfoundation.org

16 participants
24 discussions

Profiling and delay accuracy
by Andreas Raab 06 Aug '11

06 Aug '11

Hi Folks - For a long time now I had this feeling that MessageTally reports pretty bogus results in many situations without being able to precisely track down why this would be the case. Today I was looking at primitiveResponse() and, much to my surprise, noticed that the checkForInterrupts() that used to be there for years is gone (see Squeak3.6 for example which still has it). The sole reason for this check was to get both high delay accuracy and good profiling behavior. Consider this example: fc := FormCanvas on: Display. MessageTally spyOn:[ 1 to: 100 do:[:i| fc fillColor: Color white. fc printString. ]. ]. Using 3.6 this will be measured correctly as: **Tree** 87.5% {243ms} FormCanvas>>fillColor: |87.5% {243ms} GrafPort>>fillRect:offset: | 87.5% {243ms} GrafPort>>copyBits 12.5% {35ms} FormCanvas(Object)>>printString 12.5% {35ms} FormCanvas(Object)>>printStringLimitedTo: whereas the 3.10 reports it as **Tree** 99.6% {670ms} FormCanvas(Object)>>printString 94.9% {639ms} primitives 4.6% {31ms} FormCanvas(Object)>>printStringLimitedTo: I think you can see the problem and just imagine what this does to any cumulative results. I also wonder what that change does to platforms that don't have high-resolution asynchronous timers. This used to be the one place where we would catch timer changes at high resolution and unless the platform forces high resolution timer interrupts asynchronously (by resetting the interrupt counter) we must be loosing a lot in terms of delay accuracy. (it just so happens that the Windows VM *does* do asynchronous timer interrupts so I never noticed this but I'm very curious about the difference on Linux which typically still has pretty bad timer granularity). Any opinions? My feeling is that the timer check should go back in for all of the above reasons. At the very least a quickCheckForInterrupt() is required but I actually think putting the full check back in is worth it. Cheers, - Andreas

3 3

Joys of Squeak-dev image, VM Compiling on MacIntel and Spoon remote OtherBrowsing
by Ken G. Brown 16 Nov '10

16 Nov '10

MacPro OS X 10.4.9 Xcode 2.4.1 Squeak-dev-114-2, VMMaker 2.8b6.1, Squeak 3.8.15beta6U.app, and version 1657 of svn MacOS VM sources, and Spoon v2a12. Downloaded http://www.squeakvm.org/cgi-bin/viewcvs.cgi/ trunk version 1657 for MacOS Ran squeak-dev-beta-114-2.image on Squeak 3.8.15beta6U.app Loaded VMMaker 3.8b6.1 from dev image Universes. Generated vm sources by following instructions in <http://www.squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/Mac%20OS/vm/Doc…> Fought with Xcode wanting to use MacOSX10.3.9.sdk for ppc which was giving an error which was known and documented in the Readme. Finally figured out what Xcode wanted so built universal app just using 10.4.9 sdk. Couple issues: Exupery references remain in sqnamedPrims.h and sqPlatformSpecific.h from svn version 1657, I just commented them out. Notes said: Info-NPSqueak__Upgraded_.plist was to be found in the Developer directory. I could not find it so scammed a info.plist out of John's Squeak 3.8.15beta6U.app vm. Not sure what impact this has. And much, much diddling about figuring out various things... Finally got a build. It's a lot smaller (3.9MB) than John McIntosh's Squeak 3.8.15beta6U.app (8.1MB), and it looks like it is a PowerPC one but at least it runs. I'll look into the Xcode build process some more. Then: Replaced interp.c with Craig's interp.c for Spoon, rebuilt and got a VM with Spoon client stuff. Downloaded Spoon release 2a12. Moved a copy of Flow plugin from within Craig's naiad.app package into a plugins subdirectory where the new spoon client compatible MacIntel universal VM was run from. Followed Craig's Spoon instructions for loading niaid.st and niaid.pr into the 3.10 image (Squeak-dev-114-2) running on the new VM. Did the run spoon.app thing from Spoon.dmg (version 2a12), needs to be done twice if Safari is not running. Got Spoon processor running. Followed instructions again in the Spoon client and lo! Got OtherBrowser browsing the Spoon memory running on processor. Yay Craig! Who do i get to sign my certificate? :) Ken

4 7

Fwd: [Pharo-project] Could not load VMMaker in 10315
by John M McIntosh 18 Aug '09

18 Aug '09

Begin forwarded message: > From: Stéphane Ducasse <stephane.ducasse(a)inria.fr> > Date: May 24, 2009 1:35:01 AM PDT (CA) > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > Subject: [Pharo-project] Could not load VMMaker in 10315 > Reply-To: Pharo-project(a)lists.gforge.inria.fr > > Hi > > I did > > ScriptLoader loadFFI > Then loaded VMMaker-dtl.122 > Then proceeded when asked about klatt. > > And I got Cannot compile -- stack including temps is too deep > > what did I miss? > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

4 7

Resources directory in SecurityPlugin
by Bert Freudenberg 04 Aug '09

04 Aug '09

When running Etoys inside a web browser, the file sandbox is preventing access to all files outside the "Etoys" working directory (a.k.a. "untrusted user directory"). That means we cannot open help guides or switch languages or access examples or the sources file etc. Proposed solution: In the SecurityPlugin, allow read-only file to a "resource" directory (in addition to read-write access to the "untrusted user directory"). The default for this resource directory would be the image directory. I did it for Unix, you can find a diff attached to the Etoys ticket: http://tracker.squeakland.org/browse/SQ-241 Basically, the writeFlag is now passed down to isAccessiblePathName(), and in case it's read-only, it allows access to the resource dir (which is configurable but defaulting to the image path). Any chance to get the same behavior implemented on Mac and Win VMs, too? Thanks :) - Bert -

2 2

Immutability bit? Eliot?
by Göran Krampe 26 May '09

26 May '09

Hi VM gurus! I just responded to a persistence thread on the seaside-list and it occurred to me that I should ask you guys - especially Eliot I guess - will the new VM have support for detecting object modification? ...and oh, when do we get the new awesome VM? I am doing reload on mirandabanda every day but no luck so far... :) :) Cees de Groot explained a technique (a long while back) using an immutability bit on objects - combined with some Exception being signalled when an immutable object is about to be modified. This way you get both support for immutable objects AND "dirty marking" because you can always catch the Exception, add the object as "dirty" in a pool, and then resume. Especially for all the persistence solutions out there this would be great to have - and would eliminate trickery like WriteBarrier: http://map.squeak.org/packagebyname/writebarrier regards, Göran

2 1

Re: [squeak-dev] Cuis updated to #0204
by Juan Vuletich 23 May '09

23 May '09

Karl Ramberg wrote: > On 2009-05-23 14:15, Juan Vuletich wrote: >> ... >> >> BTW, at http://www.jvuletich.org/Cuis I uploaded some screen shots of >> Cuis with and without subpixel AA and at various Display depth, for >> those too lazy to actually download it. >> >> Cheers, >> Juan Vuletich >> >> > Not to be nit picking but being it anyway... > In the SubPixelAA pictures in the Workspace on top I see white pixels > in the f, t, 1, B and s.... > > Karl > > > I see some artifacts on the subpixel You are right! It is in the 32bpp image. Of course you don't see those in Squeak, it is a problem of how I saved the PNG file. I fixed it now. The details... The alpha channel of Display is ignored by VMs. So we don't pay much attention to it, but it usually contains "garbage". This was noted by people using composing window managers in Linux. You see in the png that I evaluated 'Display fixAlpha. PNGReadWriter putForm:...'. That fixed the alpha channel for the whole Display. But it seems that when evaluating, Squeak redered the selected text again, creating the defect you noticed. Cheers, Juan Vuletich

1 0

Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts
by John M McIntosh 22 May '09

22 May '09

I'm wondering if the BitBlt should be part of the main stream VM and integrated into VMMaker, versus being a separate over-riding plugin? Begin forwarded message: > Thanks, Damien! > > Note, on Mac, the VM "Squeak 4.1.1beta2U" does not contain the new > BitBlt plugin and hence the fonts are rendered without subpixel > antialiasing. To enable this, drop the attached file (this is from > the prototype one-click-image that Marcus produced some time ago) in > the Resources folder in the VM app. > > John, could this be included by default in the VMs you ship? > > Cheers, > Adrian -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

9 22

DTrace for Squeak?
by Adrian Lienhard 19 May '09

19 May '09

Has anybody considered adding a DTrace user space provider to the VM? This could be very helpful for debugging and profiling (at least on Mac; I don't know about DTrace for Linux). My man pages on OS X describe the same approach for adding probes to a C program as in http://blogs.sun.com/ahl/entry/user_land_tracing_gets_better Ruby, Java, Perl, PHP and others have such high-level providers. Cheers, Adrian ___________________ http://www.adrian-lienhard.ch/

3 3

Re: [Vm-dev] stack vm questions
by Eliot Miranda 17 May '09

17 May '09

On Thu, May 14, 2009 at 4:36 AM, Jecel Assumpcao Jr <jecel(a)merlintec.com>wrote: > > Thanks Eliot and Igor for your comments! > > Eliot is right that what Igor wrote is a good way to do a JIT but the > problem is that my hardware is essentially an interpreter and must deal > at runtime with expressions that the JIT would optimize away. > > My design is described in: > > http://www.squeakphone.com:8203/seaside/pier/siliconsqueak/details > > What is missing from that description is what the control registers (x0 > to x31) do, and that depends on the stack organization. Certainly it is > possible to have three registers as Eliot suggested. A separate control > stack is not only used on Forth processors but was also popular in Lisp > Machine designs. > > Registers t0 to t29 are really implemented through a small amount of > hardware as a range of words in the stack cache. Having to split this > set differently for each method would make the hardware larger and > slower. With a separate control stack the mapping is really simple. > > About the JIT having to use call which pushes the PC, that is not true > on RISC processors. But I suppose the focus for Cog is making Squeak > fast on the x86. Right, but also for sanity the run-time support code needs to be ISA-agnostic. So the frame organization will be unchanged between different ISAs and that means even on RISCs the return pc will be pushed; perhaps not in frameless leaf methods. but definitely in normal frames and hence it might as well be pushed in the same place, and incremented by the size of the call instruction, instead of having the return instruction add the offset at return time. > There's a tension between implementing what the current compiler > > produces and implementing what the instruction set defines. For > > example should one assume arguments are never written to? I lean > > on the side of implementing the instruction set. > > That is specially a good idea if the same VM ends up being used for > other languages like Newspeak. Certainly the Java VM runs many languages > that the original designers never expected. Good point. > > Yes. In the JIT an interpreted frame needs an extra field to hold > > the saved bytecode instruction pointer when an interpreted frame > > calls a machine code frame because the return address is the "return > > to interpreter trampoline" pc. There is no flag word in a machine > > code frame. So machine code frames save one word w.r.t. the > > stack vm and interpreted frames gain a word. But most frames > > are machine code ones so most of the time one is saving space. > > Ok, so the JIT VM will still have an interpreter. Self originally didn't > have one but most of the effort that David Ungar put into the project > when it was restarted was making it more interpreter friendly. The > bytecodes became very similar to the ones in Little Smalltalk, for > example. Have you got an URL for that bytecode set? If not, can you mail me some code or documentation that describes it? Will images be compatible between the JIT VM and the Stack VM? Or do you > expect the latter to not be used anymore once the JIT is available? I > had originally understood that the Stack VM would be compatible with > older images (since you divorce all frames on save and remarry them on > reload) but I had missed the detail of the different bytecodes for > variable instance access in the case of Context objects. Most of this I've answered in a different message. Yes, accessing Context inst vars needs special treatment. One can add the test to all relevant inst var accesses (only inst vars 0 through 2 are affected on read and 0 through 5 on write) but that would be very slow. Hence the recompile to use the long-form bytecodes is necessary. This whole treatment of Context inst var access is complex but IMO it is better to hide it in the VM using the primitive and long-form IV bytecode interface than exposing the internals to the image because that makes the bootstrap process easier and makes evolving the VM easier too. > I guess that in hardware you can create an instruction that will > > load a descriptor register as part of the return sequence in parallel > > with restoring the frame pointer and method so one would never > > indirect through the frame pointer to fetch the flags word; instead > > it would be part of the register state. But that's an extremely > > uneducated guess :) > > Well, I am trying to avoid having a flags word even though in hardware > it is so easy to have any size fields that you might want. I can check > if context == nil very efficiently. For methods, t0 is the same value as > the "self" register (x4, for example) while for blocks it is different. > And with three pointers (fp, sp and control pointer) I shouldn't need to > keep track of the number of arguments. > > > Jecel can also design the machine to avoid taking interrupts on > > the operand stack and provide a separate interrupt stack. > > Hmmm... it has been a while since I designed hardware with interrupts, > but have normally used Alto style coroutines instead. Of course; a much better architecture! > The stack cache is > divided up into 32 word blocks and can hold parts of stacks from several > threads at once. Checking for overflow/underflow only needs to happen > when the stack pointer moves from one block to a different one (and even > then, only in certain cases which aren't too common). An interesting > feature of this scheme is that only 5 bit adders are needed (which are > much faster than 16 or 32 bit adders, for example. Wide adders could > reduce the clock speed or make the operation take an extra clock). > Another detail is that having operand or control frames split among two > stack pages is no problem at all. Cool :) address of tN in the stack cache: > > raddr := fp[4:0] + N. > scaddr := (raddr[5] ? tHigh : tLow) , raddr[4:0]. > > When fp[5] changes value, then tLow := tHigh and tHigh := head of free > block list (if fp was going up). If there are no free blocks, then some > have to be flushed to their stack pages in main memory. When going down, > tLow is loaded from a linked list, which might have to be extended by > loading blocks from stack pages. With a 4KB stack cache, for example, > there are 32 blocks with 32 words each and so block 0 can dedicate a > word for each of the other 31 blocks. The bottom 7 bits of that word > (only 5 actually needed, but it is nice to have a little room to grow) > can form the "previous" linked list (tHigh and tLow would also be 5 bits > wide) while the remaining bits can hold the block's address in main > memory. > > This might seem far more complicated than a split arg/temp frame and it > certainly would be if implemented in software. In hardware, it is mostly > wires, a multiplexer and a small adder. A different world. Cool! > > -- Jecel > >

2 1

Squeak crash
by Gwenael Casaccio 14 May '09

14 May '09

Hi, I've built my own version of Squeak (with a personal plugin) and when I've launched it, I can see the environment but after 5 sec Squeak crashes. Segmentation fault 26962964 >seconds:nanoSeconds: 26962872 >seconds: 26962780 >fromSeconds: 26962680 >dateAndTimeFromSeconds: 26962588 >dateAndTimeNow 26962312 SmalltalkImage>recordStartupStamp 19198472 SmalltalkImage>snapshot:andQuit:embedded: 19198380 SmalltalkImage>snapshot:andQuit: 19198288 SmalltalkImage>saveSession 19198104 TheWorldMenu>doMenuItem:with: 19198012 [] in MenuItemMorph>invokeWithEvent: 19197920 BlockContext>ensure: 19197828 Cursor>showWhile: 19197736 MenuItemMorph>invokeWithEvent: 19197644 MenuItemMorph>mouseUp: 19197552 MenuItemMorph>handleMouseUp: 19197416 MouseButtonEvent>sentTo: 19197324 Morph>handleEvent: 19197232 MorphicEventDispatcher>dispatchDefault:with: 19197140 MorphicEventDispatcher>dispatchEvent:with: 19197048 Morph>processEvent:using: 19196956 MorphicEventDispatcher>dispatchDefault:with: 19196848 MorphicEventDispatcher>dispatchEvent:with: 19196712 Morph>processEvent:using: 19196620 Morph>processEvent: 19196528 MenuMorph>handleFocusEvent: 19196252 [] in HandMorph>sendFocusEvent:to:clear: 19196344 [] in PasteUpMorph>becomeActiveDuring: 19196160 BlockContext>on:do: 19196068 PasteUpMorph>becomeActiveDuring: 19195884 HandMorph>sendFocusEvent:to:clear: 19195792 HandMorph>sendEvent:focus:clear: 19195700 HandMorph>sendMouseEvent: 19195552 HandMorph>handleEvent: 19195292 HandMorph>processEvents 19195384 [] in WorldState>doOneCycleNowFor: 19195200 SequenceableCollection>do: 19195108 WorldState>handsDo: 19195016 WorldState>doOneCycleNowFor: 19194924 WorldState>doOneCycleFor: 19194832 PasteUpMorph>doOneCycle 18965928 [] in >spawnNewProcess 18966020 [] in BlockContext>newProcess Cheers, Gwenael Casaccio -- GtkLauncher for GNU Smalltalk : http://gtklauncher.bioskop.fr/

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev May 2009