On Thu, Jan 14, 2010 at 12:45 AM, Stéphane Ducasse < [email protected]> wrote:
> Elliot > > it would be realllllllly cool to have this in the squeak-vm what should be > done to get it? > I'll upload the Newspeak VMMaker package to a suitable repository. I could also try and do an extract and merge. Alternatively someone who is interested could do the same starting from the Newspeak release. > > Stef > On Jan 13, 2010, at 7:41 PM, Eliot Miranda wrote: > > > A *much* better way to implement this is to support immutability in the > VM (I know, I know, but all the code is available in the Newspeak VM), mark > objects one wants to mark as dirty as immutable, catch the > NoModificationError exception, and proceed after having made the object > mutable and marked it dirty. No creating hidden classes, no trying to get > change class to work for compact classes, etc. Just a simple VM-implemented > write barrier that can also be used for a host of other things > (object-database mapping, debugging, immutable literals etc). > > > > On Wed, Jan 13, 2010 at 9:55 AM, Chris Muller <[email protected]> > wrote: > > A great description of what WriteBarrier does and how it works can be > > found in the WriteBarrier class-comment, itself. > > > > In a nutshell, when an object is added to a WriteBarrier, a subclass > > is dynamically compiled for it, but not added to the Smalltalk > > dictionary. The name of the class is the same as its superclass but > > with a '*' appended to it. > > > > After creating the subclass, WriteBarrier looks at all "definitions" > > of each instance variable, and adds methods to override the methods in > > its superclass. The generated override checks the pre-state of the > > instVar, calls super, then compares the post-state of the instVar to > > the pre-state. > > > > If it changed, it signals so that the application (Magma) can mark it > dirty. > > > > So, it allows Magma to operate with a smaller readSet, which speeds up > > the part of the commit process relating to detection of changed > > objects for building the CommitPackage which is shipped off to the > > server.. > > > > - Chris > > > > 2010/1/13 Miguel Enrique Cobá Martinez <[email protected]>: > > > El mié, 13-01-2010 a las 18:08 +0200, Igor Stasenko escribió: > > >> Can someone clarify, why WriteBarrier depends on compiler (new > > >> compiler or old compiler - not really important). > > >> I just wonder what compiler functionality its depends on. > > > > > > WriteBarrier uses the class BytecodeGenerator that is part of the > > > package NewCompiler (that is currently on rewrite for the closure > > > images). Why it need it and how it use it, I really don't know. I have > > > only a vague idea of what WriteBarrier does, and as Mariano said, I use > > > Magma but never used or activated the WriteBarrier functionality of it. > > > > > > Cheers > > >> > > >> 2010/1/13 Mariano Martinez Peck <[email protected]>: > > >> > > > >> > > > >> > On Wed, Jan 13, 2010 at 5:02 PM, Chris Muller <[email protected]> > wrote: > > >> >> > > >> >> 2010/1/12 Mariano Martinez Peck <[email protected]>: > > >> >> > Magma depends on NewCompiler ??? > > >> >> > > >> >> No, WriteBarrier depends on NewCompiler. > > >> >> > > >> >> Magma can, at the explicit option of the user, turn on the > > >> >> WriteBarrier option if the WriteBarrier package is present. > > >> >> WriteBarrier used to be self-contained, later it became dependent > on > > >> >> NewCompiler. > > >> >> > > >> >> Unless the WriteBarrier option is switched on by the user, its > > >> >> presence or absence in the image (as well as NewCompiler) has no > > >> >> effect on Magma. > > >> >> > > >> > > > >> > Thanks for the clarification Chris. It was strange for me that as I > used > > >> > Magma a couple of times and I never installed WriteBarrier neither > > >> > NewCompiler. > > >> > > > >> > Cheers > > >> > > > >> > Mariano > > >> > > > >> > > > >> >> > > >> >> - Chris > > >> >> > > >> >> _______________________________________________ > > >> >> Pharo-project mailing list > > >> >> [email protected] > > >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >> > > > >> > > > >> > _______________________________________________ > > >> > Pharo-project mailing list > > >> > [email protected] > > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >> > > > >> > > >> > > >> > > >> -- > > >> Best regards, > > >> Igor Stasenko AKA sig. > > >> > > >> _______________________________________________ > > >> Pharo-project mailing list > > >> [email protected] > > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > > > Miguel Cobá > > > http://miguel.leugim.com.mx > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > [email protected] > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
