stack, heap, ...

[Matthew Son]

Can you explain how the following are related?
JVM, JVM stack, JVM heap, JVM method area,
machine stack, machine heap, static declarations.
Specifically, I am trying to verify that the JVM stack and heap are different from the actual machine stack and heap. I also would like to verify that class declarations go in the JVM method area, that objects go in the JVM heap, and that object references go in the JVM stack. I would also like to know how the keyword static affects things. And finally what is the implication of the keyword final (as pertains to memory use)
Thank you.
Matthew Son

[Cindy Glass]

42 questions . . . one post . . . :roll:
Lets see:
The JVM is allotted a certain amount of space by the OS. Part of that is dedicated to the heap and part is reserved for JVM use.
All objects live in the heap.
There is a stack for every "frame" in the JVM. Each Method gets it's own Frame. When the Method is over the stack is discarded.
Local variables hold references in the stack for the method. When the method is over and the stack discarded those are gone.
Instance variables (Fields) hold references that are kept in the object space in the heap.
Class declarations (Classfiles) go into a reserved area, which the vendor can either implement in the heap or in the JVM reserved area (which is more common).
All method declarations are kept in the Method area related to the Classfile. (Once per class, not once per object)
Static variables keep references in the reserved Classfile area.
Final variables can be optimized into constants by the JVM and are kept in the Constant Pool with the Classfile.
You might be amused by Lifestyles of the Rich and Object-Oriented
Or -
Not all Variables are created Equal

[Matthew Son]

>> The JVM is allotted a certain amount of space by the OS.
The "certain amount of space" is what type of memory and how much is allotted?
>> Part of that is dedicated to the heap and part is reserved for JVM use.
What heap are you referring to - JVM's or OS's?
What is the part that is reserved for JVM use?
>> All objects live in the heap.
What does this mean? The object references or the objects themselves?
Does an object of a static class live in the heap?
e.g. Math math = new Math()
>> There is a stack for every "frame" in the JVM.
What is a frame?
Is it a memory type?
Is it in the JVM stack, JVM heap, or something else altogether?
>> Each Method gets it's own Frame.
Does a method of a class get a frame or a method of an object get a frame?
Does one class with 20 methods get 20 frames?
If there are 2 objects of that class, are there 20, 40, or 60 frames?
what is the implication of static here?
>> When the Method is over the stack is discarded.
How can a method of a class be over?
>> Local variables hold references in the stack for the method.
local variables = object references?
>> When the method is over and the stack discarded those are gone.
How is the stack discarded?
Are you referring to the JVM stack or the OS stack?
>> Instance variables (Fields) hold references that are kept in the object >> space in the heap.
are both the value and reference to the value in the heap?
how are primitive instance variables treated versus object instance variables.
>> Class declarations (Classfiles) go into a reserved area, which the ?
>> vendor can either implement in the heap or in the JVM reserved area
>> (which is more common).
so the class declarations are kept on disk?
can you describe the reserved area and how it maps to the OS memory?
>> All method declarations are kept in the Method area related to the
>> Classfile. (Once per class, not once per object)
the method declarations are read from the classfile? The speed with which objects can be created and methods can be executed hints that this cannot be the case.
>> Static variables keep references in the reserved Classfile area.
>> Final variables can be optimized into constants by the JVM and are kept >> in the Constant Pool with the Classfile.
Can you draw me a picture of how all the OS components to memory and JVM components fit together?
Thanks and sorry for so many questions in 1 posting...
Matt

[Cindy Glass]

Originally posted by Matthew Son:
>> The JVM is allotted a certain amount of space by the OS.
The "certain amount of space" is what type of memory and how much is allotted?

Sun just publishes a specification for the JVM and anyone is allowed to implement it in anyway that they choose. The memory is typically part of RAM, but some operating systems may chose to page or use harddisk space as needed. The purpose of the JVM is that this implementation is abstracted so that you, as an application developer do not NEED to know the particular implementation details.

>> Part of that is dedicated to the heap and part is reserved for JVM use.
What heap are you referring to - JVM's or OS's?
What is the part that is reserved for JVM use?

The JVMs heap. The other space is reserved for whatever else the JVM may need to do, depending on how the vendor chose to implement the specs. You can see more about these specs in the VM Specification

>> All objects live in the heap.
What does this mean? The object references or the objects themselves?
Does an object of a static class live in the heap?
e.g. Math math = new Math()

The objects themselves live on the heap. An object is just an area of memory on the heap that is used to store the state of that object. Therefore there is space in that object area allotted to each field that the object has. Those fields either hold primitive values or references to other objects.
ALL objects live on the heap. A static VARIABLE (aka field) may be kept with the Classfile in the JVM reserved area, but that static variable holds a reference to an object that is on the heap.
You can not make an instance of the Math class. It has no public constructor.

