Java Virtual Machine (i) structure principle and run-time data region

Preface

Originally planned to write Android memory optimization, I think it is necessary to introduce the knowledge of Java Virtual machine, Java Virtual machine is not few words can be introduced, so open the Java Virtual Machine series, In this article we will learn about the structure and runtime data regions of a Java virtual machine.

1.Java Virtual Machine Overview

Oracle's officially defined Java technology architecture consists of the following components:

• Java programming language
• Java virtual machines for various platforms
• class file format
• Java API Class Library
• Third-party Java class libraries

The three parts of Java programming language, Java Virtual machine and Java API Class Library can be referred to as JDK (Java Development Kit), which is the minimal environment for Java program development. In addition, the Java SE API subset and Java Virtual machine in the Java API are collectively referred to as the JRE (Java Runtime Environment), which is the standard environment for Java programs to run.
From the above you can see the Java Virtual Machine and its importance, it is the cornerstone of the entire Java platform, is the Java language compiled code running platform. You can think of a Java virtual machine as an abstract computer with a variety of instruction sets and various runtime data regions.

1.1 Java Virtual machine family

Many students may think that the Java virtual machine is just a virtual machine, and it has a family? Or think of the Java Virtual machine as referring to Oracle's hotspot virtual machine. Here's a brief introduction to the Java Virtual Machine family, and since the Sun Classic VMs included in the JDK1.0 released by Sun in 1996, there are a number of virtual machines that have emerged and perished today, we'll simply describe the relative mainstream Java virtual machines that are currently surviving.

HotSpot VMs
Virtual machines from Oracle JDK and OPENJDK are the most mainstream and most widely used Java virtual machines. The technical articles on Java Virtual machines are introduced, most of which are introduced to hotspot VMS without special instructions. The HotSpot VM was not developed by Sun, but was designed by Longview Technologies, a small company that was acquired by Sun in 1997 and that Sun was acquired by Oracle in 2009.
J9 VMs
The J9 VM is a VM developed by IBM and is currently the main Java Virtual machine for its development. J9 VM's market positioning and hotspot VM approach, it is a design from the server to desktop applications and embedded in the consideration of a multi-purpose virtual machine, the current performance level of the J9 VM is roughly the same as the Hotspot VM is a grade.
Zing VMs
Based on Oracle's hotspot VMS, many of the details that affect latency are improved. The three biggest selling points are:

• 1. Low latency, "no pause" C4 GC,GC bring a pause can be controlled at a level below 10ms, the supported Java heap size can be 1TB;
• 2. Quick warm-up function after start-up.
• 3. Manageability: 0 overhead, can be opened in the production environment full-time, integrated within the JVM monitoring tools zing Vision.

1.2 Java Virtual machine execution process

When we execute a Java program, what is its execution process? As shown in.

There is no logical connection between the Java virtual machine and the Java language, it is only related to a particular binary: class file.

2.Java Virtual Machine Architecture

The architecture described here refers to the abstract behavior of the Java Virtual machine, rather than the implementation of the Hotspot VM as a specific one. Follow the Java Virtual Machine specification, as shown in the abstract Java virtual machine.

2.1 class file format

Java files are compiled into class files that do not depend on specific hardware and operating systems. Each class file corresponds to the definition information for the only class or interface, but the class or interface is not necessarily defined in the file, such as classes and interfaces that can be generated directly from the ClassLoader.

The file structure of the classfile is shown below.

