How the "Go" JVM works

First, the life cycle of the JVM

1. The JVM instance corresponds to a separate running Java program which is a process level

A) start. When a Java program is started, a JVM instance is generated, and any class that has the public static void main (string[] args) function can be used as a starting point for the JVM instance to run

b) run. Main () is the starting point for the program's initial thread, and any other thread is started by that thread. There are two types of threads inside the JVM: daemon and non-daemon, main () is non-daemon, the daemon is usually used by the JVM itself, and Java programs can also indicate that the thread they created is a daemon thread

c) extinction. The JVM exits when all non-daemon threads in the program terminate, and the program can use the runtime class or System.exit () to exit if the security Manager allows it.

2. The JVM execution engine instance corresponds to the thread that belongs to the user running the program, which is at the thread level.

Second, the JVM architecture

1. Class loader (ClassLoader) (Used to load. class files)

2. Execution engine (byte code execution, or local method execution)

3. Runtime data area (method area, Heap, Java stack, PC register, local method stack)

Third, JVM class loader

Steps for the entire class loading process of the JVM:

1. Loading

The load process is responsible for locating the binary bytecode and loading it into the JVM, the JVM completes the class loading through ClassLoader through the class name, the package name of the class, and also uses the above three elements to identify a loaded class: class name +

Package name +classloader Instance ID.

2. Links

The link process is responsible for verifying the format of the binary bytecode, initializing the static variables in the load class, and parsing the interfaces and classes called in the class.

When the checksum is complete, the JVM initializes the static variable in the class and assigns its value to the default value.

Finally, all properties, methods in the class are validated to ensure that they need to invoke the properties, methods exist, and have the permissions (such as public, private domain permissions, etc.), resulting in nosuchmethoderror, Nosuchfielderror and other error messages.

3. Initialization

The initialization process is the initialization of static initialization code, constructor code, and static properties in the execution class, and in four cases the initialization process is triggered:

New was called;

Reflection invokes the method in the class;

The subclass invokes initialization;

The initialization class specified during the JVM startup process.

JVM Class Load Order:

The JVM two kinds of loaders include: Start class loaders and user-defined class loaders.

The Startup class loader is part of the JVM implementation;

The user-defined class loader is part of a Java program and must be a subclass of the ClassLoader class.

JVM Load Order:

When the JVM starts, the class is loaded by bootstrap to user-defined direction;

When the application is ClassLoader, the class is found and loaded by user-defined to bootstrap direction;

1. Bootstrap ClassLoader

This is the root classloader of the JVM, it is implemented in C + +, the JVM initializes this classloader when it is started, and this classloader completes $java_home Jre/lib/rt.jar (Sun JDK implementation), this jar contains all the interfaces and implementations of the Java specification definition.

2. Extension ClassLoader

The JVM uses this classloader to load some jar packages for extended functionality.

3. System ClassLoader

The JVM uses this classloader to load the jar packages and directories in the classpath specified in the startup parameters, ClassLoader the corresponding class name Appclassloader in the Sun jdk.

4. user-defined ClassLoader

User-definedclassloader is a classloader that Java developers inherit from the ClassLoader abstract class, and custom-based classloader can be used to load jars and directories in non-classpath.

Several key methods of ClassLoader abstract classes:

(1) LoadClass

This method is responsible for loading the class of the specified name, and ClassLoader is implemented first from the class that has already been loaded, if none continues to be looked up from the parent ClassLoader, and if it is still not found, it is searched from the system classloader. Finally, call the Findclass method to look for, if you want to change the load order of the class, you can override this method

(2) Findloadedclass

This method is responsible for finding the loaded class from the cache of the current ClassLoader instance object, calling the native method.

(3) Findclass

This method throws classnotfoundexception directly, so you need to load the corresponding class in a custom manner by overriding LoadClass or this method.

(4) Findsystemclass

This method is responsible for finding the class from System ClassLoader, if it is not found, continues looking from the bootstrap ClassLoader, and returns null if it is still found.

(5) DefineClass

This method is responsible for converting the binary bytecode to the class object

(6) Resolveclass

This method is responsible for completing the link to the class object, which, if it has been linked, is returned directly.

Iv. JVM Execution Engine

The JVM provides four kinds of instructions to execute when executing the method:

