GeeCON Prague 2014*
The moose likes Beginning Java and the fly likes Verifying whats on stack and whats on heap Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Verifying whats on stack and whats on heap" Watch "Verifying whats on stack and whats on heap" New topic
Author

Verifying whats on stack and whats on heap

sridhar t patil
Greenhorn

Joined: May 05, 2011
Posts: 6
Hi all.
To understand the java memory management I have written a small code and provided which things go on stack and which on heap. please could someone validate. Thanks.


Stack – varB, stringC, varD, stringE
Heap – varA, stringE, “Welcome”, “Hello”

Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14194
    
  20

And why do you think the answers are what you said?

Specifically: Why would varB be on the stack and stringE on the heap? Why would stringC be on the stack? Did you notice that you said that stringE is both on the stack and the heap? What do you mean by that?

Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7892
    
  21

sridhar t patil wrote:To understand the java memory management...

OK, well there's a possible problem right there.

Unless you really need this information for something specific (like the SCJP exam), Java memory management is
(a) none of your business (it's the business of the JVM).
(b) not under your control.

Back when I was learning C, it was useful to know about stack frames and memory partitions and the like, because it could make a big difference to how a program ran; but in Java - unless you plan on writing a new, improved garbage collector - it really isn't necessary. In fact, it's more likely to be a distraction than anything else.

I can honestly say that in 12 years of using Java, I have never once worried about whether a program (or value) uses stack or heap memory. I create values, I use them, and I trust the JVM to get rid of them if and when it can - it really is as simple as that.

HIH

Winston

Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

As Winston points out, you don't really need to know or care about stack and heap to write Java code. Your concern about memory management is pretty much limited to:

  • "Am I keeping references to objects I'm not using any more?" and most of the time, just by writing code normally, you're automatically not doing that.
  • "Am I creating and keeping very many objects and/or very large objects, so that my app might require a particularly large -Xmx option at JVM startup?" We find this out by educated guessing and trial and error.
  • "Am I infinitely recursing, such that I might run out of stack?" If we guess wrong on this one, it will become blatantly apparent the first time we call the offending method. It's really an all-or-nothing proposition. We have a bug that leads to a requirement for an infinitely large stack, or our code is fine. There's rarely a middle ground.


  • However, curiosity is a good thing, and I always feel better if I have a rough idea of what's going on under the hood, even if it's not something I need to deal with day-to-day. So, in that light, the rules are:

    1. All local variables (including method parameters) go on the stack.

    2. Everything else--objects, class definitions, executable code--lives on the heap.

    3. Except that some newer JVMs may be storing short-lived objects on the stack, if the JVM can prove that the object won't escape that method call. We don't have any direct control over this when we write our code, and we have no way of knowing if a particular object that could theoretically go on the stack will in fact do so. I suppose there might be a JVM command line option to enable or disable the behavior on JVMs that support it, but that's just a guess.
    sridhar t patil
    Greenhorn

    Joined: May 05, 2011
    Posts: 6
    @Jesper - varB on stack as it is a method parameter. stringE on heap as it is a reference variable of the class. stringC on the stack as it is a reference variable inside the method. My bad of putting stringE on heap and stack, think should be heap.

    @Winston - Thought of understanding from an interview perspective. From your thoughts, seems I need not worry about how JVM handles it.

    @Jeff - Well after reading your and Winston's view, I have stopped caring about heap and stack .....Thanks for providing the rough idea of what's going on under the hood; will keep it in mind from an interview perspective.
    Jeff Verdegan
    Bartender

    Joined: Jan 03, 2004
    Posts: 6109
        
        6

    sridhar t patil wrote:@Jesper - varB on stack as it is a method parameter. stringE on heap as it is a reference variable of the class. stringC on the stack as it is a reference variable inside the method. My bad of putting stringE on heap and stack, think should be heap


    Not quite.



    varA and the first stringE are on the heap, because they are member variables--part of an object, and that object is on the heap*.

    varB and the second stringE are on the stack because they are parameters and hence are local to the method call.

    stringC and varD are on the stack because they are locals.

    Note that for those of the above variables that are references, regardless of where the variable itself lives, if it's non-null, then the object it points to will be on the heap*.


    *Subject, of course, to the aforementioned possibility that some JVMs may put some objects on the stack.
    sridhar t patil
    Greenhorn

    Joined: May 05, 2011
    Posts: 6
    Thanks Jeff for this clarification.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Verifying whats on stack and whats on heap