where do static variables live ?

[Amr k. Saleh]

where do static variables live ?

[Ram Narayan.M]

Static variables are allocated in Heap Memory Space...

[Amr k. Saleh]

Hi Ram Narayan, thanks for your fast reply but what about the reference that points to it ? where does it live ?

[Ram Narayan.M]

Reference Variable will also be allocated in the heap... What the thing is its allocated for only one time as soon as the class loads for the first time... For instance,

class Sample {

static int a=2;

}

When Sample class loads, "a" int primitive variable gets allocated in heap for only one time initialized with value 2...If not initialized, default value is initialized... If its non-static variable, it will get allocated whenever instance are created...

[Shanky Sohar]

Ram Narayan.M wrote:Static variables are allocated in Heap Memory Space...

I donot know how much i am correct but i think objects live on a heap and static variable are not associated with any object.
and for each new thread a new stack is created but static method doesnot even always associated with the thread also.

So where does static variable live.? confused.

[Amr k. Saleh]

Ram Narayan.M wrote:Reference Variable will also be allocated in the heap...

if the reference variable will also be allocated in the heap , it won't be collected by garbage collector ?

[Shanky Sohar]

Amr k. Saleh wrote:

Ram Narayan.M wrote:Reference Variable will also be allocated in the heap...

if the reference variable will also be allocated in the heap , it won't be collected by garbage collector ?

Hey guys,
Remember Only objects are collected by a garbage collector not the reference variable

[Shanky Sohar]

By the way
Welcome to JavaRanch....Amr k. Saleh

[Amr k. Saleh]

shanky sohar wrote:By the way
Welcome to JavaRanch....Amr k. Saleh

thanks shanky

[Ram Narayan.M]

If its a static reference variables referring to objects, reference variable will also live in heap...

for instance,

class Sample {

static Integer intRef = new Integer(2);

//methods
}

Integer object gets allocated as soon as class is loaded... Since Reference variable live in heap and intRef still refers to Integer object , Object wont be eligible for GC still now... In some method, if you make intRef to refer to other object (or) intRef is nullified, that object then becomes eligible for Garbage Collection(GC).

[Ram Narayan.M]

@Shanky

For each new thread, a new stackframe is allocated with local variables of method allocated in a different memory location... Since static variable is allocated in the heap and not associated with any object [its in Class scope].. Any thread can modify the static variable...

So, it is good that static method using static variables can be made thread-safe...

[Amr k. Saleh]

Ram Narayan.M wrote:If its a static reference variables referring to objects, reference variable will also live in heap...

for instance,

class Sample {

static Integer intRef = new Integer(2);

//methods
}

Integer object gets allocated as soon as class is loaded... Since Reference variable live in heap and intRef still refers to Integer object , Object wont be eligible for GC still now... In some method, if you make intRef to refer to other object (or) intRef is nullified, that object then becomes eligible for Garbage Collection(GC).

Sorry Ram Narayan for being picky
if i did something like this Sample.intRef = null; the intRef will be collected and no longer exists?

[Ram Narayan.M]

Reference variable exists...After nullification of intRef, Only Object referred by intRef will be eligible for GC....

[Amr k. Saleh]

Amr k. Saleh wrote:

Ram Narayan.M wrote: if you make intRef to refer to other object (or) intRef is nullified, that object then becomes eligible for Garbage Collection(GC).

Sorry Ram Narayan for being picky
if i did something like this Sample.intRef = null; the intRef will be collected and no longer exists?

sorry i didn't notice that in your older post.
thanks Ram Narayan so much for your fast reply and your help )

[Rob Spoor]

shanky sohar wrote:I donot know how much i am correct but i think objects live on a heap and static variable are not associated with any object.

Actually they are associated (somehow) with an object: a Class object representing the class. I said somehow because, to be honest, I don't know exactly how.

Similarly, static synchronized methods synchronize on this Class object. You can get a reference using Sample.class (if the class name is Sample), or of course using getClass() with an instance of the class.

[Shanky Sohar]

I am again pointing out that, only objects are eligible for garbage collection not refrence variable.

when refence variable is point to null then "new Integer(2)" will be eligible for garbage collection.

[Shanky Sohar]

Rob Prime wrote:

shanky sohar wrote:I donot know how much i am correct but i think objects live on a heap and static variable are not associated with any object.

Actually they are associated (somehow) with an object:

DisAgree.

Because if they are associated with an object (as you say somehow).then why not statics get serialized.As it is said we can get the value of static variable only if we do the deserilization on the same JVM.

[Shanky Sohar]

I think its totally dependent on JVM implementation where static variable lives.
May be JVM creates a special space for Statics Variables..I am not sure about this.

[Amr k. Saleh]

Hey Guys, i've come across this

