More stack and heap

I am still struggling to understand the circumstances when an instance name is stored on the stack and when it is stored on the heap. According to my Sun training, instance names are on the stack, pointing the instance on the heap. But if an instance has a class instance variable inside it, then perhaps that instance variable field points to another instance on the heap. Here we have the pointer inside the heap. I need to understand when the instance name is on the stack and when it is inside the heap. Also, is there just one stack or does each instance have a separate stack? Maybe that is my confusion. I am trying to resolve what I was taught at Sun, which is incomplete and confusing. I have a partial clarification from an expert, but I need more to understand this.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

I am, in retrospect, not quite sure what you are referring to when you say "instance name". It appears to correlate somehow to an object declaration (versus an instantiation). In my understanding and experience declarations have no practical representation in the Java program space. (The JVM probably has to keep track of what classes have been loaded, but that is a separate environment). For example I can write:

class MyObject
{   MyObject()
    {  return;

    int doSomething()
    {   HotelSys hs;
        int i;


This code will compile and can be run, WITHOUT the existence of a HotelSys class. The JVM will only concern itself with the class HotelSys if it actually needs to create one, or access one of its methods.

Perhaps you could explain why it is important that you understand this.

Stack and heap are simply demarcated in general. Anything created with a new keyword goes on the heap. This would include the object created, its class variables. These things can be, if needed, garbage collected.
Anything that exists due to a declaration in a method exists on the stack. This will include primitive objects (int, long etc.) as well as references to objects on the heap (MyObject my=new MyObject()). In the last case the reference is on the stack, and the object is on the heap. Also method arguments and return addresses placed on the stack. These things disappear when they go out of scope. Usually when the method returns.
There is only one stack.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
HanRuiAuthor Commented:
My motivation for the question is not to solve a particular technical problem, but rather to understand what is going on so that I can better communicate this to my students. Your explanation is consistent with what was taught at Sun, but in conflict with some answers to my question posed here. Some answers here suggested that an instantiated class on the heap could contain pointer references to other objects on the heap.
"Some answers here suggested that an instantiated class on the heap could contain pointer references to other objects on the heap".


class MyObject
{   YourObject yo;

    {   yo=new YourObject();


Now when you create a MyObject:

MyObject mo=new MyObject();

mo references an instance of MyObject which is on the heap. In that instance of MyObject there is a reference to an instance of YourObject, which is also on the heap. I can't think of any way, off hand, to instantiate an object on the stack. An object is instantiated with "new", which puts it on the heap.

I can offer one other theory as to what your "instance name" might be. An object consists of code and data. Most of the time when we think of the object we think of the data portion of the object. This is what is created when you "new" an object. This is what exists on the heap. Primitive objects consist of only data. Primitive objects are things like int, long and references.
Now, when the JVM needs to load a class (and it doesn't do this until it needs to be instantiated) the class (the class file which the code portion) gets loaded into a conceptually separate area of memory where all code resides. At present, code can not be unloaded. Any class that gets loaded, even if it is only used momentarily, has its code in this area for the duration of the programs execution. Whenever a class is instantiated the JVM will use the information in the class to determine how much space to set aside on the heap, and, when referencing an instance of the object, the code portion determines the interpretation of the data in the heap (which variables there are and in what order). Since the classes can not disappear, I suppose you could consider them to be existing in a "code stack". Stack in the sense that stuff is pushed on one after another. On the other hand, no code is ever "popped" from this stack. This area is completely separate from the heap, and from the stack on which automatic variables exist. It is completely managed and controlled by the JVM. The programmer has absolutely no way of influencing it at all. Object references will be pointing into the heap (not the codestack). The object on the heap (which is actually only its data portion) contains information as to what kind of object it is, and where its methods (code) are (is). Again, though, this aspect is "hidden" from the programmer in the sense that there is no way to manipulate it. It is stuff the JVM uses to make the program go.
HanRuiAuthor Commented:
In the start() method, I have:

Label myLabel = new Label("Hello");

Each time you resize the browser, the new instance of Label is added to the Applet container by FlowLayout manager. My question is this. Where is each instance of the Label, the myLabel, stored? It must be on the heap, since each instance is an object. Where, then, is the pointer reference to each instance that is stored on the heap? According to my Sun training, in this situation the instance name myLabel goes on the stack with a pointer reference to the instance on the heap. So the stack fills up with duplicate "myLabel" names, each of which points to a separate instance on the heap.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.