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,fd63afa4dc364b7e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-03-16 13:28:31 PST Newsgroups: comp.lang.ada Path: supernews.google.com!sn-xit-02!supernews.com!news.gv.tsc.tdk.com!news.iac.net!news-out.cwix.com!newsfeed.cwix.com!howland.erols.net!portc.blue.aol.com.MISMATCH!portc03.blue.aol.com!uunet!dca.uu.net!ash.uu.net!world!bobduff From: Robert A Duff Subject: Re: Better support for garbage collection Sender: bobduff@world.std.com (Robert A Duff) Message-ID: Date: Fri, 16 Mar 2001 16:26:49 GMT References: <98m938$2iod0$1@ID-25716.news.dfncis.de> <98pgs1$32up7$1@ID-25716.news.dfncis.de> Organization: The World Public Access UNIX, Brookline, MA X-Newsreader: Gnus v5.3/Emacs 19.34 Xref: supernews.google.com comp.lang.ada:5752 Date: 2001-03-16T16:26:49+00:00 List-Id: "Nick Roberts" writes: > "Robert A Duff" wrote: > > Robert Dewar would argue that it's because nobody wants it (at least, > > nobody wants it enough to pay for it). A more pessimistic take on this > > is that all the folks who understand the glorious benefits of GC have > > long since abandoned Ada in favor of "better" languages. > > Don't you think it significant that so many other languages do incorporate > GC? The most popular ones don't, though. But I don't think popularity implies goodness... > I must say, I get the impression, although I don't understand it, that > Robert, perhaps yourself, and a few others have an antipathy towards GC > which is not entirely objective or rational. It is not a sound argument to > say "Well, I don't want it, so nobody else does either." Well, I said in my previous post, "I too think it would be cool if GC for Ada were widely available" -- I don't see how you can interpret that as "antipathy". I think GC is a good idea in many situations. I also think other memory management strategies are appropriate in other situations. Robert also likes garbage collection, I believe. But Robert and I are both in the business of making Ada compilers, and we don't see a lot of demand for GC. Tucker, by the way, is rather down on GC. He thinks there must be some better memory management approach yet to be invented (and we've discussed some of his ideas along those lines). We'll see. > The slowness of a GC environment can always be largely overcome, by using > techniques such a B-Tree's lumping data into blocks. The advantages of > having GC, especially from the point of view of software reliability, can be > very great. It is typical these days to hear advice such as "the best way to > maintain the efficiency of NT [the operating system] is to reboot it every > day". It is typical of application programs to leak memory like a sieve. I > suspect there are many Ada programs that commit the same sin, principally > because they do not have GC. Memory leaks are indeed annoying. GC can help a lot. But it doesn't completely cure the problem -- you still have to use your brain when writing programs. I've seen memory leaks in GC'ed programs. I've also seen GC'ed programs that are horribly slow because of overreliance on GC. It's easy to get sloppy. > The difficult will take an hour. The impossible will take a little longer! > I'll try to cook up an example. Or maybe just outline it. I already understand what you're getting at much better than I did at first. > I didn't mean to give the impression that what I described is how many or > most garbage collectors work. All I meant was that what I described is how a > garbage collector would have to work to be compatible with my proposal. > > > subtype Disposability_Level is > > > Integer range 0..implementation_defined; > > > > Why "implementation_defined"? It seems like a useless non-portability. > > Okay, what figure do you suggest? 100. > > > and an attribute Disposability, which applies to any pool-specific > access > > > type, and has a static value of subtype Disposability_Level. > > > > This is the first attribute of a non-scalar type that is static. > > Is this a problem? A little bit. Think about how you would re-word the rules for static expressions. They're complicated enough as it is. > > >... A value other > > > than 0 indicates that objects referenced by access values of this access > > > type are disposable. > > > > It makes no sense to talk about the objects "referenced by access values > > of this access type", because there can be many access values, of many > > different types, all pointing to the same object. Perhaps you mean > > "allocated by allocators for this access type"? > > What I said is perfectly logical, apart from using the wrong word ... > > > (BTW, "designated" is the Ada jargon -- not "referenced".) > > ... Whoops! (Pardon me :-) ... > > I really meant "all objects designated by access values of this type". It > doesn't matter if some of those objects (or any of their subcomponents) are > designated by access values of other types. > > Perhaps I should add a specific note that if an object is designated by > several access values, of access types whose disposability levels are > different (but non-zero), the highest of those disposability levels applies. Well, you need to say *something* -- the original proposal says that an object can have multiple disposability levels, which doesn't make sense (I still claim). Don't you think it's simpler to define the level in terms of the type used for allocation, so levels aren't changing willy nilly as access type conversions occur? > The question that remains, to my mind, of what action for me to take next > reduces to three basic possibilities: (a) make the amendments suggested > herein, and send the proposal to the ARG (which e-mail address would be > best?); (b) continue discussing the proposal in this newsgroup (or > elsewhere?), and submit it later, after perhaps much refinement; (c) forget > it. I guess it depends on how disappointed you'll be if your work is wasted. I don't think your proposal has a very good chance with the ARG. Another possibility is (d) get the sources of GNAT, implement garbage collection (either using the scheme in your proposal, or some other method). Then try to get ACT to install your changes into the standard version of the sources. Maybe if GC were available, folks would use it, and other compiler writers would have incentive to implement it. - Bob