aspose file tools*
The moose likes Java in General and the fly likes Stack/Heap explanation. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Stack/Heap explanation." Watch "Stack/Heap explanation." New topic
Author

Stack/Heap explanation.

Ted Scofield
Greenhorn

Joined: Apr 04, 2009
Posts: 26
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:

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:

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
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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:

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:

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
Greenhorn

Joined: Apr 04, 2009
Posts: 26
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
Bartender

Joined: Mar 17, 2011
Posts: 8196
    
  23

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

Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Ted Scofield
Greenhorn

Joined: Apr 04, 2009
Posts: 26

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?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Stack/Heap explanation.