aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Static Fields and shared memory Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Static Fields and shared memory" Watch "Static Fields and shared memory" New topic
Author

Static Fields and shared memory

Larsen Raja
Ranch Hand

Joined: Nov 28, 2011
Posts: 58
Hi,

Do static fields get stored in the heap memory?


Larsen.
naveen yadav
Ranch Hand

Joined: Oct 23, 2011
Posts: 384


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

Joined: Nov 28, 2011
Posts: 58

The Java language specification says:




Larsen.
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3647
    
  16

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

Joined: May 23, 2003
Posts: 1304
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
Bartender

Joined: Sep 20, 2010
Posts: 3647
    
  16

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

Joined: May 23, 2003
Posts: 1304
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
Ranch Hand

Joined: Aug 31, 2010
Posts: 394

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

Joined: Oct 23, 2011
Posts: 384


what about the object created inside a method shouldn't it be stored on stack ?
Ikpefua Jacob-Obinyan
Ranch Hand

Joined: Aug 31, 2010
Posts: 394

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

Joined: Oct 23, 2011
Posts: 384

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



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

Joined: Aug 31, 2010
Posts: 394

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



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

Joined: Oct 23, 2011
Posts: 384


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
Bartender

Joined: Sep 20, 2010
Posts: 3647
    
  16

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
Bartender

Joined: Sep 20, 2010
Posts: 3647
    
  16

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.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Static Fields and shared memory