- Pharo-dev - lists.pharo.org

Re: [Pharo-project] question on traits

by Alexandre Bergel

> In 102077, btw, this test seems green. (But > strangely, #testFileOutCategory fails now.) Exact, but it failed in a 10259. > The former. LocatedMethod a simple (internal) class that encapsulates > a method and the behavior in which the method is implemented. > Nowadays, we could probably even avoid this since methods know the > behavior they are implemented in (this was not the case before). Ok. It is clearer now. > Looks good. Both traits tr2 and tr3 provide a method #foo. At the time > when LocatedMethod instances are created, no conflicts are resolved > (or methods merged) yet. The interesting logic is in > TraitMethodDescription (see class comment). If you are at fixing the > conflict of methods from the same origin, I think the right place is > TraitMethodDescription>>providedLocatedMethod. This method fails > (returns nil) if it finds more than one provided method. It should not > fail, though, if those methods have the same #origin. I extended few methods: TraitMethodDescription>>providedLocatedMethod | locatedMethod aLocatedMethod refOrigin | locatedMethod := nil. self locatedMethods ifEmpty: [ ^ nil]. self locatedMethods size > 1 ifTrue: [ aLocatedMethod := self locatedMethods anyOne. refOrigin := (aLocatedMethod location >> aLocatedMethod selector) origin. (self locatedMethods allSatisfy: [:each | each method origin == refOrigin]) ifTrue: [ ^ aLocatedMethod ]]. self locatedMethods do: [:each | each method isProvided ifTrue: [ locatedMethod isNil ifFalse: [^nil]. locatedMethod := each]]. ^locatedMethod TraitMethodDescription>>isConflict | count originMethodReferenciel | count := 0. self locatedMethods size > 1 ifTrue: ["If they are more than 1 located method, then check whether these methods have the same origin" originMethodReferenciel := self locatedMethods anyOne method origin. ((self locatedMethods collect: [:lm | lm method]) allSatisfy: [:each | each method origin == originMethodReferenciel]) ifTrue: [ ^ false ]]. self methodsDo: [:each | each isProvided ifTrue: [ count := count + 1. count > 1 ifTrue: [^true]]]. ^false In providedLocatedMethod, I am not sure about the "^ aLocatedMethod". This does not seem to be a big deal, since the result is checked for nullity only. These two enhanced methods makes testOrigin green. testOrigin is a new test that create a diamond made of 4 traits. The code is available in Traits@SqueakSource. Does this code looks okay? If yes, then I will put it in PharoInbox. Sorry for the long code excerpts. Cheers, Alexandre > > >> >> >> Cheers, >> Alexandre >> >> >> On 10 Apr 2009, at 14:32, Adrian Lienhard wrote: >> >>> Yes, this should not be a conflict. I think I had implemented it >>> that >>> way. Probably it was broken in the recent refactoring that I did for >>> method sharing... >>> >>> Adrian >>> >>> On Apr 10, 2009, at 13:47 , Alexandre Bergel wrote: >>> >>>> Hi All, >>>> >>>> Apparently, the way a conflict may be triggered is slightly >>>> different >>>> from what is described in the toplas paper. >>>> in the paper, it is said that a compiled method that is inherited >>>> from >>>> more than one path does not trigger a conflict. With the current >>>> implementation this trigger a conflict. >>>> >>>> For example: >>>> T1 defines foo >>>> T2 uses T1 >>>> T3 uses T1 >>>> T23 uses T2 + T3 >>>> C uses T23 >>>> >>>> C new foo => conflict error. >>>> >>>> One would expect no conflict since there is only one definition of >>>> foo >>>> Just wondering... >>>> >>>> Alexandre >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 14, 2009

Re: [Pharo-project] Problem with BlockClosure>>decompile

by StÃ©phane Ducasse

thanks nicolas I was just doing a release so I will harvest that now. Stef On Apr 14, 2009, at 6:31 PM, Nicolas Cellier wrote: > Issue http://code.google.com/p/pharo/issues/detail?id=738 > and PharoInbox/Compiler-nice.96 > > Cheers > > 2009/4/14 Dennis Schetinin <chaetal(a)gmail.com>: >>> This is because #who was deprecated in squeak 3.9 and removed in >>> pharo... >>> ... but the closure work by Eliot is based on a 3.8 image... >>> >>> Solution is simple: replace: >>> (homeClass := home who first) == #unknown ifTrue: [^ nil]. >>> with: >>> (homeClass := home methodClass) ifNil: [^ nil]. >> >> Thank you very much! >> >> -- >> Dennis Schetinin >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 14, 2009

Re: [Pharo-project] question on traits

by Adrian Lienhard

Hi Alex, On Apr 14, 2009, at 15:14 , Alexandre Bergel wrote: > Hi Adrian and all traits friends, > > The test TraitTest>>testLocalMethodWithSameCodeInTrait is yellow. I > guess this is because there is no sharing of compiled methods. This > test is therefore not irrelevant right? Can be safely removed? No. This test finds methods that are implemented in a class (or trait) that are equal to a method that could be obtained from a trait. This can happen if you accidentally recompile a method in a class instead of in the trait. In 102077, btw, this test seems green. (But strangely, #testFileOutCategory fails now.) > Something slightly more technical. What providedLocatedMethod should > return? What a LocatedMethod should refer to? A location of a method > in a trait, or where the method is defined for the first time? The former. LocatedMethod a simple (internal) class that encapsulates a method and the behavior in which the method is implemented. Nowadays, we could probably even avoid this since methods know the behavior they are implemented in (this was not the case before). > An example. Let's assume I have: > > tr1 := self createTraitNamed: #T1 uses: {}. > tr2 := self createTraitNamed: #T2 uses: {tr1}. > tr3 := self createTraitNamed: #T3 uses: {tr1}. > tr23 := self createTraitNamed: #T23 uses: {tr3 + tr2}. > tr1 compile: 'foo ^ 4'. > > aMethodDescription := tr23 traitComposition > methodDescriptionForSelector: #foo. > self assert: (aMethodDescription locatedMethods size = 2). > self assert: (aMethodDescription locatedMethods > includes: (LocatedMethod location: tr2 selector: #foo)). > self assert: (aMethodDescription locatedMethods > includes: (LocatedMethod location: tr3 selector: #foo)). > > The last two assertion pass. However, is it that intended? I would > have expected only one locatedMethod, which is (LocatedMethod > location: tr1 selector: #foo), however I am not sure. Looks good. Both traits tr2 and tr3 provide a method #foo. At the time when LocatedMethod instances are created, no conflicts are resolved (or methods merged) yet. The interesting logic is in TraitMethodDescription (see class comment). If you are at fixing the conflict of methods from the same origin, I think the right place is TraitMethodDescription>>providedLocatedMethod. This method fails (returns nil) if it finds more than one provided method. It should not fail, though, if those methods have the same #origin. > locatedMethods is tested nowhere and there is no documentation. Well, it has a class comment and there are unit tests in the class LocatedMethodTest. (According to the test runner's "Run Coverage", the class even is completely covered.) HTH, Adrian > > > Cheers, > Alexandre > > > On 10 Apr 2009, at 14:32, Adrian Lienhard wrote: > >> Yes, this should not be a conflict. I think I had implemented it that >> way. Probably it was broken in the recent refactoring that I did for >> method sharing... >> >> Adrian >> >> On Apr 10, 2009, at 13:47 , Alexandre Bergel wrote: >> >>> Hi All, >>> >>> Apparently, the way a conflict may be triggered is slightly >>> different >>> from what is described in the toplas paper. >>> in the paper, it is said that a compiled method that is inherited >>> from >>> more than one path does not trigger a conflict. With the current >>> implementation this trigger a conflict. >>> >>> For example: >>> T1 defines foo >>> T2 uses T1 >>> T3 uses T1 >>> T23 uses T2 + T3 >>> C uses T23 >>> >>> C new foo => conflict error. >>> >>> One would expect no conflict since there is only one definition of >>> foo >>> Just wondering... >>> >>> Alexandre >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 14, 2009

Re: [Pharo-project] Universe browser on Damien's dev image

by Ramiro Diaz Trepat

Thanks for your replies.I did install it and it works like a charm. Cheers r. On Tue, Apr 14, 2009 at 3:00 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > 2009/4/14 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > There is something I don't understand. Which is the diference between: > > > > ScriptLoader new installingXXX (example: ScriptLoader new > > installingUniverse) > > > > and > > > > ScriptLoader loadXXX (example: ScriptLoader loadFFI)) > > > > > > If it is the same, shouldn't we decide only one way to to this ? > > I agree this is the same and should be cleaned. However, the > ScriptLoader is for the core developers only, not for end-users. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 14, 2009

Re: [Pharo-project] [Vm-dev] hampering the desire of the VM and image to visit every object at startup time (multiple times)

by John M McIntosh

Well a PermSpace would be helpful since it would then avoid a GC which causes the header bits to change making all pages as written, and if the pages are written then the virtual memory system can't free the page under stress. However the real benefit here was that I actually never touch 6MB of objects, so they are never moved from Flash into dynamic RAM. So I do not need to find 1,600 pages of ram to hold pages which the application doesn't need. If I did an allInstances it would transverse PermSpace and bring all those 1600 pages into RAM, really want to avoid that. For example if the iPhone receives a phone call, it starts up a daemon to display a dialog asking if you want to answer or ignore, memory for that has to come from somewhere, or a double-click of the home key can bring up the iPod dialog prompt if the iPod audio app is running, again pages have to come from somewhere. With 700K of old objects, and about 5MB for young space it means the 4.5MB of image objects that is faulted in but not written, can be freed since a page fault will re-read them from the image file. On 14-Apr-09, at 11:02 AM, Nicolas Cellier wrote: > 2009/4/14 John M McIntosh <johnmci(a)smalltalkconsulting.com>: >> Yes, so WikiServer ( http://www.mobilewikiserver.com ) is an image >> file of 10.5 MB. >> >> As startup only 4.5 MB of OOPS memory is faulted in, and about 700K >> of >> memory is altered, which reduces initial memory use by 6MB and >> reduces >> the startup time by 3+ seconds. >> Given the slow speed of the iPhone, and the fact I've a 64MB limit, >> 6MB is a lot, and 3 seconds is welcome. Unfortunately a full GC will >> fault all that 10.5 MB in, however by doing some GC tuning one >> can avoid a full GC until things are quite stressed. >> > > Wouldn't a VW-like PermSpace reduce the burden? > > Nicolas -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

April 14, 2009

Re: [Pharo-project] [Vm-dev] hampering the desire of the VM and image to visit every object at startup time (multiple times)

by Nicolas Cellier

2009/4/14 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > Yes, so WikiServer Â ( http://www.mobilewikiserver.com ) is an image > file of 10.5 MB. > > As startup only 4.5 MB of OOPS memory is faulted in, and about 700K of > memory is altered, which reduces initial memory use by 6MB and reduces > the startup time by 3+ seconds. > Given the slow speed of the iPhone, and the fact I've a 64MB limit, > 6MB is a lot, and 3 seconds is welcome. Unfortunately a full GC will > fault all that 10.5 MB in, however by doing some GC tuning one > can avoid a full GC until things are quite stressed. > Wouldn't a VW-like PermSpace reduce the burden? Nicolas

April 14, 2009

Re: [Pharo-project] *overrides* in polymorph

by Gary Chambers

Will try to have a look tomorrow (the override does have the problem). Still waiting for a list of problematic overrides from the group... The infrastructure is in place to make some "Squeak only". This one can apply to both Squeak and Pharo though. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, April 13, 2009 2:39 PM Subject: [Pharo-project] *overrides* in polymorph > Hi gary > > It seems that I already fixed > SystemProgressMorph>>label:min:max: > so that the bloack argument is not written. > Can you check because if I redo it and it gets overridden I will have > the smae problem. > > stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 14, 2009

Re: [Pharo-project] [Vm-dev] hampering the desire of the VM and image to visit every object at startup time (multiple times)

by John M McIntosh

Yes, so WikiServer ( http://www.mobilewikiserver.com ) is an image file of 10.5 MB. As startup only 4.5 MB of OOPS memory is faulted in, and about 700K of memory is altered, which reduces initial memory use by 6MB and reduces the startup time by 3+ seconds. Given the slow speed of the iPhone, and the fact I've a 64MB limit, 6MB is a lot, and 3 seconds is welcome. Unfortunately a full GC will fault all that 10.5 MB in, however by doing some GC tuning one can avoid a full GC until things are quite stressed. I note on os-x desktop machines the entire 10.5MB is read in and the pages marked as non-referenced, but obviously the rules for the virtual memory subsystem are different. First let me suggest we change writeImageFileIO /* header size in bytes; do not change! */ headerSize = 64; f = sqImageFileOpen(imageName, "wb"); from 64 bytes to 4096 bytes, if possible. Now let's explore why, and what is going on. on unix if you decide to use mmap versus malloc to allocate storage for oops space it does #define MAP_PROT (PROT_READ | PROT_WRITE) #define MAP_FLAGS (MAP_ANON | MAP_PRIVATE) mmap(0, heapLimit, MAP_PROT, MAP_FLAGS, devZero, 0) where heapLimit is usually 1GB, start location zero. This returns a start location somewhere in memory, never zero, and generally we have to swizzle all the object pointer. On a save and restart of the squeak app the address you get back *maybe* the same address, if it is the same we don't need to swizzle pointers, however OpenBSD based systems likely will always give a different location for security reasons. I had then set a start location of 128MB, but found on os-x as the number of apps goes up you don't get 128MB, so I settled on 500MB which seems ok. 8GB pro macs running 52 applications fail at 500MB, but the failure is it chooses it's own address, so we don't care... Well yes that limits your squeak image to 3.5GB but it's doubtful that a 32bit system will let you allocate a contiguous chunk of memory > 2 GB anyway. Now the next issue was the original memory allocation logic would give you the 1GB, and you would read the entire image into that memory area. In thinking about this I thought why can't you mmap to the image file for the size of the file rounded up to the page size, then mmap after that memory to anonymous memory upto the desired heapsize. So two mmaps, one for the file, followed by another for young space. I implemented this for the os-x vm and the iPhone VM. In testing with a 500 Mhz powerpc laptop, I found the startup time was reduced by 30% because it would fault in say a 20MB page by page as it did the needless flush primitive calls logic, versus reading the 20mb into memory, the virtual memory pager was just more efficient at pullling in the data either by better I/O processing, or faster logic in finding the free pages. Problems: It turns out there is a flaw in the OS-X BSD mmap logic when you mmap files on NFS drives, it hangs, and some people with I think overstressed systems reported issues with the first mmap failing. Because of this I reverted back to the old logic by default, and put a flag in the info.plist SqueakUseFileMappedMMAP to enable the new logic. Obviously for Linux you have to decide if this flaw exists and has not been fixed? Now the problem with headerSize In the file mmap case the entire file is mapped into memory at 500MB, but the oops space starts at 64 bytes, so memory is at 500MB+64 In the anonymous mmap case memory starts at 500MB, but the oops space starts at 0, so memory is at 500MB. If the headersize was 4096 we could mmap the file at 500MB-4096, Or alter the anonymous case we could allocate at 500MB but stick the oops space at 500MB +64 (header size). However by using a headerSize of 4096 we can then get the oops space to start on a page boundary, which may or may not have implications. Anyway it would be good to resolve this bit of tricky logic. I stuck the following code into ioRelinquishProcessorForMicroseconds() since ioRelinquishProcessorForMicroseconds will only get triggered once the image finishes all it's startup logic and becomes *idle*. So that I could determine how each page was viewed by the virtual memory subsystem. xtern unsigned char *memory; extern usqInt sqGetAvailableMemory(); extern size_t fileRoundedUpToPageSize; size_t pageSize= getpagesize(); size_t vmpagesize=sqGetAvailableMemory()/pageSize + 1; char *what = malloc(vmpagesize); int err = mincore(memory, sqGetAvailableMemory(), what); int countRef=0, countMod=0,countZero=0, countOne=0, i; for (i=0;i<fileRoundedUpToPageSize/pageSize;i++) { if(what[i] == 0) countZero++; if(what[i] == 1) countOne++; if(what[i] == 3) countRef++; if(what[i] == 7) countMod++; {break for debugging here} } free(what); On 14-Apr-09, at 1:58 AM, Bert Freudenberg wrote: > > On 14.04.2009, at 07:26, John M McIntosh wrote: > >> I created a pharo entry to track the problem the VM & image has in >> wanting to visit every smalltalk object multiple times at startup >> time. >> Athought this behavior is masked by Gigaherz processors, it's very >> evident as a problem on the iPhone. Fixing it results in reducing >> MB of RAM memory usage and saves actual "seconds* of clock time at >> startup. >> >> http://code.google.com/p/pharo/issues/detail?id=737&colspec=ID%20Type%20Sta… > > Very nice. We experimented in that direction for OLPC which also is > comparatively slow CPU wise, and even slower loading the whole image > from the flash disk (which involves decompressing). Mmapping only > the pages needed should give a considerable boost. > > Do we have evidence that an mmap base address of 500 MB works across > platforms? > > - Bert - > -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

April 14, 2009

[Pharo-project] MessageTally is not reentrant: I cannot RunProfiled some tests

by Nicolas Cellier

Some Debugger tests will open a Debugger... This will open/close a MessageTally... This will nil out some MessageTally class vars... This will prevent me to run some tests with profiler (Run Profiled button). This is http://code.google.com/p/pharo/issues/detail?id=739 Workaround in PharoInbox/System-Tools-nice.4 Nicolas

April 14, 2009

Re: [Pharo-project] Problem with BlockClosure>>decompile

by Nicolas Cellier

Issue http://code.google.com/p/pharo/issues/detail?id=738 and PharoInbox/Compiler-nice.96 Cheers 2009/4/14 Dennis Schetinin <chaetal(a)gmail.com>: >> This is because #who was deprecated in squeak 3.9 and removed in pharo... >> ... but the closure work by Eliot is based on a 3.8 image... >> >> Solution is simple: replace: >> Â Â (homeClass := home who first) == #unknown ifTrue: [^ nil]. >> with: >> Â Â (homeClass := home methodClass) ifNil: [^ nil]. > > Thank you very much! > > -- > Dennis Schetinin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 14, 2009