(1) Invokestatic: Calling the static method of a class

(2) Invokevirtual: Method of invoking an object instance

(3) Invokeinterface: Defines a property as an interface for invocation

(4) INVOKESPECIAL:JVM for initializing objects (the Java constructor's method is:<init>) and for invoking private methods in the object instance.

The main implementation techniques are:

Interpretation, instant compilation, adaptive optimization, chip-level direct execution

(1) explanation belongs to the first generation JVM,

(2) JIT compilation is a second generation JVM,

(3) Adaptive optimization (currently used by Sun's HOTSPOTJVM) draws on the first generation of JVMs and second generation

JVM experience, in a way that combines both

Start by interpreting the execution of all the code and monitoring the execution of the code, and then start a background thread for the frequently called methods, compile it into local code, and optimize it. If the method is no longer used frequently, the compiled code is canceled, and it is still interpreted for execution.

V. JVM Runtime Data area

First Block: PC Register

The PC registers are the JVM directives that are used to store the next execution of each thread, and if the method is native, no information is stored in the PC register.

Second block: JVM stack

The JVM stack is thread-private, and each thread creates a JVM stack that is stored in the JVM stack as a variable of the local base type in the current thread (eight basic types defined in Java: Boolean, Char, Byte, short, int, long, float, Double), partial return result, and stack Frame, objects of non-basic type are placed on the JVM stack only one point to the heap address

Third Block: Heap

It is the area where the JVM stores object instances and array values, and it can be assumed that all the memory of objects created by new in Java is allocated here, and that the memory of the objects in the heap needs to wait for the GC to recycle.

(1) The heap is shared among all the threads in the JVM, so the allocation of the object memory on it needs to be locked, which also causes the cost of the new object to be relatively large

(2) The Sun Hotspot JVM, in order to increase the efficiency of object memory allocation, allocates a separate space Tlab (thread Local Allocation Buffer) for the created thread, the size of which is calculated by the JVM based on the running situation and allocated on Tlab object does not need to be locked, so the JVM allocates memory to the thread's object as much as possible on Tlab, in which case the performance of allocating object memory in the JVM is as efficient as C, but if the object is too large it is still directly using heap space allocation

(3) Tlab only works on the new generation of Eden Space, so when writing Java programs, it is often more efficient to allocate smaller objects than large objects.

Block Four: Method area

(1) in Sun JDK, this area corresponds to Permanetgeneration, also known as the persistent generation.

(2) The method area holds information about the class being loaded (name, modifier, and so on), static variables in the class, constants defined in the class as final, field information in the class, method information in the class, and when the developer passes the class in the program

Objects such as GetName, Isinterface, and other methods to obtain information, the data are derived from the method area, and the method area is also globally shared, under certain conditions it will also be GC, when the method region needs to use more memory than its allowable size, Throws a outofmemory error message.

Block Fifth: Running a constant pool (runtime Constant)

The space is allocated from the method area for the fixed constant information in the class, the method and the reference information of the field, and so on.

Block Sixth: Local method Stack (Native Stacks)

The JVM uses the local method stack to support the execution of the native method, which is used to store the state of each native method call.

Vi. JVM Garbage Collection

The rationale of GC is to recycle objects that are no longer in use in the GC, which is called collectors for recycling, and because the GC consumes some resources and time, Java, after analyzing the life-cycle characteristics of the object, collects the objects in the new generation, the old generation, To minimize the pauses the GC makes to your application

(1) The collection of new generation objects is called minor GC;

(2) The collection of objects of the old generation is called full GC;

(3) The GC for the active invocation of System.GC () in the program is the full GC.

Different object reference types, the GC is recycled in different ways, and the reference to the JVM object is divided into four types:

(1) Strong references: By default, objects are strongly referenced (instances of this object have no other object references, and GC is recycled)

(2) Soft reference: Soft reference is an application available in Java that is appropriate for caching scenarios (GC only if memory is not enough)

(3) Weak reference: GC is bound to be recycled

(4) Virtual reference: Because the virtual reference is only used to know whether the object is GC

Links: http://www.open-open.com/lib/view/open1408453806147.html

Http://www.cnblogs.com/sunada2005/p/3577799.html

How the "Go" JVM works