• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Verifying whats on stack and whats on heap

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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”

 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
    Posts: 6
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    @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
    Posts: 6109
    6
    Android IntelliJ IDE Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
    Posts: 6
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks Jeff for this clarification.
     
    Yes, of course, and I accept that blame. In fact, i covet that blame. As does this tiny ad:
    a bit of art, as a gift, that will fit in a stocking
    https://gardener-gift.com
    reply
      Bookmark Topic Watch Topic
    • New Topic