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 <asqueaker@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.coba@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 <marianopeck@gmail.com>:
On Wed, Jan 13, 2010 at 5:02 PM, Chris Muller <asqueaker@gmail.com>
wrote:
2010/1/12 Mariano Martinez Peck <marianopeck@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