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,e80a1497a689d8a5 X-Google-Attributes: gid103376,public From: Tucker Taft Subject: Re: Ammo-zilla Date: 1999/10/29 Message-ID: <3819B30B.516727C1@averstar.com>#1/1 X-Deja-AN: 542073396 Content-Transfer-Encoding: 7bit Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.burl.averstar.com References: <38120FAF.945ADD7D@hso.link.com> <7uutgd$87h$1@nnrp1.deja.com> <19991024.18033546@db3.max5.com> <38189268.43EB150F@mail.earthlink.net> <86ogdjtdwz.fsf@ppp-115-70.villette.club-internet.fr> <7vadsp$8q61@news.cis.okstate.edu> <1999Oct28.221910.1@eisner> <7vb3c4$8a21@news.cis.okstate.edu> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: AverStar (formerly Intermetrics) Burlington, MA USA Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-10-29T00:00:00+00:00 List-Id: David Starner wrote: > ... > As a side question: Ada 95's designers must have been familiar with Modula 3's > support of garbage collection while letting real time stuff keep track of > its own memory. What stopped them from adopting something like that for > Ada 95? Another good question... First, I agree with you that you can't really depend on garbage collection in a langauge until essentially all implementations provide it, so saying that it is allowed is sort of irrelevant. On the other hand, if you happen to be focusing on the Ada->JVM target, you can presume that all implementations (there are only 2 so far) will provide garbage collection, as it is built in to the JVM. One choice you have is to use the third-party "conservative" garbage collectors, essentially the same choice as provided by C++. These work with the same caveats in both Ada and C++. As far as why we didn't have garbage collection for some kinds of memory, and not for others, it was a question of demand, and perceived cost/benefit ratio for a language focused on "critical" systems. Prior to the arrival of Java, garbage collection was definitely not "mainstream." In the long run, making garbage collection a "mainstream" language feature may be Java's biggest contribution to the history of programming language usage. On the other hand, our local experience with Java and garbage collection is that the value it provides is greatest during prototyping. Once you get serious about scalability and performance, you have to go back to being extremely careful about unnecessary object creation, and about effectively "freeing" objects (by nulling-out pointers) as soon as possible. It is true that you don't have to worry about freeing memory too soon, but you do have to worry about making sure that objects do not remain unintentionally "reachable." Personally, I think garbage collection is a way-station toward some better as-yet-to-be-determined approach. There are some interesting languages and languge-theories out there that are based on single-point-of- access to objects. The language Hermes (nee' "Nil") by Strom et al had this as their fundamental storage management approach. It makes a lot of sense for distributed and/or multi-threaded computing, because it addresses storage management, synchronized access, and distribution in one nice package. Getting back to your original question about why not have garbage collection for some kinds of objects, and not for others. Once storage management gets this sophisticated, it begins to become more of a "programming problem" than a "language problem." There were bad experiences with Ada 83 when the language tried to get too high-level, to the point where the programmer had no intuition about the implementation model of the language feature, and implementations varied widely in the relative performance characteristics of different features. Ideally, the ability to do garbage collection could be handed over to the programmer in a way that allowed them to carve up the overall heap space into separate pools with different management approaches in each, and then the programmer, or some third party, would provide managers for these various spaces. We took a baby-step in that direction with the Storage_Pool attribute, but we didn't feel confident in doing too much invention in this area. Luckily, the Ada language design process is much more dynamic now than it was in the period from 1983 to 1990, so as good ideas are proposed and prototyped (perhaps using GNAT), there is a very real chance that they will evolve into parts of the standard. I know that some users of Ada 95 have built quite elaborate garbage collectors on top of the Storage_Pool facility (e.g. the garbage collection built into the ORBExpress/Ada product built by Objective Interface Systems). Perhaps their experience will enable us to develop a more complete user-controlled garbage collection capability for future standardization. For this to be most useful, there *will* need to be a garbage-collecting storage pool manager defined as part of the standard, so it may be used in all Ada code, not just in code written for a compiler that happens to include one. Certainly a key requirement will be that this garbage-collecting manager is not forced on all Ada users, and that it is replacable by the programmer or a third party without having to go back to the compiler vendor, and without having to dismember the rest of the run-time system. It would not be acceptable to follow the Java approach, where garbage collection is an integral part of the JVM, with no well defined way to avoid it or replace it without essentially rewriting the JVM. > -- > David Starner - dstarner98@aasaa.ofe.org -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA