Sounds great, I agree that is cleaner than the old WriteBarrier hack. Of course, I'd also like look into using a JIT-compiler enabled VM that can make *everything* a bit faster, not just Magma commits..
2010/1/13 Eliot Miranda <eliot.mira...@gmail.com>: > 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 <asquea...@gmail.com> 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 <miguel.c...@gmail.com>: >> > 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 <marianop...@gmail.com>: >> >> > >> >> > >> >> > On Wed, Jan 13, 2010 at 5:02 PM, Chris Muller <asquea...@gmail.com> >> >> > wrote: >> >> >> >> >> >> 2010/1/12 Mariano Martinez Peck <marianop...@gmail.com>: >> >> >> > 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 >> >> >> Pharo-project@lists.gforge.inria.fr >> >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > >> >> > >> >> > _______________________________________________ >> >> > Pharo-project mailing list >> >> > Pharo-project@lists.gforge.inria.fr >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > >> >> >> >> >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko AKA sig. >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project@lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > -- >> > Miguel Cobá >> > http://miguel.leugim.com.mx >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project@lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
