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: bobduff@world.std.com (Robert A Duff) Subject: Re: Garbage Collection in Ada Date: 1996/10/14 Message-ID: X-Deja-AN: 189339266 references: <01bbb910$f1e73f60$829d6482@joy.ericsson.se> <199610132138291604607@dialup101-6-14.swipnet.se> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-10-14T00:00:00+00:00 List-Id: In article <199610132138291604607@dialup101-6-14.swipnet.se>, Lars Farm wrote: >Jonas Nygren wrote: > >> Recently there has been some topics that has touched on the issue of >> Garbage Collection, GC, in Ada. I peronally think it would be great to >> have GC in Ada and I am not sure why there is such resistance. > >Cultural bias or even prejudice is the most likely reason IMHO. Not >technical reasons. On and off the same discussion comes up in the C++ >community. Those that control C++ and those that control Ada simply >don't want GC :-( Being in the C++ world, I can't speak about >technicalities in Ada, but the arguments from the GC detractors among >C++ and Ada users appear to be similar. They say that no one wants GC. Well, "GC is good" and "no one wants GC" are not contradictory. (Assuming you take "no one wants GC" to be just an exagerated way of saying "not enough people want GC".) After all, in the PC world, I've read several articles about how multi-tasking is useless from the user's point of view. Kind of like a driver who knows nothing about how cars work, saying "Pistons are useless". ;-) IMHO, the cultural bias against GC is fueled in part by GC zealots who claim that GC does more than it really does. I know for a fact that I myself took many years to come to the opinion that GC is good for many (most?) programs, primarily because I didn't believe the zealous claims. And I *still* hold the opinion that GC is bad for some kinds of programs. >They say that GC is slow and that there are certain constructs in the >languages that make GC impossible or useless or that this or that >particular implementation of GC cant work and therefor any >implementation of GC is out of the question. This may be true of C++, but GC is quite compatible with Ada. >One particularly annoying argument goes like: "Memory is a resource, GC >manages memory so GC should be able to manage any resource. Since it >only manages memory it fails and is useless". This is nonsense because >managing memory is a particularly nasty problem and GC solves it almost >completely. That it leaves all other problems is an advantage, not a >liability. This is usually called good design, high coherence. GC does >one thing, one thing only and does it very well. This might be a symptom of what I was saying above -- if zealots claim that GC solves all the worlds problems, then it's easy to disprove that, and therefore write it off. >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. I don't understand what you mean by "ordinary allocators". What you say is certainly true of off-the-shelf general-purpose allocators, but it's easy to write an allocator with predictable timing if the objects are all of the same size, and that's exactly what some real-time programs do. And some real-time programs avoid using the heap at all, so of course GC is just a waste of implementer's time, for *those* programs. I know about Henry Baker's papers on real-time GC, but I remain somewhat skeptical. (I suspect most real-time programmers have never heard of real-time GC, and would scoff at it.) >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 Ada, this is true. In C and C++, I don't believe it -- I've seen lots of code that uses pointers/arrays in a GC-unsafe way. Perhaps it doesn't *need* to, but it does. >... 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. > >For Ada one of the technical obstacles mentioned is something called >"virtual origin". A block of memory held by a biased pointer that points >at some distance outside the block. Presumably a compiler optimizer >trick allowed by the language. That seems like a harder problem than the >problems in C++ and that in turn is ironic. 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++. To me, this sounds backwards. Virtual origins are a useful optimization, and if they break your GC, then your GC is broken. It's not the compiler's fault. It's certainly possible to implement a GC that works in the presence of this optimization. And there are many other examples of optimizations that will break the typical "conservative" GC, but a proper non-conservative GC can work properly. The term "conservative" is bogus, IMHO, since if you do certain things in your code, or your friendly compiler-writer does certain optimizations, it makes the GC *liberal* -- that is, frees in-use data. Avoiding certain things in my code is tolerable, but it makes me nervous to think that the new version of a compiler, with a smarter optimizer, might come along and break the conservative GC. >None of the arguments above has convinced me that GC is a bad thing and >I'm perfectly willing to avoid some weird C++ language constructs if it >gives me GC. It would be interesting to hear what other arguments the >Ada vendors could come up with. No, Ada vendors are not typically part of the anti-GC crowd. The vendors tend to say, "GC is somewhat hard to implement, and we don't have a lot of customers asking for it." It's kind of unfortunate, because there are probably quite a few people who *would* use Ada, if Ada compilers with GC were commonly available. Probably this situation will change in the future. >... It would be even more interesting if >they could say something like "Sure GC is possible, but you'd have to >sacrifice language feature this or that" and then leave the choice up to >the users. There's really not much you have to give up, unless you're dealing with a so-called conservative GC. By the way, the Intermetrics compiler that generates Java byte codes supports GC (the non-conservative GC supported by Java), and I believe somebody is working on a conservative GC for GNAT. - Bob