Inside the Java Virtual machine reading Note one

What ?

Say the JVM, which may refer to:

• The abstract specification,
• A concrete implementation, or
• A runtime instance.

A runtime virtual machine instance (a runtime instance) is responsible for running a Java program that ends with the beginning of the Java program (the Main method runs) and disappears.

There are two types of threads in a Java virtual machine, a daemon thread and a non-daemon thread, a background thread like a GC that is a daemon thread, and the main method produces a non-daemon thread. When all non-daemon threads end, the JVM ends.

The JVM (referred to here: The abstract specification) defines the components of the abstraction and how they interact to define the implementation of the JVM (a concrete implementation):

Each JVM has a class loader subsystem that, when the class or interface (which must have a fully qualified name) is loaded into the JVM, is loaded into the class loader subsystem. Again, each JVM will have a The execution engineis responsible for executing method directives in the loaded class.

. class file with bytecode (byte code)

The class file contains the code and metadata (metadata) used to support the code. The code section is bytecode, and the metadata section includes many information such as generics. So the class file contains the bytecode, but not only the byte-code.

Class Loader Subclass

Takes care of finding and loading types

The JVM has two kinds of loaders: a primordial class loader and class loader objects (primitive class loader: A part of the JVM, a user-defined class Loader object: Part of a Java program). For class loader objects (Java programs) must inherit from
The interface method defined in Java.lang.ClassLoader.ClassLoader provides a mechanism for accessing the JVM. For each loaded type in the JVM, a Java.lang.class object is generated to represent it, and as with other object objects, the object is generated in the heap, and the type information is placed in method area.

in addition to locating and importing binary class files, the class loader must verify the correctness of the imported classes and allocate and initialize memory for class variables .

Approximate order:

1. Loading:finding and importing the binary data for a type
2. Linking:performing verification, preparation, and (optionally) resolution
   A. verification:ensuring the correctness of the imported type
   B. preparation:allocating memory for class variables and initializing the memory to default
   Values
   C. resolution:transforming symbolic references from the type into direct references.
3. Initialization:invoking Java Code, initializes class variables to their proper starting values.

Runtime Data Areas

When the JVM is running, it requires memory to be stored, such as bytecode and other information obtained from the class file, object instantiation, method parameters, return values, local variables, media for calculating results, and so on. Each JVM then defines multiple runtime data areas to organize the memory required by these executing programs. (various JVMs produce different implementations based on these abstract definitions).

Method area && Heap

Each JVM instance has a method area and a heap, which is shared by all the threads in the JVM , Methodarea, and heap. When a JVM uses ClassLoader to correctly locate and load a class file, it parses the type information from the binary information, puts the type information into the Methodarea, and puts the object instance in the heap.

I said the method area mainly put type information, so-called type information refers to:

Type Information

For each type it loads, a Java Virtual machine must store the following kinds of information in the
Method Area:

• The fully qualified name of the type

• The fully qualified name of the Typeís direct superclass (unless the type is an interface or class Java.lang.Object, Neith Er of which have a superclass)

• Whether or not the type was a class or an interface

• The Typeís modifiers (some subset of ' public, abstract, final)

• An ordered list of the fully qualified names of any direct superinterfaces

In fact, through the Java.lang.Class method, we can dynamically obtain some types of information stored in the Methodarea:

publicgetName();publicgetSuperClass();publicbooleanisInterface();publicgetInterfaces();publicgetClassLoader()

In addition, Methodarea also includes these:

• The constant pool for the type
  each type (class or interface) has a constant pool. It is an ordered collection that holds references to the base type, as well as a reference to a type (class or interface), a class variable reference, a method reference.

• Field Information
  Stores information about a class variable: the type, name, and modifier (such as private, public, final, static, and so on) of the class variable

• Methods Information
  Method name, method return value, method decorated symbol, method parameter list, byte code of method, exception list thrown by method (non-abstract, Native method).

• all Class (Static fields) variables declared in the type, except constants

li>

A reference to class ClassLoader
The JVM needs to track whether the type (type, the class or interface) is loaded into the original ClassLoader or ClassLoader object. Therefore the method area needs to store a classloader reference.

• A reference to class class
  JVM for each loaded type (interface\ Class) will create an instance of Java.lang.class. Also, the JVM has a way of associating this java.lang.class instance with its type information (presence and Methodarea).
  with this static method, you can obtain any java.lang.class instance of the type that is loaded into the ClassLoader.

publicstaticClass forName(String className)

Another way to get class is the GetClass () method for each instance of the type.

        System.out.println(Class.forName("java.lang.String"));        System.out.println(new String().getClass());

When the Java Vsan loads a type, it uses a class loader to
Locate the appropriate class file. The class loader reads in the class
File–a linear stream of binary Data–and passes it to the virtual
Machine. The virtual machine extracts information on the type from
The binary data and stores the information in the method area. Memory
For-Class (static) variables declared in the class was also taken from
The method area

Use an example to describe the JVM's actions:

class Lava {private  int  speed = 5 ;    //5 kilometers per hour  void  flow () {}}public  class  Volcano {public  static  void  main  (string[] args) {Lava Lava = new  Lava ();    Lava.flow (); }}

Run the program, the JVM finds and reads the Volcano.class file, and then reads the volcano class information into the method area in the introduced Volcano.class file. The JVM then calls the main method by interpreting the Codebyte in the method area.
Note that when the JVM executes main (), it does not load lava.class and it loads on demand.
When you execute main (), the JVM invokes enough memory space for the first volcano class of Costantpool, and then, in Volcano's Constantpool, find the reference symbol for the class Lava (that is, the character "Lava"), which checks whether Lava is loaded. When the JVM finds it, it looks for and reads the Lava.class file, and then reads the information from the binary lava.class and puts it in Methodarea. Immediately thereafter, The JVM will replace the pointer (pointer to volcano) of the first bar of the Constantpool with a pointer to the lava class data in the method area and use this pointer to quickly access the lava.
Next, the JVM quickly obtains lava information by constantpool the first pointer (pointing to Methodarea's lava information) and allocates enough memory on demand.

(The JVM always uses Methodarea type information to determine how much memory needs to be called) when the JVM determines the memory size, it allocates the heap and initializes the speed variable of the object to 0. Then, the reference to the generated lava object is pressed into the stack.

Lava Lava = new Lava (); This code is done.

Then, call flow ().

Data Type

The JVM completes the calculation by operating on multiple types of data.
The base type holds the value, and the reference type points to the object. (The difference between a base type and a reference type is simple)

This is to mention a Boolean, although it is also defined as the basic type, but the Java compiler compiles the source code into bytecode, loaded in the JVM, the boolean is expressed in int or byte, 0 is false, and a non-0 integer is represented as true.

Heap

The heap is used to hold instantiated objects or arrays , and calls are allocated to the memory space from the heap. In other words, the object itself (memory) is created on the heap.
Two Java application cannot share the heap, and when a different thread of a Java application can be shared, we use one object synchronously in multi-threading.

In addition, the code can decide when to create the object, but cannot decide when to destroy the object (freeing memory). This is entirely the JVM's own decision (GC management heap, in addition to freeing up space, it will also move objects to reduce memory fragmentation).

We already know that the stack holds a reference to the objects in the execution heap, and in addition to that, a reference to the execution method area is maintained inside the heap (for quick access to type information).

For both implementations of the heap:

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Inside the Java Virtual machine reading Note one