About Java Virtual machines: Memory processing and execution engine

A Introduction to Java Technology system:

The Java technology architecture consists of the following components:

1. Java programming language
2. Java virtual machines on a variety of hardware platforms
3. class file format
4. Java API Class Library
5. Third-party libraries from commercial organizations and open source communities

JDK (Java Development Kit): Includes Java programming language, Java Virtual machine, Java API Class library. The JDK is the smallest environment for supporting Java program development.

The JRE (Java Runtime Environment) includes a subset of Java SE APIs in the Java API Class library, and a Java virtual machine. The JRE is a standard environment that supports the running of Java programs.

Shows what the Java technology architecture contains, and the scope covered by the JDK and JRE:

The Java technology system can be divided into four platforms according to the areas served by the technology, namely:

1. Java Card: A platform that supports some Java applets (applets) running on small memory devices
2. Java ME (Micro Edition): A platform that supports Java programs running on mobile devices, streamlines Java APIs, and adds support for mobile devices.
3. Java SE (Standard Edition): Supports the Java platform for desktop-level applications and provides a complete Java Core API.
4. Java EE Edition: A Java platform that supports enterprise applications that use a multi-tiered architecture, in addition to the Java SE API, has been massively expanded and provides relevant deployment support.

Second, the Java Memory management mechanism

1. Run-time data region:

The Java Virtual machine divides the memory it manages into several different data regions during the execution of a Java program. These zones have their own purpose, as well as the creation and destruction of time, and some regions exist as the virtual machine process starts, and some regions depend on the user thread's start and end to build and destroy.

The memory managed by the Java Virtual Machine includes the following runtime data regions:

1.1 Program Counter:

A program counter is a small amount of memory space that can be thought of as the line number indicator of the byte code executed by the current thread.

In the virtual machine conceptual model, the bytecode interpreter works by changing the value of the program counter to select the next byte-code instruction that needs to be executed, and the basic functions such as branching, looping, jumping, exception handling, and thread recovery need to rely on the program counter to complete.

Because the multithreading of a Java virtual machine is implemented in a way that threads take turns switching and allocating processor execution time , at any given moment, a processor (a core for a multicore processor) executes only the instructions in one thread. Therefore, in order to recover the thread after switching to the correct execution location, each thread needs to have a separate program counter, the counter between the threads do not affect each other, isolated storage , we call this kind of memory area is thread-private memory .

If the thread is executing a Java method, the program counter records the address of the virtual machine bytecode instruction being executed, and if the native method is being executed, the value of the program counter is empty (Undefined).

The program counter is the only area in the Java Virtual Machine specification that does not stipulate any outofmemoryerror conditions.

1.2 Java Virtual Machine stack

Like the program counter, the Java Virtual machine stack is also thread-private, with the same life cycle as the thread. The virtual machine stack describes the memory model that the Java method executes: Each method creates a stack frame at the same time (stack frame, which is the underlying data structure of the method runtime) for storing local variable tables, operand stacks, dynamic links, method exits, and other information. Each method from the call until the completion of the process, corresponding to a stack frame in the virtual machine stack into the stack of the process.

The memory management is often divided into stacks, heaps, etc. for programs such as C + +. For Java, the stack refers to the virtual machine stack, or the local variable table portion of the virtual machine stack.

The local variable table holds the various basic data types (Boolean, Byte, char, short, int, float, long, double), object references (reference types, which are not equivalent to the object itself) that are known at compile time. It may be a reference address to the start address of the object, or it may point to a handle representing the object or other location associated with the object, and the ReturnAddress type (the address of a bytecode directive).

The amount of memory space required for a local variable table is allocated during compilation, and when entering a method, the method needs to allocate much of the local variable space in the frame is fully deterministic and does not change the size of the local variable table while the method is running.

You can specify the Java virtual machine stack memory size for a program by-XSS this virtual machine parameter:

java-xss=512m Hackthejava

The zone may throw the following exception:

• A Stackoverflowerror exception is thrown when the thread requests a stack depth that exceeds the maximum value;
• When the stack is dynamically expanding, it throws a OutOfMemoryError exception if it cannot request enough memory.

In the Java Virtual Machine specification, there are two exceptions to this area: if the thread requests a stack depth greater than the virtual machine allows, the STACKOVERFLOWERROR exception will be thrown , and if the virtual machine stack can be dynamically extended, If you cannot request enough memory for the extension, the outofmemoryerror exception is thrown.

