An amusing story about a practical use of the null garbage collector

Some time ago, I noted that the null garbage collector is a valid garbage collector if the amount of RAM available to the runtime is greater than the total memory requirements of the program. This insight lets us make some statements about what you can assume from garbage-collected languages.

But it also can be looked at as rules for deciding when you can simply ignore the memory leaks in your program and just use a null garbage collector. Here's one developer who learned about an application of this principle:

From: (Kent Mitchell)
Subject: Re: Does memory leak?
Date: 1995/03/31

Norman H. Cohen ( 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 an 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 its target or at the end of its 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!
Comments (15)
  1. pc says:

    Calling that the “null” garbage collector seems like not quite the right term. Maybe it’s more of a “stop-the-world” garbage collector.

    1. Scarlet Manuka says:

      Not so much a garbage collector as a garbage (and everything else) distributor… in that all your memory, in use or not, is going to be distributed over a large area.

  2. Brian says:

    I haven’t written embedded software in about 30 years (back then, it was for a Z-80). However, back in those days we did things differently.
    In the “initialize” part of the program, we would allocate all the memory the program would ever need (and, in debug builds, we put canaries on the edges of all those allocated blocks). Once the program was initialized, it ran without every allocating another byte. Pretty much the opposite of a modern garbage collected app.

    1. nathan_works says:

      Like Brian, in the embedded things I worked on you did not malloc() anything. Global or stack allocations as needed. (“new() you ask ? what’s that ? You know what that is ? That is an extra 200 MB of libraries. We ain’t got no space for new()”

  3. DWalker07 says:

    It’s all about knowing your run-time environment!

  4. Steve Friedl says:

    “Halt and Catch Fire” really is the ultimate null garbage collector.

  5. Pierre B. says:

    Little known air-fight technique, from a Russian classified engagement document:

    “When the missile heads your way, turn on your afterburner. After 5 seconds, it runs of of heap space and falls from the sky.”

  6. Martin Bonner says:

    What scares me, is that this is exactly the sort of analysis the designers of the Ariane 4 software did, when they decided that overflow would not be a problem. When the software was reused on the Ariane 5, they had forgotten they needed to redo that analysis, so they didn’t. **BOOM!**

    1. Jonathan says:

      Not a garbage collector, but a another case where the assumption about use case that was later invalidated was the Patriot missile batteries back during the gulf war. They stored the time update in a 24 bit register and truncated into it in such a way that the time error accumulated; so the longer the system had been up the further off it was, and it used that value in intercept calculations in such a way as to cause misses when the error got too large.

      Patriots being mobile tactical surface to air missiles the batteries were expected to be shut down and relocated frequently (to keep up with troops or to avoid counterattack or artillery). Prolonged static use wasn’t an envisioned use case – so no need to design a system that resisted or compensated for accumulated error; you’d restart and wipe it out long before it became an issue.
      Then. come the gulf war. they ran for days on end looking for inbound Scuds and oops.

  7. 12BitSlab says:

    Does this mean that the Halting Problem has been solved?

  8. Danny says:

    Oaw..that’s..I have no words. Having worked once in embedded world and dealing with cars on that world the constraints were insane from the law point of view. Those cars were Ford and Mazda, and 99% of the code was actually there to implement the law, ass covering and whatnot from judicial point of view. This story triggered me at fundamental level, especially remembering a discussion I had with group leader at the time regarding a possible improvement I had, which made me very proud back then, where the chip load would go below 70% and the GL said: “then we can go buy a lower specs chip and the load will be bumped back at 90%, and cut some costs, right?”. You see, back then if the resulted embedded application would not be between 70% and 90% time, the micro-controller would be replaced with a better or worse version of it.

  9. dalek says:

    It ends with division by overflow (as in an undefined amount of pieces) or you could look at it as a class whose destructor always succeeds.

  10. Erik F says:

    How much environmental damage occurs when the bit bucket is blown up? Where do those bits end up? Inquiring minds want to know!

  11. Yukkuri says:

    There is a story (perhaps apocryphal) that the early designs of the gun type (“little boy”) atomic bomb gave the Manhattan project grief due to the very heavy barrel they would need to withstand the protected wear on it.

    Then they took a step back and realized that they were designing for many shots, but this gun would need to fire only once…

  12. Kevin says:

    This reminds me of the evolution of Python’s garbage collection algorithm:

    1.x: Everything is reference counted. If you leak a cycle, it leaks.
    2.x – 3.3: If you leak a cycle, and one or more of the objects involved has a finalizer, the whole cycle leaks. Non-cyclic garbage is always collected.
    3.4+: All garbage is collected (aside from some backwards-compatibility constraints for C extension modules written before 3.4 existed). Finalizers are run at most once (as an implementation detail of CPython; other implementations are allowed to call them multiple times).

    The problem with the 1.x and 2.x approaches is that under both of them, finalizers always ran reliably or not at all, which made finalization seem artificially reliable under testing. So you see people do evil things like contents = [open(path).read() for path in paths], with the files closed automatically by the finalizer. Unfortunately, this *still* works, because the reference implementation is refcounted in addition to standard garbage collection.

Comments are closed.

Skip to main content