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?
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.
Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
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
Joined: May 05, 2011
@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.
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
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.