Java JVM Run-time Data Areas

Last modified on March 31st, 2014 by Joe.

Understanding Java Virtual Machine (JVM) run-time data areas are critical to better Java programming. One of the most dreaded errors in Java is OutOfMemoryError and it is related to Java Virtual Machine (JVM) memory areas. We should have better understanding of JVM internals, how its data area works so that we will have better grip over these kind of JVM errors. In this article, we shall learn about types of run-time memory areas in JVM and how they work.

Types of Java JVM Run-time Memory Areas,

  1. Program Counter (PC) Register
  2. Java Virtual Machine Stacks
  3. Heap Memory
  4. Method Area
  5. Run-time Constant Pool
  6. Native Method Stacks

JVM Run-time Data Areas

These six JVM run-time memory areas can be broadly classified into two groups,

  1. Managed per-thread – If the memory area is uniquely allocated for every single thread created. These data area are initialized on thread start and destroyed once the thread completes.
  2. Shared with all threads – If the memory area is common and can be accessed by all the threads. These are initialized when JVM is started and destroyed on shutdown.

1. Program Counter (PC) Register

In general computer architecture terms, program counter (PC) register keeps track of the current instruction executing at any moment. That is like a pointer to the current instruction in sequence of instructions in a program. This is same in Java JVM terms also. We have multithreaded architecture as Java supports multithreading and so, a program counter (PC) Register is created every time a new thread is created. PC keeps a pointer to the current statement that is being executed in its thread. If the current executing method is ‘native’, then the value of program counter register will be undefined.

2. Java Virtual Machine Stacks

JVM stacks are used to store Java virtual machine frames. JVM will not do any manipulation directly with the stacks and they are only storage units for frames. Memory size of stacks can be of two types, fixed and varying size. Varying size can dynamically expand as per the need. Java JVM frames are created when a method is invoked, it performs the dynamic linking. JVM stacks are created and managed for each thread.

3. Heap Memory

Heap data area is used to store objects of classes and arrays. Heap memory is common and shared across multiple threads. This is where the garbage collector comes into picture. In an earlier article I have written in detail about heap memory and memory generations like young gen, PermGen. Heap data area is created at VM startup. Claiming the memory back is done automatically by the garbage collector (GC). This is one of the best feature of Java. If the allocated memory is not sufficient at run-time JVM can throw OutOfMemoryError.

4. Method Area

In general, method area is a logical part of heap area. But that is left to the JVM implementers to decide.  Method area has per class structures and fields. Nothing but static fields and structures. It also includes the method data, method and constructor code, run-time constant pool. Method area is created at JVM startup and shared among all the threads. JVM will throw OutOfMemoryError if the allocated memory area is not sufficient during the run-time.

5. Run-time Constant Pool

Run-time constant pool is created out of the method area and it is created by JVM when a class or interface is created. Run-time constant pool contains the constant_pool table which is applicable for per class or interface. It contains the literals. JVM will throw OutOfMemoryError when it cannot find memory to allocate to run-time constant pool.

6. Native Method Stacks

JVM that supports native methods will have native method stacks. It is used for native methods, and created per thread. If the native methods cannot be loaded by a JVM then it need not have native method stacks. Memory size is managed similar to general JVM stacks like fixed or dynamic. JVM will throw StackOverflowError or OutOfMemoryError accordingly.

Comments on "Java JVM Run-time Data Areas"

  1. Rishikesh says:

    Very good article disclosing JVM internals. Thanks!

  2. phani says:

    nice one

  3. kalpesh says:

    very nice article – as usual :)

  4. Sachin Kumar says:

    Thanks Joe!! You summarized the whole stuff very clearly.
    However, I have the below doubt-
    Point #5 says – Run-time constant pool is created out of the method area and it is created by JVM when a class or interface is created.
    Whereas pt #4 says – Method area includes the method data, method and constructor code and run-time constant pool.
    This seems to be somewhat confusing to me. Can you pls elaborate more on this? Thanks

  5. swspnil says:

    Very useful …. thanks JOE…

  6. Ankit Singh says:

    good but go through deep.

  7. Anonymous says:

    Hi Joe ..
    Neatly explained.
    Look forward for more articles on JVM topics.

    Happy Thanksgiving !

    Arvind Ram

  8. Vishal says:

    Thanks joe for such a short and neat article.

    I have a question.
    How many instance of ‘Method Area’ and ‘Run-time Constant Pool’ will be there in Heap
    Single or multiple ?


  9. Pratik says:

    nice one…

  10. Fahad says:

    Thanks Joe

    Very nicely explained.

  11. Vinuraj M V says:

    Thanks a lot Joe..

  12. Anonymous says:

    -Xss is it expandable or is it for fix memory

  13. Binh Thanh Nguyen says:

    Thanks, this post help me a lot.

  14. Gang says:

    Yes, I also have same doubt. But in my opinion that run-time constants pool should be included by method area.

  15. […] uses JVM Stack memory to create the new objects that are formal parameters. This newly created objects scope is within […]

Comments are closed for "Java JVM Run-time Data Areas".