• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Static Fields and shared memory

 
Larsen Raja
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Do static fields get stored in the heap memory?


Larsen.
 
naveen yadav
Ranch Hand
Posts: 384
Java MyEclipse IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Posts: 58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

The Java language specification says:




Larsen.
 
Stephan van Hulst
Bartender
Posts: 6310
77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1304
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6310
77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1304
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 394
Eclipse IDE Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 384
Java MyEclipse IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

what about the object created inside a method shouldn't it be stored on stack ?
 
Ikpefua Jacob-Obinyan
Ranch Hand
Posts: 394
Eclipse IDE Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 384
Java MyEclipse IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 394
Eclipse IDE Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 384
Java MyEclipse IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Posts: 6310
77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6310
77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic