On Wed, Jan 13, 2010 at 1:41 PM, Igor Stasenko <[email protected]> wrote:
> 2010/1/13 Igor Stasenko <[email protected]>: > > 2010/1/13 Eliot Miranda <[email protected]>: > >> > >> > >> On Wed, Jan 13, 2010 at 12:45 PM, Igor Stasenko <[email protected]> > wrote: > >>> > >>> 2010/1/13 Martin McClure <[email protected]>: > >>> > 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. > >> > > Ah, cool.. So, even when debugging (and hence accessing context state) > > does not leads automatically to deoptimization? > > > >>> > >>> 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. > > > > I'm not saying anything against immutability, but capturing the object > > state change > > seem will be less efficient. > > By reading Cris description i imagine that WriteBarrier rewriting a code > like: > > > > SomeClass>>foo: newValue > > foo := newValue > > > > to: > > > > SomeClass*>>foo: newValue > > | old | > > old := foo. > > foo := newValue. > > old == foo ifFalse: [ Magma markAsDirty: self ] > > > > now compare performance of evaluating: > > > > [[[[[[ self foo: 5 ]]]]]] > > > > with: > > > > [[[[[[ self foo: 5 ]]]]]] on: ImmutableException do: [:ex | Magma > > markAsDirty: ex receiver. ex receiver beMutable. ex resume ] > > > > where [[[[[]]]]]] is a call stack, which can be deeeeep. > > > > A stack unwinding, actually could be avoided, if we suppose that VM > signaling the exception , by sending > SomeExceptionSpecialObject>>#signal: immutableObject > > Then Magma could hook there and override that method, to something like: > SomeExceptionSpecialObject>>#signal: immutableObject > (Magma watchingOverThisObject: immutableObject) ifFalse: [ ^ self > new signal: immutableObject ]. > Magma markAsDirty: immutableObject. > immutableObject beMutable. > "retry code here" > Right. Something of this order. Again lighter-weight than delivering an exception and much lighter weight than constructing a special class. But see my previous message for how to write it nicely, or play with Gemstone and VW non-commercial to see how it is done in a production system. > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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
