Static Fields and shared memory

[Larsen Raja]

Hi,

Do static fields get stored in the heap memory?


Larsen.

[naveen yadav]

if field is a object then it will be stored on heap irrespective if it is a static or instance .
correct me if i am wrong here.

but what about the primitive fields ?

[Larsen Raja]

The Java language specification says:

All instance fields, static fields and array elements are stored in heap memory.

Larsen.

[Stephan van Hulst]

Yeah actually that's not always true. Some Java implementations may actually store objects and their fields on the stack, if those objects are only used within the context of a method call.

This however is not the case for static fields, because they belong to the global context. So static fields are always part of the heap.

[Billy Tsai]

what about a static method such as a factory method? does it occupy a certain part of the memory? do the object(s) created in that method elgibible for garbage collection or will be poped off the stack(no longer occupy memory space)?

[Stephan van Hulst]

When it comes to memory management, static methods work no differently than their non-static counterparts. Local variables and method parameters are stored on the stack, and objects may be created on the stack following escape analysis.

[Billy Tsai]

so if a object that represents some data structure is created within a static method as a local variable then after the method finishes the space that object occupies should be cleared(i.e. available again) and that object is destroyed?

[Ikpefua Jacob-Obinyan]

Billy Tsai wrote:so if a object that represents some data structure is created within a static method as a local variable then after the method finishes the space that object occupies should be cleared(i.e. available again) and that object is destroyed?

Hello Billy, I think Stephan has said it all, in my honest opinion it doesn't really matter if the Object represents the white house
That said if the reference to that Object is returned from the method and assigned to another reference variable, located outside
the method, then it will NOT be garbage collected (or NOT be destroyed).

HtH

Ikpefua

[naveen yadav]

what about the object created inside a method shouldn't it be stored on stack ?

[Ikpefua Jacob-Obinyan]

naveen yadav wrote:
what about the object created inside a method shouldn't it be stored on stack ?

@Naveen to the best of my knowledge objects live on the heap. You can imagine Objects living on the stack and the objects are referenced from outside the method where they where created "we know that once a method completes execution its properties disappear from the stack... together with the objects"?... Its a simple logic that requires a minute of brain flexing...

[naveen yadav]

Ikpefua Jacob-Obinyan wrote:

........... objects are referenced from outside the method where they where created "

suppose i have a code in which object do not referenced from outside.It is created inside the method and used inside the method.No reference to the outside

at a look

class Jivvy
{

String nav = "naveen";
void fun()
{
Jivvy ob = new Jivvy();
System.out.println(ob.nav);
ob=null;
}
}

and yes i can access the nav directly but for the sake of explanation of my point using ob to i access nav .


should not it be ob stored on stack ?

[Ikpefua Jacob-Obinyan]

naveen yadav wrote:

Ikpefua Jacob-Obinyan wrote:

........... objects are referenced from outside the method where they where created "

suppose i have a code in which object do not referenced from outside.It is created inside the method and used inside the method.No reference to the outside

at a look

class Jivvy
{

String nav = "naveen";
void fun()
{
Jivvy ob = new Jivvy();
System.out.println(ob.nav);
ob=null;
}
}

and yes i can access the nav directly but for the sake of explanation of my point using ob to i access nav .


should not it be ob stored on stack ?

Remember that 'local' variables live on the stack, while 'objects' live on the heap;
'ob' = lives on the stack
'new Jivvy()' = lives on the heap
as soon as the 'fun()' method completes, 'ob' no longer exists, hence 'new Jivvy()' becomes eligible for garbage collection.
setting 'ob' to null in this scenario is rather redundant.

[naveen yadav]

it means object is born to live on the heap.

but in the above scenario shouldn't it be appropriate to store it on stack rather than on heap.

i mean one is unnecessarily storing object on heap since it is no longer be needed outside method.

[Stephan van Hulst]

No, that particular object will always be stored on the heap, because you pass it out of the method through a call to System.out.println(). The method does not know what the println() method could do with the object, so it's unsafe to store it on the stack.

If an object is created within a method, and never assigned to a field, or passed to a method, only then may it be stored on the stack. It depends on escape analysis though. If the compiler is smart enough to realize that the println() method does not need to store a reference to the object anywhere, then it may still create the object on the stack.

For all intents and purposes it's always safest to assume that an object is created on the heap.

Local variables and method parameters are always on the stack. Instance fields are stored together with their object. If an object is on the stack, so are its fields.

[Stephan van Hulst]

Note however that this is not part of the SCJP. All you need to know is that objects and fields usually live on the heap, and local variables and method parameters live on the stack.