I found this amazing entry at comp.lang.ada via Hacker News:
From: k…@… (Kent Mitchell)
Subject: Re: Does memory leak?
Date: 1995/03/31
distribution: world
…
newsgroups: comp.lang.ada
Norman H. Cohen (n…@…) wrote:
The only programs I know of with deliberate memory leaks are those whose executions are short enough, and whose target machines have enough virtual memory space, that running out of memory is not a concern.
(This class of programs includes many student programming exercises and some simple applets and utilities; it includes few if any embedded or safety-critical programs.)
This sparked and interesting memory for me. I was once working with a customer who was producing on-board software for a missile. In my analysis of the code, I pointed out that they had a number of problems with storage leaks. Imagine my surprise when the customers chief software engineer said “Of course it leaks”. He went on to point out that they had calculated the amount of memory the application would leak in the total possible flight time for the missile and then doubled that number. They added this much additional memory to the hardware to “support” the leaks. Since the missile will explode when it hits it’s target or at the end of it’s flight, the ultimate in garbage collection is performed without programmer intervention.
–
Kent Mitchell | One possible reason that things aren’t
Technical Consultant | going according to plan is …
Rational Software Corporation | that there never was a plan!
Similar, but not digital. As I understand it on the Standard Missile, during flight any hydraulic fluid that is used is not recycled, it’s simply ejected during flight. Using the same arguments, there’s no reason to recycle and reuse the fluid when the overall lifetime of the missile is so short. Whatever engineering and equipment is necessary, isn’t worth it in this scenario. I guess extra hydraulic fluid is better than a more complicated system plus whatever weight it adds to the missile.
Similarly, on large rockets, the motors do not produce enough thrust, inittially, to lift the vehicle due to its weight.
But that ok, because when the motors light and start dumping vast amounts of fuel, the rocket starts to get lighter. At some point (reasonably quickly), the thrust overcomes the new, lighter rocket, and it moves. This lessens the initial acceleration impulse. The acceleration is no longer dependent on the thrust (which is enormous), but the ratio of the thrust to the weight of the vehicle. With the vehicle too heavy, it starts at 0 acceleration, even though the motors are going full throttle. Now the acceleration vector is based on how fast the vehicle can burn through its fuel, vs the raw output of the motors.
As long as the rocket launches before the motors burn it up on the pad, it’s all good.
I’ve a dim recollection of a situation in the past - perhaps on SunOS - where a large process could finish quicker if it killed itself instead of calling exit. There’s no point carefully deallocating everything if you’ve nothing more to do! (It’s just possible this was on Domain/OS in which case it was even longer ago.)
I think, this is also GC Perl-style.
(I actually don’t know, whether a process just kills itself or does more of a cleanup, but the former may be well the case in light of a Perl process being much of a shell. But I do remember the docs pointing out that there’s no particular point in implementing any destructors and that Perl doesn’t do GC, but just lets go of any allocated resources as a process terminates.)
Most systems with GC make no guarantees that “finalizers” will actually execute. A finalizer is a piece of code that’s run just before something is actually GC’d, but they’re never guaranteed to run for all of the reasons mentioned: system shutdown, system abort, but also, during the duration of a program, they simply may not be GC’d. This is why finalizers tend to not be a reliable mechanic for managing scarce resources.