Stack/Heap explanation.

[Ted Scofield]

Hi all,

I'm trying to figure out if my understanding of stack/heap in Java is sound, I'd appreciate any feedback/correction/remark.

First, some theory: in general, JVM stores objects/arrays in a heap, although some implementations may use a stack (escape analysis). Local variables are put in a stack. When a method is invoked, its parameters and local variables are pushed in a stack.

Consider the following example:

class Greeter {

	public void sayHello(String name) {
		System.out.println("Hello " + name");
	}

	public static void main(String[] args) {
		Greeter elvis = new Greeter();
		elvis.sayHello("Elvis");

		new Greeter().sayHello("Frank");
	}

}

What happens when we invoke the program? JVM starts a new thread and creates its heap and stack.

Main method is executed first; a new String array object is created and stored in the heap. 'args' parameter is pushed in the stack, pointing to the newly created array.

Then a new Greeter object is created and stored in the heap. If there's not enough memory, an OutOfMemoryError is thrown. 'elvis' reference is put in the stack, pointing to the newly created object. If there's not enough memory in the stack, a StackOverflowError is thrown.

sayHello is executed on the 'elvis'. A new String object is put in the String constant pool if it doesn't already exists and 'name' param points at it.

System.out is created or retrieved from heap and println method is triggered. A new String object is added to String constant pool in the heap - "Hello Elvis".

After the println method is done, "Hello Elvis" will no longer be referenced by any variable. This makes it eligible for garbage collection. When/if GC will be performed, this String object will be collected. The same goes for the Greeter object 'elvis' is pointing at.

I'm not sure for the last one though:

new Greeter().sayHello("Frank");

I assume the following: a new Greeter object is created on the heap and right away, the method sayHello is executed on it. The method does the same thing as I described above. When it finishes, the object becomes eligible for GC.

Would this be an okay explanation of Java memory management?

[Jeff Verdegan]

Ted Scofield wrote:Hi all,

I'm trying to figure out if my understanding of stack/heap in Java is sound, I'd appreciate any feedback/correction/remark.

First, some theory: in general, JVM stores objects/arrays in a heap, although some implementations may use a stack (escape analysis). Local variables are put in a stack. When a method is invoked, its parameters and local variables are pushed in a stack.

Yes, that's correct. And you needn't say "objects/arrays". Just "objects" will do, since arrays are objects.

Also, as far as I know, putting short-lived objects on the stack is not widely implemented, and even where it is, most objects will end up on the heap regardless.

And finally, while it's good to have a general idea of the heap/stack landscape, you'll almost never actually care about it when you're developing with Java. About the only time it would come into play is if you're actually writing your own JVM implementation, or if you're working on a specialized or limited-memory JVM, or if you're doing hardcore profiling for memory or performance problems.

Consider the following example:

class Greeter {

	public void sayHello(String name) {
		System.out.println("Hello " + name");
	}

	public static void main(String[] args) {
		Greeter elvis = new Greeter();
		elvis.sayHello("Elvis");

		new Greeter().sayHello("Frank");
	}

}

What happens when we invoke the program? JVM starts a new thread and creates its heap and stack.

It creates a JVM-wide heap, and each thread gets its own stack.

Main method is executed first; a new String array object is created and stored in the heap. 'args' parameter is pushed in the stack, pointing to the newly created array.

Yes.

Then a new Greeter object is created and stored in the heap. If there's not enough memory, an OutOfMemoryError is thrown. 'elvis' reference is put in the stack, pointing to the newly created object. If there's not enough memory in the stack, a StackOverflowError is thrown.

Close. When the method is first entered, before any of its code is executed, all the stack space it will need is allocated. I don't recall if that's in the spec or not, but I'm sure any mainstream JVM does it that way. And not that it might be one slot for each variable (2 for longs and doubles), or the JVM may also optimize it to less, such as re-using the same slot for variables with non-overlapping lifetimes.

Again, though, worth having a passing knowledge of, but not something you think about day-to-day as you're writing your code.

sayHello is executed on the 'elvis'.

On the object pointed to by the reference variable "elvis", yes.

A new String object is put in the String constant pool if it doesn't already exists

That happens when the class is loaded, before any of its code is executed.

System.out is created or retrieved from heap and println method is triggered.

System.out is final. It's created long before our class is even loaded.

A new String object is added to String constant pool in the heap - "Hello Elvis".

No. Strings built at runtime aren't added to the constant pool unless we explicitly call intern().

After the println method is done, "Hello Elvis" will no longer be referenced by any variable. This makes it eligible for garbage collection.

Correct.

When/if GC will be performed, this String object will be collected. The same goes for the Greeter object 'elvis' is pointing at.

Maybe. A given invocation of GC may not necessarily reclaim all available space. It might get some now, and another piece next time. Also, the "elvis" Greeter is still reachable, and therefore not GC-eligible, until main() completes.

I'm not sure for the last one though:

new Greeter().sayHello("Frank");

I assume the following: a new Greeter object is created on the heap and right away, the method sayHello is executed on it. The method does the same thing as I described above. When it finishes, the object becomes eligible for GC.

Yes, although internally the JVM may not even consider it until the method exits. That's probably implementation-dependent.

[Ted Scofield]

Hi Jeff,

a wonderful reply, thank you very much for your time/clear explanation, I really appreciate it.

And finally, while it's good to have a general idea of the heap/stack landscape, you'll almost never actually care about it when you're developing with Java. About the only time it would come into play is if you're actually writing your own JVM implementation, or if you're working on a specialized or limited-memory JVM, or if you're doing hardcore profiling for memory or performance problems.

To be honest, I'm preparing for an interview and it seems this question is pretty popular.

Again, thank you very much.

[Winston Gutkowski]

Ted Scofield wrote:To be honest, I'm preparing for an interview and it seems this question is pretty popular.

Probably because these questions are made up by people who learned their programming in the 70's-90's, who still haven't got their heads around the fact that, for many modern languages, these sorts of things simply aren't important.

If this was an interview for a perl job, a question like that would generate derisive laughter - and rightly so - so why do people think it's important for Java?

Winston

[Ted Scofield]

Probably because these questions are made up by people who learned their programming in the 70's-90's, who still haven't got their heads around the fact that, for many modern languages, these sorts of things simply aren't important.
If this was an interview for a perl job, a question like that would generate derisive laughter - and rightly so - so why do people think it's important for Java?

While I agree with you, I think it's still nice to know (at least in very broad terms) what happens under the hood.
Also, if you were hiring a Java developer, what would be the question that - if answered correctly - would make you think the candidate does know a thing or two about programming?