Is the stack garbage collected in Java?

Question

The heap memory is garbage collected in Java.

Is the stack garbage collected as well?

How is stack memory reclaimed?

Answer 1

The stack could be garbage collected. However, in most JVM implementations, it is handled as, well, a "stack", which by definition precludes garbage collection.

What we call the stack is the accumulation of method activation contexts: for each invoked method, this is the conceptual structure which contains the method arguments, local variables, a hidden pointer to the context for the calling method, and a slot to save the instruction pointer. The activation context is not accessible as such from the Java language itself. A context becomes useless when the method exits (with a return or because of a thrown exception). It so happens that when a method A calls a method B, it is guaranteed that when A regains control, the context for B has become useless. This implies that the lifetime of the context for B is a subrange of the lifetime of the context for A. Therefore, activation contexts (for a given thread) can be allocated with a LIFO ("Last In, First Out") discipline. In simpler words, a stack: a new activation context is pushed on top of the stack of contexts, and the context on top will be the first to be disposed of.

In practice, the activation contexts (also called stack frames) are concatenated, in stack order, in a dedicated area. That area is obtained from the operating system when the thread is started, and the operating system gets it back when the thread terminates. The top of the stack is designated by a specific pointer, often contained in a CPU register (this depends on whether the JVM is interpreting or compiling code). The "pointer to caller's context" is virtual; the caller's context is necessarily located just below in stack order. The GC does not intervene: the area for the stack is created and reclaimed synchronously, from the thread activity itself. This is also how it works in many languages such as C, which do not have a GC at all.

Now nothing prevents a JVM implementation from doing otherwise, e.g. allocating activation contexts in the heap and having them collected by the GC. This is not usually done in Java Virtual Machines since stack allocation is faster. But some other languages need to do such things, most notably those which play with continuations while still using a GC (e.g. Scheme and its call-with-current-continuation function), because such games break the LIFO rule explained above.

Answer 2

The memory on the stack contains method-parameters and local variables (to be precise: the references for objects and variables itself for primitive types). That will be automatically removed if you leave the method. If the variables are references (to objects) the objects itself are on the heap and handled by the garbage collector.

So the stack isn't garbage collected in the same way as the heap, but stack is a form of automatic memory-management in it's own (which predates garbage collection).

A more detailed answer is given by Thomas Pornin, look into that for more details.

Answer 3

The stack is not garbage collected in Java.

The stack allocated for a given method call is freed when the method returns. Since that's a very simple LIFO structure, there's no need for garbage collection.

One place where the stack and garbage collection interact is that references on the stack are GC roots (which means that they are the root references from which reachability is decided).

Answer 4

No one, data is pushed and popped from stack as you have inner variables in methods, during method calls, etc. You don't need to care about this.

Answer 5

All objects in Java are allocated on the heap. (At least as far as the spec goes, the actual implementation may allocate them on the stack if they transparently behave as if they were on the heap.)

Exactly what is collectible is a bit subtle. If the only reference to an object is in a single stack frame, and it can be shown that reference will not be used again, then the object may be collected. If the object is only used to read a field, then that field read may be optimised forward and the object collected earlier than you might expect.

This doesn't usually matter unless you are using finalisers (or presumably References). In that case you should be careful and use locks/volatile to enforce a happens-before relationship.

When threads stop, then typically the entire stack will be deallocated.

Answer 6

Everything located on stack is treated as global roots by a garbage collector. So, yes, you definitely can say that stack is "garbage collected".