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,3498dd887729ed19 X-Google-Attributes: gid103376,public From: John Howard Subject: Re: Garbage Collection in Ada Date: 1996/10/14 Message-ID: X-Deja-AN: 189339987 references: <01bbb910$f1e73f60$829d6482@joy.ericsson.se> <199610132138291604607@dialup101-6-14.swipnet.se> content-type: TEXT/PLAIN; charset=US-ASCII organization: SkyNET Internet Services mime-version: 1.0 newsgroups: comp.lang.ada Date: 1996-10-14T00:00:00+00:00 List-Id: On Sun, 13 Oct 1996, Lars Farm wrote: [snip] > managing memory is a particularly nasty problem and GC solves it almost > completely. [snip] GC just provides *automatic* deallocation of "unreachable" dynamically allocated objects. GC is not cost-free. Ada 95 flexibly provides a programmer with capable mechanisms to manually manage memory. Plus the safeguards of Ada help minimize creating slop to clean up and so the deallocation can likely be managed easily enough manually. I am not against using GC if its reliability is guaranteed and it saves me some money. Otherwise I prefer to manually control the deallocation. > Another common nonsense argument against GC is real time behaviour. GC > is no different than ordinary allocators. They have no time constraints > either. If one needs absolutely predictable timing one has to manually > take over memory management for that section of code with GC and with > ordinary allocators anyway. > > As for C++ the GC-dangerous constructs are very few and very obscure and > luckily rarely used and easily avoided. Using them usually invokes > "undefined behaviour" anyway (deliberately hiding pointers from the GC - > on disk or with various xor tricks,...). In practice GC (conservative > collector by Boehm) works very well with C++ and in my experience is > faster than ordinary new/delete. If one also uses the fact that one has > a GC in the design, things become faster still. Less need to copy > datastructures (there is a lot of redundant copying in C++ out of fear > that one wont know when to release memory otherwise). Granted, the speed > is not just because of GC, but also because Boehms GC (that I have used > in C++) is a much better allocator than the ones delivered with my dev > systems. You argue that GC is already worthwhile for the culture of C++ programming. Perhaps it is most cost-effective if an operating system does GC instead of having several programs doing their own GC. That seems to be a goal of the Java Virtual Machine. [snip] > Ada allows GC, C++ doesn't even acknowledge its existence. One would > have thought that the stricter Ada would be easier to adapt to GC than > the "sloppy" C++. [snip] > Lars Farm, lars.farm@ite.mh.se I argue that GC is far less worthwhile for the culture of Ada programming. (Similarly Ada spared us from needing an equivalent C Lint program to clean up code). >From "Ada as a Second Language" (2nd ed.) by Norman Cohen, ISBN 0-07-011607-5, McGraw-Hill: Section 8.2 p. 328 " The rules of Ada also allow "garbage collection"---automatic deallocation of dynamically allocated objects that are no longer pointed to by any other variables in the program, that are pointed to only by other dynamically allocated objects that are themselves no longer pointed to, and so forth. Such objects are said to be unreachable because there is no way to refer to them. [...] Some implementations of garbage collection continually slow down a program's ordinary computations; other implementations are not invoked until the program needs more storage, at which point all ordinary computations are momentarily halted while the garbage collector does its work. Either behavior is usually unacceptable in a real-time program. Therefore, Ada provides a pragma allowing you to ensure---in the unlikely event that your compiler supports garbage collection---that the garbage collector will not get invoked. The pragma Controlled ( access-type-name ); ensures that objects created by allocators for the named access type will not be garbage-collected. [...] There are many possible data structures and algorithms for managing the storage to be used for dynamic allocation and deallocation. One scheme may use up more space but take less time than another. The performance of some schemes may depend on the patterns of allocations and deallocations requested by your program. [...] But certain highly tuned programs may require special storage-management schemes tailored to the application. Section 19.5.1 will describe advanced mechanisms for specifying programmer-defined subprograms to be invoked by the evaluation of an allocator or a call on an instance of Ada.Unchecked_Deallocation. " -- John Howard -- Team Ada Team OS/2 --