
Intentional memory leaks - throwaway2048
https://groups.google.com/forum/message/raw?msg=comp.lang.ada/E9bNCvDQ12k/1tezW24ZxdAJ
======
tjalfi
The previous discussion is
[https://news.ycombinator.com/item?id=14233542](https://news.ycombinator.com/item?id=14233542)

------
wyldfire
It's certainly a humorous anecdote and arguably a practical solution to the
problem.

But when the mission of the code expands beyond the original use case, this
element might be lost. It's best to encode these limitations/constraints into
the design of the program, whenever possible. However for this case I cannot
imagine how to do that. When that's impossible, it's ideal to advertise these
limitations as a design feature coupled with the intended use cases. Therein
lies the only hope of discovering this before it causes problems.

These days, the vast, vast majority of our code can and should undergo unit
testing and have sanitizer tests enabled for that unit testing. We should be
extremely cautious about whitelisting/bypassing those checks (but at least
those are more explicit signals).

~~~
beached_whale
I thought I remember reading this story in the past but it also talked to the
real time requirements and there wasn't enough time to free the memory. Not
sure if I am making this up or not though. Either way, it is a factor that
cannot be ignored

------
cpeterso
I would be very surprised if embedded missile guidance software actually used
dynamic memory allocation. It would most likely use static data.

~~~
vardump
Embedded dev here.

I concur. I've heard this story a number of times, and it smells like a myth.

Well, maybe terrain recognition navigation system might need to allocate
memory. Or perhaps a data link for processing commands. But probably not.

Funny, though.

------
stcredzero
I remember this kind of approach being proposed for a game debugging tool, and
for writing games in a managed language. Basically, everything you wanted to
keep or consider permanent was marked or kept in one part of the heap, and
everything that was allocated to execute a frame was implicitly thrown away.
(One way to do it would be to compact the heap before starting the frame, then
use the top of the heap as a barrier.)

I also saw this strategy used in coursework. I was in graduate school, and I
had just done the Compiler class the previous semester. My best friends were
taking the course, and the professor had concocted a home made leak checker
and foisted it on the class, declaring that no program with leaks would be
accepted for the final project. It was only a few weeks before the end of the
term, and everyone was demoralized. Jokingly, I suggested that everyone just
make their own mechanism of the same kind, which would track allocations then
release all of the program's allocated memory just before the prof's leak
checker ran. As it turns out, the whole class ended up implementing my idea.
The test data was small enough, that everyone's compilers could afford to
simply leak memory, then release it all at the end. Problem solved.

------
ysleepy
true stop-the-world garbage collection.

~~~
saalweachter
One of the anecdotes I keep in my back pocket about how _anything_ can be
funded by the military was a compilers professor whose research on real-time
Java was funded by the military. Apparently some drone control software was
written in Java, and having your drone use stop-the-world garbage collection
is bad in a number of ways.

------
zwieback
That's humorous but sad in so many ways. Regarding the original quote - if I
see a malloc for a bunch of memory intended for the lifetime of the app and
it's at the beginning of main and then it doesn't get freed before the end of
process execution it's not really a memory leak in my book. Still, I wouldn't
write code like that.

~~~
zlynx
A variant of that I've seen in many small 1990s C apps is create a huge struct
with all the program data in it, with fixed size arrays of things big enough
so that's all you ever need, and just declare one global struct.

It was one struct instead of separate globals because of some coding style
guide at the time.

"But what if we want to use this in a library?" "Here's all the data in one
container, malloc it and use that."

I don't think many of those programs ever did end up in libraries.

~~~
tempodox
The original yacc(1) was written with fixed-size arrays for the parser tables,
statically allocated. If the parser was too complex, the arrays would blow. To
fix that, change the DEFINEs and recompile yacc.

------
theandrewbailey
Missiles: for when you really want to outsource your garbage collector.

------
nikanj
In the good old 90s, we talked about improving reboot speeds by removing
destructors from software.

I don't think the project ever got anywhere, but back then, your KDE desktop
spent a good 15-30 seconds carefully deallocating all objects.

------
amelius
If rebooting requires less than a few seconds, then I'd say they could simply
do that, even while in flight, to collect the garbage.

~~~
brokenmachine
A missile will cover a fairly large distance in a few seconds.

In fact, it's entire flight time could be a few seconds. Imagine an air-to-air
missile fired by an aircraft at another aircraft.

------
jjdredd
So adding memory was cheaper than fixing the leaks?

~~~
matte_black
way cheaper

~~~
cbhl
I imagine this depends on how many missiles are being made:

adding memory: $xxx per missile paying a software engineer to fix a memory
leak: $x,xxx,xxx

~~~
nomel
> paying a software engineer to fix a memory leak: $x,xxx,xxx

Paying the software engineer would be a fraction of the cost to fix the memory
leak in software. Recertification of the software would blow it all away.

~~~
amelius
> Recertification of the software would blow it all away.

This makes me wonder, will self-driving cars need recertification if even one
line of code is touched?

~~~
matte_black
Let me put it this way, if there is a car that doesn’t get its driving
software recertified even after one line of code is changed, you do not want
that car.

~~~
amelius
Yeah, ok, but what about the cars that drive around me?

------
vernie
Embedded, harm-critical applications.

------
anfilt
Why I normally would not reccomend such a thing. The punchline is funny.

~~~
tempodox
“the ultimate in garbage collection” had me almost fall out of my chair.
Memory management in embedded systems truly increases entropy in the universe.

------
JetSpiegel
Classic.

Missing (1995) on the title, and perhaps a [Usenet] tag?

------
Tommyatomic
Kaboom. Garbage collection handled.