1.3 Local Method Stack

The local method stack (Native methods stack) is very similar to the virtual machine stack, and the difference is that the virtual machine stack executes Java methods (that is, bytecode) services for the virtual machine. The local method stack is the Native method service used by the virtual machine. As with the virtual machine stack, the local method stack throws Stackoverflowerror and OutOfMemoryError exceptions.

1.4 Java Heap (heap)

For most applications, the Java heap (Java heap) is the largest piece of memory managed by a Java virtual machine. Java a heap is an area of memory that is shared by all threads and created when the virtual machine is started . The only purpose of this memory area is to hold object instances . In the JVM, almost all of the object instances are allocated memory here. The description in the Java Virtual Machine specification is that all object instances and arrays are allocated on the heap, but as The development of the JIT compiler and the escape technology matures, stack allocation, scalar substitution optimization techniques will cause some subtle changes to occur, All objects are allocated on the heap and become less absolute .

Java The heap is the main area of garbage collector management , so the Java heap is also known as the "GC Heap" (garbage collected heap).

The modern garbage collector basically uses the Generational collection algorithm, the idea of this algorithm is to take different garbage collection algorithms for different objects, so the virtual machine divides the Java heap into the following three blocks:

• New Generation (young Generation)
• Old Age (Generation)
• Permanent generation (Permanent Generation)

When an object is created, it first enters the Cenozoic, and then it may be transferred to the old age. The new generation holds a large number of short-lived objects, so the new generation has the highest frequency of garbage collection in three regions. For more efficient garbage collection, the new generation continues to be divided into the following three spaces:

• Eden
• From Survivor
• To Survivor

• From the memory allocation point of view, the thread-shared Java heap may divide multiple thread-private allocation buffers (thread Local Allocation buffer, Tlab). According to the Java Virtual Machine specification, the Java heap can be in a physically discontinuous memory space, as long as it is logically contiguous. When implemented, it can be either fixed-sized or extensible, and throws a OutOfMemoryError exception if there is no memory-complete instance allocation in the heap and the heap can no longer be expanded.

  The Java heap memory size of a program can be specified by-XMS and-xmx two virtual machine parameters, the first parameter sets the minimum value, and the second parameter sets the maximum value.

  Java-xms=1m-xmx=2m Hackthejava

  1.5 Method Area

  The method area, like the Java heap, is an area of memory shared by each thread that stores data such as class information, constants, static variables, and code compiled by the immediate compiler that have been loaded by the virtual machine . Although the Java Virtual Machine specification describes the method area as a logical part of the heap, it has an alias called Non-heap (Not a heap), which should be distinguished from the Java heap.

  The Java Virtual Machine specification has a very loose limit on the method area, and you can choose not to implement garbage collection, except that you do not need contiguous memory and can choose a fixed size or extensible, as with the Java heap. Garbage collection behavior is relatively rare in this area, but not data entering the method area is as permanent as a permanent name. The memory reclamation targets for this zone are primarily for the collection of constant pools and for unloading types.

  According to the Java Virtual Machine specification, a OutOfMemoryError exception is thrown when the method area does not meet the memory allocation requirements.

  run a constant-rate pool ( Runtime costant Pool ) is part of the method area . class file In addition to the class version, fields, methods, interfaces, and other descriptive information, there is also a constant pool (Constant pool), for the compilation period generated by the various literal and symbolic references, which will be loaded in the class load into the method area of the run constant pool.

  Another important feature of running a constant pool with respect to a regular pool of class files is its dynamic nature . The Java language does not require constants to be generated only at compile time, which means that the contents of a constant pool of class files are not pre-placed to enter the method area to run a const pool, and new constants may be put into the pool during run time, such as The Intern () method of the String class.

  Since the run-time zone is part of the method area, a OutOfMemoryError exception is thrown when the constant pool cannot request memory.

  class file parsing

  Java: Write once, run everywhere. Write Once,run Anywhere.

  The program storage format used by virtual machines and all platforms in different platforms is the cornerstone of platform independence, the bytecode (bytecode) .

  The Java virtual machine is not bound to any language, including Java, and is associated only with a specific binary file format such as "Class file."

  The class file contains the Java Virtual machine instruction set and symbol table, as well as a number of other ancillary information.

  1. 1. Structure of class file

  Any class file corresponds to the unique definition of a class or interface, but conversely, a class or interface is not necessarily defined in a file (for example, a class or interface can also be generated directly from the ClassLoader).

  Class A file is a set of 8 bits are the binary stream of the base unit, and each data item is tightly arranged in order Class There is no delimiter added in the middle of the file.

  There are only two types of data in a class file: unsigned number and table .

  Unsigned numbers are basic data types that can be used to describe numbers, index references, quantity values, or follow UTF-8 The encoding constitutes a string value.

  A table is a composite data type that has multiple unsigned numbers or other tables as data items, and all tables are habitually "_info" end.

  The data items in the class file, whether sequential or quantitative, or even the byte order of the data store, are strictly qualified, which byte represents what meaning, what length is, how long, and how the order is not allowed to change.

  The class file format is as follows:

