Monday, April 25, 2011

Memory Structure in JVM

JVM has various Runtime data areas some of which are created at the startup of JVM and are destroyed at the shutdown of JVM. Remaining data areas are per-thread.
Figure below explains the Runtime data areas that JVM has:

JVM has only two Runtime memory area types.:
  1. Heap
  2. Non-Heap
    1. PC register
    2. JVM stack
Let us explore every Memory Area one by one.
  1. JVM Heap:
    1. shared across all the Threads
    2. Created on JVM start-up
    3. Memory is reclaimed using the Garbage Collection.
    4. Heap can be of fixed size or dynamically expandable. Users can expand the memory between permissible limits.
    5. If JVM Heap is configured for dynamic expansion and sufficient memory is not available then JVM will throw OutOfMemoryError Error
  2. PC(program Counter) Register: PC is created per Thread. At one time, it executes code of one method for the associated thread.
    1. If that method is not native, It contains the address of the JVM instruction currently being executed.
    2. If the method currently being executed by the thread is native, the value of the Java virtual machine's pc register is undefined.
  3. JVM stack: Each JVM thread has a private Java virtual machine stack, created at the same time as the thread
    1. It stores frames.frames
    2. Stacks are similar to conventional language(example,) stacks
    3. These store local variables, partial results and plays part in method invocation and return
    4. Size of JVM stack can be fix or expandable. If the size is fixed and for some operation memory required is more than the size then JVM throws StackOverFlowError. If Stack size is dynamically expandable and now if the required memory is more then the available then JVM will throw OutOfMemoryError Error
  4. Method Area: It is shared among all Java virtual machine threads.It is created on virtual machine start-up.
    1. It stores per-class structures such as the runtime constant pool, field and method data, and the code for methods and constructors, including the special methods used in class and instance initialization and interface type initialization
    2. It is logically part of the heap but Specification doesn't restrict this.So it can be independent part also
    3. if JVM runs short of Method Area memory for a request then OutOfMemoryError Error will be thrown.
  5. Runtime Constant Pool: Runtime constant Pool memory is allocated from the Method Area. The runtime constant pool for a class or interface is constructed when the class or interface is created by the Java virtual machine.
    1. It is a per-class or per-interface runtime representation of the constant_pool table in a class file. Similar to symbol table in conventional languages
    2. It stores different kinds of constants, ranging from numeric literals known at compile time to method and field references that must be resolved at run time.
  6. Native Method Stacks: These stacks are provided by JVMs that support native methods (methods written in languages other than Java). They are created per thread.
Discussing about JVM stacks I mentioned about Frames. Lets discuss them now. Frames A frame is used to store data and partial results, as well as to perform dynamic linking , return values for methods, and dispatch exceptions.A new frame is created each time a method is invoked. A frame is destroyed when its method invocation completes, whether that completion is normal or abrupt.Each frame has its own array of local variables , its own operand stack (§3.6.2), and a reference to the runtime constant pool of the class of the current method. The memory of these frames is determined at compile time and allocated when the method is actually invoked at runtime. Frames have again three parts:
  1. Local variables's stack
  2. Operand stack
  3. Frame Data
So, If we summarise
  • Instance variables are stored in Heap
  • Local variables are stored on stack
  • Static variables are stored in Method Area
  • Arrays are stored on heap
Now take a look at the diagram below to make things more clear: original source of above image Now finally references:


  1. This is a clear explanation of the JVM memory which has helped to explain why the max Java heap is <2GB on 32-bit Windows. See but it's rather inaccurate now, I see

    It's prompted me to do some more exploration of Java memory. I've updated by old post about Java heap size, but this is clearly very dated now. I need to do a proper overhaul, which I'll do once I upgrade to 64-bit Windows in the next month or so.

  2. Impressed with the simple and clear explanation.