
The Ultimate in Garbage Collection (1995) - tjalfi
https://groups.google.com/forum/message/raw?msg=comp.lang.ada/E9bNCvDQ12k/1tezW24ZxdAJ
======
aag
This reminds me of a demo a friend once gave me on a Symbolics Lisp Machine.
He turned the garbage collector off, then ran a program that allocated memory
like mad. After a while, a message popped up saying something like "you are
about to run out of memory. Activate GC?" He declined, and the program
continued running. After a bit more time, another message popped up saying
"you are about to run out of memory, and if you don't start GC now, there will
not be enough room to run it when you do. Activate GC?" Again, he declined.
After more time, another message popped up saying "you have run out of memory,
and it is not possible to start GC now. Would you like to attach an external
disk drive?" The idea was that the external drive could serve as additional
memory either to continue running without GC or as scratch memory for the GC.
I've always found that impressive.

~~~
lispm
On a Symbolics you can add swap space files when there is an out-of-memory
error. If you find some disk space somewhere (possibly after deleting some
unused junk), create a swap file, add it and continue.

------
ScottBurson
Reminds me of a comment I once read by someone who had created instrumentation
for underground nuclear tests. They had, if memory serves, something like 5
milliseconds between initial detonation and the point where the equipment
would be destroyed. "Now _that 's_ a hard-real-time constraint," they said.

~~~
dkarl
That reminds me of a wonderful, surely apocryphal story I was told by an old
boss who went to grad school at Cornell in the 1970s.

The story goes that there was some talk about the Cornell computer science
department doing nothing but ivory tower mathematics that was useless to
people who actually, you know, _used_ computers in their research — such as
the physicists programming data collection controllers for the particle
accelerator. This concerned the head of the CS department as the harsh talk
was creating a little bit of mutual resentment, not to mention an image
problem for his department. He resolved to help bridge the theory-practice
divide and show the non-CS computer users on campus that his theoreticians
were doing worthwhile work.

So one day a CS professor schedules an intro talk on formal methods, nothing
but basic mathematical maturity required, and the department chair seizes his
chance! He invites a bunch of the particle accelerator folks to the talk,
telling them formal methods will help them write more reliable code so they
don't waste their time re-running experiments because of data collection
errors. The physicist roll their eyes and shake their heads, but when the hour
rolls around, some of them are present at the back of the room.

The professor gives a pretty standard formal methods talk, introducing a
hypothetical (of course) programming language, showing how mathematical
propositions about a program can be formulated and proved, defining a simple
mathematical problem involving coloring a graph, and demonstrating a proof of
correctness for a solution in the hypothetical programming language.

The physicists are impressed but a little wary. After all, their problems are
mostly with performance rather than the kind of correctness addressed in the
lecture. One of them raises his hand. "Is it possible, using these methods, to
bound the number of times each subroutine is called?"

The CS professor, who has been instructed to engage the physicists and be very
accommodating and diplomatic, is delighted by the question. "Yes! We can
formulate an answer in terms of the input and prove it by recursion." He turns
to the blackboard and formulates the statement and a proof. "There we have it.
And I must congratulate you on such an interesting theoretical question."

"I'm actually getting at something very practical," the physicist replies.
"Namely, performance. This program isn't worth much if it takes too long to
solve the problem."

The CS professor narrows his brow and says, "Hmmm, I see. Yes, that can be a
concern sometimes. Well, I hope these ideas have put all your fears to rest on
that topic!"

"I'm afraid it's not so obvious to me," the physicist says.

"Well, we've proved the program terminates, and that when it terminates, it
produces a correct solution. We can prove various other properties such as
which solution will be produced if there are multiple correct solutions."

"There are other properties of the program that are of interesting as well.
Can you prove whether runs within certain memory bounds?"

The CS professor starts to look profoundly bored. "Yes, these methods could be
used for that. Space and time bounds can be very interesting."

"Wonderful, wonderful! So if I need to be sure that this code runs in, say, 50
milliseconds...."

"Runs? In 50 milliseconds?"

"Yes, supposing I want to run it hundreds of times per second, I..."

"Hold on a second, I don't think you've got the point after all. You _never_
have to run the program. That is why" (the CS professor gestures at the
chalkboard) "we have done all of this work! You never have to run it, because
_you already know it produces the correct answer!_ "

~~~
sillysaurus3
Alternative punchline: "Hold on a second, we can't run our program. We've
solved the halting problem, so we can't actually run it without violating our
assumptions."

(This story was awesome, by the way.)

------
gumby
That's funny because I had the opposite experience: had a sales call at
unnamed aerospace company. They were interested in Cygnus's free embedded OS
(now eCos). Why?

Well, the O/S they were using was licensed "per device". When they deployed,
they had one device, but during operation they would have more than one.

