Best Regards,<br />Vipin<br />MCA, SCJP5, SCWCD in progress
Best Regards,<br />Vipin<br />MCA, SCJP5, SCWCD in progress
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.
Best Regards,<br />Vipin<br />MCA, SCJP5, SCWCD in progress
Best Regards,<br />Vipin<br />MCA, SCJP5, SCWCD in progress
Originally posted by vipin jain:
hello fundu man
As per JavaRanch Rules you have to Rename your specific name.
I don't think funda man is any person name.
Originally posted by fundu man:
Thanks everyone for good informations.
But can anyone say where Interface variables are stored ? heap or stack?
MCP, AWS Certified Developer Associate, Preparing for OCPJP...!!
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.
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.
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.
Tell the difficulties that i am difficult.
Campbell Ritchie wrote:
Class objects, including method codeand static fields: heap.Objects, including instance fields: heap. Local variables and calls to methods: stack And as Henry has pointed out some objects can be created on the stack in Java 6.
Tell the difficulties that i am difficult.
saloni jhanwar wrote:
Campbell Ritchie wrote:
Class objects, including method code and static fields: heap. Objects, including instance fields: heap. Local variables and calls to methods: stack And as Henry has pointed out some objects can be created on the stack in Java 6.
In method code, only if you create any object then it will go in heap else all local variables will go in stack.
saloni jhanwar wrote:Youtube Video
Jeff Verdegan wrote:
saloni jhanwar wrote:
Campbell Ritchie wrote:
Class objects, including method codeand static fields: heap.Objects, including instance fields: heap. Local variables and calls to methods: stack And as Henry has pointed out some objects can be created on the stack in Java 6.
In method code, only if you create any object then it will go in heap else all local variables will go in stack.
False, what Campbell stated was correct. All the executable code for method bodies goes on the heap. It's only local variables that go on the stack.
Tell the difficulties that i am difficult.
saloni jhanwar wrote:
Jeff Verdegan wrote:
saloni jhanwar wrote:
Campbell Ritchie wrote:
Class objects, including method codeand static fields: heap.Objects, including instance fields: heap. Local variables and calls to methods: stack And as Henry has pointed out some objects can be created on the stack in Java 6.
In method code, only if you create any object then it will go in heap else all local variables will go in stack.
False, what Campbell stated was correct. All the executable code for method bodies goes on the heap. It's only local variables that go on the stack.
In a method code, we not only create objects but we also create local variables, so we can't say that whole method code will go on heap,i think so.
Jeff Verdegan wrote:
saloni jhanwar wrote:
Jeff Verdegan wrote:
saloni jhanwar wrote:
Campbell Ritchie wrote:
Class objects, including method codeand static fields: heap.Objects, including instance fields: heap. Local variables and calls to methods: stack And as Henry has pointed out some objects can be created on the stack in Java 6.
In method code, only if you create any object then it will go in heap else all local variables will go in stack.
False, what Campbell stated was correct. All the executable code for method bodies goes on the heap. It's only local variables that go on the stack.
In a method code, we not only create objects but we also create local variables, so we can't say that whole method code will go on heap,i think so.
It doesn't matter what we create. There's no reason that the executable code has to live in the same region of memory as the data it refers to.
The executable code exists exactly once for each method, and it goes in the method area which is part of the heap. Executable code never goes on the stack.
http://docs.oracle.com/javase/specs/jvms/se5.0/html/VMSpecTOC.doc.html
http://docs.oracle.com/javase/specs/jvms/se5.0/html/Overview.doc.html#6656
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.
Tell the difficulties that i am difficult.
Jason Gosling wrote: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
No. There is a compiler error in that code, so it won't be stored anywhere. If you correct that error, you will probably find it is stored on the heap, referred to from its surrounding object. You will have difficulty verifying that because the execution will throw a nice error at runtime!Prithiv raj wrote:. . . . Could you tell me, now where would a be stored?
A sonic boom would certainly ruin a giant souffle. But this tiny ad would protect it:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|