I gutted the JVM

1. You can’t get around the JVM when it comes to monster upgrades

The JVM, for advanced Java programmers, is a topic that cannot be avoided or avoided.

You will encounter OOM, GC and other issues during the project launch. At this time, the foundation of the JVM is very important.

In this article, we will gut the JVM from the point of view of the code we write. Look at the code we’ve written, what’s going on in each area of the JVM?

On the other hand, the JVM is also a must-ask in the interview for a Java engineer, so it’s important to know your JVM skills both in the interview and on the job.

That’s a bit of a digression. Let’s get back to it!

2. JVM region division

JVM areas, roughly have the following blocks:

• Program counter

• The virtual machine stack

• The heap

• Methods area

• Local method stack

Let’s think of the JVM as an organism, and these parts are its various organs. We’ll look at how these organs in the JVM make our Java code run in terms of how our Java code runs through the JVM.

3. Program counter

Suppose we have the following class, the very basic HelloWorld:

public class HelloWorld { public static void main(String[] args) { System.out.println("Hello World"); }}Copy the code

The above code will first exist in a file with the suffix “.java “, which is the Java source code file.

But this file is for us programmers, computers can’t read this code.

In this case, the “. Java “source code files have to be compiled into”. Class “bytecode files through the compiler.

The bytecode file with the suffix “.class “contains the bytecode compiled for the code you wrote.

Bytecode is a language that calculators understand, not a bunch of code that we write. The bytecode looks something like this:

Note: this bytecode is not a complete reference to the HelloWorld class, just to give you an example of how “. Java “translates to”. Class “.

To give you an idea, the “0: aload_0” in the picture is a “bytecode instruction”, which corresponds to the machine instructions. Only when the computer reads the machine code instructions can it know exactly what to do.

For example, a bytecode instruction might allow the computer to read or write data from memory. There are all sorts of instructions that tell the computer to do all sorts of things.

So here’s the first thing to understand: Java code is translated into bytecode, and different bytecode instructions tell computers to do different things.

What does a program counter in the JVM do when executing bytecode instructions?

** Is used to record the location of the bytecode instructions currently executed by each thread, i.e. which bytecode instructions are currently executed by the current thread.

In practice, multiple threads execute different code concurrently, so each thread has its own program counter that keeps track of which bytecode instructions are currently executed by the current thread.

The diagram below shows their relationship more clearly.

4. Java VM stack

Ok, let’s move on. Everyone knows that when Java code executes, it must be a thread that executes the code in a method. Even the most basic HelloWorld has a main thread that executes the code in the main method.

In a method, it is common to define some local variables within the method, such as the following, which defines a local variable “name” in the method.

public void sayHello() {
    String name = "hello";
}
Copy the code

The JVM must have an area for storing local variables and other data within each method. This area is the Java virtual machine stack

Why do we need this area? Because each thread executes code for various methods and calls other methods nested within methods, each thread has its own Java virtual machine stack.

If a thread executes a method, a stack frame is created for that method call

The stack frame contains the method’s local variator, operand stack, dynamic linkage, method exit, and so on. There’s something else that’s a little bit harder to understand here, and we’ll elaborate on it in other articles, but you can just understand a local variable.

Going back to the example above, if a thread calls the “sayHello” method, a stack frame for the “sayHello” method will be created and pushed into the thread’s own Java virtual machine stack.

In the local variable list of the stack frame there is the local variable “name”, as shown in the following figure.

Then if the “sayHello” method calls another “greeting” method, like this:

Another stack frame is created for the “greeting” method and pushed onto the thread’s Java virtual machine stack.

Think about why that is? There is a “greet” variable in the stack frame that is local to the greeting method.

The following figure shows the process:

Then, if the “greeting” method completes, the stack frames corresponding to the “greeting” method are pushed off the Java virtual machine stack, and if the “sayHello” method completes, the “sayHello” method is pushed off the Java virtual machine stack.

This is where the Java Virtual Machine stack component in the JVM comes in.

The thing to keep in mind here is that when you call any method that executes it, you create a stack frame for that method, and then you push it.

The stack frame stores data such as local variables corresponding to the method, including other relevant information about the method execution, and the method is removed from the stack after completion of execution.

5. Java heap memory

Another very critical area of the JVM is the Java heap, which holds the various objects we create in code, such as the following code:

public void teach(String name) {
  Student student = new Student(name);
  student.study();
}
Copy the code

The “new Student(name)” above creates an instance of an object of type Student that contains some data. Objects like Student are stored in Java heap memory.

Then in the stack frame’s local variable table, the “student” local variable of the reference type will hold the address of the student object. You can assume that “student” in the local variable table refers to the Student object in the Java heap.

The following figure shows the process:

6. Methods/Metaspace

This section of the JVM contains information about the Student class, as well as a constant pool. This section of the JVM contains information about the Student class.

However, after JDK 1.8, the name of this area was changed to “Metaspace”, which stands for “metadata space” and of course is mainly where we write our own class-related information.

7. Local method stack

In the JDK many underlying APIS, such as IO related, NIO related, network Socket related, if you look at his internal source code, you will find that many places are not Java code.

In many places, native methods will be used to call some methods in the local operating system, which may be methods written in C language or some low-level class libraries, such as the following:

public native int hashCode();

When calling this native method, there will be a local method stack corresponding to the thread, which is similar to the Java virtual machine stack, and also stores information such as the local variable table of various Native methods.

As for this, I will not expand on it here, and we will write an article on it later when we have the opportunity.

8. Off-heap memory

There is also an area, not owned by the JVM, that can be allocated outside of the Java heap through an API called allocateDirect in NIO, and then referenced and operated on outside of the heap via DirectByteBuffer in the Java VIRTUAL machine.

Many technologies use this approach, as there are scenarios where out-of-heap memory allocation can improve performance.

9. Summary of the paper

A final note:

• When Java code is run through the JVM, it must first execute the compiled bytecode instructions line by line

• Then, during execution, for method calls, stack frames are created through the Java virtual machine stack for each method, loading and unloading, and the stack frames contain local variables for the method.

• Object creation is allocated to Java heap memory

• Class information is stored in areas such as the method area/Metaspace

• There are two other special areas:

• Native method stack: a stack used to execute native methods, similar to the Java virtual machine stack

• Out-of-heap memory: Memory space can be allocated outside the Java heap to store some objects.