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,3498dd887729ed19 X-Google-Attributes: gid103376,public From: lars.farm@ite.mh.se (Lars Farm) Subject: Re: Garbage Collection in Ada Date: 1996/10/13 Message-ID: <199610132138291604607@dialup101-6-14.swipnet.se>#1/1 X-Deja-AN: 189221304 references: <01bbb910$f1e73f60$829d6482@joy.ericsson.se> organization: pv nntp-posting-user: s-49817 newsgroups: comp.lang.ada Date: 1996-10-13T00:00:00+00:00 List-Id: 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. 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. 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. 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. 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++. 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. 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. -- Lars Farm, lars.farm@ite.mh.se