• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Runtime Data Areas : Stack, heap etc

 
Mustafa Garhi
Ranch Hand
Posts: 111
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic