where does static variable reside

[Imtiaz Nizami]

Local variables of a method reside on stack. Instance variables reside on the heap within objects. As one of the positive sides of declaring static or class variable is to save memory I am sure it cannot reside in every object. Where does it live?

Also, please explain if there might be a reason to declare a static variable within a method? I know using static variable in 'C' functions will maintain variable's value when the method is called subsequently.

[Jeanne Boyarsky]

Originally posted by Imtiaz Nizami:
Also, please explain if there might be a reason to declare a static variable within a method? I know using static variable in 'C' functions will maintain variable's value when the method is called subsequently.

Java does not have the concept of a static variable within a method.

[John Dell'Oso]

I think that static variables "live" in a fixed location in RAM - whether or not that means the stack, I'm not too sure. The stack "lives" in RAM but is generally supported by the processor via a stack pointer.

Regards,
JD

[Imtiaz Nizami]

Thank you both. Can I get an answer to where does static variable live in terms of stack, heap etc. Thanks again.

[Pravin Jain]

Not sure, but the Class instance for the class, could be a good
place for the static variable. The Class instances are in the
method area, which most of the time is part of the heap.
[ June 02, 2007: Message edited by: Pravin Jain ]

[Ilja Preuss]

As far as I know, static variables reside in the same space as the class' byte code - a special area of the heap called the "permanent generation".

[Kaydell Leavitt]

Wouldn't you want to separate static variables from byte code so that the byte-code could be read-only and the static variables could be read-write?

Kaydell

[Jim Yingst]

[Ilja]: As far as I know, static variables reside in the same space as the class' byte code - a special area of the heap called the "permanent generation".

That's my understanding too. I think both are inside the Class object associated with the class, which is stored on the heap, in the permanent generation.

[Kaydell]: Wouldn't you want to separate static variables from byte code so that the byte-code could be read-only and the static variables could be read-write?

I don't believe that's necessary. The JVM places sufficient restrictions on code so that you can't accidentally or intentionally write to areas of memory you're not supposed to.* Even if it's right next to something you are supposed to be able to write to.

*One might quibble over what "supposed to" means here, since reflection allows various ways to circumvent some of the rules of Java. But you still can't overwrite the code portions of a class definition.

[Ilja Preuss]

Originally posted by Kaydell Leavitt:
Wouldn't you want to separate static variables from byte code so that the byte-code could be read-only and the static variables could be read-write?

How would separating them in memory help with that?

[Kaydell Leavitt]

[Me]: Wouldn't you want to separate static variables from byte code so that the byte-code could be read-only and the static variables could be read-write?

My idea is apparently wrong. I agree that In Java, we don't need to worry about unititialized pointer since all object references aren't pointers and object references are either initialized to null or you get a compile-time warning. Also, we don't have pointer arithmetic. Also, in Java, you can't index off the end of an array and stomp on something that you shoudln't since we are protected from ourselveswith the ArrayOutOfBounds exception and we are protected by the NullPointerException.

I accept what people have been telling me that there is not need for memory protection for where the byte-code and the static variables live (wherever that may be).

Kaydell
[ June 03, 2007: Message edited by: Kaydell Leavitt ]