First, two concepts are clarified: JVM instances, which correspond to a independently running Java program, and JVM execution engine instances, which correspond to threads belonging to user-running programs; That is, JVM instances are at the process level and execution engines are at the thread level.

What is the JVM? – Life cycle of the JVM

JVM instance birth: When a Java program is started, a JVM instance is created, and any class that has publicStaticVoidMain (String[]args) can be used as the starting point for the JVM instance. So how does the JVM know that it is running main classA and not main classB? This requires the JVM to be explicitly told the name of the class, which is how we normally run Java programs, such as JavaclassAhelloworld, where Java is the Java virtual machine that tells the OS to run SunJava2SDK, and classA specifies the name of the class needed to run the JVM.

JVM instance execution: Main () is the starting point for the program’s initial thread, which starts any other threads. There are two kinds of threads inside the JVM: daemons and non-daemons. Main () is a non-daemon thread, which is usually used by the JVM itself. Java programs can also identify the threads they create as daemons. JVM instance death: The JVM exits when all non-daemons in the program terminate; The program can also exit using the Runtime class or System.exit() if the security manager allows it.

What is the JVM? – Architecture of the JVM

Roughly, the INTERNAL architecture of the JVM is divided into three parts: the ClassLoader subsystem, the runtime data area, and the execution engine. We’ll start with the class loader, then the execution engine, and finally the runtime data area

Class loaders, as the name suggests, are used to load.class files. The two types of JVM loaders are startup class loaders, which are part of the JVM implementation, and user-defined class loaders, which are part of Java programs and must be subclasses of the ClassLoader class. (The following is for SunJDK1.2)

Dynamic classloader: only looks for classes to load in the installation path of system classes (JavaAPI class files)

User-defined class loaders:

System class loaders: Created at JVM startup to find classes to load in the CLASSPATH directory. Other custom class loaders: It’s worth mentioning a few methods of the ClassLoader class, which are crucial to understanding how custom class loaders load.class files.

  1. protectedfinalvoidresolveClass(Classc)  

DefineClass is used to import binary class files (new types) into the method area. In this case, the class is user-defined (that is, the class responsible for loading).

FindSystemClass is loaded by the fully qualified name of the type, first by the system Class loader or the boot Class loader, and returns a Class object.

ResolveClass: Let the class loader perform join actions (including validation, allocating memory initialization, and resolving symbolic references to types into direct references). This involves the Java namespace problem. The JVM guarantees that all classes referenced by a class loaded by a class loader will be loaded by the class loader. Classes loaded by the same class loader can be accessed by each other, but classes loaded by different class loaders cannot see the opposite party, thus achieving effective masking.

2. Execution engine: It either executes bytecode or executes local methods

An execution engine requires a set of instructions, each containing a one-byte opcode, followed by zero or more operands.

How does this instruction set design meet the requirements of Java architecture?

Platform independence: Generally, The stack is used to pass the intermediate results of compilation to the connection optimizer. If the instruction set is based on stack, it is beneficial to combine the optimization work at runtime with the execution engine that performs just-in-time compilation or adaptive optimization. Generally speaking, it is to unify the data structure used for compilation and operation, which is more conducive to the development of optimization.

Network mobility: Compactness of class files.

Security: Most opcodes in the instruction set specify the type of operation. (Using the data flow analysis period for one-time validation at load time instead of executing each instruction improves execution speed).

(2) Execution technology

The main execution techniques are: interpretation, just-in-time compilation, adaptive optimization, and cha-level direct execution. Interpretation belongs to the first-generation JVM, just-in-time compilation belongs to the second-generation JVM, and adaptive optimization (currently Sun’s HotspotJVM uses this technology) combines the experience of first-generation and second-generation JVMS

Adaptive optimization: Start with all code interpreted and monitored, then start a background thread for frequently invoked methods, compile them into native code, and carefully optimize them. If the method is no longer used frequently, the compiled code is cancelled and interpreted execution continues.

3, runtime data area: mainly includes: method area, heap, Java stack, PC register, local method stack

(1) The method area and heap are shared by all threads

Heap: Holds objects created by all programs at run time

Method area: When the JVM’s classloader loads a. Class file and parses it, it puts the parsed type information into the method area.

(2) The Java stack and PC registers are exclusive to the thread during the creation time of the new thread

(3) Local method stack: Stores the state of local method calls

The run-time data area is covered in general above, and will be covered in more detail below. To cover the data area, you have to explain the data types in the JVM.

Data types in the JVM: The basic unit of data in the JVM is Word, and the length of word is determined by the JVM implementer

Data types include base types and reference types,

(1) Basic types include: Numeric types (including all basic Java data types except Boolean), Boolean (represented by int in the JVM, 0 for false, and all other int values for true), and returnAddress (the internal type of the JVM used to implement the finally clause).

(2) Reference types include: array type, class type, interface type

Given the representation of data in the JVM, let’s enter the data area of the JVM

First, let’s look at the method area:

