This series of articles is written in the form of notes, mostly from the book “Understanding the Java Virtual Machine in Depth: Advanced JVM Features and Best Practices (3rd edition) – Zhiming Zhou.”
Runtime data area
During the execution of Java programs, the Java VIRTUAL machine divides the memory it manages into different data areas. These zones have their own purposes and creation and destruction timings, with some zones persisting with the start and end of a virtual machine process and others being created and destroyed depending on the start and end of user threads.
Program counter
- Thread private
The Program Counter Register is a small memory space that can be thought of as a line number indicator of the bytecode being executed by the current thread.
Java virtual machine stack
- Thread private
The virtual machine Stack describes the threaded memory model of Java method execution: For each method execution, the Java VIRTUAL machine synchronously creates a Stack Frame to store information about local variables, operand stacks, dynamic connections, method exits, and so on. The process of each method being called and executed corresponds to the process of a stack frame moving from the virtual machine stack to the virtual machine stack.
Local method stack
- Thread private
The role of Native Method Stacks is very similar to that of the virtual machine stack, except that the virtual machine stack performs Java methods (i.e. bytecodes) for the virtual machine, whereas the Native Method stack services the Native methods used by the virtual machine.
The heap
The Java Heap is the largest chunk of memory managed by a virtual machine. The Java heap is an area of memory that is shared by all threads and is created when the virtual machine is started. The sole purpose of this memory area is to hold object instances, and “almost” all object instances in the Java world are allocated memory here.
Methods area
The Method Area, like the Java heap, is an Area of memory shared by threads that stores data such as type information that has been loaded by the virtual machine, constants, static variables, and code caches compiled by the just-in-time compiler.
Run-time constant pool
The Runtime Constant Pool is part of the method area. In addition to the Class version, field, method, interface, and other description information, the Class file contains the ConstantPool Table, which is used to store various literals and symbolic references generated at compile time. This part of the Table is stored in the runtime ConstantPool of the method area after the Class is loaded.
The biggest difference between JDK 1.8 and JDK 1.7 is that metadata sections replace permanent generations. Similar in nature to permanent generations, meta-spaces are implementations of method areas in the JVM specification. However, the biggest difference between a meta-space and a persistent generation is that the metadata space is not in the virtual machine, but uses local memory. Many people prefer to refer to the method area as “Permanent Generation” or confuse the two, which are not essentially equivalent because it was only the then HotSpot VIRTUAL machine design team that chose to extend the generational design of the collector to the method area. Or to implement method sections using persistent generation. However, for other virtual machine implementations, such as BEA JRockit, IBM J9, etc., there is no concept of permanent generation.
Direct memory
Direct Memory is not part of the run-time data area of the virtual machine, nor is it defined in the Java Virtual Machine Specification. But this part of memory is also frequently used and can cause OutofMemoryErrors, so we’ll cover it here.