The Garbage Collection Handbook
Key topics
A humorous discussion erupted around the concept of garbage collection, sparked by a link to "The Garbage Collection Handbook," with commenters taking a detour into the absurd world of missile technology, where "garbage" is handled in creative, if not destructive, ways. Some folks joked that missiles employ a form of region-based memory allocation or generational garbage collection, albeit with a rather... explosive collection mechanism. As commenters riffed on the idea, they uncovered some fascinating examples of unorthodox "garbage collection" in action, from hydraulic fluid being spat out by Standard Missiles to fuel being used as coolant in the SR-71. The lighthearted exchange reveals how even the most unlikely domains can be connected through clever analogies.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
59m
Peak period
10
21-24h
Avg / period
4.5
Based on 54 loaded comments
Key moments
- 01Story posted
Dec 22, 2025 at 2:30 PM EST
11 days ago
Step 01 - 02First comment
Dec 22, 2025 at 3:29 PM EST
59m after posting
Step 02 - 03Peak activity
10 comments in 21-24h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 24, 2025 at 11:17 AM EST
9 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
As I heard the tale, on the Standard Missile, they don't recirculate the hydraulic fluid, they just spit out as the missile flies. It's a wonderful engineering solution.
"There was a lot we couldn't do, but we were the fastest kids on the block..."
https://www.amazon.de/-/en/Realtime-Collection-Oriented-Prog...
https://www.aicas.com/products-services/jamaicavm/
This created one of the worst performing partches of the game ever, and they had to back all the way out. They ended up just passing the separate floats around again.
My takeaway is that GC doesn't have to be slow, it just imposes a bunch of new constraints on what can be fast.
That's not a necessity, though - you can use a GC in languages that allow you to control whether structs get allocated on the heap or on the stack, and then you don't have this issue. For example, in Go, structs can be allocated on the stack and passed by value, or they can be allocated on the heap and passed by reference, and this is under the control of the application programmer [2].
[1]: Actually, according to the Java spec, Java does not have pass-by-reference, and objects are always passed by value. However, that's just strange nomenclature - in Java parlance, "object" names the reference, not the actual range of memory on the heap.
[2]: The language spec does not guarantee this, so this is technically implementation-defined behavior. But then, there's really only one implementation of the Go compiler and runtime.
That’s Java’s fault for not having value types (though that’s changing soon maybe).
Reference counting gives you eager destruction. GC cannot.
GC gives lets you have garbage cycles. RC does not.
I think a part of the GC crew reclassified RC as GC to try to gain relevance with industry types during a time when GC was not used in serious software but RC was.
But this is brain damage. You can’t take a RC C++ codebase and replace the RC with GC and expect stuff to work. You can’t take a GC’d language impl and replace the GC with RC and expect it to work. Best you could do is use RC in addition to GC so you still keep the GC semantics.
Tracing GC can't. Reference counting, which is by definition a GC can. It's like insects vs bugs.
And destructors are a specific language feature. No one says that they are a must have and if you don't have them then you can replace an RC with a tracing GC. Not that it matters, a ladybug is not the same as an ant, but they are both insects.
You are defining reference counting as being a kind of garbage collection, but you can’t point to why you are doing it.
I can point to why that definition is misleading.
Reference counting as most of the industry understands it is based on destructors. The semantics are:
- References hold a +1 on the object they point to.
- Objects that reach 0 are destructed.
- Destruction deletes the references, which then causes them to deref the pointed at object.
This is a deterministic semantics and folks who use RC rely on it.
This is nothing like garbage collection, which just gives you an allocation function and promises you that you don’t have to worry about freeing.
They are different approaches for the same thing: automatic memory management. (Which is itself a not trivial to define concept)
One tracks liveness, while the other tracks "deadness", but as you can surely imagine on a graph of black and white nodes, collecting the whites and removing all the others vs one by one removing the black ones are quite similar approaches, aren't they?
I agree that RC and GC are both kinds of automatic memory management.
RC’s semantics aren’t about tracking deadness. That’s the disconnect. In practice, when someone says, “I’m using RC”, they mean that they have destructors invoked on count reaching zero, which then may or may not cause other counts to reach zero. If you squint, this does look like a trace - but by that logic everyone writing recursive traversals of data structures is writing a garbage collector
CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.”
https://www.youtube.com/watch?v=JfmTagWcqoE
This is the biggest difference, but if you disallow cycles then they come close. For example, the jq programming language disallows cycles, therefore you could implement it with RC or GC and there would be no observable difference except "eager destruction", but since you could schedule destruction to avoid long pauses when destroying large object piles, even that need not be a difference. But of course this is a trick: disallowing cycles is not a generic solution.
What is science is programming language semantics, and by that science, RC and GC are different.
Semantics are well defined in research literature.
Not that I think it's a reasonable approach to language to be pedantic on this. RC being GC is, of course, true from an analytic approach to language: a garbage collection system is defined as a system that collects and frees objects that are unreachable and thus dead; a reference counting pointer collects and frees objects that are unreachable and thus dead; therefore, reference counting is garbage collection.
One problem with this is the vagueness: now, the use of a call stack is garbage collection; after all, returning from a function collects and frees the objects in the stack frame. Leaking memory all over the place and expecting the operation system to clean up when you call `exit()` likewise is "garbage collection".
But more importantly, it's just not how anyone understands the word. You understood perfectly well what I meant when I said "you would be hard-pressed to find a modern AA game that does not already use a GC"; in other words, you yourself don't even understand the word differently. You merely feel an ethical imperative to understand the word differently, and when you did not, used my comment as a stand-in to work through the emotions caused by your own inability to live up to this unfulfilled ethic.
Being pedantic is required mechanism to fix urban myths, that is how we end up with he says, she says, adultered knowledge.
All those "garbage collection" variations are exactly the proof what happens when people on the street discuss matters without having a clue about what they are talking about, it is like practice medecine with village recipes "I hear XYZ cures ABC".
It is not vague, IEEE and ACM have plenty of literature on the matter.
https://www.militaryaerospace.com/defense-executive/article/...
https://www.lockheedmartin.com/en-us/products/aegis-combat-s...
https://vita.militaryembedded.com/1670-aonix-uss-bunker-hill...
Not all GC are born alike, and in real life there isn't "insert credit to continue".
When the handbook came out, I bought it because "hey, I know that guy". Ultimately, I don't think it's necessary, but having a more in depth knowledge of garbage collection and the problems in the space occasionally comes in handy.
For example, what implication do finalizes have on garbage collection design? Reading about that was kind of an eye opener.
(387 points, 166 comments)
1 more comments available on Hacker News