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,3ccb707f4c91a5f2 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Date: 1996/10/12 Message-ID: #1/1 X-Deja-AN: 189056605 references: <325BC3B3.41C6@hso.link.com> <325D7F9B.2A8B@gte.net> <325FF8D0.6660@io.com> organization: New York University newsgroups: comp.lang.ada Date: 1996-10-12T00:00:00+00:00 List-Id: Dave Jones said "BTW: I have heard that, for C++, someone has written a garbage collector which can be added to almost any C++ program. Would it be any more difficult to do the same thing for Ada95? I would certainly look forward to such a product. IMHO, memory management is something that a machine should do (whenever possible) -- freeing up humans to do things which require more skill and creativity." Well sentences that start "I have heard that" most often end with something wrong at worst and misleading at best :-) In fact it is impossible to provide a general garbage collector for typical implementations of C++ (there simply is not enough runtime information around). What you have heard about is conservative garbage collectors that make the basic assumption that a block is dead if there is no word in memory that *could* be a pointer to or into the block. This assumption is (a) inadequate, as someone pointed out here recently, the use of virtual origins can upset this assumption and result in blocks being collected which are in use and (b) too strong, blocks that are not in use can be held by integers that accidentally mimic pointers. That being said, this kind of conservative garbage collection can work quite well in some applications, and is of course equally applicable to Ada 95 as it is to C++. By the way, a little history. Ada was originally designed with the expectation that garbage collection would be available in typical implementations. Look at the description of pragma Controlled to get a feel for this. However, almost no implementations provided GC. During the Ada 95 development effort I made the suggestion that we at least "require" GC for the information systems annex, but other people found this laughably unrealistic, and there was zero support inside and outside the Ada 9X design group, DR's and ISO for such a step. Note of course that Ada 95 certainly *permits* garbage collection, and the design was carefully carried out to ensure that this is the case, but there was no sympathy for trying to require it (the requirement of course would be a somewhat wooly one, since GC is not something you can specify formally, but there are plenty of other wooly requirements like this already. It is possible that Java will reorient people's thinking regarding garbage collection. However, there are some things to bear in mind. 1. There are significant efficiency issues that have to be faced. Of course in an interpretive environment like JVM, these are completely swalled up by the interpretive overhead in any case. 2. The mixture of GC with low level features like pointer mucking is a very worrisome one, because anything that upsets the integrity of the pointer structures can cause unimaginable chaos in a garbage collected environment. (bitter experience debugging SPITBOL compilers remembered here :-) 3. The mixture of GC with real time continues to worry a lot of people. This statement will of course bring a certain advocate of real time GC out of his silence, but the fact is that Henry Baker has not managed to convince the world on this point yet, despite a lot of effort on his part. 4. There are some worrisome interactions between garbage collection and finalization that have to be sorted out, and between garbage collection and other features, such as ATC.