Classfile {U4 magic;//magic number with a fixed value of 0xCAFEBABE to determine if the current file is a class file that can be processed by a Java virtual machineU2 minor_version;//Sub-version numberU2 major_version;//Major version numberU2 Constant_pool_count;//Chang counterCp_info constant_pool[constant_pool_count-1];//ChangU2 access_flags;//class and interface-level access flagsU2 This_class;//Class indexU2 Super_class;//Parent-Class indexU2 Interfaces_count;//Interface counterU2 Interfaces[interfaces_count];//Interface TableU2 Fields_count;//Field counterField_info Fields[fields_count];//Field tableU2 Methods_count;//Method counterMethod_info Methods[methods_count];//Method tableU2 Attributes_count;//Property counterAttribute_info Attributes[attributes_count];//attribute table}

Class 2.2 Loader subsystem

The ClassLoader subsystem finds and loads class files into a Java virtual machine through a variety of classloader. Java virtual machines have two kinds of loaders: the system loader and the user custom loader. The system loader consists of the following three types:

• The Boot class loader (Bootstrap class Loader): A loader that is implemented in C + + code to load the system classes required by the Java Virtual Runtime, which are in the {jre_home}/lib directory. The start of a Java virtual machine is accomplished by creating an initial class by booting the ClassLoader. Because the ClassLoader is implemented using the platform-related underlying c/+ + language, the loader cannot be accessed by Java code. However, we can query whether a class has been loaded by the boot class loader. The Boot class loader does not inherit java.lang.ClassLoader.
• Extension class loader (Extensions class Loader): For loading Java extension classes, extended classes are generally placed in the {jre_home}/lib/ext/directory, to provide additional functionality in addition to the system classes.
• Application class Loader (Application class Loader): This classloader is used to load user code and is a portal to user code. Applying the ClassLoader to extend the class loader as its own parent ClassLoader, when trying to load the class, first try to let the extension class loader load, if the extension class loader successfully loaded, then directly return the load result class instance, if the load fails, it will ask whether the boot class loader has loaded the class , and if not, the app ClassLoader will try to load itself.

The user-defined loader implements its own ClassLoader by inheriting the Java.lang.ClassLoader class.
In addition to loading class file classes into a Java virtual machine, the ClassLoader subsystem must also be responsible for verifying the correctness of the imported class class, allocating and initializing memory for class variables, and helping to parse symbol references. These actions must be performed in the following order:

1. Load: Find and load the class file.
2. Links: validation, preparation, and parsing.

• Validation: Ensure that the type being imported is correct.
• Prepare: Assign fields to the static fields of the class and initialize them with default values.
• Parsing: Dynamically determines a specific worthwhile process based on the symbolic reference of a running constant pool.

3. Initialize: Initializes the class variable to the correct initial value.

2.3 Data Types

Java virtual machines are similar to the Java language data types and can be divided into two categories: basic types and reference types. The Java Virtual machine expects the compiler to do the type checking as much as possible during compilation, so that the virtual machine does not need to perform type checking operations during the run.

2.4 Run-time data regions

Many people divide Java's memory into heap memory (heap) and stack memory (stack), which is not accurate enough, and Java's memory partitioning is actually far more complex.
Java Virtual machine in the process of executing Java program will divide the memory that it manages into different data region, according to the Java Virtual Machine specification (Java SE7 Edition), these data regions are program counter, Java Virtual machine stack, local method Stack, Java heap and method area, respectively. Let's introduce them in one by one below.

2.4.1 Program Counter

In order to ensure that the program executes continuously, the processor must have some means to determine the address of the next instruction, which is what the program counter does.
Program Counter Register, also known as a PC register, is a small memory space. In the virtual machine conceptual model, the bytecode interpreter works by changing the program counter to select the next byte-code instruction that needs to be executed, and the multithreading of the Java Virtual machine is implemented by rotating and assigning the processor execution time, at a certain moment only one processor executes the instruction in a thread, To be able to recover to the correct execution location after a thread switchover, each of the threads has a separate program counter, so the program counter is thread-private. If the thread executes a method other than the native method, the program counter holds the byte-code instruction address that is executing and, if it is the native method, the value of the program counter is empty (Undefined). The program counter is the only data region in the Java Virtual Machine specification that does not specify any outofmemoryerror conditions.

2.4.2 Java Virtual machine stack

Each Java Virtual machine thread has a Java VM stack (Java Virtual machine Stacks), which is a thread-private. It has the same life cycle as the thread and is created at the same time as the thread. The Java Virtual machine stack stores the state of a Java method call in a thread, including local variables, parameters, return values, and intermediate results of the operation. A Java Virtual machine stack contains multiple stack frames, and a stack frame is used to store information such as local variable tables, operand stacks, dynamic links, method exits, and so on. When a thread calls a Java method, the virtual machine presses a new stack frame into the thread's Java stack, and when the method executes, the stack frame pops up from the Java stack. What we normally call stack memory is the Java Virtual machine stack.
Two exception conditions are defined in the Java Virtual Machine specification:

• If a thread requests an allocated stack capacity that exceeds the maximum allowable capacity of a Java virtual machine, Java Virtual opportunity throws stackoverflowerror.
• If the Java Virtual machine stack can be dynamically extended (most Java virtual machines can be dynamically extended), but the extension cannot request enough memory, or if there is not enough memory to create the corresponding Java virtual machine stack when creating a new thread, a OutOfMemoryError exception is thrown.

2.4.3 Local Method Stack

Java Virtual machine implementations may use C stacks to support the Native language, the C stacks is the local method stack (Native methods stack). It is similar to the Java Virtual machine stack, except that the local method stack is used to support the native method service. If the Java virtual Machine does not support the native method and does not rely on C Stacks, you can not support the local method stack. In the Java Virtual Machine specification, there is no mandatory requirement for the language and data structure of the local method stack, so a specific Java virtual machine can implement it freely, such as a hotspot VM combining the local method stack with the Java Virtual machine stack.
Similar to the Java Virtual machine stack, the local method stack throws Stackoverflowerror and OutOfMemoryError exceptions

2.4.4 Java Heap

The Java heap (Java heap) is a region of run-time memory that is shared by all threads. The Java heap is used to hold object instances where almost all object instances are allocated memory. The Java heap stores objects are managed by the garbage collector, and these managed objects do not have to be destroyed by the display. From the perspective of memory recycling, Java heap can be roughly divided into the new generation and the old age. From the point of view of memory allocation the Java heap may divide multiple thread-private allocation buffers. Regardless of the partitioning, the contents of the Java heap storage are constant and are partitioned to enable faster recycling or allocating memory.
The capacity of the Java heap can be fixed or dynamically extended. The Java heap used within the existence of the physical need not continuous, logically continuous can.
An exception condition is defined in the Java Virtual Machine specification:

• A OutOfMemoryError exception is thrown if there is not enough memory in the heap to complete the instance assignment and the heap cannot be extended.

2.4.5 Method Area

The method area is a run-time memory area that is shared by all threads. Used to store the structure information of a class that has been loaded by a Java virtual machine, including:
Run data such as constant pool, field and method information, static variables, and so on. A method area is a logical part of the Java heap, which does not need to be contiguous physically, and optionally does not implement garbage collection in the method area. The method area is not equivalent to a permanent generation, only because the hotspot VM uses the permanent generation to implement the method area, and for other Java virtual machines such as J9 and JRockit, there is no permanent generation concept.
An exception condition is defined in the Java Virtual Machine specification:

• If the memory space of the method area does not meet the memory allocation requirements, the Java virtual opportunity throws a OutOfMemoryError exception.

run a constant-rate pool
The runtime Constant pool is part of the method area. In this section of the 2.1 class file format, we learned that the class file not only contains information such as the version, interface, fields, and methods of the classes, but also contains a constant pool, which holds the literal and symbolic references generated during the compilation period, which are stored in the run-time pool of the method area after the class is loaded. A running constant pool can be understood as a run-time representation of a const pool of classes or interfaces.
An exception condition is defined in the Java Virtual Machine specification:
When a class or interface is created, the Java virtual opportunity throws a OutOfMemoryError exception if the amount of memory required to construct the run-time pool exceeds the maximum value that the method area can provide.

Resources
In-depth understanding of the second edition of Java virtual machines
Java Virtual Machine specification (Java SE7 Edition)
Understanding the Java Virtual Machine architecture
What are the current mainstream Java virtual machines?-Know
JVM Runtime Data Region resolution
Schematic diagram of the Java Virtual machine
Explore the Java class loader in depth

Welcome to my public number, the first time to get blog update reminders, and more into the system of Android-related original technology dry.
Sweep the two-dimensional code below or long press identification QR code, you can pay attention to.

Java Virtual Machine (i) structure principle and run-time data region