JVM JRE JDK

JVM JRE JDK

1. Basic concepts

JDK(Java Development Kit)

• JDK is Java Development Kit, which is a full-featured Java SDK. It has everything a JRE has, plus a compiler (javac) and tools (like javadoc and jdb). It is able to create and compile programs.
• tips: SDK (Software Development Kit) software development kit

JRE(Java Runtime Enviroment)

• JRE is the Java Runtime Environment. It is a collection of everything needed to run a compiled Java program, including the Java virtual machine
  (JVM), Java class library, java command and some other basic components. However, it cannot be used to create new programs.

JVM(Java Virtual Marchine)

• JVM is a virtual machine that runs Java bytecode. The JVM has specific implementations for different systems (Windows, Linux, macOS), with the aim of using the same bytecode, they will all give the same result. The bytecode and the JVM implementation of different systems are the key to the Java language "compile once, run anywhere".

What is bytecode? What are the benefits of using bytecode?

• In Java, the code that the JVM can understand is called bytecode (that is, a file with the extension . class), which is not oriented to any specific processor, but only to the virtual machine.
• The Java language solves the problem of low execution efficiency of traditional interpreted languages ​​to a certain extent through bytecodes, while retaining the portability of interpreted languages. Therefore, Java programs are more efficient at runtime, and, because the bytecode is not specific to a specific machine, Java programs can run on computers with different operating systems without recompilation.

2. JVM

• The JVM is a hypothetical computer that can run Java code, including a set of bytecode instruction sets, a set of registers, a stack, a garbage collector, a heap, and a storage method domain. The JVM runs on top of the operating system and has no direct interaction with the hardware.

run

Java programs generally have the following three steps from source code to operation:

• We all know that Java source files, through compilers, can produce corresponding .Class files, that is, bytecode files, and bytecode files are compiled into machine code on a specific machine through the interpreter in the Java virtual machine.
  That is as follows:

1. Java source file—>compiler—>bytecode file
2. Bytecode file—>JVM—>machine code

Specifically (execution of Java code)
  1) Compile code into class —> javac
  2) Load class -----> ClassLoader
  3) Execute class
    (1) Interpreter
    (2) Compiler
      client compiler
      sever compiler

What we need to pay special attention to is the step of .class->machine code.
   In this step, the JVM class loader first loads the bytecode file, and then interprets and executes it line by line through the interpreter. The execution speed of this method will be relatively slow. Moreover, some methods and code blocks often need to be called (that is, the so-called hot code), so the JIT compiler was introduced later , and JIT belongs to runtime compilation . When the JIT compiler completes the first compilation, it will save the machine code corresponding to the bytecode, which can be used directly next time. And we know that the operating efficiency of machine code is definitely higher than that of Java interpreter . This also explains why we often say that Java is a language where compilation and interpretation coexist.

  HotSpot adopts the method of lazy evaluation (Lazy Evaluation). According to the 28th law, only a small part of the code ( hot code ) consumes most of the system resources, and this is the part that JIT needs to compile. The JVM will collect information based on each time the code is executed and make some optimizations accordingly, so the more times it is executed, the faster it will be.
  JDK9 introduces a new compilation mode AOT (Ahead of Time Compilation), which directly compiles bytecode into machine code, thus avoiding the overhead of JIT warm-up and other aspects. JDK supports layered compilation and AOT collaborative use. However, the compilation quality of the AOT compiler is definitely not as good as that of the JIT compiler.

  The interpreter of each platform is different, but the virtual machine implemented is the same, which is why Java can be cross-platform. When a program runs from the beginning, the virtual machine starts to be instantiated. When a program is started, there will be multiple virtual machine instances. When the program exits or is closed, the virtual machine instance dies, and data cannot be shared among multiple virtual machine instances.

1.1 thread

  The thread mentioned here refers to a thread entity in the process of program execution . JVM allows an application to execute multiple threads concurrently. The Java thread in the Hotspot JVM has a direct mapping relationship with the native operating system thread . When thread local storage, buffer allocation, synchronization objects, stack, program counter, etc. are ready, an operating system native thread is created. When the Java thread ends, the native thread is recycled . The operating system is responsible for scheduling all threads and assigning them to any available CPU. When the native thread is initialized, the run() method of the Java thread is called . When the thread ends, all resources of the native thread and the Java thread are released.

Hotspot JVM runs in the background (system threads) mainly as follows:

