November 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Ideas for CompiledMethod proxies?

by Mariano Martinez Peck

> A proxy actually should hold only some unique value (id), or as Eliot > suggested be a unique by itself. > This is enough to find a correspondence between any proxy and its > original method. > Yes....but I was wondering if there was a way to use the same proxy instance for everybody and using some conventions, guess which was the original compiled method. Now that that seems not possible, I can use any of these possibilities: id, identity, store class pointer, store a 4bytes array, store the filename directly, etc.... > You can simply delegate loading the method to some object, which > 'knows' how to load a method and where it is stored: > > " id based lookup: " > Proxy>>literals > | method | > method := MethodsProxyManager methodFor: id. > ^ method literals > > "or identity based lookup: " > > Proxy>>literals > | method | > method := MethodsProxyManager methodFor: self. > ^ method literals > > > Thanks > > > > Mariano > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Nov. 20, 2010

Re: [Pharo-project] Ideas for CompiledMethod proxies?

by Mariano Martinez Peck

On Fri, Nov 19, 2010 at 11:03 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi Mariano, > > it strikes me that the class and selector are implicit in method > dictionaries. So if you use a zero-sized object to replace a method (one > word in memory if you make it an instance of a compact class) you can find > its class and selector by searching all method dictionaries in the class > hierarchy. In an image with approximately 90,000 methods on a 2.66GHz Core > i7 it takes Cog 15 milliseconds on average to locate a method in the > hierarchy: > > | cms | > cms := CompiledMethod allInstances. > cms := (1 to: cms size by: 100) collect: [:i| cms at: i]. > { Time millisecondsToRun: > [cms do: > [:cm| > [:exit| > ProtoObject withAllSubclasses do: > [:c| > c selectorsAndMethodsDo: [:s :m| m == cm ifTrue: [exit value]]]] > valueWithExit]]. > cms size } #(13371 917) > 13371 / 917.0 14.58124318429662 > CompiledMethod instanceCount 91696 > > So one thing might be to use a zero-sized object. > > Of course you could use a one instance variable object whose instance > variable was the class and then things would be /much/ faster, with only one > method dictionary to search. > > Thanks Eliot for the idea. I didn't think about searching the method in the whole hierarchy because I thought it was going to be much slower. And its true, storing a pointer to the class will be fast enought. So...taking into account all the answers I think I should discard the idea of using the SAME proxy instance for everybody and using fileName patterns to guess the file. It seems there is no way. So...if I need an instance per proxy, now let's see how to make this object as small as possible. In the case you told me, the object will be zero sized and if the class is compact, then it would be just one word. But the "search" will take some time.....if I store the class pointer, then it would be 8 bytes per proxy... This is why I liked the Levente solution (I answer after to him). > Or perhaps you could use a 4-byte byte array and keep the identity hash of > the class and the identity hash of the selector in two 16-bit values in the > 4-byte array, but this wouldn't get you anything over and above the one > instance variable object pointing to the class. > Exactly. The only thing here is that since I have both, class and selector, and don't need to do the search in the class method dict. > However, if you are talking abut optimizing a closed world then this does > hold water. One thing you can do if you *really* want to save space is > eliminate symbols, replacing them by integers. The lookup machinery should > be able to deal with a SmallInteger selector, and if it doesn't it has a > bug. This is a space saving technique I first heard about in the ActiveBook > which used my BrouHaHa VM and ParcPlace's Smalltalk-80 v2.3 back in the 80's > to produce an early tablet computer. So the idea is to number classes and > selectors and use the selector numbers to replace symbols. Now the byte > array makes sense because if you have < 64k symbols and < 64k classes you > have the class and the selector directly. > exactly! If you were clever you could put the selector numbering in the compiler and > keep the symbol table externally in a file, mapping selector number to > symbol there-in. Obviously the tricky thing is in eliminating or > implementing asSymbol in perform: usage. > ahhhhh ok, I got the idea :) Thanks Eliot for the help. > Sometimes you see horror show code like > self perform: (self opPrefix, self opSuffix) asSymbol > which makes it /really/ hard to find implementors and senders (and IMO > people who write this kind of thing should be shot, and IIRC there is stuff > like this in the change notification code, ARGH!!!). > > HTH > Eliot > > On Fri, Nov 19, 2010 at 12:47 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Hi. I am developing kind of proxies for unused compiled methods. I want to >> detect them, put a proxy instead of them, and swap them to disk. Then, in >> case they are used, I put back the original ones. With this, I want to >> realease memory. This is why I need the proxy objects to be as small as >> possibles. >> >> Right now, I do something like this: >> >> aProxy := CompiledMethodProxyReferenceStreamWithFileName installOn: >> ClassWith1Var selector: #foo. >> >> this will instantiate the proxy, do the ClassWith1Var methodAt: #foo put: >> proxy, write the original compiledMethod that was in #foo into a file, >> etc.... >> >> and then if I do "ClassWith1Var new foo", then using the #run:with:in I >> load the file from disk and I put back the original method. To know WHICH >> file I have to load, I have to store the fileName in the proxy object. >> >> In addition, if I DON'T execute the compiled method, but instead I send a >> message, for example: >> >> (ClassWith1Var >> #foo) literals >> >> this has to do the same: load and put back the original compiled method. >> To do this, I use the doesNotUnderstand:. >> >> This is easy to do if I store the fileName in the proxy instance. Right >> now, I am using as fileName this: CLASS >> SELECTOR. For example, in this >> case, the file would be named "ClassWith1Var >> #foo" >> >> Now.....with this solution, I need create an proxy instance for each >> compiled method, and these instances have also another instance for the >> filename. If I could use the same proxy instance for everybody, the amount >> of memory released would be muuuuch more. So I thought that maybe from the >> context I can "guess" the filename if I use conventions. >> >> For example, if you do "ClassWith1Var new foo" then in the #run:with:in I >> receive all the information to KNOW that the fileName should be >> "ClassWith1Var >> #foo". So, no problem here. >> >> But for the second case, suppose "(ClassWith1Var >> #foo) literals", I >> don't see a way to know this. In this case, #literals is intercepted by the >> doesNotUnderstand: of my proxy, and here I should load back the original >> compiled method from disk. The problem is that I cannot know in which CLASS >> and SELECTOR this proxy was put. The only way I know to do this, is to store >> the class + selector in the proxy instance....but it is the same...I will >> need an instance per compiled method. In such case is even easier to >> directly store the fileName. >> >> Anyway, if someone has a solution or advice on this, I would be >> appreciated that. I tried with thisContext, but it didn't help me. >> >> Thanks >> >> Mariano >> > >

