[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
sneaky uses for copy-on-write
- To: <tribble>
- Subject: sneaky uses for copy-on-write
- From: Mark S. Miller <mark>
- Date: Fri, 27 Oct 89 18:07:33 PDT
- Cc: <xtech>
- In-reply-to: <Eric>,21 PDT <8910261904.AA29337@xanadu>
Date: Thu, 26 Oct 89 12:04:21 PDT
From: tribble (Eric Dean Tribble)
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.
I'm worried about the number and kinds of cases that our garbage
collector is going to be expected to handle. You are correct that
copy-on-write for Tables only works well when unreferenced Tables get
*immediately* finalized. RefCounts can do this, and the alternatives
that I know of cannot. However, because of potential cycles,
refCounts cannot handle everything, neither are they (probably) as
efficient as the non-immediate alternatives. One possibility that
we've talked about is to refCount collect types that may appear in
cycles, and collect other types using a non-immediate alternative.
Note that, though Tables typically will not appear in cycles, they
*may*, and therefore are yet a third, mixed, case. Yucko!
Much as I approve of the general attitude that we should make
programming at one level simpler by investing in abstractions and
creating more powerful, simpler building blocks at a lower level, I
fear we may be on the far side of the trade-off this time. How
painful would it be to explicitly delete the old Table when you want
copy-on-write to be able to write without copying. Note that a
regular garbage collector will still let you postpone figuring out
when and where to put these deletes; just at the cost of actually
copying sometimes when you didn't need to. If it's at least
*plausible* that we can figure out where we *need* to put these
deletes (i.e., where they *actually* make a *significant* difference),
then let's postpone adding yet more complexity to our garbage
collector requirements until we find we need to.
Btw, before this example, it never occured to me before to make a
distinction between immediate collectors and eventual collectors.