sneaky uses for copy-on-write

[Mark S. Miller <mark>]

Date: Sat, 28 Oct 89 19:30:07 PDT
   From: tribble (Eric Dean Tribble)

   We need two roughly
   orthogonal mechanisms.  The garbage collector walks over most classes
   of objects and finalizes then when it finds circularities.

I assume you are not considering restricting the garbage collector to
only finalizing circularities, as opposed to circularities plus other
garbage that it encounters?  I'm almost certain you must mean that,
but am just checking.  A possibility is that you're talking about
always refCounting all objects (which will pick up all non-circular
garbage immediately) in addition to running a regular garbage
collector (which would then only have circular garbage to worry
about).  Please tell me that this is not what you are talking about.

   The cost for a regular garbage collector would be
   ALWAYS copying when you typically don't need to.  

No.  The cost of a regular garbage collector would be to copy when:

1) there exist more than 1 copy-on-write Table sharing the same
internal state.

2) only one of these is non-garbage.

3) That one is modified.

4) the eventual garbage collector hasn't yet collected its garbage
brothers. 

5) the programmer hasn't explicitly deleted its garbage brothers.

Admittedly #4 is highly probable.  I think #3 is the weak link.  Also
our motivating example is iterating over Tables.  With our new
iteration style, explicitly deleting in time should usually be easy:

{
    Stepper * tableIt;
    for (tableIt = table->stepper(); tableIt->notDone(); tableIt->step()) {
	/* stuff that doesn't modify table */
	....
    }
    delete tableIt;
}

Isn't the above idiom in fact most of the cases we are worried about?
Our pass-by-value style for using Steppers makes the above idiom safe.