On Wed, Jan 13, 2010 at 12:45 PM, Igor Stasenko <siguc...@gmail.com> wrote:
> 2010/1/13 Martin McClure <mar...@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
