Memory question

[Arnb Sen]

Hi All,

Is this the right forum to ask questions about memory issues like

- what is a stack memory and a heap memory ?
- how are these memories differntiated ?
- what are the properties of these different memory types ?
- where in memory (stack or heap) are the reference variables stored ?
- where in memory are the values of these reference variables stored ?
- where in memory are the primitive variables stored ?
- where in memory are the values of these primitive variables stored ?

Are these advanced questions and should I get the basics correct first ?

[Norm Radder]

Why does a normal programmer need to know any of this?
And especially a beginner?

[Arnb Sen]

Knowledge never hurts. However, knowing these details help in writing better codes.

Any answers to these queries ?

[Ernest Friedman-Hill]

Most of these questions really don't have answers -- i.e., when you know the answers to a few of them, the others don't really make sense. You have to remember that in Java, these are abstract terms that refer to parts of an abstract Virtual Machine -- they're not real, physical things. A lot is left unspecified.

The "stack" is where local variables are stored. Each time a method is invoked, a "stack frame" is allocated, and its local variables are stored there. All local variables, primitive or reference, are stored in stack frames.

The "heap" is where all objects are created. Even if a local variable on the stack is a reference to an object, that object lives in the heap. Therefore member variables of all kinds -- primitive or reference -- are in the heap, because they're inside of objects.

That's about it. Any of your questions that aren't answered by these explanations really have no definite answers in a Java context.

[Arnb Sen]

Hi Ernest,

Thanks for the explanation.

* All local variables are stored in Stacks
* All member variables are stored in Heap
* Objects are stored in Heap
* What about the actual values that the primitive variables store ? Where are these variables stored ?

Although Stack and Heap are abstract and virtual elements, but there must be certain differences between them. Any information on this diffrence ?

[Ernest Friedman-Hill]

To store a primitive means to store its value; if a primitive is on the stack, then the value is on the stack.

What kind of differences are you thinking? Heap memory can hold objects; stack memory can hold variables. If you want to go down to the JVM bytecode level, then the difference is more distinct; you deal more directly with "slots" on the stack, and with references to objects on the heap, so the kinds of operations you can do on them are somewhat different. But their purposes are so disjoint that it's not meaningful to discuss (for example) which one is "faster" or "bigger" or anything.
[ September 04, 2005: Message edited by: Ernest Friedman-Hill ]

[Arnb Sen]

Well to put my question in a different way, why are some variables stored in Stacks and some in Heaps ? What advantage does one get by having variables or the values stored in Heap over Stack or the vice-versa ?

Isn't this information important ? If I find that accessing Heap memory is faster or more efficient to maintain than Stacks then I will probably avoid creating local variables. On the other hand, if Stacks are better, then I would prefer to create local variables.

Also, doesn't garbage collection play any factor here ? Maybe garbage collection of unused variables in Heap have a higher priority than that of unused variables in Stacks. So to have better garbage collection, I would prefer to create member variables, which uses Heap.

[Ernest Friedman-Hill]

I think you're missing my point. You don't get a choice. All objects are always on the heap. All local variables are always on the stack. There are really no situations in which you get to choose one or the other based on the kind of criteria you're describing.

It is true that accessing member variables is probably slower than accessing local variables; but this isn't a "stack vs. heap" issue, but an indirection issue. To get at a member variable, you have to first get a handle to the object, the JVM has to compute the location of the variable inside the object, and retrieve it; that's a bit more work than just accessing a local variable. But even this is just guesswork, and because of the highly optimizing nature of the HotSpot JVM, in many cases there may be no real difference at all. Still, I suppose it's worth pointing out that a for-loop index variable, for instance, should be a local variable. But since that's the natural way to do things, it's not something that people generally bother to write down.
[ September 05, 2005: Message edited by: Ernest Friedman-Hill ]

[Marilyn de Queiroz]

Well to put my question in a different way, why are some variables stored in Stacks and some in Heaps?

That's the way Gosling made Java.

