From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 21 Apr 92 23:48:36 GMT From: eachus@mitre-bedford.arpa (Robert I. Eachus) Subject: Re: Garbage collection? Message-ID: List-Id: In article <1992Apr21.160955.2523@titan.ksc.nasa.gov> mcroberts@titan.ksc.nasa. gov writes: > I'm curious as to the state of the art in automated garbage > collection. No Ada compiler I know of does complete garbage collection. This is not because it is too hard, but because the interaction of tasking and garbage collection leads to unacceptable compromises. Since in good Ada compilers the only way to create garbage that needs collection is with access types, the general wisdom in Ada currently is that garbage collection is the resposibility of the application. I'm not happy with that, but that is the way the culture has evolved. Is this something one needs to worry about when using solid production quality Ada compilers... Yes. ...and is there any negative performance impact if you don't clean up your own garbage. Very definitely. An application which doesn't create much garbage and doesn't need to run for long periods of time can ignore the problem, but most real-time applications cannot. Fortunately, the type of garbage collection needed for most real-time applications is easy to program in Ada. However, the structures needed by many AI applications are not easy to clean up after. I've thought about writing a more-or-less portable garbage collector which would only need a few low-level routines rewritten to move it to a new environment. But it would be a lot of work, and the usual "solution" to the problem in safety critical systems instead is to just forbid access types. -- Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...