[gclist] Finalizer flame wars.

[Francois-Rene Rideau]

It seems to me that the finalizer flame war comes from a lack of
understanding/agreement of what is being implemented upon what
existing platform.

   The computer is a finite window with some strict a priori bound
(=available physical electronic/magnetic memory) that gives a view
upon a mathematically well-defined infinite Universe of objects,
some of which are I/O monads that interact with the Outside World,
and whose semantics is the root of all interest in the system.
Most languages hide the fact that there be monads,
or (worse even) give a low-level interface to the Universe;
good languages don't (e.g. Clean).
   Maybe the fact that the window is finite is unclean, low-level, etc,
but if anyone knows any trick to escape this fact, please tell me.
Until someones does tell me, I'll admit that we have to do with it.
   Finalizers are primarily meant to free resources that are managed
outside of the scope of the explored Universe, in the (Outside) Meta-World.
Their implementation should indeed NOT interfere with the semantics
of the explored Universe (unless and in so far as the Universe is reflective);
however, they SHOULD interfere with the semantics
of the Meta-World, by freeing idle resources from the finite pool.


>> Collectors need to be efficient and transparent.
>
> Efficient, yes!
> Transparent, not necessarily!
>
Efficiency and Transparency are opposite requirements;
the more you control one, the least you control the other
(now, you can *have someone else* control the other for you,
if you trust him sufficiently).
   The Right Thing (TM) is to allow one to make one's own compromise,
instead of requiring one to comply by yours.


>> Adding finalizers hurts their efficiency and transparency.
It doesn't hurt anything if you *add* them:
if using finalizer hurts anything,
adding them allows to fall back to not using them.
   Now, finalizers can do lots of thing that cannot be done without:
pray tell me how you free resources managed outside your GC'ed space
(e.g. memory on a remote host, disk files managed by the underlying OS,
file handles, etc).
   I'm sure that whatever you do, I can call that a finalizer,
even though your set of finalizers might be staticly defined,
and/or not be managed transparently by the GC.


>> Finalizers need to be prompt and sure.
>
> If one of your finalizer needs to be prompt and sure, you should probably not
> use a finalizer in the first place but rather use explicit finalization.
>
A way to do that cleanly is to use a language
with "uniqueness" annotations on types,
which would allow the compiler to call the proper finalizers just in time.

BTW, what are the standard way to have finalizers
in a reflective environments ?
   The most obvious implementation I see is
to have a rooted list of objects being finalized,
with the last instruction in the finalization thread
being to remove the object from that list,
thus triggering finalization for other objects.
   However, unless some kind of ref counting is maintained for
other finalizable objects pointed by this one,
the next GC will have to be waited for for the next cleanup to happen;
this ref counting could be a conservative add-on to usual tracing GC,
done just for finalizable objects;
but the more useful we want it to be, the more expensive, too.

--    ,                                         ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
                 TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"