- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] VM repository rename

by Esteban Lorenzano

yes, in fact I used pharovm because pharo-vm was taken, but I was hoping Camillo does what he actually did :) On Sep 6, 2013, at 8:25 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > because all other repos have a dash here: https://github.com/pharo-project > might be the wrong original decision, but at least its consistent, if its > consistent it can be easily refactored in the future :) > > On 2013-09-06, at 15:21, "Esteban A. Maringolo" <emaringolo(a)gmail.com> wrote: >> Why the dash? >> Esteban A. Maringolo >> >> >> 2013/9/6 Camillo Bruni <camillobruni(a)gmail.com>: >>> I renamed the VM repository on github to be more consistent with the other repository names >>> >>> OLD: https://github.com/pharo-project/pharovm >>> NEW: https://github.com/pharo-project/pharo-vm >>> >>> Note that github does automatic forwarding, thus old urls will continue to work. >> >

Sept. 6, 2013

Re: [Pharo-dev] VM repository rename

by Camillo Bruni

because all other repos have a dash here: https://github.com/pharo-project might be the wrong original decision, but at least its consistent, if its consistent it can be easily refactored in the future :) On 2013-09-06, at 15:21, "Esteban A. Maringolo" <emaringolo(a)gmail.com> wrote: > Why the dash? > Esteban A. Maringolo > > > 2013/9/6 Camillo Bruni <camillobruni(a)gmail.com>: >> I renamed the VM repository on github to be more consistent with the other repository names >> >> OLD: https://github.com/pharo-project/pharovm >> NEW: https://github.com/pharo-project/pharo-vm >> >> Note that github does automatic forwarding, thus old urls will continue to work. >

Sept. 6, 2013

Re: [Pharo-dev] VM repository rename

by Esteban A. Maringolo

Why the dash? Esteban A. Maringolo 2013/9/6 Camillo Bruni <camillobruni(a)gmail.com>: > I renamed the VM repository on github to be more consistent with the other repository names > > OLD: https://github.com/pharo-project/pharovm > NEW: https://github.com/pharo-project/pharo-vm > > Note that github does automatic forwarding, thus old urls will continue to work.

Sept. 6, 2013

VM repository rename

by Camillo Bruni

I renamed the VM repository on github to be more consistent with the other repository names OLD: https://github.com/pharo-project/pharovm NEW: https://github.com/pharo-project/pharo-vm Note that github does automatic forwarding, thus old urls will continue to work.

Sept. 6, 2013

Re: [Pharo-dev] blog post

by Eliot Miranda