• • Chang ( Constant_pool )

• constant Pool entry , a constant pool can be understood as a resource repository in a class file, which is the data type most associated with other projects in the class file structure, and is one of the largest data items in the class file space. It is also the first table-type data item that appears in a class file.

  There are two main types of constants in a constant pool: literal and symbolic references .

  Literal comparisons are similar to the concept of constants at the Java level, such as text strings, constant values declared final, and so on.

  The following three types of constants are included in the summary of symbolic references:

  • The fully qualified name of the class and interface (that is, the class name with the package name, such as: Org.lxh.test.TestClass)
  • The name and descriptor of the field (private, static, and other descriptors)
  • The name and descriptor of the method (private, static, and other descriptors)

  The virtual machine does not dynamically connect when the class file is loaded-that is, the final memory layout information for each method and field is not saved in the class file, so the symbolic references to these fields and methods cannot be directly used by the virtual machine without conversion. When the virtual runtime is running, the corresponding symbolic reference needs to be obtained from the constant pool, which is then replaced with a direct reference and translated into a specific memory address during the parsing phase of the class loading process.

  Symbol Reference: A symbol reference is a set of symbols to describe the referenced target, the symbol can be any form of the literal, as long as the use can be used without ambiguity to locate the target. The symbolic reference is independent of the memory layout implemented by the virtual machine, and the referenced target is not necessarily loaded into memory.

  Direct Reference : A direct reference can be a pointer to a target directly, a relative offset, or a handle that can be indirectly anchored to the target. A direct reference is related to the memory layout implemented by the virtual machine, and a direct reference that is translated on a different virtual machine instance by the same symbolic reference will not generally be the same. If you have a direct reference, it means that the target of the reference must already exist in memory.

  • Access Flags ( Access_flags )

  Access Flags ( Access_flags ), this flag is used to identify some class or interface-level access information. Including:

  • Whether this class is an interface or not;
  • is defined as public type;
  • is defined as an abstract type;
  • If it is a class, whether it is declared final, etc.

  The access flags include public/protected/private/abstract/final and so on.

  Virtual machine class loading mechanism:

  virtual machines take the data from the description class Class The file is loaded into memory and the data is validated, converted, parsed, and initialized, resulting in a direct use of the virtual machine. Java type, which is the class loading mechanism of the virtual machine.

  Class loading process

  In the Java language, the loading, connection, and initialization of types are done during program runs.

  Features: flexibility, dynamic expansion (dynamic load and dynamic connection during runtime)

