wood burning stoves 2.0*
The moose likes Java in General and the fly likes Where do static variables & methods live? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Where do static variables & methods live?" Watch "Where do static variables & methods live?" New topic
Author

Where do static variables & methods live?

Jack Kay
Ranch Hand

Joined: Aug 01, 2004
Posts: 62
Because I was reading and since static variables/methods aren't objects, they don't live on the heap. And since they're not being run in a thread all of the time, they can't live on the stack...

Hmmmm! I'm guessing the heap, because the stack seems too off.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

Short answer: it's implementation-dependent.

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.


[Jess in Action][AskingGoodQuestions]
Jack Kay
Ranch Hand

Joined: Aug 01, 2004
Posts: 62
But what if I'm in Who Wants to be a Millionaire - Nonmultiple Choice Special Edition, and they ask me:

Q: Objects & their instance variables live on the heap. Threaded methods & their variables live on the stack. Now, where do the static variables live?

A: It doesn't matter! As long as we know they're there!?
[ August 01, 2004: Message edited by: Jack Kay ]
Vijayendra V Rao
Ranch Hand

Joined: Jul 04, 2004
Posts: 195
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
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!
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

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.

Or in other words, the answer is "mu".
sever oon
Ranch Hand

Joined: Feb 08, 2004
Posts: 268
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
Originally posted by Ernest Friedman-Hill:
Or in other words, the answer is "mu".


Objects --> Heap
Threads --> Stack
Static --> mu (Memory Unit?)

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?
Sadanand Murthy
Ranch Hand

Joined: Nov 26, 2003
Posts: 382
Originally posted by Jack Kay:

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 ]

Ever Existing, Ever Conscious, Ever-new Bliss
Nick George
Ranch Hand

Joined: Apr 04, 2004
Posts: 815
Originally posted by Vijayendra V Rao:




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" ???!!

[...]



Can I get a shout-out for the "be nice" rule?


I've heard it takes forever to grow a woman from the ground
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Jack Kay:
mu (Memory Unit?)


More likely http://en.wikipedia.org/wiki/Mu_%28Japanese_word%29


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
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
Originally posted by Jack Kay:


Objects --> Heap
Threads --> Stack
Static --> mu (Memory Unit?)


mu is short for "moooh" which is the sound a cow makes when it doesn't care where the grass comes from as long as it tastes good


42
Jack Kay
Ranch Hand

Joined: Aug 01, 2004
Posts: 62
Originally posted by Jeroen Wenting:
mu is short for "moooh" which is the sound a cow makes when it doesn't care where the grass comes from as long as it tastes good


"Your question is inherently nonsensical and irrelevant."
- http://en.wikipedia.org/wiki/Mu_%28Japanese_word%29

Well, I'll go with the cow lol.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Where do static variables & methods live?
 
Similar Threads
Reference Variables
where variable and objects are stored
Static variables
Where do static variables (class variables) live (scope)?
static variables in multithreading