Best Regards,<br />Vipin<br />MCA, SCJP5, SCWCD in progress
vipin jain
Ranch Hand
Joined: Aug 24, 2008
Posts: 122
posted
0
hello Arjun,
AS I Think Primitives are stored on the stack, objects in the heap space.
int j = 20; will be stored on the stack, because the variable itself holds the value and it's much faster, but if you wrap it: Integer p = new Integer(20); then it's stored in the heap space because it's now an object.
Campbell Ritchie
Sheriff
Joined: Oct 13, 2005
Posts: 26636
posted
0
That doesn't sound right; I thought that all fields live in the heap and local and intermediate variables are pushed onto the stack. That is slightly imprecise for Java 6 however.
Anybody else?
sameer khazi
Greenhorn
Joined: Sep 05, 2008
Posts: 28
posted
1
Hi Arjun...
Well Heap and stack are the two main memories that JVM is concerned as far as memory allocation by the OS(operating system) is concerned.
As said above, stack and heap are the memories allocated by the OS to the JVM that runs in the system.
Stack is a memory place where the methods and the local variables are stored.
Heap is a memory place where the objects and its instance variable are stored.
Also it is to be remembered that the variable references (either primitive or object references) are stored in the stack.
i have written this to the best of knowledge. Any corrections are welcome.
Originally posted by fundu man: Thanks everyone for good informations.
But can anyone say where Interface variables are stored ? heap or stack?
Heap, since interfaces only exists as implementations in classes and they are on the heap.
Jason Gosling
Greenhorn
Joined: Oct 18, 2009
Posts: 5
posted
0
I concern about this much. Remember in Runtime Environment Data, we have another field named "Method Area" which contains Method information and class variables as well
In my opinion, the separation between stack and heap can be deemed as following:
+ Stack: local variables (both primitive & reference) and method parameters
+ Heap: object
==>When we have a declaration like this
class A{
int e = 1;
public int math (int x, int y){
A a = new A();
return (A.e + x + y);
}
}
Then we have:
Stack: x, y, a
Heap: instance a (it is A object), a.e = 1
(Note that a in stack points out to instance a in heap)
If instance a is no longer used, it is garbage collected
jeetendra Choudhary
Ranch Hand
Joined: Jun 02, 2009
Posts: 33
posted
0
Hi guys,
I have doubt as per my knowledge interfaces can have constants which are direct values, so it should be in the stack. Please correct if I am wrong here.
Regards
Jeetendra
Preparing for SCJP...!!
Jeff Verdegan
Bartender
Joined: Jan 03, 2004
Posts: 3089
posted
1
jeetendra Choudhary wrote:Hi guys,
I have doubt as per my knowledge interfaces can have constants which are direct values, so it should be in the stack. Please correct if I am wrong here.
You are wrong here. I don't know what you mean by "direct values," as that's not part of any standard Java lexicon, and whatever it means, I don't know why you would think that means they go on the stack.
The rule, however, is quite simple: Local variables (including method parameters) go on the stack. Everything else goes on the heap. And note that variables never store objects; they only hold primitives and references. So all objects go on the heap. And all class definitions go on the heap (in a special area called the method area), which includes constants defined in those classes.
(Note that there was some talk of including or allowing escape analysis in Java 7, so that implementations would be allowed to store objects on the heap if they could verify that the object was never used outside that method invocation. I don't know if that made it into the spec, or, even if it did, if any implementations take advantage of it. So for now, it's safe to say that all objects are always on the heap, and only local variables are on the stack.)
Dattatraya Tembare
Greenhorn
Joined: Feb 01, 2009
Posts: 10
posted
0
Dear All,
Here one important thing has missed, it will clear all doubts.
Heap: is a single area where JVM allocates memory for -Objects, including method code , static variables & instance variables.
Stack: Stack is created for each individual thread, JVM allocates memory for - local variables & arguments (values passed to method variables)
@ interface - all values in interface are constants i.e final static, so it's stored on Heap only.
Hope these will clear the picture.
Jeff Verdegan
Bartender
Joined: Jan 03, 2004
Posts: 3089
posted
0
Dattatraya Tembare wrote:Dear All,
Here one important thing has missed, it will clear all doubts.
Heap: is a single area where JVM allocates memory for -Objects, including method code , static variables & instance variables.
Already covered. Not missed.
Stack: Stack is created for each individual thread, JVM allocates memory for - local variables & arguments (values passed to method variables)
True, and worth knowing, but not really important for the OP's question.
@ interface - all values in interface are constants i.e final static, so it's stored on Heap only.
Correct.
Hope these will clear the picture.
I'm not sure why you'd think the picture wasn't clear already.
That video is somewhere between misleading and just plain wrong.
It seems to suggest that a method's executable code goes on the stack, which is false. If that's not what it's trying to say, it should be clearer in how it's worded.
It also talks about stack variables being "flushed", as if there's some active process to remove or clear them. That's not how it works. The stack pointer simply gets reset to its previous value. The old values of the variables are still there on the stack until another stack frame overwrites them.
Note also that the executable code is not copied for each invocation of the method. There's no reason to do so, since the executable code is read-only.
Note also that the executable code is not copied for each invocation of the method. There's no reason to do so, since the executable code is read-only.