views:

380

answers:

3

Hey guys, I'm reviewing some questions but I can't really figure it out, i looked through the text book but i'm not sure where i can find answer...

I know it would be quite hard to do memory diagrams w/o pictures but please bear with me.

interface Lovable
   public void love();

class Foo implements Lovable
   public void love();
      // something
   public int val()
      // return something1

public class Love
   public static void main(String args [])
      Foo foo = new Foo()
      foo.love()
      foo.love()
      int bar = =foo.val()
      System.out.print(v)

Now, I see that foo is declared with new, so I know actual Foo class information is stored in heap and there's a frame?pointer? that points to that memory space in heap on top of the stack (before foo calls any methods). so then what about the interface? would that be stored in the heap too?

so on the bottom of the stack would be the class Love(also contains int bar), a pointer that points to Foo foo in heap, a frame for foo.love(), another frame foo.love(), a fram for foo.val(), a framee for print?

Am i getting the idea ? or am i really really far off? If you know any where I can get more information, please let me know. I appreciate any input..

+4  A: 

Generally, are objects are stored on the heap managed by the garbage collector.

Only the latest release of Java 6 has escape analysis to store objects on the stack if they do not escape.

Class information is store in the perm space.

Thomas Jung
A: 

foo the reference is on the stack. The object pointed to by foo is on the heap (it may actually be optimised onto the stack in simple cases, but conceptually it is on the heap).

The object's class may have superclasses and implement interfaces. However, whichever class a field is declared in, instances fields are all kept in the same allocation of memory on the heap.

Tom Hawtin - tackline
A really nice picture!
Thomas Jung
That's very odd...
Skilldrick
Oh, yes it has 3 arms.
Thomas Jung
A: 

Memory layout depends on the JVM and JVMs have lots of leeway about how to use memory as long as they maintain the logical view of the Java object model that the programmer thinks about. The Sun JVM has several "heaps" because it implements generational garbage collection. Objects are created in the eden space, which is treated as a stack so that objects can be created very quickly. If they live long enough, objects get moved to longer lived generations, and those are implemented more like normal dynamically allocated heaps. The JVM stores classes and interned strings in the "permspace" heap. Permspace is not actually permanent: classes are collected when there are no more references to their instances or classloader. And, as pointed out above, Java 6 will allocate an object on the call stack if it can determine that references to the object do not leave the block.

Nat