As mentioned above, the method area is mainly used to store type information extracted by the JVM from the class file. How is type information stored? Java is known to use big endian (big? Endian: that is, the low-byte data is stored in the high-order memory. For example, 1234 is the high-order data and 34 is the low-order data, so the storage format in Java should be 12, 34 is the high-order memory, and the storage format in x86 is the opposite) to store data. This is actually the storage format for the data in the class file, but when the data is dumped into the method area, the JVM can store it in any way.

Type information: Including the fully qualified name of the class, the class’s immediate parent, class type or interface type, class modifiers (public, etc.), a list of all direct parent interfaces, Class objects provide a window to access this information (either class.forname (” “) or instance.getClass()). Here is the Class method.

getName(),getSuperClass(),isInterface(),getInterfaces(),getClassLoader();

Static variables are stored as part of the type information

References to a ClassLoader class: Other classes referenced in the class are loaded when dynamically connected

References to Class classes: Of course, as described above

Constant pool of this type: includes direct constants (String, INTEGER, and FloatPoint constants) and symbolic references to other types, fields, and methods (note: The constant pool is not a place to store constants in the ordinary sense. These symbolic references may be variables that we touch in programming

Field information: Fields declared in a normal type

Method information: Information about the various methods in a type

Compile-time constants: Class variables initialized with a final declaration or with a value known at compile time

Class copies all constants to its constant pool or to its bytecode stream.

Method table: An array containing all direct references to instance methods that its instances may call (including those inherited from parent classes)

In addition, if a class is not abstract and native, it also stores the method’s bytecode, operand stack and the method’s stack frame, and exception table.

For example:

  1. privateintspeed5LavalavanewLava}  

 

 

 

(1) THE JVM finds the Volcano. Class and extracts the corresponding type information into the method area. By executing the bytecode in the method area, the JVM executes the main () method, which always holds a pointer to the Vocano class’s constant pool.

(2) the Main () in the first instruction tells the JVM is as listed in the constant pool first class allocated memory (here again the constant pool not only storage constant information), then the JVM find constant pool first, discovery is symbol of Lava reference, test area, see if Lava class loading, the result is not loaded, Find “lava. class”, write the type information into the method area, and replace the symbol reference in the original constant pool of Volcano with the pointer to the Lava class information in the method area, that is, replace the symbol reference with the direct reference.

(3) The JVM sees the new keyword and is ready to allocate memory for Lava. It finds the location of Lava in the method region based on the first entry in the Volcano’s constant pool and analyzes how many pairs of space it needs. After determining this, it allocates space on the heap, starts the speed variable at 0, and pushes references to the Lava object onto the stack

(4) Call lava flow ()

Ok, now that you have an overview of the method area, let’s take a look at the heap

Heap implementation of Java objects:

Java object is mainly composed of instance variables (including own class and the declaration of its parent class) as well as the pointer to the data method in class, a pointer to the method table, object lock (not required), waiting for the set (not a must), GC related data (not required) (mainly depends on the GC algorithm, such as for tag and remove algorithm, need markers are whether the object reference, And whether the Finalize () method has been called).

So why do Java objects have Pointers to class data? Let’s think about it in a couple of ways

First: When a program converts an object reference to another type, how do I check whether the conversion is allowed? Class data is required

Second: for dynamic binding, you don’t need a reference type, you need a runtime type,

The puzzle here is: why do class data hold the actual type instead of the reference type? I’ll leave that for now, and I think it will be clear in the notes that follow

Pointers to method tables: this is similar to VTBL in C++, which helps to make method calls more efficient

Object lock: Used to achieve mutually exclusive access to shared data by multiple threads

Wait set: Used to allow multiple threads to coordinate efforts to achieve a common goal. Notice the wait(),notify(), and notifyAll() methods in the Object class.

Java array heap implementation: Arrays also have a Class instance associated with their Class. Arrays of the same dimension and type are instances of the same Class. For example, [[LJava/lang/Object represents Object[][], [I represents int[], [[[[B represents byte[][][] []

Now that the heap is basically covered, let’s look at program counters and the Java stack

 

Program counter: unique to each thread, created when the thread starts,

 

If Thread executes a Java method, the PC saves the address of the next execution instruction.

 

If thread executes native methods, the value of Pc is undefined

 

Java stack: The Java stack stores the running state of a thread in frames. The Java stack has only two operations, frame pushing and frame unloading.

 

Each frame represents a method, and a Java method has two ways to return it, return and throw an exception. Both ways cause the frame corresponding to the method to go off the stack and free memory.

 

Frame: the local variable area (including the method parameters and local variables, for instance methods, but also the first save this type, including the method parameters strictly in declaration order placed, local variables can be arbitrarily placed), the operand stack, the frame data area (to help support the constant pool parsing, returned to normal method and exception handling).

 

Local method stack: Depending on the implementation of a local method, such as the local method of a JVM implementation using the C-connection model, the local method stack is the C stack. When a thread calls a local method, it can be said that the JVM can use the local method to dynamically extend itself.

I think you understand what a JVM is

Reference: http://blog.csdn.net/witsmakemen/article/details/9163419




In this paper, from a little to conquer The original garden blog, blog link: http://www.cnblogs.com/ldq2016/p/5276607.html, for reprint please contact the original author