Inside the JVM — Part 4 (Memory Area)

Chamal Weerasinghe
3 min readMay 7, 2021
Photo by Markus Spiske on Unsplash

“Memory is more indelible than ink.” ― Anita Loos

In previous ClassLoader 01 and ClassLoader 02 articles, we talked about the detailed approach of the classloader. But the JVM has a lot to do!

After the ClassLoader into the JVM, the class should be stored in the JVM, but it is not that simple, Java has various data types, methods to deal with and the way of storing and using them are different from one another for these purposes Java has Memory Area and it has few elements inside it.

JVM Memory Area Architecture

Method Area

The memory area is created when the JVM start-up, This area is shared among all the JVM threads in a particular JVM instance. It stores the information per-class basis structure such as

  • The runtime constant pool.
  • Field and Method data.
  • Code for methods and constructors

Based on the implementation programmer can adjust the initial size of the memory area, including minimum and maximum, allowed size. If the current request cannot be processed by the currently available space in the method area JVM will throw an “OutOfMemoryError”.

Heap Area

The Heap area is a also shared memory area just like the method area, and creates the same as when JVM startup. Heap is the runtime data area for the instances of the classes(Objects) and arrays.

Once the object is created on the heap it cannot be reclaimed back manually this is where the automatic memory management process called the garbage collection process engages with, Garbage collector will remove the objects with no direct reference and circular references without direct references from the heap area. This mechanism is based on the implementation and the type of garbage collector.

The size of the heap can be modified by the programmer as initial heap size, maximum heap size, and many other properties, But if there will be less space than expected to run the program JVM will throw an “OutOfMemoryError”.

Stack Area

Each Java Virtual Machine thread has its own space of Stack, When a thread starts a separate stack created only limited for that thread. And that will store the method call, and for each and every method call a separate data frame created and pushed into the stack, this Data Frame contains the local variables, reference to the constant pool for the particular method.

The Data Frame inside the Stack will be pop if the method returns normally to the end or if an uncaught exception caused in the middle of the thread execution, This is also where the “printStackTrace()” method provides information about the exception thrown using the one stack frame.

Stack is dynamically expanded, However, due to programming error or for any other reason if there is less space than it required JVM will be thrown a “StackOverFlowError”

PC Registers

When a thread is executing it has to keep track of the order of the execution to keep the flow without an error. PC register will be created as soon as the thread started and it will hold the details of the next execution only if the process is non-native. But if the current execution process is a native method (A method is written using C or C++) the PC register value will be undefined.

Native Method Area

JVM is written by using the languages Java, C, and C++, The JVM can identify and execute directly methods written in Java but not in C and C++ these methods are called native methods (defined using “native” keyword in methods). JVM cannot load these methods by itself for this it uses a conventional stack that is called a native method area.

--

--