• Classes start from being loaded into the virtual machine memory, and the entire life cycle includes:

  • Load ( Loading )
  • Verification ( Verification )
  • Parsing ( Resolution )
  • Initialize ( initialization )
  • Use ( Using )
  • Uninstall ( unloading )

  So, under what circumstances do you need to start loading the first stage of the class loading process?!! There are only five kinds of situations!!

  • When encountering the New/getstatic/putstatic/invokestatic 4 bytecode directive, if the class has not been initialized, it needs to trigger its initialization first (corresponding to: Instantiate the object with new, read or set the static field of the class, Call a static method of a Class).
  • When you use the Java.lang.reflect package method to make a reflection call to a class, if the class has not been initialized, you need to trigger its initialization first.
  • When initializing a class, it is necessary to trigger the initialization of its parent class if it finds that its parent class has not yet been initialized.
  • When the virtual machine starts, the user needs to specify a main class to execute (the class that contains the main () method), and the virtual opportunity initializes the main class first.
  • When using dynamic language support, if a java.lang.invoke.MethodHandle instance finally resolves the result of a method handle, and the corresponding class of the method handle has not been initialized, it is necessary to trigger its initialization first.

  Passive references:

  • Referencing a static field of a parent class through a subclass does not cause subclasses to initialize;
  • Referencing a class by an array definition does not trigger initialization of this class;
  • Constants are transferred into the class's constant pool during the compilation phase and are not inherently referenced directly to the class that defines the constants, so the initialization of the class that defines the constants is not triggered. (Constant propagation optimization)

  For the interface loading process, we need to note that when a class is initialized, it is required that all of its parent classes have been initialized, but when an interface is initialized, it does not require that all of its parent interfaces be initialized, only when the parent interface is actually used.

  The class loading process consists of 5 phases: load, validate, prepare, parse, and initialize.

  1.1 Loading

  During the load phase, the virtual machine needs to complete the following three things:

  1. A binary byte stream that defines this class is obtained through the fully qualified name of a class.
  2. Transform the static storage structure represented by this byte stream into the runtime data structure of the method area;
  3. A Java.lang.Class object representing this class is generated in memory as a access entry for various data of this class in the method area.
  1.2 Verification

  The purpose of the validation phase is to ensure that the information contained in the byte stream of the Class file conforms to the requirements of the current virtual machine and does not compromise the security of the virtual machine itself . Validation is an important part of the virtual machine's own protection.

  Overall, the verification phase will generally complete the following 4 phases of the inspection action:

  • File Format Verification

  The first phase verifies that the byte stream conforms to the specification of the Class file format and can be processed by the current version of the virtual machine . The main purpose of this verification phase is to ensure that the input byte stream is correctly parsed and stored in the method area, in a format that conforms to the requirements of a Java type information.

  • Meta-data validation

  The second stage is the semantic analysis of the information described in bytecode to ensure that the information it describes conforms to the requirements of the Java language Specification. The main purpose of this verification phase is to check the metadata information of the class to ensure that there is no metadata information that does not conform to the Java Language Specification .

  • BYTE code Verification

  The third stage is the validation analysis of the method body of the class to ensure that the method of the checked class does not make the event that endangers the security of the virtual machine at runtime . The main purpose of this verification phase is to determine that the program semantics are legal and logical through data flow and control flow analysis .

  • Symbol Reference Validation

  Phase IV is a matching check of information other than the class itself . The main purpose of this verification phase is to ensure that the parsing action is performed properly, and if it cannot be verified by a symbolic reference, it will throw a java.lang.IncompatibleClassChangeError The subclass of the exception .

  For the class loading mechanism of virtual machines, the validation phase is a very important, but not necessarily necessary, phase.

  1.3 Preparation

  The prep phase is the stage that allocates memory for class variables and sets the initial value of class variables.

  Note: Memory allocations at this time include only class variables (static modified variables), not instance variables.

  Consider one of the following questions:

  Compare the values of value for the following two scenarios in the preparation phase.

  Situation One

  public static int value = 123;

  Scenario Two

  public static final int value = 123;

  The answer is: For scenario one, value is 0 after the prep phase, and for scenario two, value is 123 after the prepare phase.

  The reason is that the assignment of value is done in the <init> section, and in case two, value corresponds to the Constantvalue property.

  1.4 Parsing

  The parsing phase is the process by which a virtual machine replaces a symbolic reference within a constant pool with a direct reference .

  Symbol references ( Symbolic References ): The symbol reference is a set of symbols that describe the referenced target, and the symbol can be any form of literal, as long as it can be used without ambiguity to locate the target.
  Direct Reference ( Direct References ): A direct reference can be a pointer to a target directly, a relative offset, or a handle that can be indirectly anchored to the target.

  The virtual machine specification does not specify the time at which the parsing phase occurs.

  Parsing actions are primarily for classes or interfaces, fields, class methods, interface methods, method types, method handles, and call Point qualifier 7 class symbol references.

  1.5 Initialization

  The class initialization phase is the last step in class loading. In the preparation phase, the variable has already assigned the initial value of the system requirement, and during the initialization phase, the class variables and other resources are initialized according to the subjective plan developed by the programmer through the program. In other words, the initialization phase is <clinit> the process of executing the class constructor method.

  <clinit>method is generated by the assignment of all class variables in the compiler's automatic collection of classes and statements in a static statement block , the order in which the compiler collects is determined by the order in which the statements appear in the source file, and the static statement block can only access variables defined before the static statement block, the variables defined behind it, The preceding static statement block can be assigned a value, but cannot be accessed. For example:

  public class Test {

  static {

  i = 0; Assigning values to variables can be compiled correctly

  System.out.println (i); Illegal forward reference!!!

  }

  static int i = 1;

  }

  • The <clinit> method differs from the class's constructor (instance constructor <init>), which does not need to explicitly call the parent class constructor, and the virtual opportunity guarantees that the subclass's <clinit> The <clinit> method of the parent class has been executed before the method executes.
  • Because the <clinit> method of the parent class executes first, there is a static statement block defined in the parent class that takes precedence over the variable assignment operation of the child class .
  • The <clinit> method is not required for a class or interface, and if there is no static statement block in a class, and there is no assignment to the variable, the compiler can not generate an <clinit> method for the class.
  • Static statement blocks cannot be used in an interface, but there are still assignment operations for variable initialization. However, unlike the class interface, the <clinit> method that executes the interface does not need to perform the parent interface's <clinit> method first. The parent interface is initialized only if the variables defined in the parent interface are used .
  • Virtual Opportunity guarantees a class of <clinit> methods are properly locked and synchronized in a multithreaded environment, and if multiple threads initialize a class at the same time, only one thread will execute the class. <clinit> method , the other threads need to block the wait until the active thread executes the <clinit> method finishes. Also, it is important to note that while other threads are blocked, if the thread that executes the <clinit> method exits the <clinit> method, the other thread does not enter the <clinit> method again after it wakes up. Under the same classloader, a type is initialized only once.
  2. Class Loader

  The virtual machine design team takes the "fully qualified name of a class to obtain a binary byte stream (that is, bytecode) that describes this class" in the class-loading phase, which is implemented outside the Java virtual machine, so that the application can decide for itself how to get the required class. The code module that implements this action is called the class loader.

  Class 2.1 and Class loader

  For any class, it is necessary to establish its uniqueness in the Java virtual machine, together with the class loader that loads it, and the class itself, each with a separate class namespace. In layman's terms: Compare whether two classes are "equal" (the "equality" referred to here, including the Equals () method of the Class object, the IsAssignableFrom () method, the Isinstance () method, and the return result of the (), including the use of instanceof () Keywords do object ownership relationship determination, and so on, only if the two classes are loaded by the same class loader, the premise is meaningful, otherwise, even if the two classes from a class file, is loaded by the same virtual machine, as long as loading their class loader is different, then the two classes must be unequal.

  Class 2.2 Loader categories

  From the point of view of a Java virtual machine, there are only two different classloader:

  • Start the ClassLoader (Bootstrap ClassLoader), a class loader implemented with C + +, which is part of the virtual machine itself;
  • All other class loaders, which are implemented by Java, are independent of the virtual machine and all inherit from the abstract class Java.lang.ClassLoader.

  From the Java developer's point of view, the ClassLoader can be divided in more detail:

  • Launch class loader (Bootstrap ClassLoader) This loader is responsible for storing in the <JAVA_HOME>\lib directory, or -Xbootclasspath in the path specified by the parameters, and is recognized by the virtual machine (only by file name, such as Rt.jar, the name does not conform to the class library even if placed in the Lib The catalog is not loaded) The class library is loaded into the virtual machine memory. The startup ClassLoader cannot be referenced directly by a Java program, and when a user writes a custom class loader, it needs to delegate the load request to the startup ClassLoader, using NULL instead.
  • Extension class loader (Extension ClassLoader) This classloader is implemented by Extclassloader. It is responsible for <JAVA_HOME>/lib/ext loading or being java.ext.dir loaded into memory by all class libraries in the path specified by the system variables, and developers can use the extension class loader directly.
  • The class loader for the application ClassLoader (application ClassLoader) is implemented by Appclassloader. Because this classloader is the return value of the Getsystemclassloader () method in ClassLoader, it is generally referred to as the System class loader. It is responsible for loading the class library specified on the user classpath (ClassPath), which the developer can use directly, if the application does not have its own classloader, typically this is the default class loader in the program.

About Java Virtual machines: Memory processing and execution engine