chase@Ozona.orc.olivetti.com (David Chase) (07/07/89)
In article <9522@alice.UUCP> bs@alice.UUCP (Bjarne Stroustrup) writes: > >There is an important question that needs to be asked in regards to GC >of C++ programs: > > ``When an object is garbage collected should its destructor > (if any) be called?'' > >People often simply assume that the answer is `yes.' > >This is not obvious. [and goes on to point out that if the answer is yes, then "normal program termination" will require a round of destructor-calling.] Two other problems also appear. The first occurred to me when this was discussed (in general terms) for Modula-3, and the other was pointed out by people at Xerox PARC working on PCR. (1) if a cyclic pointer graph is collected, there is really no way for the collector to know which object's "destructor" should be called first. Barring interesting restrictions on what can be done in a destructor, the collector could easily get this wrong. (2) invocation of destructors ("finalization", to use the PARC/Cedar terminology) on unreachable objects interferes with timely garbage collection. This is so because (assuming a non-cyclic pointer graph) the objects referenced by a finalized object cannot be collected until after finalization; the destructor might also wish to refer to those objects. If few objects are marked for finalization, then this won't seriously degrade the performance of the collector. If, however, every single "object" collected must have its destructor called before it can be recycled, then memory will be returned to the free list more slowly. This depends on the shape of the graphs which become garbage, however -- balanced trees of N nodes will be recycled in roughly log N collections, but lists (degenerate trees) of N nodes will require N collections before they are completely recycled. Make of this what you will. For C++, it looks like the issue is "do we really want garbage collection?" For Modula-3, the question is instead "do we really want finalization"? Some time was briefly spent designing a finalizing copying-compacting garbage collector. If the page protection games are played [*], then it looks (informally) like finalization might be more practical in a compacting collector. Of course, such a collector cannot be used with ordinary C compiled by ordinary C compilers. David [*] See work by Appel, Ellis, and Li (SIGPLAN '88, Atlanta) Appel and MacQueen (Func. Prog. Lang. and Comp. Arch '87, Portland) Bartlett (DEC WRL tech report, I believe) discussing use of page protection to help implement copying-compacting collectors on "stock hardware".
jima@hplsla.HP.COM (Jim Adcock) (07/08/89)
>Make of this what you will. For C++, it looks like the issue is "do >we really want garbage collection?" For Modula-3, the question is >instead "do we really want finalization"? Again, I would hope GC is not going to become a "built-in" feature of C++, but rather, like streams, a standard library that people can choose to use or not choose. Then, like any other library, a GC that prohibits the use of other GC libraries would be a bad design. And general purpose classes that aren't tied to a particular GC would be better than ones that are. And classes that don't need GC would still be the ones most widely applicable, reusable, and therefore "best." I hope these issues can continue to be decided on a class-by-class basis.