Hi StÃ©ph, On Fri, Sep 6, 2013 at 9:35 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Hi eliot > > This is really good that you write this blog. I read and I saw ephemerons > (excellent because we were discussing them again today with esteban and > igor) > I have some questions that may be are stupid. > - I was wondering if you plan to have a dedicated class space. > Clement told me that in Chrome (but I may be wrong) they have that and in > the class space the classes are not moved. But with the table you are sure > that your index do not change so may be the gain is not important. > exactly. > - Did I get it rid that you want to have a become: that does not > require scanning the full memory? > yes, this is very important for the FFI. I want to be able to pin objects very cheaply, and I think that the way to do that is to a) become: objects in newSpace into pinned objects in oldSpace, and b) have an incremental collector/compactor in oldSpace that doesn't move pinned objects. If objects can be pinned in newSpace I think newSpace will fill up. So... > But with a body as in VW. This is what you mean with the > lazyBecome: and the forwarding pointer? > Here are the relevant paragraphs in SpurMemoryManager's class comment: - lazy become. The JIT's use of inline cacheing provides a cheap way of avoiding scanning the heap as part of a become (which is the simple approach to implementing become in a system with direct pointers). A becomeForward: on a (set of) non-zero-sized object(s) turns the object into a "corpse" or "forwarding object" whose first (non-header) word/slot is replaced by a pointer to the target of the becomeForward:. The corpse's class index is set to one that identifies corpses (let's say classIndex 1), and, because it is a special, hidden class index, will always fail an inline cache test. The inline cache failure code is then responsible for following the forwarding pointer chain (these are Iliffe vectors :) ) and resolving to the actual target. (In the interpreter there needs to be a similar check when probing the method cache). It has yet to be determined exactly how this is done (e.g. change the receiver register and/or stack contents and retry the send, perhaps scanning the current activation). See below on how we deal with becomes on objects with named inst vars. We insist that objects are at least 16 bytes in size (see 8-byte alignment below) so that there will always be space for a forwarding pointer. Since none of the immediate classes can have non-immediate instances and since we allocate the immediate class indices corresponding to their tag pattern (SmallInteger = 1 & 3, Character = 2, SmallFloat = 5?) we can use all the class indices from 0 to 7 for special uses, 0 = free, and e.g. 1 = isForwarded. (and later on) As described earlier the basic idea behind lazy become is to use corpses (forwarding objects) that are followed lazily during GC and inline cache miss. However, a lazy scheme cannot be used on objects with named inst vars without adding checking to all inst var accesses, which we judge too expensive. Instead, when becomming objects with named inst vars, we scan all activations in the stack zone, eagerly becomming these references, and we check for corpses when faulting in a context into the stack zone. Essentially, the invariant is that there are no references to corpses from the receiver slots of stack activations. A detail is whether we allow or forbid pinning of closure indirection vectors, or scan the entire stack of each activation. Using a special class index pun for indirection vectors is a cheap way of preventing their becomming/pinning etc. Although "don't do that" (don't attempt to pin/become indirection vectors) is also an acceptable response. - For Characters since they are immediate (if I got it right) we > could use Unicode directly or am'I wrong? > That's right. This should speed up string access and mean that all characters are unique, so one can use #==. > > Stef > > > > Hi All, > > > > I've just written a blog post on progress with Spur, which is my > nickname for a new memory manager for the Cog VM. I hope it'll be > interesting. > > -- > > best, > > Eliot > > > -- best, Eliot

Sept. 6, 2013

Re: [Pharo-dev] blog post

by StÃ©phane Ducasse

Hi eliot This is really good that you write this blog. I read and I saw ephemerons (excellent because we were discussing them again today with esteban and igor) I have some questions that may be are stupid. - I was wondering if you plan to have a dedicated class space. Clement told me that in Chrome (but I may be wrong) they have that and in the class space the classes are not moved. But with the table you are sure that your index do not change so may be the gain is not important. - Did I get it rid that you want to have a become: that does not require scanning the full memory? But with a body as in VW. This is what you mean with the lazyBecome: and the forwarding pointer? - For Characters since they are immediate (if I got it right) we could use Unicode directly or am'I wrong? Stef > Hi All, > > I've just written a blog post on progress with Spur, which is my nickname for a new memory manager for the Cog VM. I hope it'll be interesting. > -- > best, > Eliot

Sept. 6, 2013

Re: [Pharo-dev] codegen-scripts/extract-commit-info.sh

by Camillo Bruni

OK, that solves it for the jenkins builds. IMO that is the wrong place, since when you debug it with XCode you run into the same problem again. I think this should be in the CMake scripts, much like you download cairo, you want to generate the versionInfo when it is not there yet. On 2013-09-06, at 13:03, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > you don't > > build.sh already does that for you > > > On Sep 6, 2013, at 5:05 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> Where do I have to add code to make this script run automatically before each build? >> I really don't see the point of having to run this script manually :( > >

Sept. 6, 2013

Re: [Pharo-dev] Sound on Ubuntu Problems

by J.F. Rick

SUCCESS! I installed the libpulse0 package. LDD showed that the library was linked to the i386 libraries. It worked. It seems like someone needs to update the other sound packages to point to the i386 packages rather than to default to the x86_64 ones. Thanks, Jeff On Thu, Sep 5, 2013 at 3:52 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > On Wed, Sep 4, 2013 at 12:37 PM, J.F. Rick <self(a)je77.com> wrote: > > apt-get install libpulse-dev > > > the *-dev packages are only useful when you compile packages. If you > don't want to compile C files, you only need the non -dev packages > (libpulse0). > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Sept. 6, 2013

Re: [Pharo-dev] blog post

by StÃ©phane Ducasse

eliot this is an excellent news. Now do you plan to have support for ephemerons and immutable objects? Stef On Sep 5, 2013, at 8:38 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi All, > > I've just written a blog post on progress with Spur, which is my nickname for a new memory manager for the Cog VM. I hope it'll be interesting. > -- > best, > Eliot

Sept. 6, 2013

Re: [Pharo-dev] codegen-scripts/extract-commit-info.sh

by Esteban Lorenzano

you don't build.sh already does that for you On Sep 6, 2013, at 5:05 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Where do I have to add code to make this script run automatically before each build? > I really don't see the point of having to run this script manually :(

Sept. 6, 2013