Vm-dev February 2011

vm-dev@lists.squeakfoundation.org

25 participants
79 discussions

source version info
by Eliot Miranda 06 Feb '11

06 Feb '11

Hi All, in building up to the VM releases for 4.2 I would like to add meaningful source info to all VMs in a consistent way. The main rationale here is to know exactly what source a VM was built from so that there's a chance of recreating it, hence to be able to use gdb-style debugging tools against source, and reduced chance of putting out different VMs that answer the same version info. There are two elements to the source info. One is the VMMaker package. This is in the Cog VMs in getSystemAttribute: 1007 (Interpreter class) and getSystemAttribute: 1008 (Cogit class, if any). But there's no similar specific info for the ensure VM source (platform tree, and hopefully generated source aincluded in it). Rather than just provide a revision in whatever version control system we're using I'd like us to use a url and a version identifier, e.g. " http://www.squeakvm.org/svn/squeak/branches/Cog 2359". This could be getSystemAttribute: 1009 but that would probably break code that enumerates attributes until it gets an empty one since the StackInterpreter and Interpreter don;t have a Cogit class. So, if there's agreement on including the url/version I would make that 1007 and move the Interpreter class and Cogit class to 1008 and 1009 respectively. Since various version control systems don't necessarily provide a convenient way to derive the version info I suggest we modify the build system to include a file that is not included in the source tree that nas to be manually edited to contain the relevant string. We can then provide helpful info close to the error location (when one tries to compile the file when its missing) that explain how to fill in the file. (better ideas?) Also, the three platforms define their version info SQ_VERSION and VM_VERSION in different places and using different mechanisms, which makes it hard to keep things consistent. I'd like to see these defined in platforms/Cross/vm/ something (platforms/Cross/vm/sqVersion.h ? platforms/Cross/vm/sq.h?). SQ_VERSION appears to be unused so I'm nuking it from the Cog sources. Does this make sense? best Eliot

2 1

VM Maker: Cog-eem.44.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 06 Feb '11

06 Feb '11

Eliot Miranda uploaded a new version of Cog to project VM Maker: http://www.squeaksource.com/VMMaker/Cog-eem.44.mcz ==================== Summary ==================== Name: Cog-eem.44 Author: eem Time: 8 January 2011, 2:32:43 am UUID: f3c6694c-7678-4fd9-98f3-8f406565043e Ancestors: Cog-eem.43 Support for multi-processors instead of the dreadful old hack. Provide a read/execute write-protect code zone. Refactor disassembly decoration. Use unsignedLongAt: to get retpcs etc. Don't print the fp regs if they're empty. Support for smashing caller-saved registers. ShootoutTests take stdio from StandardFileStream not OSProcess.

1 0

VM Maker: VMMaker-oscog.47.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 06 Feb '11

06 Feb '11

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-oscog.47.mcz ==================== Summary ==================== Name: VMMaker-oscog.47 Author: eem Time: 6 February 2011, 9:43:10 am UUID: a4053f20-cb87-415d-aad3-3bb29b03724c Ancestors: VMMaker-eem.718, VMMaker-oscog.46 Move the genExternalizePointersForPrimitiveCall and genLoadCStackPointersForPrimCall to the front of compileInterpreterPrimitive so that a) reg args are pushed before any calls, and b) ceCheckProfileTick is run on the C stack. The first fixes the StackToRegisterBasedCogit's crash when profiling. The second is safer than running it on a Smalltalk stack page. Fix simulation of the profling machinery (to debug the above). Fix mapping for backward branches which must of course map to themselves, otherwise the VM can break out of loops prematurely. Bring StackInterpreter generation up to date (less labelling, vmCallback). zero instuctions on recompiling block after numInitialNils mis-estimation. More methods for the in-image facade for compiling quick prims. Both Cogits Fix pc mapping once and for all. Tests allow compiling all methods in current image and testing all mapped bcpcs and mcpcs map and map ack correctly. Fix bad bug with jump fixups that caused some fixups to be missed (error in the index used to define the range of valid fixup adresses). StackToRegisterMappingCogit Fix bug in addBlockStartAt:numArgs:numCopied:span: that caused one block entry to be omitted when some block was recompiled due to initialNil misestimation. As part of pc mapping fixing add an annotateUse flag to sim stack entries so that the eliminated send in a folded constant still gets a pc map entry. CoInterpreter Fix bug in checkLogIntegrity for an empty log. Safety in activation printing (for backtraces etc). SImulator Run quitBlock on closing simulator window. StackToRegisterMappingCogit: Fix bug in repeated block compilation for initial nil handling. Repeated attempts to insert the same block start are filtered out instead of repeating all block inserts (which doesn't work). Fix bad bug in frameless block entry. Don't use initSimStackForFramelessMethod:! Add a target fixup for a conditional jump even if it is a jump on true or false since the simStack must still be valid for merges. Nuke as-yet-unused merge state in CogSSBytecodeFixup. Add a subclass using image facilities to compute numnitialNils correctly to compare against repeated block compilation. CoInterpreter: comment an apparently unsent method to stop me from deleting it. Fix StackToRegisterMappingCogit being confused by initial pushNils in blocks that provide parameters rather than initialize temps by tracking stack depth and recompiling if the depth is wrong at the end of the block. Do this by refactoring compileMethodBody into compileEntireMethod et al. Fix atCache leakage for super sends in machine code by assigning to lkupClass (since commonAt:[put:] use lkupClass to filter-out super sends). Simulator fixes and tidyups.

