My Brain Works Like the JVM Published on
I love metaphors, trying to map real-world mechanics and processes onto software development is not just fun to think about, but also good when explaining things to others (even to non-software developers).
I actually came across this topic when I was asking myself "What things do I remember and which not?".
The JVM Memory Layout
The Stack
The Stack is the most temporary and short-lived memory segment, it's where the current state of a running thread is stored.
See it as your daily memory space. At the end of your day, you probably could tell me which sorts of food you ate that day, but could you also tell me what you ate 249 days prior? I guess not. Depending on whether your brain is multithreaded or not, you will have multiple stacks - or not.
The Heap
The stack itself doesn't store any objects, it rather just stores references to objects on the heap. Both the Young Generation and the Old Generation are part of the heap.
Young Generation
Every newly created object is first put into Eden Space, which is part of the Young Generation. Additionally, there are survivor spaces (S0 and S1 in the picture). The longer an object survives (in terms of garbage collection cycles) in Eden Space, the more likely it is to be moved into S0 or S1 afterward (read more about how they function here). You could also see this as objects being upgraded or promoted over time.
Back to our metaphor, in this memory space it's decided how the memory/knowledge will end up - is it important for us to remember? Ever been at a party and talked to like ten different new people? Well, I have, and most of those didn't get promoted in my head.
Old Generation
This is where the old objects live, having survived long enough to be part of long-term memory. The memory is nowhere safe to not be garbage collected but the objects in this area have already been alive for longer time.
My whole life experience lives here - the adventures, the people, the big decisions I made, and the knowledge I built up over time, this is who I am.
Gargabe Collection
Since the JVM is a memory-safe platform, there needs to be a mechanism to allocate and deallocate the objects needed. This is the responsibility of the garbage collector. Unfortunately, a computer doesn't quite work like our brains; we do not need to actively decide to forget or remember something. This means that we want the GC to be as efficient as possible so as not to cause any big CPU load or latency problems for our running JVM application.
If only computers worked more like my brain, where garbage collection naturally discards (personally) irrelevant details, we wouldn’t have to worry about memory management so much (or if there would be infinite memory of course).
[ A metaphor about Alzheimer's or a memory leak should go here, but I haven’t found the right one yet... ]
The division into young and old generation is based on a hypothesis that most objects are short-lived. This way the minor garbage collector can reclaim space more frequently cleaning up the young generation, while the major garbage collector runs less often, ensuring efficient management of long-lived objects and reduced pause times.
There are different collectors available, and not all use the same classical memory layout as described above. Every garbage collector makes trade-offs regarding throughput, latency, and memory efficiency. Depending on your use case, you might want to switch off the default one (at the time of writing it's the G1GC for Java 9 and later).
If you want to dive a bit deeper into the this topic you can read more about it on baeldung.com/jvm-garbage-collectors or javacodegeeks.com/2025/01/optimizing-java-memory-new-garbage-collectors-in-2025.
Key Takeways
I hope you now understand why we humans need our sleep, it's part of our garbage collection process.
The Stack – the running state of a thread.
The Heap – all objects, divided into young/old generations.
Garbage Collector – part of the runtime that manages, allocates and deallocates objects on the heap.