Nov. 20, 2010

[Pharo-project] Issue 3276 in pharo: DNU finalizer beNull with TT Fonts while cleanUpForRelease

by pharo＠googlecode.com

Status: Accepted Owner: aplantec New issue 3276 by aplantec: DNU finalizer beNull with TT Fonts while cleanUpForRelease http://code.google.com/p/pharo/issues/detail?id=3276 Pharo image: core Pharo core version: #12248 Steps to reproduce: 1. load TT Fonts (from the settings browser, Update fonts from system) 2. choose a TT fonts for all fonts 3. ScriptLoader new cleanUpForRelease PharoDebug attached Attachments: PharoDebug.log 29.5 KB

Nov. 20, 2010

Re: [Pharo-project] Not happy with the issues feed from Google

by Alain Plantec

Le 20/11/2010 11:49, George Herolyants a Ã©crit : > Ok. > > +1 to this list. > -1 to the special "bug tracker" list. it's a dev list so, again +1 to this list. -1 to the special "bug tracker" list. Alain > George > >

Nov. 20, 2010

Re: [Pharo-project] Issue 3266 in pharo: Clean TextEditor

by Alain Plantec

Le 20/11/2010 10:21, StÃ©phane Ducasse a Ã©crit : > We should get in the sophie events hierarchy. no ? It depends of the amount of work it would requires... what about working on SimpleMorphic for that ? Alain > Stef > > > > > >> Cheers >> Alain >> >> >

Nov. 20, 2010

Re: [Pharo-project] Not happy with the issues feed from Google

by Miguel CobÃ¡

