> From: Stephane Richard > > I would like to push this question to the following: > > If Ada does not have a garbage collection, does it need one? From a marketing perspective, the answer may be "yes". In the software industry overall, garbage collection is high on the "must have" list for an implementation language. Why? Because memory leaks are such a huge problem. People can argue forever about *why* memory leaks are in fact such a big problem, but in the eyes of many, managing the lifetimes of dynamically allocated objects is just one more burden from which programmers should be relieved. Are they right about this? Who cares, because right now we are talking about the marketing perspective :-) Open Source advocate Eric Raymond discusses languages in a chapter of his book in progress, "The Art of Unix Programming". The chapter is entitled "To C or not to C?" and you can read it at http://www.tuxedo.org/~esr/writings/taoup/chapter3.html. Notice the primacy given to automatic storage management as the distinguishing feature of modern languages, or languages that have a future. It practically trumps all other considerations. While I don't share this perspective, I would guess that it represents the views of many. So, if there are prospective users for whom GC is the make-or-break issue, the availability of a GC Ada implementation might help them to at least consider Ada. But there are some problems with GC as well. One problem is that you must pay something for it in system overhead. You also may have to sacrifice schedulability as well, you're willing to pay in overhead: real-time (deterministic) GC can be done, but it is slower. In the culture of IT geekdom, there is really no point in asking whether the penalties for GC are worth it, since it seems to really be the only cure for the plague of memory leaks (but not the only treatment... in recognition of the practice of periodically restarting application servers to preempt the inevitable memory-leak-induced crash, the ASP.NET platform provides for -- automatic scheduled restarts! LOL...). If you ask, "but where will the extra cycles come from?" the answer is, "From Intel." That's what we have Intel for, to crank out ever-faster machines to accomodate things like GC, right? Someone always objects with some statement like, "Oh yeah, but what about if you have, like, an airplane, and the collision-avoidance alarm is about to go off but then the system has to stop for the GC to run, and the planes crash into one another and everybody perishes in a giant fireball... "where's my Mommy, I want my Mommy!" "Sorry, son, that's the price you pay for GARBAGE COLLECTION... at least it wasn't a MEMORY LEAK..." Except we're not talking about Ada in airplanes here. It's already in airplanes. We're talking about getting Ada into the stuff people buy on Egghead.co -- oops. OK, the stuff people buy from Amazon.com and Office Depot. You know, the other 95% of software that doesn't care if the GC has to run every so often. The other problem is that there are other types of resource leaks besides memory leaks. Anything that has to be claimed and then released is a potential source of leaks: synchronization objects like mutexes, file descriptors, connections to session-based services, etc. GC doesn't cure these problems; moreover, other problems arise around the attempts to link finalization/destruction with garbage collection, which always falls short and must be shored up with hacks, and even with the hacks you end up with something that is not altogether satisfactory (e.g. Java, .NET). > or does it > just manage it's objects by their scopes and global availability? Something like that. Ada gives you kind of a cocktail of features that work together to help guard against memory leaks: 1) When you declare an access type, a storage pool is created for that access type. When the access type goes out of scope, the storage pool is freed. This ensures that a dynamically allocated object can't live longer than the access type that was used to allocated it. 2) Accessibility checks (such as for access parameters). These close some loopholes that can otherwise result in dangling pointers. 3) Controlled types, which allow you to do things like reference-counted storage management, by specifying whatever needs to be done for initialization, assignment and finalization. > > By that I am asking is would it be an actual advantage to have a garbage > collector in the language? > I would say, it would have just about as much actual "silver bullet factor" as in any other language, which in turn is less than it's made out to be. Mark Lundquist