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

Today, I will talk to you about how to analyze the jvm architecture, which may not be well understood by many people. In order to make you understand better, the editor has summarized the following contents for you. I hope you can get something from this article.

This is not an article that describes what jvm is, nor does it introduce the cross-platform features of jvm, nor is it an article about jvm security features, let alone an article on jvm instruction manipulation and data operations. The following focuses on the life cycle of types.

The life cycle of a type involves: class loading, jvm architecture, garbage collection mechanism.

Why talk about jvm architecture? Because the class loading and garbage collection mechanisms are closely related to the jvm architecture.

So what is the jvm architecture?

When jvm runs, it will request a memory area from the system (different jvm implementations may be different, some can use virtual memory), and divide this memory into parts to store many things, such as objects created by the program, parameters passed to the method, return values, local variables, etc., which we call the "runtime data area". The runtime data area can be divided into method area, heap, java stack, pc register and local method stack.

Looking at the picture above and these comments, you may have a rough idea of what the jvm system looks like, but you may not know what the method area in the runtime data area is for.

Method area: when the virtual machine loads a class file, it parses the type information from the binary data contained in the class file. However, these types of information are put into the method area. Because the method area is shared by all threads, thread safety of the data must be considered. If both threads are trying to find the lava class, only one thread should load while the other thread waits if the lava class has not been loaded.

Pc registers: each new thread generation will get its own pc register and a java stack frame.

Heap: stores all objects generated when the program is running. Heap is a thread-shared memory area, so we need to consider concurrency when writing multithreaded programs.

Java stack: the java stack consists of many stack frames, as shown in the figure. When a thread calls the java method, the virtual machine pushes a new stack frame into the java stack. When the method returns, the stack frame is popped up from the java stack and discarded.

So now you can imagine how some jvm works, should you go on to talk about how it works? But there is no hurry, first understand the loading mechanism of the following classes.

Before you understand the class loading mechanism, understand the class loaders in jvm: Bootstrap Loader, ExtClassLoader, AppClassLoader.

ExtClassLoader (responsible for loading rt.jar, charsets.jar under jre) and AppClassLoader (responsible for reprinting class packages under classpath) are subclasses of ClassLoader (abstract classes)

Bootstrap Loader (responsible for loading the jre core library) is the root loader that is written by cswab + and cannot be seen in java.

These three class loaders have a parent-child relationship. The root loader is the ExtClassLoader parent loader and ExtClassLoader is the AppClassLoader parent loader.

The loading of classes in Jvm is also the threshold of the security sandbox model. The Java load class uses the "parent delegation mode"-that is, overall responsibility for the delegation mechanism.

Okay, now let's get an idea of the loading process.

When loading a class, if the user specifies a class loader to load, then that class loader will first delegate to the parent class loader, all the way to the root loader. If you load a java.lang.String, because it belongs to the core class library and has already been loaded, it will directly return a class object. What if it is a class that the root loader cannot find? It is then handed over to the subclass (the next parent class) loader, and if the class file is still not found, it will then be loaded by the class loader specified by the previous user. The process of loading the superclass is not described here, please do not neglect it.

If someone maliciously wrote a basic class java.lang.String, will it affect the virtual machine? Not because this class will eventually be loaded by the root loader, but the root loader will only go to the jre core class library to load, the final returned class type is not user-written String, and the system comes with String, that is, user-written String will never be loaded.

Now that we understand how the classloader works, we also need to understand the class file format

The ClassFile Structure ClassFile {U4 magic; / / magic number U2 minor_version; / / class minor version number U2 major_version; / / class major version number U2 constant_pool_count; / / constant pool count cp_info constant_ pool [constant _ pool_count-1]; / / constant pool U2 access_flags; / / modifier U2 this_class; / constant pool index U2 interfaces_count; U2 interfaces [interfaces _ count]; U2 fields_count Field_info fields [fields _ count]; U2 methods_count; method_info methods [methods _ count]; U2 attributes_count; attribute_info attributions [attrudes _ count];}

There's a lot we need to know, but what we don't understand is the cp_info constant_pool constant pool.

There are many tables in a constant pool.

