[Python-Dev] finalization again

[Tim Peters]

[Guido]
> ...
> Conclusion
> ----------
>
> Are the Java rules complex? Yes. Are there better rules possible? I'm
> not so sure, given the requirement of allowing concurrent incremental
> garbage collection algorithms that haven't even been invented
> yet.

Guy Steele worked his ass off on Java's rules.  He had as much real-world
experience with implementing GC as anyone, via his long & deep Lisp
implementation background (both SW & HW), and indeed invented several key
techniques in high-performance GC.  But he had no background in GC with
user-defined finalizers -- and it shows!

> (Plus the implied requirement that finalizers in trash cycles
> should be invoked.) Are the Java rules difficult for the user? Only
> for users who think they can trick finalizers into doing things for
> them that they were not designed to do.

This is so implementation-centric it's hard to know what to say <0.5 wink>.
The Java rules weren't designed to do much of anything except guarantee that
Java (1) would eventually reclaim all unreachable objects, and (2) wouldn't
expose dangling pointers to user finalizers, or chase any itself.  Whatever
*useful* finalizer semantics may remain are those that just happened to
survive.

> ...
> Unlike Scheme guardians or the proposed __cleanup__ mechanism, you
> don't have to know whether your object is involved in a cycle -- your
> finalizer will still be called.

This is like saying a user doesn't have to know whether the new drug
prescribed for them by their doctor has potentially fatal side effects --
they'll be forced to take it regardless <wink>.

> ...
> Final note: the semantics "__del__ is called whenever the reference
> count reaches zero" cannot be defended in the light of a migration to
> different forms of garbage collection (e.g. JPython).  There may not
> be a reference count.

1. I don't know why JPython doesn't execute __del__ methods at all now, but
have to suspect that the Java rules imply an implementation so grossly
inefficient in the presence of __del__ that Barry simply doesn't want to
endure the speed complaints.  The Java spec itself urges implementations to
special-case the snot out of classes that don't  override the default
do-nothing finalizer, for "go fast" reasons too.

2. The "refcount reaches 0" rule in CPython is merely a wonderfully concrete
way to get across the idea of "destruction occurs in an order consistent
with a topological sort of the points-to graph".  The latter is explicit in
the BDW collector, which has no refcounts; the topsort concept is applicable
and thoroughly natural in all languages; refcounts in CPython give an
exploitable hint about *when* collection will occur, but add no purely
semantic constraint beyond the topsort requirement (they neatly *imply* the
topsort requirement).  There is no topsort in the presence of cycles, so
cycles create problems in all languages.  The same "throw 'em back at the
user" approach makes just as much sense from the topsort view as the RC
view; it doesn't rely on RC at all.

stop-the-insanity<wink>-ly y'rs  - tim