From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a77baf86c187076a X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Garbage collection (was a spinoff of a spinoff of a GA Date: 1996/10/22 Message-ID: X-Deja-AN: 191332069 sender: news@organon.com (news) references: <9610211427.AA06636@most> organization: Organon Motives, Inc. newsgroups: comp.lang.ada Date: 1996-10-22T00:00:00+00:00 List-Id: In article <9610211427.AA06636@most> "W. Wesley Groleau (Wes)" writes: > Let me put my question another way: > > What are the pros and cons of the following three choices? > > Choice One (in the spec): > Declare a data type. Put a comment on it saying > -- Make sure you put calls to the cleanup routines in in every place > -- where an object of this type might leave scope. Make sure you > -- put an exception handler in every routine that declares one of these, > -- or else ensure that no exception can occur. And better guarantee that > -- exceptions cannot occur in declarative regions. Pro: Can be done at C level language constructs (simple RT impl. model) Con: Low level => usually broken (i.e., unlikely that person can keep track of this level of bookkeeping for anything beyond a trivial program). That is, complex/complicated user (programmer) model. The sort of thing that generally results in a) leaks, b) dangling references. Requires a lot of manual futzing and checking (language offers no real help). You're on your own. Also, just doesn't work in some situations (without amending the various "make sures") > Choice Two (in the spec): > -- If you intend to use this data type, you had better ensure that your > -- compiler has a good garbage collector, or get an add-on that can > -- work with your compiler's allocation methods. Forget the "add-on" - that will at best be a conservative collector. For the precise collector: Pro: You need not worry about memory management at the programmer's level. Frees you, the human, to worry about more important things. Higher level of abstraction (simpler user model) More robust in non trivial programs since it does not rely on human bookkeeping Faster - allocations can be _much_ faster and collections can be much more efficient than good ol' "free". Works across the board (no need for special casing various situations) Con: Requires more of vendor => more $$ could be involved in purchase and support. Of course the same is true for _ANY_ high level construct, such as tasking, generics, etc. But I am more than willing to pay more for a language/impl that supports these because in the long run it is _CHEAPER_. Can potentially fool you into thinking that you don't need to know anything about what is going on at this level and thereby you could end up wondering why your stuff isn't working quite like you thought. > Choice Three (in the BODY): > > procedure Finalization (...) is > -- this will ensure that cleanup cannot be forgotten. Pro: Works better than nothing (which is choice one above...) Con: Doesn't work everywhere Expensive (in time and space) Requires you to roll your own managers per type per application (but in those cases where it doesn't work, need to augment with other stuff - e.g. your own storage pools and management...) > What are the cases Finalization doesn't cover? (Other than those the > programmer DECIDED not to apply it to.) Lots's of places. Finalization works pretty darn well for _stack_ allocated things, but pretty poorly (even not at all) for long lived shared heap allocated things. Since the latter are very important in most large scale programs of any note, ... > And what is so hard about "roll your own"? After all this argument about > how and why this and that type of collector can bite you on the behind, > how can anyone complain that What's so hard about rolling your own tasking model on top of the base thread package of your OS? What's so hard about rolling your own polymorphic dispatching model on top of variant programming constructs? What's so hard about using the OS file system directory structure for hierarchical subsystems? You get the picture. GC really is this fundamental a construct. Collectors won't bite you on the behind if they are precise and offered as part of the total package from the vendor. > is so difficult. Sure, the compiler might fail to call it, but we have > better ways of dealing with naughty compilers than adding on outside tools > of arguable value. It may fail to be called not because the compiler is wrong, but because you Joe Programmer got the bookkeeping wrong. Worse - it may be called when it should NOT be called for the same reason. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com