Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How JVM runs Java code

2025-01-18 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/02 Report--

This article mainly introduces "how JVM runs Java code". In daily operation, I believe many people have doubts about how JVM runs Java code. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "how JVM runs Java code". Next, please follow the editor to study!

Why do I need JVM?

One of the most important features of Java is its platform independence, and the use of JVM is the key to this feature. As a high-level programming language, Java has complex syntax and high degree of abstraction. Therefore, it is not realistic to run such a complex program directly on the hardware. So before running the Java program, we need to convert it.

A virtual machine oriented to the characteristics of Java language is designed, and the Java program is converted into an instruction sequence that can be recognized by the virtual machine through a compiler (because the operation code (opcode) of the Java bytecode instruction is fixed to one byte, it is also called Java bytecode).

JVM generally provides software implementations on various existing platforms (such as Windows, Linux), so that once a program is converted to Java bytecode, it can be run in virtual machine implementations on different platforms (write once, run everywhere).

Another benefit of JVM is that it comes with a managed environment (Managed Runtime), which can replace dealing with lengthy and error-prone parts of code, including automatic memory management and garbage collection (GC).

In addition, the managed environment also provides dynamic detection such as array out of bounds, dynamic types, security permissions, and so on, which frees us from writing code that has nothing to do with business logic.

How does JVM run Java code?

How exactly does JVM run Java bytecode? Let's take a look at it together:

From the perspective of JVM, to execute the Java code, you first need to load the class file it compiled into JVM. The loaded Java class is stored in the method area (Method Area). When actually running, JVM executes the code in the method area.

JVM divides the heap and stack in memory to store run-time data, and JVM subdivides the stack into Java method stacks for Java methods, local method stacks for local methods (native methods written in C++), and PC registers for each thread's execution location.

During the run, each time a call enters a Java method, JVM generates a stack frame in the current thread's Java method stack to hold local variables and bytecode operands. The stack frame size is calculated in advance, and JVM does not require stack frames to be continuously distributed in memory space.

When exiting the currently executed method, JVM pops up the current stack frame of the current thread and discards it, regardless of whether it is returned normally or unexpectedly.

From a hardware perspective, Java bytecode cannot be executed directly. Therefore, JVM needs to translate bytecode into machine code.

In HotSpot, the above translation process has two forms: the first is interpreter, which translates bytecode into machine code one by one and executes it; the second is just-in-time compilation (Just-In-Time compilation,JIT), which translates all bytecodes contained in a method into machine code before execution.

The advantage of the former is that you don't have to wait for compilation, while the advantage of the latter is that it actually runs faster. HotSpot adopts mixed mode by default, which combines the advantages of interpretive execution and just-in-time compilation. It first interprets the executed bytecode, and then compiles the hot code that is executed repeatedly on a method-by-method basis.

The entire Java code execution process is as follows:

Use javac to compile .java source files into bytecode (file suffix .class)

Bytecode is determined by the JIT environment variable whether it belongs to hot code (method or loop body that is called many times).

Hotspot code is compiled into executable machine code using JIT

Non-hot code uses an interpreter to interpret and execute all bytecodes

Among them, there are two types of hot code that will be compiled instantly during the run:

A method that is called many times

The body of a loop that is executed many times

For the first category, the compiler uses the entire method as a compiled object, which is also the standard JIT compilation method. For the second type, it starts from the loop body, but the compiler still uses the entire method as the compilation object, because it occurs during method execution, which is called stack substitution.

HotSpot uses a variety of technologies to improve startup performance and peak performance, and just-in-time compilation is one of the most important technologies.

Just-in-time compilation is based on the assumption that the program conforms to the 28 law, that is, 20% of the code accounts for 80% of the computing resources.

For most of the less commonly used code, we do not need to spend time compiling it into machine code, but run it by interpreting execution; on the other hand, for only a small part of the hot code, we can compile it into machine code to achieve the ideal running speed.

In order to meet the needs of different user scenarios, HotSpot has built-in several just-in-time compilers: C1, C2. The reason for introducing multiple just-in-time compilers is to make a trade-off between compilation time and the execution efficiency of the generated code.

C1 (Client compiler) is for client-side GUI programs that require startup performance, and the optimization method used is relatively simple, so the compilation time is short.

C2 (Server compiler) is for server-side programs that require peak performance, and the optimization methods used are relatively complex, so the compilation time is longer, but the execution efficiency of generating code at the same time is higher.

Starting with Java 7, HotSpot defaults to hierarchical compilation: hot methods are first compiled by C1, and then hotspots in hot methods are further compiled by C2.

In order not to interfere with the normal operation of the application, the real-time compilation of HotSpot is carried out in an additional compilation thread. HotSpot sets the number of compilation threads based on the number of CPU and configures it to C1 and C2 compilers at 1:2.

In the case of sufficient computing resources, bytecode interpretation and real-time compilation can be carried out at the same time. The compiled machine code is enabled the next time the method is called to replace the original interpreted execution.

To determine whether a piece of code is a hot code and whether it needs to trigger real-time compilation is called hot spot detection (Hot Spot Detection). There are two detection algorithms:

Sampling-based hotspot detection (Sample Based Hot Spot Detection): the virtual opportunity periodically checks the top of each thread stack. If some method often appears at the top of the stack, this method is the hot method. The advantage is that the implementation is simple and efficient, and it is easy to obtain the method invocation relationship. The disadvantage is that it is difficult to identify the reduce of the method and is vulnerable to thread blocking or other external causes.

Counter-based hotspot detection (Counter Based Hot Spot Detection): a counter is established for each method (even a code block). If the number of times of execution exceeds the threshold, it is considered a hot method. The advantage is that the statistical results are accurate and rigorous. The disadvantage is that it is troublesome to implement and can not get the calling relationship of the method directly.

HotSpot uses the second type of counter-based hotspot detection, and there are two types of counters: method call counters (Invocation Counter) and backtracking counters (Back Edge Counter).

At this point, the study of "how JVM runs Java code" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report