[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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4