Java JVM Run-time Data Areas

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

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.

• StackOverflowError – this error occurs in fixed size JVM stacks, if the memory size is not sufficient during the program execution.
• OutOfMemoryError – in dynamic sized stacks, while trying to expand for more memory need and there is no additional memory available to allocate and we get OutOfMemoryError.

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.