Summary: Discussion of the Java stack and heap definitions.
I just read a couple of emails about the concepts of a Java stack and heap, and thinking that their descriptions weren't exactly right, I decided to do a little research. There's no better source than the source, so directly from Sun's Java website, here are definitions for the Java stack and Java heap.
Java stack definition
Here's the definition of a Java stack, with a few pieces removed for clarity:
Each Java virtual machine thread has a private Java virtual machine stack, created at the same time as the thread. A Java virtual machine stack stores frames. A Java virtual machine stack is analogous to the stack of a conventional language such as C: it holds local variables and partial results, and plays a part in method invocation and return. Because the Java virtual machine stack is never manipulated directly except to push and pop frames, frames may be heap allocated.
In layman's terms, a simplification is to say that local variables and methods are on the Java stack.
Java heap definition
Here's the definition of a Java heap, again with a few pieces removed for clarity:
The Java virtual machine has a heap that is shared among all Java virtual machine threads. The heap is the runtime data area from which memory for all class instances and arrays is allocated.
The heap is created on virtual machine start-up. Heap storage for objects is reclaimed by an automatic storage management system (known as a garbage collector); objects are never explicitly deallocated.
The heap may be of a fixed size or may be expanded as required by the computation and may be contracted if a larger heap becomes unnecessary. The memory for the heap does not need to be contiguous.
A Java virtual machine implementation may provide the programmer or the user control over the initial size of the heap, as well as, if the heap can be dynamically expanded or contracted, control over the maximum and minimum heap size.
Again, in lay terms, things like objects, class variables, and instance variables go on theheap. Another way to think about this is that if you end up having "memory leaks" in your code, the memory leaks will be in the heap, and a Java profiling tool can help you debug this problem.
More Java memory definitions
If you're digging into the Java heap and stack for some reason, it's very important to know that there's more to this story. The Sun documentation describes other memory concepts, such as these:
- The pc Register
- Method Area
- Runtime Constant Pool
- Native Method Stacks
- Frames
Java Frames are a particularly important concept. Here's are a few bullet point definitions of a Java Frame:
- A frame is used to store data and partial results, as well as to perform dynamic linking, return values for methods, and dispatch exceptions.
- A new frame is created each time a method is invoked. A frame is destroyed when its method invocation completes.
- Frames are allocated from the JVM stack of the thread creating the frame. Each frame has its own array of local variables, its own operand stack, and a reference to the runtime constant pool of the class of the current method.
- The sizes of the local variable array and the operand stack are determined at compile time and are supplied along with the code for the method associated with the frame.
- Only one frame, the frame for the executing method, is active at any point in a given thread of control. This frame is referred to as the current frame, and its method is known as the current method. The class in which the current method is defined is the current class.
- A frame ceases to be current if its method invokes another method or if its method completes.
- A frame created by a thread is local to that thread and cannot be referenced by any other thread.
There's more than this to know about Java Frames, but I tried to whittle the Sun description down to make it easier to digest initially.
