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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no 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/25 Message-ID: #1/1 X-Deja-AN: 192134267 sender: news@organon.com (news) references: <9610211427.AA06636@most> organization: Organon Motives, Inc. newsgroups: comp.lang.ada Date: 1996-10-25T00:00:00+00:00 List-Id: In article eachus@spectre.mitre.org (Robert I. Eachus) writes: > > In article jsa@alexandria (Jon S Anthony) writes: > > > > 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: ... > > 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) > > You must have been smoking some good stuff. Precise collectors can > do the later, but never the former. Think for a second, any reclamation > the garbage collector can do, the free routine can do as well, without > the memory scan for live references. Nah, you're in the weeds for several reasons. Hans Bohem did a good job of listing many. No need to repeat them - just read them. > > > 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, ... > > Let's take the absolute best example of a structure that "requires" > garbage collection an arbitrary graph consisting of nodes with > arbitrary numbers of edges, and cycles allowed. Had to implement one > of those recently, and the requirements allowed nodes to be moved from > one graph to another. > > The finalization routine took five lines, and neat trick was in the > Adjust routine. What "adjust" routine? When you have limited types you don't even _have_ adjust. Besides, "adjusting" still reflects a value semantic mentality and that is not always what is needed (in fact it is often not what is desired). Do you prevent a client from allocating one of these nodes? Assigning that access result to some access variable? On the stack? Or maybe in a field of a variable of another structured type? What about those references? You can't have "controlled access types". Yes, you can hack a clumsy, heavy weight version which in the end just kicks the problem up one level anyway. I don't see the relevance of what you are trying to say here. > From a garbage collection point of view it was "extra overhead" but Yes. > it allowed me to do other operations such as reachability more > efficiently. ??????? > (You can't reach a node with a lower absolute generation number. > The biggest win is that you only have to check against nodes you > have visited before with the current generation number. Beats > marking and unmarking and allows more than one such operation to be > conducted simultaneously.) What makes you think that is the only, let alone the best, option???? /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com