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

[Chris Muller]

> In terms of implementation, this is quite easy to do: since graph
> comes from database in serialized form, creating an initial copy is
> just about materializing same object twice (or materializing and then
> copying) instead of once.
> One will be used in working set,
> and another will be used to detect the changes upon committing transaction.

Magma essentially does this today.  Back in the early 2000's, it made
shallow copies of each materialized object and identity-mapped them to
the "working copy" of the object.  It would compare them upon
transaction commit to see if they should be part of the commit
package.

Since then, it was changed to just keep the original buffers that were
already part of the materialization (so not making copies when just
reading from the db).  On transaction commit it now compares the
referenced oids of each to determine if different.

BTW:  I just realized a BIG problem with the WriteBarrier approach to
change-detection:  If the method which modifies the inst-variable ALSO
happens to perform the commit, then the commit will not notice the
changes!

For example, consider a simple setter:

    name: aString
        myDbSession commit: [ name = aString ]

WB will override this method in its generated anonymous subclass to:

    name: aString
        | t1 |
        t1 := name.
        returnVal := super name: aString.
        t1 == name ifFalse: [ self writeBarrier modified ].
        ^ returnVal

Do you see the problem?  Super call already tried the commit before it
even knew it was changed.  It emphasizes the limitation of WB:  That
it can only work via method calls, not direct assignments like a
immutability-bit could.

The only solution is to NEVER co-locate the updating of a persistent
inst-var in the same method as performing/signaling the commit.  That
sucks bad enough that I've made Magma sessions now default
allowWriteBarrier to false.   :-(