Deep knowledge of JVM learning

Deep knowledge of JVM learningPreface

I believe a lot of people like me long-term use of Java programming, but very little attention to the JVM bottom-up implementation, which is largely because the JVM design is very sophisticated, so the project rarely encountered problems involving the JVM. But on the one hand, for the curiosity of Java underlying technology, on the other hand, some high concurrency, to the specific scenario optimization or troubleshooting problems also urgently need to understand the JVM implementation, so the landlord these two days carefully read the "inside JVM" this book about the JVM classics, Some of the implementation details of the JVM have a clearer understanding of some of the learning experience and harvest recorded with you have the same troubled friends to share.

This article will cut from several core technologies of the JVM: JVM memory Management, class file format, classes loading, garbage collection, multithreading concurrency. It is important to note that because Java is a platform-agnostic technology, the JVM must have different implementations on different platforms, so Sun released a JVM specification (Java Virtual machine specification) for that year. A JVM implemented by any group or individual must comply with this specification in order to run Java programs correctly. So many of the techniques discussed in this article may differ on different virtual machines, and this article only discusses some of the common techniques and some of the requirements of the virtual machine specification definition.

JVM Memory Management

In the Java Virtual Machine specification, the memory of the JVM virtual machine is divided into areas such as the data area in the runtime

These areas are method area, heap, Java stack, PC register, local method stack, respectively. Next we'll take a detailed understanding of the role of these memory areas.

The first thing to say is the heap, which holds all the objects created during the Java program's run, because in Java, the array is in the form of an object, so the array is stored in the heap. The heap occupies much of the JVM's memory. Therefore is also the Java GC, the garbage collector main work of the target area.

The next thing to say is the method area, which stores all the information (such as static variables, constants, global names of classes, method information, and so on) that all classes need to be loaded and related to this class. In the section on the class file that follows, we will describe in detail how the class file will be written to the data structure of the method area after it is loaded.

And the two areas described earlier are all thread-sharing, the Java stack and the local method stack, and the PC registers are all thread-exclusive, meaning that each thread has a Java stack and a PC register or a local method stack (if local methods are used).

Speaking of the need to introduce local methods, we know that Java is cross-platform, but we need to read the file, we do not have to care about which platform will be running in the future, as long as the call FileInputStream to read the file into it, do not call the underlying operating system API functions, This is because different platform Java APIs encapsulate all of these platform-related operations and provide a unified Java programming interface. The Java API implements these functions by invoking some native methods, many of which are compiled executable C programs. While Java implements some of the features of most platforms (such as IO, multithreading, etc.), some of the features of the platform are unique to the platform, and the vendors that provide the Java virtual machines often provide some local method calls in the form of dynamic link libraries to improve the functionality of the JVM on the platform. As for how to invoke and how to communicate with local methods (get return values, etc.) is what the specific JVM implementation needs to do.

Having said so much about the contents of the local method, now go back to the Java stack, where each thread has its own separate Java stack, and each time the thread executes into a new method, it pushes a stack frame inside the stack. The frame contains the local variables in the method, the operand stacks, and the frame data area. Local variables in these three regions are well understood, and are variables that are within the scope of the method, including references to basic variables and objects. Understanding the stack of operations before the JVM executes a Java program, it is possible to implement the JVM instruction set in the class file in three ways, such as interpreting execution, instant compilation execution, and mixed execution, after the JVM has loaded into the class file. The JVM instruction set is a 4-byte instruction set, just as assembly language does add operations that require two numbers to be stored in the register first, and the JVM instructs data-related operations to press the data into the stack of operations on the Java stack before it can be done. For example, the sum of I variables and J variables are assigned to the Z,JVM first to press I into the operand stack, then j into the operand stack, and finally write the result back to the local variable table or the field of the object. As for the frame data area, it is used to access the data of the method area and return the result of the method during method execution. After a method executes, if it returns normally, it presses the returned result into the stack of the previous method, and if the exception exits without a catch, the exception is run until the previous method continues to throw the exception.

The local method is just like the Java method, except that the Java stack is the memory requested by the thread that executes the Java method, and the local method is the memory that is requested to execute the local method. The following diagram shows the relationship between the two.

The last program counter is set up for each thread to record the currently executing bytecode position, which needs to be recorded under which step the thread is currently executing so that the thread can continue to execute correctly when it gets back to the CPU execution.

By the way, in Java, objects are manipulated by reference, stored inside a stack, and stored in a heap. Different JVM implementations may differ in the specific implementation of the reference, and the two popular ways are through object handle references and through direct pointer references. The JVM's GC also uses references to determine which objects can be recycled. The implementations of the two references are represented separately:

In contrast to these two reference implementations, the method of the handle pool is only necessary to modify the pointer address of each object in the handle pool when the GC needs to move the object (eliminating memory fragmentation to hold large objects). But referencing Access objects requires two address lookups, which reduces efficiency. The direct point to the object is to modify the address of each reference when it is necessary to move the object, which is much more expensive than directly modifying the handle pools, but because one addressing improves efficiency.

Careful readers may notice that each reference has a pointer to that type of data in the method area, regardless of the way it is used. This is because in Java, unlike C + + you can directly do type conversion of memory objects, Java Type conversion must be done before the type check to ensure that the conversion is safe to avoid the possible resulting program crashes. Therefore, each reference has a pointer to the type data.

This article devoted a lot of time to the content of Java stack, because the author believes that in these areas, the Java stack is the most difficult to understand the part, I hope readers can read patiently, what questions are also welcome message exchange, finally in order to deepen the heap and stack storage of what data to understand, the author Wrote two separate functions to generate OutOfMemoryError and stackoverflowerror to help understand that the OOM function continually adds data to the array object s. The last heap memory fails to meet the new addition requirement the JVM exits and OutOfMemoryError, the stack () method has a double-precision local variable of s, while the Java stack is constantly calling itself, the new method stack is pressed in, and finally the JVM exits and reports Stackoverflowerror

Java code:

PackageExperiment;ImportJava.util.ArrayList;PublicClassTESTJVM {PublicStaticvoid main (string[] args) {stackof (); //oom ();  private static void Oom () {arraylist<integer> s=new ArrayList <> (); while (true); }} private static void< Span style= "color: #000000;" > Stackof () {double S; stackof ();}}     

Operation Result:

Original address: http://www.cnblogs.com/developerY/p/3330811.html reprint please indicate the source

Deep knowledge of JVM learning