• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

What is stored on Stack and Heap

 
Ranch Hand
Posts: 629
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

Can anyone tell me what is stored on a stack and what is stored on a heap in a Java program?

Thanks.
 
Ranch Hand
Posts: 122
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hello,
go below link
http://forums.sun.com/thread.jspa?messageID=2406140
 
vipin jain
Ranch Hand
Posts: 122
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Marshal
Posts: 65417
248
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Greenhorn
Posts: 28
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Thank You.
 
author
Posts: 23838
141
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stack is a memory place where the methods and the local variables are stored.



By "methods", I am assumming that you mean the callstack -- not the actual code for the methods.

Heap is a memory place where the objects and its instance variable are stored.



Yes.

Also it is to be remembered that the variable references (either primitive or object references) are stored in the stack.



Only for local variables. For instance and class variables, they are part of the object, hence, on the heap.

Finally, Java 6 may throw a monkey wrench into this. Due to "escape analysis" optimization, sometimes Java 6 will allocate objects on the stack.

Henry
 
vipin jain
Ranch Hand
Posts: 122
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hello,

i thing all thought is going different way so can any replay wath is final and Actully answere ?
 
Campbell Ritchie
Marshal
Posts: 65417
248
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
  • 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.
     
    Greenhorn
    Posts: 3
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks everyone for good informations.

    But can anyone say where Interface variables are stored ? heap or stack?
     
    vipin jain
    Ranch Hand
    Posts: 122
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    hello fundu man

    As per JavaRanch Rules you have to Rename your specific name.
    I don't think funda man is any person name.
     
    Campbell Ritchie
    Marshal
    Posts: 65417
    248
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    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.



    I think you are right: fundu man please confirm that is your real name or go to update profile and correct it to match the naming policy.
     
    Ranch Hand
    Posts: 326
    Android Mac OS X Firefox Browser
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    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.
     
    Greenhorn
    Posts: 5
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
     
    Ranch Hand
    Posts: 41
    Mac OS X Eclipse IDE Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
     
    Bartender
    Posts: 6109
    6
    Android IntelliJ IDE Java
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    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.)
     
    Greenhorn
    Posts: 10
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 6109
    6
    Android IntelliJ IDE Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    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.

     
    Ranch Hand
    Posts: 583
    Firefox Browser Notepad Windows
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Youtube Video
     
    saloni jhanwar
    Ranch Hand
    Posts: 583
    Firefox Browser Notepad Windows
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    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.
     
    Jeff Verdegan
    Bartender
    Posts: 6109
    6
    Android IntelliJ IDE Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    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.



    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.
     
    Jeff Verdegan
    Bartender
    Posts: 6109
    6
    Android IntelliJ IDE Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    saloni jhanwar wrote:Youtube Video



    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.
     
    saloni jhanwar
    Ranch Hand
    Posts: 583
    Firefox Browser Notepad Windows
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Jeff Verdegan wrote:

    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.



    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
    Bartender
    Posts: 6109
    6
    Android IntelliJ IDE Java
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    saloni jhanwar wrote:

    Jeff Verdegan wrote:

    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.



    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.
     
    saloni jhanwar
    Ranch Hand
    Posts: 583
    Firefox Browser Notepad Windows
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Jeff Verdegan wrote:

    saloni jhanwar wrote:

    Jeff Verdegan wrote:

    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.



    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.



    Thanks for links.
     
    Jeff Verdegan
    Bartender
    Posts: 6109
    6
    Android IntelliJ IDE Java
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    You're welcome.
     
    Ranch Hand
    Posts: 112
    Eclipse IDE Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hello Cambell Ritchie and Henry Wong,

    I am curious what can make the jvm to store an object in the stack area. I'm really interested in knowing it. Could you guys please explain it...

    Thanks,
    Pavan.

    EDIT: I came to know that this is Escape Analysis,..a compiler optimization technique. I would look into it..thanks .
     
    Greenhorn
    Posts: 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    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



    class A{
      int e = 1;
          A a = new A();
      public int math (int x, int y){
          return (A.e + x + y);
      }
    }

    Could you tell me, now where would a be stored?


     
    Campbell Ritchie
    Marshal
    Posts: 65417
    248
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Prithiv raj wrote:. . . . Could you tell me, now where would a be stored?

    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!

    And, welcome to the Ranch
     
    Everybody's invited. Except this tiny ad:
    professionally read, modify and write PDF files from Java
    https://products.aspose.com/pdf/java
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!