1 0

VM Maker: CMakeVMMaker-EstebanLorenzano.21.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 06 Feb '11

06 Feb '11

Esteban Lorenzano uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-EstebanLorenzano.21.mcz ==================== Summary ==================== Name: CMakeVMMaker-EstebanLorenzano.21 Author: EstebanLorenzano Time: 6 February 2011, 9:27:54 am UUID: ed713a01-6616-47d9-8db2-85c09b30f06e Ancestors: CMakeVMMaker-EstebanLorenzano.20 generateCocoaVM now alse generates external plugins. UnixOSProcessPlugin is first client :)

2 1

VM Maker: CMakeVMMaker-EstebanLorenzano.20.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 06 Feb '11

06 Feb '11

Esteban Lorenzano uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-EstebanLorenzano.20.mcz ==================== Summary ==================== Name: CMakeVMMaker-EstebanLorenzano.20 Author: EstebanLorenzano Time: 5 February 2011, 8:21:03 am UUID: ed532c15-e14a-4929-bdcc-7228551eaa0b Ancestors: CMakeVMMaker-IgorStasenko.Stasenko.19 Cocoa Stack VM configuration working

1 0

CMake configuration for Stack VM ready (not performant)
by Esteban Lorenzano 06 Feb '11

06 Feb '11

Hi, I commited a version of CMake generator who can generate a configuration for Cocoa Cog StackVM. As other generates, it works but the resulting executable is still presenting performance issues. Any help there is welcome :) as usual, the sources for this work are on http://gitorious.org/~estebanlm/cogvm/cogvm next steps: merge with blessed clone. And that way it can be integrated in trunk soon :) Cheers, Esteban

1 0

sqMouseEvent.reserved1?
by Esteban Lorenzano 06 Feb '11

06 Feb '11

Hi, I'm trying to compile a Cocoa Stack VM and I found that at some points it asks for a sqMouseEvent.reserved1, which is not defined at sq.h. I just added it to sq.h and everything seems to be working, but I wonder if there is a reason why it is not there? Cheers, Esteban

2 4

different vmFullPath between MacVM
by Luc Fabresse 05 Feb '11

05 Feb '11

Hi All, SmalltalkImage current vmFullPath evaluates to: '/Applications/SmalltalkVMs' with the MacVM 5.7.4 (the directory that contains the .app vm application) '/Applications/SmalltalkVMs/Squeak-4.2.5beta1U.app/Contents/MacOS/Squeak VM Opt' with the MacVM 4.2.5b1 (the exec file) Is this difference known? I found nothing on the mailing lists. Is it a bug? it is to know we should adapt Coral or not. Cheers, #Luc

1 0

windows crash
by Esteban Lorenzano 04 Feb '11

04 Feb '11

Hi, One customer of mine is having a recurrent crash, using Seaside One-Click 3.0.3 (which has a oscog.35 inside). I don't understand why, he is having an out-of-memory like two or three times a day. I think it shouldn't happen as it's image is about 40M. Anyway, he is running on a Windows Vista 64bits and this is a dump for the crash. Any idea how can I do for prevent the error? Thanks, Esteban

2 1

MiscPrimitivePlugin, translated primitives and ByteString method(s)
by Igor Stasenko 04 Feb '11

04 Feb '11

The aim of this change is to help fixing the ByteString>>findSubstring:in:startingAt:matchTable: issue by moving the selector names , which should be translated from MiscPrimitivePlugin class to the corresponding classes, so they could choose which selectors to include. The problem, that Pharo having the fix for findSubstring:in:startingAt:matchTable: bug but this method can't be used for translation anymore because it is moved to another one: findSubstringViaPrimitive:in:startingAt:matchTable: , while original one dispatching to it, after testing that there is no widestrings. And so, VMMaker can't work on pharo without error, so either a patch should be applied to VMMaker to change selector from #findSubstring:in:startingAt:matchTable: to #findSubstringViaPrimitive:in:startingAt:matchTable: in MiscPrimitivePlugin , which sucks, because then VMMaker package become dirty and it is seen in builds and gets into every source file.. , or if we apply this changeset to our images, then Pharo could answer different selector, without need patching anything. And for future, this pattern could be extended, to seek for all #translatedPrimitiveSelectors implementors in system, not just in 3 classes. But that gets us back to discussion about separating responsibilities... so.. lets try to fix what we have instead. http://lists.squeakfoundation.org/pipermail/vm-dev/2009-November/003364.html -- Best regards, Igor Stasenko AKA sig.

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev February 2011