[Vm-dev] [Pharo-project] Plan/discussion/communication around new object format

[Igor Stasenko]

in your case (Magma) you can do even better:
at the beginning of transaction make a deep copy of object graph.
Upon finishing transaction, you walk the modified graph and compare
objects if they are changed or not.
This could be somewhat memory-hungry (but do we care?), but you don't
have to use anything like
write barrier or overriding compiled methods.

And with having a per-object properties, it just another piece of cake:

Object>>maIsChanged
   ^ (self propertyAt: #originalCopy) = self

and for nested transactions, you can make it even more hungry

Object>>maIsChangedIn: transaction
   ^ (self propertyAt: transaction) = self

:)
but nested (and not even) transactions implying anyways that you hold
the original somewhere,
to be able to roll back the changes.

So in case of rollback, all you need to do is to send #restore to the
root object:

Object>>restore
   self befomeForward: (self propertyAt:#originalCopy).
   self allIvarsDo: [:each | each restore]

Now, add there a VM primitive which can quickly mark a graph starting
from your roots,
and stockpile marked objects into some array, and you will have a
super fast thingy :)


On 12 June 2012 00:00, Chris Muller <ma.chris.m at gmail.com> wrote:
> (discussion branch moved to Magma list).
>
> Well, I doubt it's faster than just using Avi's regular WriteBarrier.
> Understand the overrides are only compiled once per class, not once
> per object.  In the real world compilation is not a significant factor
> on performance.
>
> The overridden methods follow the pattern:
>
> someMethod
>  | t1 t2 newT1 newT2 returnValue |
>  t1 := self instVarAt: 1.
>  t2 := self instVarAt: 2.
>  returnValue := super someMethod.
>  newT1==t1 ifFalse: [ self modified. ^ returnValue ].
>  newT2==t2 ifFalse: [ self modified.  ^ returnValue ].
>  ^ returnValue
>
> which is probably even faster than unwinding stack all the way to the
> Immutable handler every time an attribute is set.  Not sure, but the
> above is fast enough to accomplish the overall goal and substantially
> improve app performance.
>
>
>
>> Ok, what if we call it a "fast write-barrier provided by the VM".
>> Would that change your view? Igor?
> _______________________________________________
> Magma mailing list
> Magma at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/magma



-- 
Best regards,
Igor Stasenko.