Isn't this information important? If I find that accessing Heap memory is faster or more efficient to maintain than Stacks then I will probably avoid creating local variables. On the other hand, if Stacks are better, then I would prefer to create local variables.

You probably want to avoid making unnecessary objects.

Also, doesn't garbage collection play any factor here ? Maybe garbage collection of unused variables in Heap have a higher priority than that of unused variables in Stacks. So to have better garbage collection, I would prefer to create member variables, which uses Heap.

Garbage collection is only on the heap, never on the stack. No garbage to collect on the stack because all objects are on the heap.

You probably want to stick with local variables because of encapsulation issues, not memory issues.

90% of the time you don't need to worry about memory in Java.

[Rick O'Shay]

>> Isn't this information important? If I find that accessing Heap memory is faster or more efficient ...

It's important that you be aware of the distinction between the stack and the heap and that local variables are stack resident while instance variables are not. It is equally important to be aware that all objects reside on the heap, regardless of where the reference to that object lives.

It's also important to learn the language as an abstraction and that you are guided by the wealth of training materials out there. If at some point there is a common theme where an author points out that you need to be aware of the stack versus heap issue, then follow that path. Otherwise you might not be focused on the right issues for a beginning Java developer.

Finally, it is a trivial matter to explain this distinction and all of the ramifications of each and why these two structures are as they are. However it requires those in the dicussion have a solid foundation of knowledge. If you want to learn how to make pancakes you can ignore the molecular makeup of the cooking surface, at least initially.
[ September 05, 2005: Message edited by: Rick O'Shay ]

[Arnb Sen]

Hi All,

Have been trying tounderstand most of what is posted in this topic but now getting confused. For a beginner, I would like to keep it short and present my understanding. Can you please clarify if this is what was intended in this topic ?

When I talk about variables, I mean 'i', 'j', 'k' etc.. These variables contain values like 5, 'a', "abc" etc.. depending on the type of variable.

So the memory must allocate locations to store both the "variables" as well as the "values".

Local primitive variable : Stack
Value assigned to Local primitive variable : Stack

Local refrence variable : Stack
Object to which the Local reference variable points : Heap

Instance primitive variable : Heap
Value assigned to Instance primitive variable : Heap

Instance reference variable : Heap
Value assigned to Instance reference variable : Heap

Also, can anyone shed some light on whether static or final -- primitive or reference variable have any effect on where it will be stored ?

[Stan James]

Static variables are stored as data with the class rather than a particular instance of the class, but still on the heap. Final doesn't affect where they are stored. When you're in a method the arguments to the method are just like local variables on the stack.

All of this is interesting "under the covers" stuff, but the important bit is the life cycle and visibility of your variables.

Local variables are visible inside the method only (with some exceptions for inner classes ... leave those for another day) and go out of scope when the method exits. If you haven't passed references to other objects with longer scope, objects referenced by local variables are eligible for garbage collection when the method exits.

Instance variables go out of scope with the enclosing object. Again if you haven't passed references to some other object to hold they can be GCd when the enclosing object becomes eligible.

Static variables never go out of scope. The class is kept in memory just to hold them. The JVM can unload classes ... anybody know the rules for when that can happen?

Under the covers when a method exits the stack frame is released so those references go away, but I don't like to think in those terms. I grew up on machines without a "stack" so I tend to think of the stack and heap as one possible way to implement the life cycle and scope rules and not the key thing to understand. I'm rather offended by languages that force me to know about the stack & heap because they fail to abstract the machine will enough. Guess that makes me an old grouch.

[Hentay Duke]

I think your making this way to difficult. You don't decide whether or not to create a local variable by where it's stored in memory but by what your code calls for.

Java takes care of Garbage collection, java takes care of memory usage. If you're concerned by these things you're talking about much more advanced topics.

[fred rosenberger]

I agree with Hentay... deciding what kind of variable based on where it would be stored is putting the cart before the horse. How you're going to use the variable is more important. And lets not forget about readability and maintanability.

[Bert Bates]

We always make a point to teach the basics of how Java uses the stack and the heap. We think it's important because when you have a solid understanding of these topics, you'll have a much easier time visualizing and understanding topics like:
- what a reference variable really is,
- what a primitive variable really is,
- pass-by-value for both primitives and reference variables,
- memory management and garbage collection,
- variable scoping, and when variables are alive, but out of scope,
- threads,
- decorators,
- has-a relationships,
- initialization

what am I missing?

Anyway, when we teach these topics, we often return to diagrams of the stack and the heap, what goes where, and how the various Java thingies connect to each other. So our vote is that it's really, really useful to understand the stack and the heap.

hth,

Bert

[Arnb Sen]

Well.. learning to know how the inner things work is always interesting .. atleast to me.. and hence, my obvious curiosity to understand all about heap and stack...

So comingback to the question I had posted earlier --

So the memory must allocate locations to store both the "variables" as well as the "values".

Local primitive variable : Stack
Value assigned to Local primitive variable : Stack

Local refrence variable : Stack
Object to which the Local reference variable points : Heap

Instance primitive variable : Heap
Value assigned to Instance primitive variable : Heap

Instance reference variable : Heap
Value assigned to Instance reference variable : Heap

Any answer to this ?

[Hentay Duke]

I agree it's a good thing to learn, and I could certainly use a better understanding of it myself. Just seemed like in a forum where a good portion of the people are coming to figure out how to set the classpath, it might be putting the cart before the horse. But of course I don't know how much arnb knows already and apparently I was wrong. So please carry on.

Sorry I can't be more help in the matter, I'm not sure I even understand what your question is at this point.

[Ernest Friedman-Hill]

The chart is correct, except for the assumption that a primitive variable and its value are "stored" in different locations -- they're not. You would probably find this useful, and perhaps this as well.

[Bert Bates]

The thing about Java is that it's 'write once, run anywhere' - at least in theory, and as such, a lot of what you're asking about is left to individual JVM designers. So, for a specific JVM you might be able to find out the answer to some of your questions, but there's NO GUARANTEE that the next JVM you study will do it the same way. Let me give you a couple of examples:
- there is speculation that most JVMs use 64 bits for reference variables, but they don't have to, and you can't mess with them anyway.
- who knows how many bits a boolean takes? 1? 8? 16? 32? it's JVM dependent.

The first order of business is to make sure you understand these topics:

- the stack and variable scoping
- the difference between a primitive and a reference variable
- the difference between a reference variable and an object
- pass-by-copy
- what lives on the heap
- instance variables vs. local variables
- how garbage collection works

hth,

Bert

[Stan James]

I'm curious (but apparently not curious enough to look it up) does the JLS specify stack & heap allocations? I guess that would require the JVM to have virtual stack & heap even if the hardware or OS never heard of them. I'd still rather not know about them.

[Arnb Sen]

Hi Bert,

Any material where I can get a complete, thorough and detailed information with examples about

- the stack and variable scoping
- the difference between a primitive and a reference variable
- the difference between a reference variable and an object
- pass-by-copy
- what lives on the heap
- instance variables vs. local variables
- how garbage collection works

If I may ask, which book have you written ?

So are you suggesting that often-asked interview question : how many bits does an integer take

is inappropriate ?

[Ernest Friedman-Hill]

Originally posted by Arnb Sen:
So are you suggesting that often-asked interview question : how many bits does an integer take is inappropriate ?

No, actually. The sizes of byte, short, char, int, long, float, and double are precisely defined in the Java spec. But the representation of a boolean is not!

[Bert Bates]

Hi Arnb-

If I may ask, which book have you written ?

So are you suggesting that often-asked interview question : how many bits does an integer take

is inappropriate ?

As Ernest indicated I brought up the sizes of reference variables and booleans precisely because they're not specified

As for whether the interview question is appropriate... I guess it would depend on the situation.

As far as books I've written, I've written a few Java books, mostly at the beginner to intermediate level, and a fair amount aimed at Sun certifications. So, I haven't written anything that would really dive in to the bowels of any particular JVM, because my focus has been on teaching generic Java.

My purpose in answering this thread is to give advice that seems appropriate for the beginner forum. I do think that it's important for beginners to understand the topcis I listed above, and as far as cracking a given JVM goes, I'd say that that might be an interesting discussion for the intermediate or advanced forums.

hth,

Bert

[Ernest Friedman-Hill]

Originally posted by Bert Bates:

As far as books I've written, I've written a few Java books, mostly at the beginner to intermediate level, and a fair amount aimed at Sun certifications.

Handsome and humble!

[Layne Lund]

Originally posted by Arnb Sen:
...So the memory must allocate locations to store both the "variables" as well as the "values"....

No, the program only allocates a location in memory to store the value of the variable.

Layne

[Arnb Sen]

No, the program only allocates a location in memory to store the value of the variable.

So where is the variable stored ?

[Ernest Friedman-Hill]

What is the sound of one hand clapping?

The variable is the value. A known location (i.e., a piece of an object on the heap, or a slot on the stack) is set aside for the variable, and that's where the value is stored, in that location.

[Arnb Sen]

ok.. so if I say

Object a = new Object();
b = a;

This means that both a and b point to the same location in the memory i.e. the location where the Object is stored.

The above information is what we all know. In addition, what I had been thinking is that some memory is being used to store the alphabets a and b itself and hence, the confusion. But as per the last explanation, alphabets a and b are not stored in the memory.

[Arnb Sen]

Just aone liner confirmation would be very helpful. Alphabets a and b aer not stored in the memory ?

[Stan James]

The "a" and "b" in your source code are names for locations. Try making some easy-to-spot public and private variable names in source code and then look at the generated class file. Did your names make it into the class file? The names are just there so the runtime can find the values. They aren't really anything you can use without getting a bit more advanced with reflection. I'd try to not imagine or worry about where the names "a" and "b" are stored.

[Marc Verschueren]

As an 'old' procedural type programmer the Head First Java book made the difference in understanding the topics (stack, heap, ...) mentioned here.

It is an excellent book and i can't imagine beginning to learn Java with another one!

It made also clear to me that, besides that all this is indeed interesting knowledge, the JVM may place programming elements wherever he (she ?) wants ...

[Joel McNary]

Originally posted by Bert Bates:

As far as books I've written, I've written a few Java books,

Originally posted by Marc Verschueren:
As an 'old' procedural type programmer the Head First Java book made the difference in understanding the topics (stack, heap, ...) mentioned here.

This is starting to get a little surreal...can you put two and two together...?

In order to try to clear up any confusion that seems to be going on (even though I think that we might be clear on the topic at this point...) it might be useful to think of "references" as primitives in Java. Thus, our primitives include things like int, short, boolean, char and this "reference" type.

Note that what I'm saying here isn't official or anything; it's just that if I'm trying to understand what Java is really doing, I find it usefule to separate "reference" and "object" and lump "reference" in with the rest of the primitives. This particularly helps int he "pass-by-value or pass-by-reference" debates that occur. (Only primitives (including "references") are passed from method to method by value, never by reference -- so you cannot reference a "reference!")

Now, all local variables are stored in the Stack. If we take references as primitives, then all local variables are primitives. Thus, the Stack only stores primitives. The Stack maps variable names to slots in the stack; internally, you might have "j" stored at slot "15". (Note that that j::15 mapping is not stored in the stack, but rather it is something that the compiler maps when it does its magic.) So when we want to know the value of "j", we go to slot "15" and get that value.

What's returned and what you can do with it, of course, depends on the type. Different primitives support different functions -- numerics support the "+" and "-" operators, boolean are used by "if" and "while" statements, and our references support the "." dereferencing operator.

The "." operator is our key to the heap. That tell you that the reference points to a location in the heap, and we can go there to get an object. We can do stuff to the object or get values from it (which may be primitives -- including our "reference" primitive, which may point to another object somewhere in the heap).

That's about the extent that a beginner to Java really needs to know about the memory structure -- that, and don't let it get in the way of good design. It is more important for code to be easily understood by humans, since machines can understand anything that the compiler tells it to, and the compilers these says are quite smart with their optimizations.

If you are really interested in the under-the-hood workings, I suggest "Compilers: Principles, Techniques, and Tools" by Aho, Sethi and Ullman. It will tell you more than you want to know about how compilers work, and knowing that will teach you about the differences between stack and heap memory.

[Bert Bates]

This is starting to get a little surreal

I'd say we ought to throw a discussion of bytecode analysis and obfuscators (sorry my dictionary isn't handy ) into the mix, and move this baby to a more advanced forum...

[Michael Ernest]

Why not? Let's kick this up one notch and see what's what.

[Mr. C Lamont Gilbert]

Point of clarification. The JLS does not mention 'stack' anywhere. The JLS speaks only of thread local memory. Coneptually, thread local memory is all you need to understand for a programming advantage. Whether or not the JVM actually uses a stack model is up to the implementation.

[Ernest Friedman-Hill]

If I may be so bold: the JLS isn't really relevant here; it's the JVM spec that's relevant. And the JVM spec does, indeed, talk about stacks and frames. See, for example here.

Now, it's true that Java doesn't have to run on a JVM, in which case the answers to many of the questions discussed here aren't quite right, and the JLS would remain the only authority. But I'm pretty sure we're talking about conventional Java-on-a-JVM, because if we're not, then you can barely say anything useful at all!

[Mr. C Lamont Gilbert]

I can't understand your position. What knowledge is there in the JVM spec that is not a fulfillment of a JLS concept

I don't believe that is true that Java does not have to run on a JVM. Its true however that the JVM spec gives the implementor a lot of freedom but some things like byte codes must be preserved I believe.

IMHO, once you read the JLS you are set. I would refer to the JVM spec only if I were writing a JVM or wanted to comprehend java byte codes. The JVM spec is not enough to know how memory is used in any implementation as its only conceptual and you will have to consult an actual implementation spec to know how its really done.




A variable is more equivalent to a memory address. When you write x=5, the memory address x points to now contains 5. If you write x=a, the memory address x points to now contains the value contained at the address a points to. If you write Object o = new f(); the memory address o points to now contains a reference that points to the object f(which is on the heap).


Lets talk thread local memory. Objects themselves are on the Heap, but objects are made purely of primitives (int, long, 'reference', etc.) primitives are allowed to be copied into thread local memory to be used. This is why volatile is important. Conceptually, thread local memory includes your stack, and any local space the implementation might use to cache class member variables as well. So don't get the misconception that using class members is saving 'thread local memory' space.
[ September 19, 2005: Message edited by: Mr. C Lamont Gilbert ]

[Stan James]

If the JLS really says nothing about stack & heap, I stand by my opinion (!) that I'd rather not think about them. The important thing to know is variable life span & scope as it relates to code. If it turns out that visualizing the stack & heap helps you visualize life span & scope, more power to you. I'm not sure whether introducing it to newbies to coding is going to help or hurt with parts of this thread as evidence that it may just confuse. Remember abstraction and information hiding?
[ September 19, 2005: Message edited by: Stan James ]

[Layne Lund]

Originally posted by Mr. C Lamont Gilbert:
I don't believe that is true that Java does not have to run on a JVM.
[ September 19, 2005: Message edited by: Mr. C Lamont Gilbert ]

It isn't difficult to imagine a Java compiler that compiles Java code directly to machine code. On current machines, you will probably lose some features that are only available in a JVM but not typically available in native machine code. However, it isn't difficult to imagine hardware that provides support for these features.

Layne

[Stan James]

Folks have built chips where the native instruction set happens to exactly match byte code from some comiler. One of the early Pascal compilers generated byte code that was interpreted at runtime and I remember reading about a project to make a chip to run the bytecode directly. I think it was an academic exercise, not a commercial one. Man, I can almost say the name of that fool compiler, something based on UCSD I think. I was forced to use it for a couple months before somebody changed the project to Clipper.