Re: copy-on-write (was: globals considered harmful)

["J.J. Larrea" <jjl@panix.com>]

> > However, there may be some clever trick to implement COW efficiently.
> > Sounds like a Ph.D. thesis to me... :-)
> > 
> > -Urs

To which Bill Burdick (burdick@ars.rtp.nc.us) writes:

> I sent a message about NewtonScript and copy-on-write on the 12th, but it 
> doesn't look like it got through :(.

I also wonder whether my original message got through (other than to Urs) -
all replies so far have been to Urs' reply to it.
  
> How about a blend of indirect access and the pointer redirection.  Only use 
> indirect access for objects that use copy-on-write (i.e. objects that still 
> inherit some slots from a prototype).  Once an object's slots are all copied, 
> you redirect the pointers once to the new object.
> 

This is essentially a sub-case of the "form factoring" I suggested, except
the factoring (ie. reduction of duplicate forms) is only done against the
form of the prototype object, and not the entire tree of derivatives.  At
first this suggests a possible speedup - the form need be compared only if
the number of slots == that of the parent.  The actual slot identities still
need to be checked since some of the slots making up the total count could
have been explicitly added to the object, and of course the comparison is
still not linear-time because even if no new slots are defined the order
of automatic slot addition might be different than the order in which they
were defined in the prototype.  But I think the cases where *all* deferred
slots get ultimately defined will be far fewer than those for which only
a subset get defined, and that factoring should happen at every slot
addition.

I hope I haven't confused the issue by getting my terminology wrong (my
copies of the Self Report are packed and inaccessible at present): By "form"
I mean the underlying "pseudo-classes" that SELF maintains to factor out
the structure of multiple objects' data slots from their individual slot
values.  Please correct me if I mis-remembered the term!

> For example, make a stub object with an inheriting slot to the COW object.  
> This object inherits from the prototype and grows new slots as needed.  You 
> guarantee that the only pointer to the COW object is the stub, this way, you 
> don't need to use addSlotsIfAbsent:, you can just make a new object, copy the 
> old slots, and reassign the stub's pointer to the new object.  When the COW 
> object copies the last slot, you do a define: to make the stub effectively 
> become the COW object.

I don't see the need for the stub object; addSlotsIfAbsent: takes care of
copying the remainder of the slots while preserving object identity.
Or perhaps I'm misunderstanding your example.

> This gives you the benefit of COW objects when you need them, at the expense 
> of indirect access.

If slot-cacheing is performed, the expense should be small, no?

- JJ Larrea (jjl@panix.com)