Remember that "the Java heap" is an abstraction created by the JVM. Asking whether something is or isn't in the Java heap is ultimately a meaningless question, because it's unknowable without looking at the source code for a given JVM implementation. It doesn't and can't have any effect at all on the operation of a Java program. As far as your Java code is concerned, the static variables "exist", and that's all that matters.

Originally posted by Jack Kay: But what if I'm in Who Wants to be a Millionaire - Nonmultiple Choice Special Edition, and they ask me:

Read Ernest's reply once again please...very carefully. It makes perfect sense. Tell me, what do you understand by the word "Heap" and "Stack" ???!!

You cannot give a universal answer for this since the way memory is allocated for anything for a Java app running in a JVM is implementation dependent! Moreover...it REALLY doesn't matter until you are working in NASA and want to design and write code for a satellite!

Vijayendra <br /> <br />"The harder you train in peace, the lesser you bleed in war"

Jack Kay
Ranch Hand

Joined: Aug 01, 2004
Posts: 62

posted Aug 02, 2004 05:10:00

0

Originally posted by Vijayendra V Rao: Tell me, what do you understand by the word "Heap" and "Stack" ???!!

Well I'm reading from a book, and the heap is where objects live. And the stack is where...well, where methods that are being ridden live! I don't know jeezzz

So...the heap is where objects live, and when they're abandoned (by not having a reference), they get thrown into the garbage, and destroyed (when the garbage man comes).

And then the stack, is where they stack the methods that are being used. You see I know what I'm talking about! Now tell me where the static methods & variables live!! NOW!

Well, let's see. First of all, every running Thread has its own stack. What's stored on the stack are not "methods", but the local variables declared by each running method. In every thread, the local variables of the currently executing method are on top of the stack for that thread. It makes no difference whatsoever if that method is a member method or a static method.

Note that this has nothing whatsoever to do with where the method itself is stored (I take that to mean the code for the method.) In Java's virtual machine environment, the code is stored "nowhere". It's not accessible to Java code, and therefore it's as if it doesn't exist. Again, there's no difference here between static and non-static methods.

Now, again, where are static variables stored? Well, certainly not on the stack, as they're not local variables. And certainly not on the heap, since by definition the Java heap is where dynamically-allocated Java objects are stored. Therefore, the correct answer is somewhere else, as I said earlier.

I can understand the frustration that comes with trying to learn the language and being denied a visual in a situation like this. Unfortunately, Mr. F-H is right...for all intents and purposes, it simply doesn't matter where a particular JVM keeps this information as long as it's available when it's needed.

From a visualization standpoint, that's not a satisfying answer. So, let me give this question a shot. Beware, though, what I'm about to tell you is not actually true--it's just a good way to think about it.

As you already know, each instance of a class--each object--is dynamically allocated on the heap. So, if you think about it, what varies from one instance to the next? The instance data does...what about the methods? These vary only in the sense that they operate on a different instance's data...other than that, these do not vary from instance to instance. If I have two instancese of the Dog class, fido and rover, the eat() method executes the same sequence of steps for both fido and rover, but calling fido.eat() only alters fido's state (makes him full)...it has no effect on the data in memory associated with rover.

If I write a class Foo that has a method bar(int x), that method bar() takes an int and executes the same sequence of steps regardless of which instance owns it. I'm sure you've read about the this reference...that's how one copy of bar() in memory actually knows which instance it's working on. Every instance method implicitly passed a this reference which points to the relevant instance.

Static methods are not specific to a particular instance, so those do not get passed a this reference behind the scenes like instance methods do. That's why you can't call an instance method from a static method without referencing a specific object instance. Example:

So clearly, since each instance method has this implicit this reference passed to it, it would be a waste of memory for each instance to maintain a separate copy of its methods. If I had 100 instances of the Foo class instantiated, it makes sense that we should only need a single copy of these methods...we only need to keep 100 separate sets of data maintained by each Foo instance and pass around the appropriate this reference.

So the methods (both instance and class methods) only need one copy floating around of that executable code. Also, as you know, we only need one copy for static data as well. Where to put it?

Imagine if we had a class that represents classes. An instance of that class could represent the Foo class. Another instance might represent the Xyzzy class. The instances of this "class class" could serve as an object for containing all of the class' methods and static data. Fortunately, we have such a class...it's called the java.lang.Class class.

So (and again, this isn't an accurate representation of what's actually going on, it's just a good visualization device), you can think of each class existing itself in memory as an object, a Class instance. These objects exist like any other objects, and contain the common stuff for that particular class as instance data within itself.

I'll leave you to visualize how this works for the Class class itself.

sev [ August 02, 2004: Message edited by: sever oon ]

Jack Kay
Ranch Hand

Joined: Aug 01, 2004
Posts: 62

posted Aug 02, 2004 16:27:00

0

Originally posted by Ernest Friedman-Hill: Or in other words, the answer is "mu".

So the static variables just live in memory that the JVM keeps track of? Because the Math. methods, they're all static. I suppose those methods live in a place in memory referenced from the JVM (so they're like regular classes except there is only one reference, and it's in the JVM?)? Could I look at it that way?

You could look at it that way. Or you could look at it any which way. It will not make any difference to the JVM. . It will look at it the way the implementors tell it to. [ August 03, 2004: Message edited by: Sadanand Murthy ]

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus