wood burning stoves*
The moose likes Java in General and the fly likes Runtime Data Areas : Stack, heap etc Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Runtime Data Areas : Stack, heap etc " Watch "Runtime Data Areas : Stack, heap etc " New topic
Author

Runtime Data Areas : Stack, heap etc

Mustafa Garhi
Ranch Hand

Joined: Nov 05, 2008
Posts: 111
How advisable is it to read about Runtime Data Areas on :
http://java.sun.com/docs/books/jvms/second_edition/html/Overview.doc.html#1732

I found the stuff not very simple.

Plus, if i had the following method, please check if my understanding is ok regarding what goes where ..

public String display(String str) { // Line 1
String anotherStr = str; // Line 2
int slNo = 1; // Line 3
anotherStr = slNo+ "." + anotherStr; // Line 4
System.out.println(anotherStr); // Line 5
}

Line 1 : This is regarding the method, its written type so this stays is the FRAME on the STACK. Also the reference str stays on STACK and its object on HEAP.
Line 2 : anotherString reference is on STACK that points to the object on HEAP
Line 3 : slNo on STACK and its value ???
Line 4 : The add instruction for anotherStr = slNo+ "." + anotherStr; goes to the HEAP
Line 5 : Print instruction on HEAP again

Thanks in advance ranchaaz
Ranjan Maheshwari
Greenhorn

Joined: May 04, 2011
Posts: 5
The JVM specs tells about the RunTime data areas very briefly. More details about the runtime data areas can be found at Inside The Java Virtual Machine (JVM Architecture)

I hope this helps.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Up through Java 6 at least, it's quite simple:

1. All local variables go on the stack.

2. All objects go on the heap.

3. Class definitions, constant pools and executable code go in the method area, which is "logically part of the heap."

And that's it.

Starting with Java 7, there was talk of allowing objects to be placed on the stack, if escape analysis could prove that no reference to the object outlived the stack frame, but I don't know if that made it into the spec, and if it did, if any JVMs are implemented to take advantage of it. So you can add to the above that starting with Java 7 or possibly a later version, some short-lived objects might go on the stack.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Mustafa Garhi wrote:
Line 1 : This is regarding the method, its written type so this stays is the FRAME on the STACK. Also the reference str stays on STACK and its object on HEAP.


That first part doesn't really make any sense. There's no such thing as a "written type". The method's executable code is in the method area, which is part of the heap. Every time we invoke the method, a new stack frame is created. The parameter "str" is a local variable and so it goes on the stack. The String object that str points to is in the heap.

Line 2 : anotherString reference is on STACK that points to the object on HEAP


Correct.

Line 3 : slNo on STACK and its value ???


It's a local variable, so it's on the stack. So is its value. A variable's value is always where the variable is, by definition. Ntoe that, in Line 1, the value of the variable str is a reference, and is on the stack, because a variable's value is wherever that variable is, by definition. A variable's value is never an object in Java.

Line 4 : The add instruction for anotherStr = slNo+ "." + anotherStr; goes to the HEAP


The concatenation operation with the + operator will be implemented by a method call, and that method's executable code is in the method are, which is part of the heap.

Line 5 : Print instruction on HEAP again


Same as above.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Runtime Data Areas : Stack, heap etc
 
Similar Threads
One more time :) G. C. Q and A
Garbage Collection Q & A
Once more about Array
String literal GCed?
how many objects are available for gc?