Vm-dev August 2011

vm-dev@lists.squeakfoundation.org

40 participants
111 discussions

Small finding about NewObjectMemory>>clone:
by Dimitry Golubovsky 16 Aug '11

16 Aug '11

Hi, I have just spotted that the method NewObjectMemory>>clone as found in VMMaker-oscog-IgorStasenko.116.mcz (with hyphen): clone: oop "Return a shallow copy of the given object. May cause GC" "Assume: Oop is a real object, not a small integer. Override to assert it's not a married context" self assert: ((coInterpreter isContext: oop) not or: [(coInterpreter isMarriedOrWidowedContext: oop) not]). ^super clone: oop causes compilation error in the interpreter. It seems that it has been fixed in VMMaker.oscog-eem.116.mcz (with dot) clone: obj "Return a shallow copy of the given object. May cause GC" "Assume: Oop is a real object, not a small integer. Override to assert it's not a married context" self assert: ((coInterpreter isContext: obj) not or: [(coInterpreter isMarriedOrWidowedContext: obj) not]). ^super clone: obj basically s/oop/obj/g - I had to make similar change in my local copy of VMMaker. So, Igor: please merge this into the CMMaker-oscog branch. Thanks. PS Is this some kind of inliner bug? When super method is inlined, argument identifier remains the same instead of being substituted. -- Dimitry Golubovsky Anywhere on the Web

3 2

what is FoxReceiver ?
by Jean Baptiste Arnaud 16 Aug '11

16 Aug '11

What is the FoxReceiver in StackInterpreter. Regard Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

2 1

VM Maker: CMakeVMMaker-LaurentLaffont.135.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 16 Aug '11

16 Aug '11

Mariano Martínez Peck uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-LaurentLaffont.135.mcz ==================== Summary ==================== Name: CMakeVMMaker-LaurentLaffont.135 Author: LaurentLaffont Time: 15 August 2011, 3:32:15 pm UUID: bea4ade1-62c7-420f-b9e3-ba02eaec0b0f Ancestors: CMakeVMMaker-IgorStasenko.134 Add CogOnDebian64Config - used to build 32 bit Cog on Debian 64 bits.

1 0

VM Maker: CMakeVMMaker-IgorStasenko.134.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 15 Aug '11

15 Aug '11

Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-IgorStasenko.134.mcz ==================== Summary ==================== Name: CMakeVMMaker-IgorStasenko.134 Author: IgorStasenko Time: 15 August 2011, 10:37:46 am UUID: d22597cb-7172-dc4a-aec1-a5119a8eae1f Ancestors: CMakeVMMaker-IgorStasenko.133, CMakeVMMaker-IgorStasenko.131 - added -m32 linker flags for driver(s) - merge with .131

1 0

[Cog] New builds available on Jenkins server
by Igor Stasenko 12 Aug '11

12 Aug '11

Hello, during last couple of weeks i was busy migrating migrating VM jobs from Hudson server to more up to date Jenkins server and creating a jobs for running tests on newly built VMs. The new location for built VMs are https://ci.lille.inria.fr/pharo/view/Cog/ I disabled the old jobs on Hudson server (https://pharo-ic.lille.inria.fr/hudson/view/Cog/) and also put a comment where they moved. So, from now all VMs which are built on Jenkins server will be automatically tested. If you go to jenkins page, you could see that each job , like StackVM-Unix has a parallel job named StackVM-Unix Tests , which runs tests after successful build of corresponding VM. The image which is used to run tests is Pharo 1.4. latest build (can be found on same server - https://ci.lille.inria.fr/pharo/view/Pharo%201.4/job/Pharo%201.4/) So, in this way we have a streamlined continuous integration setup, which tests every possible combination(s) of VMs and latest Pharo image, so we can easily track regressions as well as different behavior between platforms (ideally, there should be none ;)) Details about new builds: - it is a merge with VMMaker.oscog-eem.115 which contains an important fix for #become: primitive With this fix, i could say that Cog VMs are much stable! Problems, not yet solved: Windows: - there is no windows jobs yet, because we're still having problems with windows slave (it is inaccessible right now), but once it will work, i will add jobs for windows as well. Mac Cocoa builds: - i migrated the cocoa builds to jenkins server as well, but it is not yet using an updated verison of sources (we have to wait till Esteban will sync sources) - also those VMs cannot run tests because command-line interface for them is severely broken now :( -- Best regards, Igor Stasenko AKA sig.

2 2

Explicitly avoiding process switch
by Mariano Martinez Peck 12 Aug '11

12 Aug '11

