Reference counting garbage collection

[Alex Martelli]

"Chris Tavares" <ctavares at develop.com> wrote in message
news:QO2h7.4623$XY4.463031 at newsread2.prod.itd.earthlink.net...
    ...
> > that .NET would NOT use reference counting but rather
> > mark-and-sweep (so, no guaranteed finalization time).
>
> Actually, .NET uses a generational copying collector, NOT a mark & sweep
> collector. Just to be pedantic. :-)

Pedantry is important in computing, but my point stands:
it does not matter much what specific implementation of GC
is in the current betas, or which one will make it to the
production release (and they can change it any time of
course), the really important things are the semantics
as specified.  The .NET Framework, and specifically the
IL semantics as submitted to standards bodies, don't get
into implementation details.

The relevant point here is IMHO that, coding to .NET
specs, you can rely on mark-and-sweep semantics: "the
system" will finalize stuff even if it's in reference
cycles, BUT it will finalize it if and when it happens
to be convenient to "the system", subject to the sole
constraint that it will not keep non-finalized stuff
that it could finalize if and when it gives you an
out-of-memory exception (NO such guarantee applies to
ANY other resource except memory, I believe -- I wish
I was wrong on this point, and that collect-all-you-
can finalization was guaranteed before any other kind
of resource-exhausted error, but I can't find any
mention of that whatsoever on the .NET specs).

And programmers used to reference-count semantics
(finalization doesn't occur given reference loops,
but without them it occurs instantly as soon as an
object is found to be unreferenced) have proven to
be very reluctant to abandon those semantics for
m&s semantics (whether _implemented_ by m&s, copying,
generational mixed-strategies, etc, isn't the point:-).


Alex