Inside the JVM — Part 05 (Execution Engine)

Chamal Weerasinghe
3 min readMay 8, 2021

--

Photo by Eduardo Buscariolli on Unsplash

“Choice is the engine of our evolution.” - Gary Zukav

In the previous article on JVM Memory Area, we talked about how the class stores in JVM and does its processes, As the flow of the JVM, the last part is the Execution area where the application execution is happening. The execution area has three main components.

Execution Engine Architecture

1. Interpreter

The interpreter’s job is to goes through each line and compile them into the native code and executing them line by line this process follows a sequential order. The disadvantage of using the interpreter is that it has to compile repetitive code blocks again and again. As an example, if some method is called in more than one place interpreter has to go through each line inside the method every time where it occurs.

2. JIT Compiler

JIT(Just in Time) compiler is introduced to overcome the issues brought by the interpreter to avoid repetition interpretation. Using the process counter it identifies what are the frequently used code segments in an application, after that, it will be compiled into the native code and stored in the cache. This will stop the interpretation of the same codes again and again.

Hence the JIT compiler speeds up the execution, compiling the entire application using the JIT compiler brings another drawback which is the startup time. The compilation process takes much more startup time compared to the interpretation process, so an enterprise-level application has to wait a considerable amount of time to startup the complete application only when depending on the JIT compiler. And because of that JVM only compiles what are really necessary and other codes will be interpreted.

Within the Execution engine there are few components currently doing on improvements and contribution to the performance improvements.

  • Profiler
  • Code Optimizer
  • Target Code Generator
  • Intermediate Code Generator

3. Garbage Collector

As discussed in the JVM Memory Area the “Heap Area” is where the objects are stored, this is an expensive memory storage unit, so there should be proper memory management on cleaning the unused and unreachable objects from the Heap Area and make that space available, Garbage collector is responsible for that operation, GC is a daemon thread, how it chooses the objects to be removed is that if the objects do not have direct references or if the object has circular references without direct references.

Furthermore programmers called to the garbage collector by using the method “System.gc()”, but that does not guarantees the immediate cleaning process because the to run garbage collection itself consumes the performance of the application in that case JVM decides the proper time for cleaning process.

However programmers can adjust the size of the Heap Initial size (-Xms:) and Maximum size (-Xmx:) at the JVM startup. There are also different garbage collector implementations available such as.

  1. Serial Garbage Collector
  2. Parallel Garbage Collector
  3. CMS Garbage Collector
  4. G1 Garbage Collector

Java Native Interface (JNI)

JNI act as an intermediate brigde JVM execution area and then Native Method Libraries. JVM cannot operate it by itself on the platform without having it’s help so there should be way of communication when those methods are needed JNI act as a middle man and provides the API for execution of native methods.

Native Method Library

As discussed before those are the libraries and methods to execute when java application runs on a particular platform those are mostly written on using C and C++.

--

--

No responses yet