• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Stack & heap for Static methods

 
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can someone kindly explain how does the stack and heap work for static methods?
[ May 25, 2006: Message edited by: Isuru Sampath ]
 
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In exactly the same way they work for a non-static method. What's your point of confusion? Can you post some sample code to illustrate?
 
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What does methods have to do with stack and heap?

Object instances are stored in the heap, while their references are stored in the stack. That's all I can say.
 
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
aren't static variables stored in the stack memory ? whears instance variables obviously in the heap ?

may be that was the context of the question ...
 
Isuru Sampath
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My apologies for the poor forming of the question. I think Chris understood me right. Thanks chris.
 
Ranch Hand
Posts: 518
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Chris Wox:
aren't static variables stored in the stack memory ? whears instance variables obviously in the heap ?



No. As Jeff said earlier, declaring something static has no impact on where it is stored.

Objects are always on the heap. Primitives and object references can be on the stack or heap depending on where they are declared.
 
Chris Wox
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Scott Johnson:


Primitives and object references can be on the stack or heap depending on where they are declared.



So local variables always on stack and instance/class variables always on heap ?
 
Jeff Albertson
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Consider what a drawing of this code would look like:

x = new X();
y = x;

Both variables x and y refer to the same object, so there are three "things" in memory: the object and two variables refering to it:

[var x] ----> [object memory] <--- [var y]

So where in memory are these three things? Objects are always allocated on the heap. What about variables x and y? I avoided declaring them, on purpose. If they are local variables, they are allocated in the method's stack frame -- on the stack. Otherwise, they must be fields: either a static field (class variable) or a non-static field (instance variable). In either case, the memory for the reference is declared on the heap.

End of story? Well, a smart allocator could use what's called escape analysis to determine that an object's lifetime is so short and contained that it could be allocated on the stack. They main thing about this, is that if this happened, your code would never notice the difference -- that's semantics for yah. In these "tree falls in the forest" scenarios, does it make a sound? The answer is: you don't care. As long as the semantics of objects and references are what you know them to be, who cares about some stack -vs- heap implementation details? For example, some garbage collectors keep objects' locations fixed in the heap, others may move them around. Should you care? No, although performance characterics of gc may be relevant... This is like a post I saw earlier this week. The poster wanted to know how much memory a reference took up. I asked why and he said he was just curious. Okay, suppose the answer is "4 bytes", and he walks away with the information, then a month later he finds out it is 8 bytes. What's changed in his conception of how things work? Nothing! So aside from knowing that a reference is cheap to allocate and copy, what use is there in knowing the implementation details? It's like asking what elements are used in making the hardware. How important to programming in Java is knowing what percentage of a chip is silicon?

Hmmm... I appear to be ranting...
 
reply
    Bookmark Topic Watch Topic
  • New Topic