Inside the JVM

[YuezhenQin]

Write, compile and run: javac and java (JVM)

First of all, java code goes through 2 stages: a compilation from source code to bytecode (.java -> .class) and a bytecode interpretation.

write by Intellij IDEA compile by javac decompile by javap run by java

What is JVM?

The Java Virtual Machine (JVM) is a virtual simulation of a physical computer that executes compiled Java programs (.class), according to the JVM specification document. The JVM runs as an application on top of an operating system and provides an environment for Java programs.

Because they use virtual machines, Java programs are platform-independent and can be executed on different hardware and operating systems according to the WORA (Write Once Run Anywhere) principle.

There are a lot of different JVM implementations. HotSpot is the primary reference Java VM implementation. It's used by Oracle Java and OpenJDK.

JVMs (including HotSpot) are implemented according to the Java Virtual Machine Specification.

JVM internals overview

Let's consider every subsystem in more detail.

1. class loader subsystem: .class 文件(字节码) 加载和验证子系统

It loads the bytecode for execution, verifies it and then allocates memory for the bytecode.

There are 3 standard class loaders: bootstrap, platform, and system. A class loading process is performed according to a delegation model. Although dealing with classloading is not a daily job for most programmers, understanding the concept helps to investigate some types of exceptions.

2. runtime data areas (RDA): 运行时数据区

It reporesents JVM memory. The areas are used for different purposes during the program execution.

• PC register: holds the address of the currently executing instruction;
• Native method stack: stores native method information;
• Stack area: stores method calls;

  • A call stack is a special data structure, following the LIFO rule, used by the JVM to define the method execution order and to access method information. The information includes local variables, the address of a method, method parameters, intermediate computations, and some other data.
  • A call stack consists of stack frames containing information about methods that were called and have not yet finished their execution.
  • The machine executes the method on top of the call stack. If this method calls a new one, then a new stack frame is added to the call stack, and the execution goes to this new method, and so on. When the top method finishes the execution, the corresponding stack frame is removed from the call stack, and the execution goes to the next top method.
  • The number of possible method invocations depends on the amount of memory allocated for the stack. A stack containing too many stack frames may lead to a StackOverflowError that will stop the execution.

Figure 1. JVM call stack

• Heap area: stores all created objects (instances of classes);

  The heap space is a special section of memory located in Random Access Memory, where the application stores objects created during the execution. It is closely related to stack since objects are referred from the heap using variables from the stack that store a reference to the object.

Before Java 8, a heap space had a special separate section called a Permanent Generation (PermGen) which stored loaded class metadata, String Pool objects (up to the seventh version of Java), and some other stuff. Since Java 8 it has been replaced by the Metaspace which isn't part of a heap and, unlike the PermGen, can increase its size automatically.

• Method area: stores all the class level information, like class name and all static variables.

Every thread has its own PC register, stack, and native method stack, but all threads share the same heap and method area.

3. execution engine: 字节码执行引擎

It is responsible for executing the bytecode. It also interacts with various data areas of the JVM when executing a bytecode.

The execution engine has the following parts:

1. bytecode interpreter: interprets the bytecode line by line and executes it (rather slowly);

2. just-in-time compiler (JIT compiler): translates bytecode into native machine language while executing the program (it executes the program faster than the interpreter);

3. garbage collector: cleans unused objects from the heap.

Different JVM implementations can contain both a bytecode interpreter and a JIT compiler, or only one of them.

[YuezhenQin]

JVM Option

What are JVM options? They allow configuring parameters of JVM and are usually specified at the JVM startup. Some of them are static and set at the JVM startup, which means they can't be overridden at runtime. Others are manageable: you can update them during runtime. To set an option you can use these two structures:

java [options] classname [args]
java [options] -jar filename [args]

Here [options] means single or multiple options. If several options are passed, they should be separated by spaces.

Standard options

Standard options are supported by all JVM implementations, which allow you to launch the application, set up an environment, and use some Java APIs.

-verbose:gc: enable displaying output about every garbage collection event. -verbose:class: show information about each loaded class

-D=: sets a system property value.

Non-standard options

Non-standard options start with -X, where X stands for extension, which can change the mode of runtime compilation, enable profiling, use CDS, and set heap size.

Stack Management

-Xss<size>: sets the size of the thread stack..

Heap Management

-Xms for setting the initial heap size when the JVM starts. The full structure for this command is -Xms+size. For instance, if you want to set it equal to 10MB the full command is -Xms10m or -Xms10240k.

-Xmx for setting the maximum heap size. It is configured in the same way as the previous command. If you want to set it to 1GB the full command is -Xmx1g or -Xmx1024m.

It is preferable to limit the maximum size of the heap. This will help reduce the impact of memory leaks on other processes in the operating system. Otherwise, the OS memory may be overused due to the work of your application and other processes will also lack memory.

Memory leaks occur when, due to incorrect memory management, unnecessary objects aren't deleted or become unreachable for some reason. In such situations, the memory allocated for the application is consumed faster. When the heap runs out of free memory and there isn't enough space to allocate new objects, the application will throw the OutOfMemoryError.

[YuezhenQin]

tmp

[YuezhenQin]

The relationship bettwen JDK, JRE and JDK