Hi guys. We were discussing yesterday with Marcus about the following.... I remember a problem we have in Pharo because of changing "foo == nil" to "foo isNil" in some important places like Process/Delay/Semaphore. Such change introduces a suspension point, where if I understand correctly, the scheduler can switch to another process only during method sends. #== is optimized with a special bytecode and there is no message send. Sending #isNil is a message sent, and hence we introduce a suspension point. In 99% of the cases this is not a problem. But I can imagine that there are places (mostly those related to Process/Delay/Semaphore) where this changes can be very very bad. To do some experiments, I want to remove the bytecode for #== but of course, I think I will have all these problems. And there are more. Marcus told me that some optimizations done by the compiler end up sending #==. And I also remember some code he told me (I think it was #allObjectsDo:) that would never finish because of the block closure objects creation. So...what about making the necessity of NOT sending a message or NOT introducing a suspension point more explicit? first we should have the support for that and second know each place where we need them. The most basic thing I can think of is doing something like: (ParseNode classVarNamed: 'StdSelectors') at: #== put: #bytecodedEqualEqual. Compiler recompileAll. And put a nice comment why one may want to use #optimizedEqualEqual. But again, in which places should I change #== for #bytecodedEqualEqual Any thought or idea about them is really appreciated. Thanks -- Mariano http://marianopeck.wordpress.com

7 10

Cog VMMaker.oscog-eem.114/r2485
by Eliot Miranda 11 Aug '11

11 Aug '11

Hi All, please find new VMs in http://www.mirandabanda.org/files/Cog/VM/VM.r2485/. These fix a couple of long-standing bugs. One is a rare crash in GC on copying a compiled method, caused by the VM not making sure that a copy of a method that has been compiled to machine code is an independent copy. The other is a potential bug in GC with become where a become causes some machine code methods to gain references to young objects but the VM forgets to include these methods in the young referrers (those machine code methods that refer to young objects). -- best, Eliot

4 7

OSX Smalltalk vmFullPath
by Camillo Bruni 11 Aug '11

11 Aug '11

I guess this has been mentioned before… But to me the current implementation under OSX makes no sense whatsoever, since you basically get only half of the needed information back (ie. I don't know which executable is running the image) Smalltalk vmFullPath yields '/Applications' so what about getting at least the '.app' dir? (most of the information can be reconstructed from there on) This would simply require to change setVMPathFromApplicationDirectory: - self.vmPathStringURL = [NSURL fileURLWithPath: [[[NSBundle mainBundle] bundlePath] stringByDeletingLastPathComponent]]; + self.vmPathStringURL = [NSURL fileURLWithPath: [[NSBundle mainBundle] bundlePath]]; camillo

4 3

Re: [Pharo-project] Troubles with #flushCache and #run:with:in:
by Mariano Martinez Peck 11 Aug '11

11 Aug '11

Maybe cc'ing VM mailing list can help. On Fri, Jul 1, 2011 at 9:32 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > Hi Eliot, > > I am using one of the latest VMs from your site (VM.r2434) and I > continue to have subtle problems with objects as methods (#flushCache, > #run:with:in:). > > The issue is that the test coverage in Pharo is kind of broken on Cog > for a long time already. It reports methods as not covered that are > clearly covered, and tests seem to randomly fail. > > I suspected that there is something wrong with the coverage code > itself. So I started to experiment with TestCoverage>>flushCache and > noticed that the current implementation > > TestCoverage>>flushCache > self reference methodSymbol flushCache > > performs not that well: The set of not covered methods is wrong and > many tests suddenly fail. If I replace it with > > TestCoverage>>flushCache > self reference actualClass flushCache > > I actually get accurate coverage information, but there are still a > few tests constantly failing. I tried to use all possible combinations > of #flushCache (also calling it on the compiled method), but only > flushing the cache on the class seems to work properly. So far so > good, but I really wonder what the correct way is to flush the cache? > :-) > > For my experiments I was using the package 'AST-Tests-Semantics'. This > is a small package with lots of test methods that cover each method > but one (RBSemanticAnnotationMisssing>>#isResumable). Now the "real" > problem is that when running these tests in coverage mode, the same 4 > tests always fail: > > RBSemanticTest>>testBlockScope > RBSemanticTest>>testCascadeReceiver > RBSemanticTest>>testClassVariableBinding > RBSemanticTest>>testGlobalVariableBinding > > Not sure of how to debug that? Do you have an idea why these otherwise > passing tests suddenly fail? If you want to try to reproduce you can > use any Pharo image with the tests loaded, or use those that I used: > > > http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifac… > > http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifac… > > Open the Test Runner, select 'AST-Tests-Semantics' and 'Run Coverage'. > > Any help or clarification would be appreciated :-) > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > -- Mariano http://marianopeck.wordpress.com

3 6

VM Maker: CMakeVMMaker-IgorStasenko.131.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 10 Aug '11

10 Aug '11

Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-IgorStasenko.131.mcz ==================== Summary ==================== Name: CMakeVMMaker-IgorStasenko.131 Author: IgorStasenko Time: 10 August 2011, 2:36:06 am UUID: 36da6b08-579c-054b-b299-a800479dadc1 Ancestors: CMakeVMMaker-EstebanLorenzano.128 - fixed Windows configs to not generate debug info for release builds

1 0

← Newer
1
...
6
7
8
9
10
11
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev August 2011