preface

Java.class files are loaded into virtual machine memory by the class loader and executed by the JVM through parsing or compilation. To facilitate the management of incoming.class content, the JVM introduced the concept of a run-time data area for the Java Virtual machine. The data area during Java VIRTUAL machine operation can be divided into two types: thread private and thread shared. Thread private includes program counter, virtual machine stack and local method stack. Thread sharing includes Java heap, method area.

Without a deeper understanding of the JVM, it is common to divide the Java runtime data area coarse-grained into “heap”, where object instances are held, and “stack”, where object references are held. As we learned more about the JVM, we realized that the JVM’s partitions of memory were far more complex than the run-time data areas we were aware of in the early stages of learning Java. While C/C++ programmers need to manually free up memory that is no longer needed in their programs, in Java, the virtual machine automatically reclaims resources that are not needed. This requires a deeper understanding of the JVM’s runtime memory partitioning, which helps us to have a better understanding of our programs.

Data details

Program counter

The Program Counter Register is a relatively small data area. Because in Java support multithreading, and that means within each thread requires a piece of memory space, record the current thread (destroyed) site, when the current line number, implemented by the bytecode for the thread to get to the execution time, CPU can then the last byte code number of rows continue execution (recovery) at the scene. The program counter is introduced to record the number of lines of bytecode execution by the current thread.

The bytecode parser selects the next bytecode instruction to parse and execute based on the value of this counter. Java code relies on this counter for looping, jumping, exception handling, thread recovery, and so on.

If the thread is executing a Java method, this counter records the address of the virtual machine bytecode instruction being executed. If native methods are being executed, the value of this counter is null (Undefined). The program counter is the only area of the JVM where no OOM condition is specified.

The virtual machine stack

Java Virtual Machine Stacks are also thread-private and have the same lifetime as threads. The virtual machine stack describes the memory model of Java method execution: a stack frame is created for each method execution in Java, which is then pushed onto the virtual machine stack. Stack frames can also be divided into local variables, operand stacks, dynamic links, method exits (method return addresses), and additional additional information. The execution of Java methods corresponds to the process of pushing frames onto and off the virtual machine.

  • The local variable table mainly stores the local variables in the execution process of the method. Such as the eight basic types defined in the method, local variables, and so on.

  • Operand stacks hold operands. The operand stack is a stack structured data structure, and the stack elements can be any Java data type. When a method first allocates stack frame space for execution, the operand stack is empty. When an operation is performed on a local variable in the method, the operand stack performs an in/out operation.

  • The main purpose of dynamic linking is to support Java language polymorphism (methods that require classloading, run-time determination), dynamics.

  • The method return address returns a return of the method result. If the return is normal, the address in the program counter is called as the return; If it is an exception return, it is determined by the exception handler table (not in the stack frame).

Also, the Java Virtual Machine specification defines two exceptions to the virtual machine stack:

abnormal define
StackOverFlowError Raised when the requested stack depth exceeds the initial stack frame depth defined by the current stack frame
OutOfMemoryError If the virtual machine can dynamically allocate stack memory space at run time, throw it if the Java virtual machine cannot allocate more stack memory

Local method stack

The Native Method Stack plays a similar role to the virtual machine Stack, except that the virtual machine Stack provides memory space for Java’s ordinary methods, while the Native Method Stack provides memory space for Java’s Native methods. Therefore, some virtual machines, such as the Sun HotSpot VIRTUAL machine, simply merge the virtual machine stack with the local method stack.

The local method stack, like the virtual stack, also throws StackOverFlowError and OutOfMemoryError.

The Java heap

The Java heap is the largest memory area in the virtual machine, and this memory area is shared by each thread. The Java heap is created when the virtual machine is created, and its main purpose is to store object instances, array data. But with the development of JIT compilers and escape analysis techniques, objects can be allocated on the stack.

The Java heap is the primary area for GC garbage collection. From the perspective of memory reclamation, because Java heap mainly adopts generational collection algorithm, Java heap can be divided into new generation, old generation, and the new generation can be divided into Eden space, From Survivor and To Survice space.

From the perspective of memory sharing, the Java heap can be divided into Thread Local Allocation Buffers (TLabs) shared by multiple threads.

According to the virtual machine specification, the Java heap can be physically discontinuous in memory and logically continuous. Meanwhile, OutOfMemoryError is thrown when the heap cannot complete its allocation of power and the virtual machine cannot claim more heap memory.

In virtual machines, object instances are allocated primarily in the Java heap, and object instances are laid out in memory as follows:

The memory layout of an object Instance is divided into three areas: Header, Instance, and Padding.

  • The object Header in HotSpot consists of two pieces of information: the runtime data used to store the object itself, and the type pointer. For the first part used to store its own runtime data as shown in the figure above; For the second type of pointer, the object’s pointer to its metadata, the virtual machine uses this pointer to determine which class instance the object belongs to. However, not all virtual machines need to keep a type pointer on the object header data, because it is not necessary to go through the object itself (such as reflection) to find the metadata of the object.

  • The instance data part is where the object actually stores valid information, such as the various types of field content defined in Java source code, including data content inherited from its parent class. The storage in the instance data section is also influenced by the virtual machine’s allocation strategy (FieldsAllocationStyle) and the order of the fields in the Java source code.

  • Alignment padding is not necessarily present in the layout of an object instance and has no special meaning. The automatic memory management system of the VIRTUAL machine requires that the object must be an integer multiple of 8 bytes. The object header size is just a multiple (1 or 2) of 8 bytes, and when the instance data is not aligned, alignment padding is needed to complete.

The purpose of storing an instance of an object in the Java heap is to access the object in use. Java programs need to manipulate specific objects on the heap through reference data in the local table of variables on the virtual machine stack. At present, there are two main access methods: handle and direct pointer.

At the same time, the Java heap can throw OutOfMemoryError.

Methods area

The Method Area, like the Java heap, is an Area of memory shared by each thread. It is used to store information about classes that have been loaded by the virtual machine, constants, static variables, code compiled by the just-in-time compiler, and so on. GC is less visible in this Area. The method area also contains a pool of run-time constants.

The runtime constant pool is used to hold various literal and symbolic references generated at compile time, which will be stored in the runtime constant pool in the method area after the class is loaded.

  • Literals are similar to Java language level concepts, including text strings, constants declared final, and so on.

  • Symbolic references include: fully qualified names of classes and interfaces, field names and descriptors, method names and descriptors;

The method area can also throw OutOfMemoryError.

summary

This includes areas that the JVM runtime assigns to Java.classes for loading into the JVM, thread-private and thread-shared. Of course, this is only a small step towards understanding the JVM’s garbage tagging of the Java heap, as well as garbage collection……