The Java Virtual Machine heap is the area of memory used by the JVM (and specifically HotSpot) for dynamic memory allocation. The heap is split up into "generations":

* The young generation stores short-lived objects that are created and immediately garbage collected.
* Objects that persist longer are moved to the old generation (also called the tenured generation).
* The permanent generation (or permgen) is used for class definitions and associated metadata.

so, maybe static variables reside in the permanent generation area

[Campbell Ritchie]

Amr k. Saleh wrote:where do static variables live ?

If you go through the Java™ Language Specification and the Java™ Virtual Machine Specification, you find out the correct and definitive answer:














Don't know.

It is not specified, so different implementations can use different interpretations of the JVM can use different locations. I always thought that static fields lived inside the Class<T> object, but I might be mistaken.

[Campbell Ritchie]

Amr k. Saleh wrote:Hey Guys, i've come across this

The Java Virtual Machine heap is the area of memory used by the JVM (and specifically HotSpot) for dynamic memory allocation. The heap is split up into "generations":

* The young generation stores short-lived objects that are created and immediately garbage collected.
* Objects that persist longer are moved to the old generation (also called the tenured generation).
* The permanent generation (or permgen) is used for class definitions and associated metadata.

so, maybe static variables reside in the permanent generation area

Where did you find that?

Actually, static fields can be re-assigned (unless they are also final), so their contents would not necessarily be in the tenured or permanent generations. Note that those three generations represent one possible way to manage a heap, and there are other possibilities too.

[Mike Simmons]

Campbell Ritchie wrote:Actually, static fields can be re-assigned (unless they are also final), so their contents would not necessarily be in the tenured or permanent generations.

Well, being in the permanent generation doesn't mean the data is immutable - it means the object will not be garbage collected. At least, not anytime soon. If you have a static long, for example, then somewhere in the JVM there's got to be 8 bytes of memory that will available as long as the class is loaded. The value of that long may change over time, but it will always require 8 bytes, so it would be nice if those 8 bytes are stored somewhere that won't be GC'd. A field inside a Class object stored in permgen seems like a perfectly sensible place to put it. Though I agree with those who say this doesn't seem to be specified anywhere.

Put another way, I agree that static fields are not necessarily stored somewhere in the tenured or permanent generations. That's an unspecified implementation detail. But I don't think mutability has anything to do with it.

[Amr k. Saleh]

Campbell Ritchie wrote:Where did you find this?

http://en.wikipedia.org/wiki/Java_Virtual_Machine

[Shanky Sohar]

I think it totally depends upon our implementation that where the statics gets stored

Like in Interface since "public static final"constants are there so they will occupy a stack memory.

but inside a class,statics share a memory space along with the class

[Rob Spoor]

shanky sohar wrote:

Rob Prime wrote:

shanky sohar wrote:I donot know how much i am correct but i think objects live on a heap and static variable are not associated with any object.

Actually they are associated (somehow) with an object:

DisAgree.

Because if they are associated with an object (as you say somehow).then why not statics get serialized.As it is said we can get the value of static variable only if we do the deserilization on the same JVM.

Because they are not associated with an instance of your class, but an instance of the java.lang.Class class. Like I said, they may or may not be directly associated. But even if they are directly associated, Class objects are a form of singletons, like enums. Each ClassLoader has only a single instance of each Class object. Therefore it will use the local values, not the serialized values. Although I'm sure that the JVM mechanisms for static fields are such that they are not serialized.

[Shanky Sohar]

Because they are not associated with an instance of your class, but an instance of the java.lang.Class class. Like I said, they may or may not be directly associated. But even if they are directly associated, Class objects are a form of singletons, like enums. Each ClassLoader has only a single instance of each Class object. Therefore it will use the local values, not the serialized values. Although I'm sure that the JVM mechanisms for static fields are such that they are not serialized.

Agree.It might be possible that they associated with the instance of java.lang.Class class but like i understood earlier they are not associated with instance of any class.

[Campbell Ritchie]

Amr k. Saleh, thank you for quoting the source.

[Joseph Bernabe Bagnes]

Hey guys, we have 3 segments in our memory
1. Stack Segment
2. Heap Segment
3. Code Segment

Heap - contains all created objects in runtime, objects only plus their object attributes (instance variables)
Stack - contains local variables and Reference variables(variables that hold the address of an object in the heap)
Code - the segment where the actual compiled Java bytecodes resides when loaded
* Static members (variables or methods) are called class members, meaning they reside where the class(bytecode) resides, which is in the Code Segment.

ANSWER IS: Static members (variables or methods) reside in the Code Segment of the memory.

*Hope it'll clarify things

[Campbell Ritchie]

Welcome to the Ranch

[Joseph Bernabe Bagnes]

Campbell Ritchie wrote:Welcome to the Ranch

thanks Mr. Ritchie