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/14 Message-ID: <19961014235451303023@dialup118-1-7.swipnet.se>#1/1 X-Deja-AN: 189428154 references: <01bbb910$f1e73f60$829d6482@joy.ericsson.se> <199610132138291604607@dialup101-6-14.swipnet.se> organization: pv nntp-posting-user: s-49817 newsgroups: comp.lang.ada Date: 1996-10-14T00:00:00+00:00 List-Id: Robert A Duff wrote: > (Assuming you take "no one wants GC" to be just an exagerated way of > saying "not enough people want GC".) Yes. > IMHO, the cultural bias against GC is fueled in part by GC zealots who > claim that GC does more than it really does. Yes, I hope I haven't added to that. > And I *still* hold the opinion that GC is bad for some kinds of > programs. I don't think of GC as a Silver Bullet, just a very useful tool. > >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. For Ada I was thinking of virtual origins and conservative collectors, but I realise there are other algorithms. For C++ I think the only reasonable alternative is a conservative collector and figured the same was true for Ada. OTOH I also disclaimed any expertise of Ada so perhaps my error can be forgiven? > >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. Yes. > >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, An ordinary allocator would be the one prescribed in the language spec (operator new in C++ or its equivalent in Ada). No more suited for realtime stuff than a collecting allocator. > 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. This is what I had in mind for "manually take over memory management". Such allocators are staight forward to write in C++ and I assume in Ada too. > 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. There are legal things that can break a conservative collector, but they are few. I've seen lots of illegal code in C or C++ that happens to work in this or that particular implementation. What can I say. Broken code is broken. This is no argument against GC. The next version of the standard operator new might break such code too or a new (legal) compiler optimization or... > >One would have thought that the stricter > >Ada would be easier to adapt to GC than the "sloppy" C++. This is probably saying more about my knowledge of Ada than anything else... (see above) > To me, this sounds backwards. Virtual origins are a useful > optimization, and if they break your GC, then your GC is broken. No, I didn't claim that Boehms collector worked in Ada. I said it works nicely in C++ and it does! The Boehm GC is written for for C and C++ where such techniques are forbidden. A pointer can be NULL, can point at or into an object or at the imaginary element directly after the last element of an array. Anything else is illegal. So virtual origins are definitely illegal in C++ and therefor not an issue for Boehms collector used in C or C++. Boehms collector correctly handles the legal cases, but AFAIK not pointers pointing at other seemingly unrelated offsets of the block. Therefor Boehms GC isn't broken because of virtual origins, but virtual origins prevents the use of that collector in Ada. -- Lars Farm, lars.farm@ite.mh.se