Re: Ada 0Y plans for garbage collection?

[Jeffrey Carter <spam@spam.com>]

Jano wrote:
> 
> I'm very happy using Ada but when one needs to use heap-allocated 
> objects and unchecked deallocation it becomes tiresome rapidly, and that 
> leaving aside memory leaks.
> 
> After some time using Java/.NET or other managed languages this becomes 
> rapidly a great pain if you are in the less real time constrained 
> environments. I was wondering if there are plans to add a standard 
> garbage collection mechanism to the next revision of Ada. Seeing where 
> are going things this seems almost a necessity if Ada has to keep 
> current with times.
> 
> Can someone comment on this? Are there plans to mandate it in 0Y? As a 
> side note, is out there any public implementation of GC for Ada 95?

Ada was designed for mission-critical real-time embedded systems. It is 
the only widely used language designed for real-time embedded systems. 
That's why it has features such as fixed-point types. In other 
languages, such things have to be simulated manually, with the inherent 
increase in errors that entails.

Languages with mandatory GC are generally not used in such systems, and 
are unlikely to be used in such systems in the near future. Therefore, 
the standard will not mandate GC.

The standard could allow GC, so compilers for real-time systems can not 
provide it, but compilers for other systems can. In fact, the standard 
already does allow GC. That you cannot obtain a compiler with GC 
indicates the importance paying customers put on this feature.

For an example of the "Ada way" of addressing memory management, see the 
unbounded, unprotected data-structure components of the PragmAda 
Reusable Components:

http://home.earthlink.net/~jrcarter010/pragmarc.htm

The implementations of these perform manual allocation and deallocation, 
but the client need never concern himself with it. A person, such as 
you, developing systems where memory management is acceptable, can use 
such components and pretend that the language has GC; those developing 
real-time software can avoid such components. If you need to move your 
software to another compiler, you need not limit your compiler selection 
to those that provide GC.

The need for explicit heap allocation is much rarer in Ada than in 
lesser languages. If you are using heap allocation for anything other 
than dynamic data structures, the odds are very good that you can do the 
same thing without heap allocation.

So, if you are a software engineer, memory management is isolated in a 
few well defined places in your software, and the bulk of your 
development effort can ignore memory management issues. If there are 
problems with the memory management, they are easy to find and correct. 
If, on the other hand, you are a coder and sprinkle allocations and 
deallocations throughout your system, then you get what you deserve.

The best thing you could do if you want to demonstrate the importance of 
GC in Ada is to modify GNAT to include GC. If there is really an 
incipient demand for GC, then your version would become widely used, and 
your changes would be incorporated into the mainstream versions of GNAT. 
If not, you would still have a version with GC for your personal efforts.

-- 
Jeff Carter
"Nobody expects the Spanish Inquisition!"
Monty Python's Flying Circus
22