Compilation of the subclass is only done once per class (and cached). It takes under one second per class and could be done at application start-up anyway. So I'm dubious that any kind of Exception Handling approach is going to be "far more performant" that simply calling "self modified:" as the existing WriteBarrier implementation does. As for "less-problematic", that might have been true with GemStone. Personally, I would worry about forgetting to set the immutable bit on my objects. If that were the basis by which changed-detection occurs, forgetting to set immutable could result in object changes not being detected, and therefore not committed. Silently - you wouldn't know you lost work until much later. *That* sounds problematic! For Magma, the existing WriteBarrier approach really hasn't been problematic at all, even under lots of heavy use (though we run with it turned off in our own production systems, don't need it). It operates transparently to the Magma user as a "set and forget". I concur, however, that it *is* a more complex solution than simply handling the NoModify exception approach. Introducing the notion of a VM-level immutable bit to objects may be a nice feature, but "feels" less-dynamic, since it reflects a similarity with static typing. I have "set up" objects for use and, introduces the notion that every single mutative operation, in all places, must (or at least should) now have to handle the NoModify exception. - Chris 2010/1/13 Eliot Miranda <eliot.miranda@gmail.com>:
On Wed, Jan 13, 2010 at 12:45 PM, Igor Stasenko <siguctua@gmail.com> wrote:
2010/1/13 Martin McClure <martin@hand2mouse.com>:
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).
Since object dirtying is at the core of the product I work with, and I've worked extensively with both methods of implementing write barriers...
I very strongly agree with Eliot. *So* much nicer a way to do this.
It could be more efficient, in respect that you don't need to create shadow classes. But triggering exception leads to stack unwinding to find a handler, which inevitably leads to deoptimizing all contexts..
Uh, not so. Â In VW and Cog examining a context does _not_ deoptimize a context. Â A context will be "deoptimized" (actually converted to a vanilla heap context) only if you write to other than its stack contents or sender. Â i.e. a context's frame is only discarded if - one assigns to any of its instance variables other than sender - the stack zone runs out of room for new frames and a stack page must be vacated, causing all frames on that page to be converted to stack contexts So exception handling does *not* usually involve converting contexts. Â It would be very slow if it did.
and if stack depth is high (between point of writing attempt and hook, where magma will handle exception), this will be much slower than WriteBarrier implementation, described by Cris, which checking the value in-place, without the need of touching exception machinery.
I disagree strongly. Â Martin's experience with Gemstone (and Gemstone's experience) covers over twenty years and the VM-supported immutability implementations (first in VisualAge IIRC) of Gemstone are far more performant and less problematic than the code-rewriting implementations similar to Magma. Â Martin really knows what he's talking about.
Just 2 cents.
Regards,
-Martin
_______________________________________________ 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project