2.1 Runtime data area
2.1.1 Program counter
Similar to the program counter executed by functions in other languages, it can be thought of as a line number indicator of the bytecode executed by the current thread and used to store the address of the next bytecode instruction to be executed. Each thread needs a separate program counter to keep track of where the current method is executed, and is therefore thread-private. In a local method, the value of the program counter should be null.
2.1.2 Java Virtual Machine Stack
Similarly, the Java virtual machine stack is thread-private, storing information about each method’s local variables, operand stacks, dynamic connections, method exits, and so on. Each method is called to the end of the execution process, corresponding to a stack frame in the virtual machine from the stack to the stack process. The storage space in the local variable table is represented as a local variable slot, with long and double data occupying two slots and the rest occupying only one (a different size from the heap type). The required memory space is allocated at compile time.
2.1.3 Local method stack
Similar to the virtual stack, but serving local methods.
2.1.4 Java heap
The heap is an area of memory shared by all threads, created at virtual machine startup for the sole purpose of holding object instances, and is therefore an area of memory managed by the garbage collector. A Java heap can be in a physically discontinuous memory space, but logically should be considered contiguous (such as a file system). Java heaps can be fixed size or (mainstream) extensible. From the perspective of allocating memory, the heap can be divided into Thread Local Allocation Buffers (TLabs) that are private to multiple threads to improve the efficiency of object Allocation.
2.1.5 method area
The method area is also a thread-shared memory area that stores type information that has been loaded by the virtual machine, constants, static variables, just-in-time compiled code cache, and so on. Method is worth mentioning that area and the permanent generation is not the concept of equivalent before JDK8, choose to use the permanent generation HotSpot virtual machine to implement the method, allowing the garbage collector to like management heap memory management section, however, this is not a good idea, permanent generation with a memory limit, out of memory and therefore are more likely to encounter problems, therefore, In JDK8, the concept of permanent generation is completely abandoned and replaced by a meta-space implemented in local memory.
2.1.6 Runtime constant pool
The Runtime Constant Pool is part of the method area. The constant pool table in the Class file is put into the runtime constant pool after the Class is loaded and is used to hold the various literal and symbolic references generated during compilation. The runtime constant pool is dynamic, and new constants can be put into the pool at run time, such as the Intern () method of the String class.
2.1.7 Direct Memory
Direct Memory is not part of the virtual machine’s run-time data area. Mainly due to the introduction of NIO in JDK1.4, it can use Native libraries to allocate out-of-heap memory directly and then operate with DirectByteBuffer objects stored in the heap as references to that memory.
2.2 Discovering VM Objects
2.2.1 Object Creation
Class loading check ———— Allocate memory ———— initialize to 0———— Set the object header ———— Initialize the object according to the program. Allocating memory: pointer collisions and free lists. Pointer collision: Use Pointers to distinguish used memory from free memory. The choice of allocation method depends on whether the Java heap is clean, which in turn depends on whether the garbage collector adopted has the ability to compress and collation space. Another consideration. There are two options to solve this problem. One is to use CAS operation and retry to ensure atomicity of update operation. Another way to do this is to divide memory allocation into different Spaces by thread, known as local Thread allocation caching (TLAB). A synchronization lock is required only if a thread’s local buffer is exhausted. You can specify whether to use this function with the -xx: +/ -usetlab parameter.
2.2.2 Memory Layout of objects
In the HotSpot virtual machine, the object storage layout in the heap can be divided into three parts: object Header, Instance Data, and Padding. The object header contains two types of information. The first type is used to store the runtime data of the object itself, such as hash code, GC generation age, lock status flag, thread held lock, bias thread ID, bias timestamp, etc., called Mark Word. Considering the space efficiency of virtual machines, Mark Word is designed as a dynamically defined data structure to store as much data as possible in a very small space, reusing its own storage space according to the state of the object.
| Store content | Sign a | state |
|---|---|---|
| Object hash code, object age generation | 01 | unlocked |
| A pointer to a lock record | 00 | Lightweight locking |
| Pointer to a heavyweight lock | 10 | Swell (heavyweight lock) |
| Empty, no information needs to be recorded | 11 | The GC tag |
| Bias thread ID, bias timestamp, object generation age | 01 | Can be biased |
The other part of the object header is the type pointer, which the object points to its type metadata. Not all virtual machine implementations are required to keep type Pointers on object data, meaning that finding metadata information about an object does not have to go through the object itself (see the next section). In addition, if the object is a Java array, there must be a block of data in the object header that records the length of the array. The instance data part is the valid information for the object store. Fields of the same width are always allocated together, and variables defined in the parent class precede those defined in the subclass if this condition is met. If the HotSpot VIRTUAL machine’s +XX: CompactFields is True, the narrower variables of the subclass are also allowed to be inserted into the gap between the parent variables. Alignment padding is just a placeholder.
2.2.3 Object Access Positioning
Java programs manipulate concrete objects on the heap using reference data on the stack. The main access methods are handle and direct pointer. HotSpot mainly takes the second approach. Using a handle is equivalent to a secondary index.