Memory is a very important system resource. It is the intermediate warehouse and bridge between the hard disk and the CPU, and it carries the real-time selection of the operating system and application programs. The memory layout of the JVM specifies the strategies for memory application, allocation, and management during the running of Java, ensuring the efficient and stable operation of the JVM.
Different VMs have some differences in memory division methods and management mechanisms. Combined with the JVM virtual machine specification, let's discuss the classic JVM memory layout.
The Java virtual machine defines several types of runtime data areas that will be used during the running of the program, some of which will be created when the virtual machine starts and destroyed when the virtual machine exits. Others are one-to-one correspondence with threads, and these data areas corresponding to threads will be created and destroyed as threads start and end.
The gray ones in the above figure are private to individual threads, and the red ones are shared by multiple threads. Right now:
- Each thread: independently includes the program counter, stack, and native method stack.
- Sharing between threads: heap, off-heap memory (permanent generation or metaspace, code cache)
program counter
The program counter (Program Counter Register) is a small memory space, which can be regarded as the line number indicator of the bytecode executed by the current thread . In the conceptual model of the Java virtual machine, the bytecode interpreter selects the next bytecode instruction to be executed by changing the value of the counter when it works. It is an indicator of the program control flow, branch, loop, jump , exception handling, thread recovery and other basic functions need to rely on this counter to complete.
Since the multithreading of the Java virtual machine is realized by switching threads in turn and allocating processor execution time, at any given moment, a processor (a core for a multi-core processor) will only execute one instructions in the thread. Therefore, in order to return to the correct execution position after thread switching, each thread needs to have an independent program counter. The counters between threads do not affect each other and are stored independently. We call this type of memory area "thread private". of memory.
If the thread is executing a Java method, this counter records the address of the virtual machine bytecode instruction being executed; if the thread is executing a native (Native) method, the counter value should be empty (Undefined). This memory region is the only one that does not specify any OutOfMemoryError conditions in the Java Virtual Machine Specification.