1. Virtual machine thread (VM thread)

  This thread waits for the JVM to reach a safepoint operation to occur. These operations must be performed in separate threads, because threads require the JVM to be at a safe point when heap modification cannot be performed. The types of these operations are: stop-the-world garbage collection, thread stack dump, thread suspension, and thread biased locking release.

2. Periodic task thread

  This thread is responsible for timer events (that is, interrupts), which are used to schedule the execution of periodic operations.

3. GC thread

  These threads support different garbage collection activities in the JVM.

4. Compiler threads

  These threads dynamically compile bytecode into native platform-dependent machine code at runtime.

5. Signal distribution thread

  This thread receives signals sent to the JVM and calls the appropriate JVM method for processing.

1.2 JVM memory area

The JVM memory area is mainly divided into

1. Thread private area (program counter, virtual machine stack, local method area)

  The life cycle of the thread private data area is the same as that of the thread, and it is created/destroyed depending on the start/end of the user thread (in the Hotspot VM, each thread is directly mapped to the local thread of the operating system, so the storage/non-existence of this part of the memory area follows native thread life/death correspondence).

2. Thread shared area (JAVA heap, method area)

  The thread shared area is created/destroyed with the startup/shutdown of the virtual machine.

3. Direct memory.

  Direct memory is not part of the JVM runtime data area, but it is also frequently used: NIO introduced in JDK1.4 provides an IO method based on Channel and Buffer, which can use the Native function library to directly allocate off-heap memory, and then Use the DirectByteBuffer object as a reference to this memory (see: Java I/O extensions for details), which avoids copying data back and forth between the Java heap and the Native heap, so performance can be significantly improved in some scenarios.

1.2.1 Program counter (thread private)

   A small memory space is the line number indicator of the bytecode executed by the current thread . Each thread must have an independent program counter. This type of memory is also called " thread private " memory. If the java method is being executed, the counter records the address of the virtual machine bytecode instruction (the address of the current instruction). If it is still a Native method, it is empty.
  This memory region is the only one that does not specify any OutOfMemoryError conditions in the virtual machine.

1.2.2 Virtual machine stack (thread private)

It is a memory model that describes the execution of java methods. When each method is executed, a stack frame (Stack Frame) is created to store information such as local variable tables, operand stacks, dynamic links, and method exits. The process of each method from invocation to execution completion corresponds to the process of a stack frame being pushed into the virtual machine stack to popped out of the stack. Stack frame (Frame) is a data structure used to store data and some process results , and is also used to handle dynamic linking (Dynamic Linking), method return value and exception dispatch (Dispatch Exception). Stack frames are created when a method is called and destroyed when the method ends—whether the method completes normally or completes abnormally (throwing an exception that was not caught within the method) counts as the end of the method.

1.2.3 Local method area (thread private)

The local method area is similar to the Java Stack. The difference is that the virtual machine stack serves for executing Java methods , while the local method stack serves for Native methods . If a VM implementation uses the C-linkage model to support Native calls, then the stack will be A C stack, but HotSpot VM directly combines the local method stack and the virtual machine stack into one.

1.2.4 Heap (Heap-thread sharing)-runtime data area

It is a memory area shared by threads. The created objects and arrays are stored in the Java heap memory , and it is also the most important memory area for garbage collection by the garbage collector . Since modern VMs use generational collection algorithms, the Java heap can also be subdivided from the perspective of GC: the new generation (Eden area, From Survivor area, and To Survivor area) and the old generation.

1.2.5 Method area/permanent generation (thread sharing)

That is, what we often call the Permanent Generation (Permanent Generation), which is used to store data such as class information loaded by the JVM, constants, static variables, and code compiled by the just-in-time compiler . HotSpot VM extends GC generational collection to the method area, that is, uses the permanent generation of the Java heap to implement the method area , so that the HotSpot garbage collector can manage this part of memory like the Java heap, without having to develop a special method area Memory manager (the main goal of the memory recovery of the permanent belt is the recovery of the constant pool and the unloading of types, so the benefits are generally small).
The Runtime Constant Pool is part of the method area. In addition to information such as the version of the class, fields, methods, interfaces, etc., in the Class file, there is also a constant pool (Constant Pool Table), which is used to store various literals and symbol references generated during compilation. This part The content will be stored in the runtime constant pool in the method area after the class is loaded . The Java virtual machine has strict regulations on the format of each part of the Class file (including the constant pool naturally). The data that each byte is used to store must meet the requirements of the specification, so that it will be recognized by the virtual machine. Load and execute.