They didn't want to get in trouble by wasting the government's money on
unnecessary licenses, yet they didn't want to get the government in trouble
(because they would get in trouble) for using unlicensed software. A free
software (i.e. open source) alternative would solve the problem.

I pretty much immediately realized that they were building MIRV, and at some
point suggested that perhaps it would not be a problem. They didn't seem
particularly amused by this point, and after the visit wow, our sales person
was pissed!

And indeed they didn't follow up -- I imagine they just struck a deal with
their existing vendor who will go unnamed.

------
brandonbloom
Fun story!

The same idea applies more generally as well with so-called "region-based"
memory allocation. A sub-process allocates incrementally from a pool, then
when that process ends, the entire pool is freed at once. Optionally, garbage
collection or other memory freeing can happen during the process.
Additionally, regions can be arranged hierarchically for processes and sub-
proesses, recursively.

The easiest way to take advantage of this is, if for example, you have a
short-lived command line tool. Maybe you don't even bother to free any memory
at all, as the operating system is going to free it all for you when you're
done anyway.

~~~
frutiger
The (new in c++17) polymorphic allocators allow this, as you can instantiate a
monotonic_memory_resource, and use it to construct all the regular C++
containers with it for the duration of the remaining scope - this works just
fine as long as no memory is needed outside of that scope.

~~~
blt
That's cool. Do the C++ containers now contain a pointer to the
monotonic_memory_resource, or is there some magic that lets the local calls to
push_back, etc., know about the allocator in that local scope?

When I needed many arena-backed vectors, I wrote an ArenaVec with an API that
takes a pointer to the arena in all methods that can allocate, keeping the
memory size down.

~~~
frutiger
Yes they do, but since c++11, allocators were not required to be stateless. As
a result, containers (or any allocator-aware objects) have needed to hold an
instance of the allocator.

------
ec109685
High frequency traders are able to avoid JVM garbage collection during the
trading day by just holding off until the market is closed.

~~~
Retr0spectrum
Do you have a source for that? It's an interesting idea.

~~~
ramchip
I worked at a bank and saw that pattern used in market connection middleware
as well. It's really common, but since that stuff is all closed source it's
hard to point to a concrete example.

(The thing was also optimized to reuse objects to allocate as little as
possible... but a writeup from that team on an internal website said,
basically, that Java GC was so efficient nowadays that it may not have been
worth the extra maintenance effort and potential for bugs, in retrospect)

------
dboreham
Long time ago I shared an office with a guy who had designed missiles. He had
a similar tale but relating to cooling and thermal management : the guidance
system was designed to be inadequately cooled, in that if it ran for long
enough it would overheat. However that time was well in excess of its maximum
flight time..

------
convolvatron
i have a similar apocryphal story from the dod. there was an image processing
element for a missile targeting system that was a 3d stack of silicon. it ran
at an amazingly large number of ops per second, but only for a few seconds,
because there was no way to get the heat out of the stack.

which was (apparently) fine, but it made testing very expensive

~~~
i336_
What year (or decade) was this, and what ballpark of OPS did it run at?

That's amazing.

Was the device able to be downclocked for certain tests?

~~~
convolvatron
this was early 90s, i don't remember the ops, but i remember it being
comparable in magnitude to the CM-2, which was where we were running some kind
of simulation (in a skif, so everything I heard was very second hand)

------
glangdale
OK, so they apparently understood the software well enough to predict to
within a factor of 2 the magnitude of the leaks, but not well enough to fix
the leaks. I suppose that's possible, but a little unnerving.

~~~
barrkel
Writing code that explicitly manages memory has costs too; there's a risk of
use after free, or double free. If you don't free you can't have these
specific problems. And if you accept this, it opens the way for GC style
programming, for some parts of the app at least.

------
sp332
After all, garbage collection is just emulating having an infinite amount of
memory. If you have enough RAM, no need to pretend :)

------
alexeiz
Small utilities with limited lifetime can be written in the same manner. You
just allocate memory and never free it. When the utility finishes its job, it
just terminates freeing all the memory it allocated in one shot.

------
rurban
Why bother with lexical or local variables at all? <satire>

With only globals used, you don't have to worry about free() at all. The OS
does it better and faster.

------
alkoumpa
So, Kim Jong-un has a memory leak problem, but that's probably good for the
rest of us..

------
mjewkes
>Norman H. Cohen (nco...@watson.ibm.com) wrote:

Anyone know what the watson group at IBM was doing in 1995?

~~~
blt
Maybe indicates the Watson Lab?

[https://www.research.ibm.com/labs/watson/](https://www.research.ibm.com/labs/watson/)

------
pizlonator
That really blows my garbage collectors away.

------
agumonkey
Information is Energy

Rolf Landauer

------
amygdyl
So long as that isn't somehow still in the guidance modules of the latest
Tomahawks that can be told to circle / reposition / group awaiting the final
target telemetry!