El sÃ¡b, 20-11-2010 a las 10:29 +0100, StÃ©phane Ducasse escribiÃ³: > The other mailing-list is created and we can change no time now. > so decide. -1 to new list. +1 to current list > > Stef > On Nov 20, 2010, at 10:04 AM, George Herolyants wrote: > > > Stef, > > > > After some thinking about it I changed my mind. I agree now that the > > initial idea of sending messages from the tracker to this list was not > > so bad. And definitely better than having a separate mailing list for > > it. You say that that's the pharo developers mailing list after all, > > so it's intended for such processes. And I agree with this statement > > also. > > > > The only concern I still have is not splitting a discussion between > > the mailing list and the tracker. I propose that if someone wants to > > answer to the issue, he'd rather do it on the tracker, because this > > way his message will appear on both sides: the tracker and the mailing > > list, which is good. But the other way, if someone answers to the > > issue on the mailing list, it won't appear on the tracker (at least > > until google provides such feature) and this is not good. > > > > So you can strike me now from the list of opponents :) > > > > George > > > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Nov. 20, 2010

[Pharo-project] [update 1.2] #12248

by StÃ©phane Ducasse

12248 ----- - Issue 3274: text finding fixes. Thanks Alain Plantec

Nov. 20, 2010

Re: [Pharo-project] Issue 3274 in pharo: text finding fixes

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3274 by stephane.ducasse: text finding fixes http://code.google.com/p/pharo/issues/detail?id=3274 in 12247

Nov. 20, 2010

Re: [Pharo-project] Ideas for CompiledMethod proxies?

by Levente Uzonyi

On Fri, 19 Nov 2010, Mariano Martinez Peck wrote: > Hi. I am developing kind of proxies for unused compiled methods. I want to > detect them, put a proxy instead of them, and swap them to disk. Then, in > case they are used, I put back the original ones. With this, I want to > realease memory. This is why I need the proxy objects to be as small as > possibles. > > Right now, I do something like this: > > aProxy := CompiledMethodProxyReferenceStreamWithFileName installOn: > ClassWith1Var selector: #foo. > > this will instantiate the proxy, do the ClassWith1Var methodAt: #foo put: > proxy, write the original compiledMethod that was in #foo into a file, > etc.... > > and then if I do "ClassWith1Var new foo", then using the #run:with:in I > load the file from disk and I put back the original method. To know WHICH > file I have to load, I have to store the fileName in the proxy object. > > In addition, if I DON'T execute the compiled method, but instead I send a > message, for example: > > (ClassWith1Var >> #foo) literals > > this has to do the same: load and put back the original compiled method. To > do this, I use the doesNotUnderstand:. > > This is easy to do if I store the fileName in the proxy instance. Right now, > I am using as fileName this: CLASS >> SELECTOR. For example, in this case, > the file would be named "ClassWith1Var >> #foo" > > Now.....with this solution, I need create an proxy instance for each > compiled method, and these instances have also another instance for the > filename. If I could use the same proxy instance for everybody, the amount > of memory released would be muuuuch more. So I thought that maybe from the > context I can "guess" the filename if I use conventions. > > For example, if you do "ClassWith1Var new foo" then in the #run:with:in I > receive all the information to KNOW that the fileName should be > "ClassWith1Var >> #foo". So, no problem here. > > But for the second case, suppose "(ClassWith1Var >> #foo) literals", I don't > see a way to know this. In this case, #literals is intercepted by the > doesNotUnderstand: of my proxy, and here I should load back the original > compiled method from disk. The problem is that I cannot know in which CLASS > and SELECTOR this proxy was put. The only way I know to do this, is to store > the class + selector in the proxy instance....but it is the same...I will > need an instance per compiled method. In such case is even easier to > directly store the fileName. > > Anyway, if someone has a solution or advice on this, I would be appreciated > that. I tried with thisContext, but it didn't help me. In a 15MB image all CompiledMethods use only ~3MB, so this technique won't save much space IMHO. To minimize the space usage, use SmallIntegers as proxies. To avoid the (Object >> #hash) literals problem swap back the real method in MethodDictionary >> #at:ifAbsent:. A SmallInteger has 31 bits which can easily identify the file index and position where the swapped out method is. For example you can use 7 bits for index and 24 bits for position. That allows you to have 128 files which can hold 16MB data each. Or you can store a single method in a file, this way the SmallInteger identifies the file. Levente > > Thanks > > Mariano >

Nov. 20, 2010

Re: [Pharo-project] Not happy with the issues feed from Google

by Tudor Girba

+1 to this list. -1 to the special "bug tracker" list. Doru On 20 Nov 2010, at 11:49, George Herolyants wrote: > Ok. > > +1 to this list. > -1 to the special "bug tracker" list. > > George > -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

Nov. 20, 2010