Conventional wisdom on finalization
David Chase maintains a well-regarded GC FAQ, at http://www.iecc.com/gclist/GC-faq.html Interested folks should look it up. A couple highlights: On cycles with finalizers: In theory, of course, a cycle in the graph of objects to be finalized will prevent a topological sort from succeeding. In practice, the "right" thing to do appears to be to signal an error (at least when debugging) and let the programmer clean this up. People with experience on large systems report that such cycles are in fact exceedingly rare (note, however, that some languages define "finalizers" for almost every object, and that was not the case for the large systems studied -- there, finalizers were not too common). On Java's "finalizer called only once" rule: if an object is revived in finalization, that is fine, but its finalizer will not run a second time. (It isn't clear if this is a matter of design, or merely an accident of the first implementation of the language, but it is in the specification now. Obviously, this encourages careful use of finalization, in much the same way that driving without seatbelts encourages careful driving.) Until today, I had no idea I was so resolutely conventional <wink>. seems-we're-trying-to-do-more-than-anyone-other-than-us-expects-ly y'rs - tim
participants (1)
-
Tim Peters