>> There is a stack for every "frame" in the JVM.
What is a frame?
Is it a memory type?
Is it in the JVM stack, JVM heap, or something else altogether?

A frame is a section of work that the JVM has bitten off. It is a concept that JVM writers need to know and understand, and application coders do not. It is something else altogether.

>> Each Method gets it's own Frame.
Does a method of a class get a frame or a method of an object get a frame?
Does one class with 20 methods get 20 frames?
If there are 2 objects of that class, are there 20, 40, or 60 frames?
what is the implication of static here?

There is no such thing as �a method of an object�.
An object invokes a method of a class. Each invocation of a method gets its own frame. A class with 20 methods gets a frame for each invocation of each method. Potentially thousands. The same method can get invoked over and over. Each time a new frame.
There can be lots of objects calling that same method. Each objects invocation of the method gets it�s own frame.
When a static method is called it also gets it�s own frame.

>> When the Method is over the stack is discarded.
How can a method of a class be over?

The invocation of the method of the class is completed. All the logic in the method has completed, and currency returns to wherever the method was called from.

>> Local variables hold references in the stack for the method.
local variables = object references?

All variables hold either primitive values or references to objects. Local variables are in the stack, fields or instance variables are in the object space, static variables are by the Classfile, but they all either hold primitive values or references to objects on the heap.

>> When the method is over and the stack discarded those are gone.
How is the stack discarded?
Are you referring to the JVM stack or the OS stack?

That depends on what operating system you are running on and how this JVM was implemented on that operating system. I am referring to the JVM stack.

>> Instance variables (Fields) hold references that are kept in the object >> space in the heap.
are both the value and reference to the value in the heap?
how are primitive instance variables treated versus object instance variables.

Not sure as all what you mean here. A variable that holds a primitive, holds that primitive. Some variables are in the stack, instance variables (fields) are in the object space, static variables are in the Classfile space, but still, no matter where the variable happens to be it holds the value of the primitive.
How are they treated?? Not sure what you mean � they are still just variables. It just saves the JVM one step because it has the value right there and does not have to follow a reference.

>> Class declarations (Classfiles) go into a reserved area, which the ?
>> vendor can either implement in the heap or in the JVM reserved area
>> (which is more common).
so the class declarations are kept on disk?
can you describe the reserved area and how it maps to the OS memory?

No the classfile declarations are typically kept in the JVM reserved area of RAM. No I can not map it, there are zillions of OS�s out there and each could potentially be different. How a JVM in a chip in a thermostat works (which may have NO disk) may be completely different than how a JVM on a unix box works.

>> All method declarations are kept in the Method area related to the
>> Classfile. (Once per class, not once per object)
the method declarations are read from the classfile? The speed with which objects can be created and methods can be executed hints that this cannot be the case.

Well, sorry about that, but it IS the case. Please note that the word classfile does not refer to the .class file that comes out of compiling a .java file. A Classfile is the storage area that the JVM uses to put Class related information when that class is loaded into memory.

>> Static variables keep references in the reserved Classfile area.

That is one potential implementation of the specifications, yes.

>> Final variables can be optimized into constants by the JVM and are kept >> in the Constant Pool with the Classfile.

Yep.

Can you draw me a picture of how all the OS components to memory and JVM components fit together?

Did you read that article that I pointed you to? There were several pictures there

Can you please split your question up into different topics from now on. This makes is much less usable for OTHER folks that might want the same answers.
[ August 21, 2003: Message edited by: Cindy Glass ]

[Roger Chung-Wee]

Also, local variables are faster than instance and class variables. This is because they are stack variables, and the JVM is a stack machine.

[Suhrid Karthik]

>> Instance variables (Fields) hold references that are kept in the object >> space in the heap.
are both the value and reference to the value in the heap?
how are primitive instance variables treated versus object instance variables.
Not sure as all what you mean here. A variable that holds a primitive, holds that primitive. Some variables are in the stack, instance variables (fields) are in the object space, static variables are in the Classfile space, but still, no matter where the variable happens to be it holds the value of the primitive.
How are they treated?? Not sure what you mean � they are still just variables. It just saves the JVM one step because it has the value right there and does not have to follow a reference.

Im curious to know the JVM "finds" variables (primitives, object references) in memory. For Object's the reference variable holds some sort of address which points to the Object on the Heap. For primitive variables, the variable contains the value of the variable itself. If I want to read the value of the variable and change the value, the JVM must know the memory address where this value is stored ? How does the JVM do it ?

//Object reference variable
Person p = new Person();

p.setFirstName("ABCD");
System.out.println("Age " + p.getAge());

//Primitive variable
int i = 10;
i = i + 1;

p.setFirstName() and p.getAge() work because the address of the Person object is contained in p. However how does the JVM know where to find the memory address of "i" ? For that matter, how does the JVM find the memory address of the reference variable p ?

Im guessing this has something to do with how compilers and interpreters operate, but would appreciate anyone letting me know how it works.