CONSTANT_Utf8 UTF-8 encoded Unicode string CONSTANT_Integer int type literal value CONSTANT_Float float type literal value CONSTANT_Long long type literal value CONSTANT_Double double type literal value CONSTANT_Class to a class or interface symbol reference CONSTANT_String String class type literal value CONSTANT_Fieldref to a field symbol reference CONSTANT_Methodref to a class method symbol A symbolic reference by CONSTANT_InterfaceMethodref to a method in an interface. A partial symbolic reference by CONSTANT_NameAndType to a field or method.

I'm not going to explain these table structures, but it doesn't matter if you don't know enough about class files. So we understand the jvm system, classloader workflow, then we take a closer look at the classloader work, jvm runtime data area changes, the structure of the method area, and so on.

During class loading, each class loader forms a table in the method area that records the permission names of the loader and the corresponding class. Without such a table, it forms the namespace within jvm. At the same time, the constant pool and other information of this class is also returned in the method area.

Well, speaking of these, in fact, the process is still very vague, and a lot of knowledge has been left behind, so let's now look at a more detailed loading process.

When a normal class is loaded, the loadClass method of the class loader is called. If the class you want to load has not been loaded into the namespace, jvm passes a fully qualified name of that type to the classloader, that is, the loader of the entry of the constant pool CONSTANT_Class_info (the table stores information about the parent class, classloader, and so on) to attempt to load the referenced type. If the type that originates the reference is defined by the jvm loader, it is loaded by the jvm class loader, otherwise it is loaded by the user-defined loader, then once the referenced type is loaded, jvm carefully examines its binary data if the class is a class and is not java.lang.Object. Jvm loads (recursively applies) its fully qualified name based on the data. This process also requires recursive hyperinterfaces.

Loading is almost finished, a complete process is: load-connect-initialize

Then the connection and initialization go by, with an emphasis on garbage collection.

The process of connection is mainly verification (confirming that the type conforms to the semantics of the java language, and it does not endanger the integrity of the virtual machine), preparation (the java virtual machine allocates memory for class variables and designs default initial values), and parsing (the process of finding conformant references to classes, interfaces, fields, and methods in the constant pool of types and replacing these symbolic references with direct references).

During initialization, if there is a direct superclass in the class and the superclass has not been initialized, initialize the direct superclass first. Initializing an interface does not require initializing its parent interface.

Add:

Jvm when running a method, first push the method into the java stack, which contains local variables and other information, so where to put the object? What is pushed into the stack are references to objects, that is, variables, and all objects are stored in the heap.

Why put objects on the heap and data such as variables on the stack? To put it bluntly, the object is too large, so it is troublesome to store it in the stack. (of course, the standard answer is not like this. I'm just explaining the substance here.)

After understanding such a process, we must understand the garbage collection mechanism.

Basic recovery algorithm

1. Citation count: an older recycling algorithm. The principle is that this object has a reference, which increases a count, and deletes a reference reduces a count. For garbage collection, only objects with a count of 0 are collected. The deadliest thing about this algorithm is that it can't handle circular references.

two。 Mark-clear: this algorithm is executed in two phases. The first phase marks all referenced objects from the reference root node, and the second phase traverses the entire heap to clear the untagged objects. This algorithm needs to pause the entire application and generate memory fragmentation at the same time.

3. Copy: this algorithm divides the memory space into two equal regions, using only one area at a time. When garbage collection, traverse the current use area and copy the objects in use to another area. The secondary algorithm only deals with objects in use at a time, so the replication cost is relatively small, and the corresponding memory can be demarcated after copying, but there is a "fragmentation" problem. Of course, the disadvantage of this algorithm is also obvious, which requires twice the memory space.

4. Mark-organize: this algorithm combines the advantages of "mark-clear" and "copy" algorithms. It is also divided into two stages, the final stage marks all the referenced objects from the root node, and the second stage traverses the entire heap, clearing the untagged objects and "compressing" the living objects into one of the pieces of the heap and discharging them sequentially. This algorithm not only avoids the fragmentation problem of "mark-clear", but also avoids the space problem of "copy" algorithm.

5. Incremental collection: implement the garbage collection algorithm, that is, garbage collection while the application is in progress.

6. Generation: a garbage collection algorithm based on the analysis of the life cycle of objects. The objects are divided into the young generation, the old generation and the persistent generation, and the objects with different life cycles are recycled using different algorithms (one of the above methods).

After reading the above, do you have any further understanding of how to analyze the jvm architecture? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.