> 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.
>>
> 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.
>