sneaky uses for copy-on-write

[Eric Dean Tribble <tribble>]

I was considering Tables in the Ent yesterday and realized some
interesting properties of copy-on-write.

Converting between immutable, non-immutable, and read-only tables and
sets is a constant time operation.  Since the elements array is
copy-on-write, just make a new Table frame of the appropriate.  Then
throw away the old one.  If there was only one reference to the old
table frame, then the elements array gets coopted for the new Table.

A similar trick can be used for state change to a variable containing
an immutable set (or table).

ocrums = ocrums ->with(newElem);

becomes:

{ MuSet * newCrums = ocrums ->asMutable();
  ocrums = NULL;
  newCrums -> store(newElem);
  ocrums = newCrums ->asImmutable();
}

Note that this requires reference counting for Tables.  It is
efficient only if the 'ocrums' set gets immediately deallocated when
NULL is assigned.  We can't make an explicit delete because ocrums
might be shared.  This would only be done to places that GProf points
at, of course.

Note that reference counting of Tables may be a good idea anyway.
Typically tables won't refer to themselves, so immediate reclamation
reduces the work for the garbage collector.  This will require
measurment.

dean