Runtime data area
-
Thread private area
- Program counter
- Java virtual machine stack
- Local method stack
-
Thread shared area
-
The Java heap
-
Methods area
-
Runtime constant pool (part of the method area)
As shown in figure – >
Program Counter Register
Because multithreading in the Java VIRTUAL machine is implemented by the way threads alternate and allocate processor execution time, at any given time, one processor (or core for multi-core processors) will execute instructions in only one thread. Therefore, in order to recover to the correct execution position after thread switching, each thread needs to have an independent program counter, which is not affected by each other and stored independently. We call this kind of memory area “thread private” memory. If the thread is executing a Java method, this counter records the address of the virtual machine bytecode instruction being executed. If the Native method is being executed, this counter value should be null.
This memory region is the only one where the Java Virtual Machine Specification does not specify any OutOfMemoryError cases.
Java Virtual Machine Stack (Java Virtual Machine Stack)
The Java virtual machine stack is also thread-private and has the same life cycle as a thread. 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. The “stack” usually refers to the virtual machine stack in this case, or more often just a partial variable table portion of the virtual machine stack.
In the Java Virtual Machine Specification, two types of exceptions are specified for this memory region:
1. StackOverflowError is raised if the thread request stack depth is larger than the virtual machine allows.
/** * Thread request stack depth is greater than the maximum depth allowed by the VM * VM Args: -Xss128k */ public class StackOverflowErrorTest { static class JavaVMSOF { private int stackLength = 1; public void stackLeak() { stackLength++; stackLeak(); } } public static void main(String[] args) { JavaVMSOF javaVMSOF = new JavaVMSOF(); try { javaVMSOF.stackLeak(); } catch (Throwable e) { System.out.println("stack length = " + javaVMSOF.stackLength); throw e; }}} -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- the output -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- the stack length: 2402 Exception in the thread "main" java.lang.StackOvSerflowError at org.fenixsoft.oom. JavaVMStackSOF.leak(JavaVMStackSOF.java:20) at org.fenixsoft.oom. Javavmstacksoft.java :21) at org.fenixsoft.oom. Javavmstacksoft.leak (javavMStackSoft.java :21)... Follow-up exception stack information is omittedCopy the code
2. If the Java VM stack can be dynamically expanded, an OutOfMemoryError will be thrown if sufficient memory cannot be allocated during stack expansion
The local variable table contains all the basic Java virtual machine data types (Boolean, byte, CHAR, short, int, float, long, double) and object references (reference type, which may be a reference pointer to the starting address of the object) known at compile time. They may also point to a handle representing an object or other location associated with that object) and the returnAddress type (which points to the address of a bytecode instruction).
The storage space of these data types in the local variable table is represented by local variable slots, where 64-bit long and double data types occupy two variable slots and the rest occupy only one. The memory space required for the local variable table is allocated at compile time. When entering a method, how much local variable space the method needs to allocate in the stack frame is completely determined, and the size of the local variable table does not change during the method run. Please note that “size” refers to the number of variable slots, and how much memory the virtual machine really uses to implement a variable slot (for example, 32 bits, 64 bits, or more per variable slot) is entirely up to the individual virtual machine implementation.
Native Method Stacks
The role of the Native method stack is very similar to that of the virtual machine stack, except that the virtual machine stack performs Java methods (that is, bytecode) services for the virtual machine, while the Native method stack serves the Native methods used by the virtual machine. Like the virtual stack, the local method stack throws StackOverflowError and OutOfMemoryError, respectively, when the stack depth overflows or the stack extension fails.
Java Heap
The Java heap is the largest chunk of memory managed by the 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.
The Java Virtual Machine Specification describes the Java heap as follows: “All the object instance and the array should be” allocated on the heap, and here to write “almost” refers to from the Angle of implementation, along with the development of the Java language, now we can see some signs of possible value type support in the future, even if only consider now, because of instantaneous compiling technology progress, especially the escape analysis technology of increasingly powerful, Allocation on the stack, scalar replacement optimization has led to some subtle changes, so it is becoming less absolute that Java object instances are all allocated on the heap.
The Java Heap is also known as the “Garbage Collected Heap”. From the perspective of reclaimed memory, since most modern garbage collectors are designed based on generational collection theory, Java heap often has “new generation”, “old generation”, “permanent generation”, “Eden space”, “From Survivor space”, “To Survivor space”, etc.
From the perspective of memory Allocation, the Java heap shared by all threads can be allocated with multiple Thread private Allocation buffers (TLabs) to improve the efficiency of object Allocation. However, no matter what the perspective is, no matter how it is divided, it does not change the commonality of what is stored in the Java heap. No matter what region is stored, it can only store instances of objects. The purpose of subdividing the Java heap is to recycle memory better, or to allocate memory faster.
The Java heap can be implemented as either fixed size or extensible, but most current Java virtual machines are implemented as extensible (with the -xmx and -xms parameters).
The Java virtual machine will throw an OutOfMemoryError if there is no memory in the Java heap to complete the instance allocation and the heap can no longer be extended.
/** * VM Args: -Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError */ public class HeapOOM { static class OOMObject { } public static void main(String[] args) { List<OOMObject> list = new ArrayList<OOMObject>(); while (true) { list.add(new OOMObject()); }}} -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - the output -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Java. Lang. OutOfMemoryError: Java heap space Dumping heap to java_pid3404.hprof ... Heap dump file created [22045981 bytes in 0.663 secs]Copy the code
Method Area
The method area, like the Java heap, is an area of memory shared by individual threads to store type information that has been loaded by the virtual machine, constants, static variables, just-in-time compiled code caches, and so on. Although the Java Virtual Machine Specification describes the method area as a logical part of the Heap, it has an alias called “non-heap” to distinguish it from the Java Heap.
In JDK 7 HotSpot has removed the string constant pool, static variables and so on from the permanent generation. In JDK 8 HotSpot has completely abandoned the concept of permanent generation and replaced it with a meta-space implemented in local memory. Move all of the remaining content of the persistent generation in JDK 7 (mainly type information) into the meta space.
OutOfMemoryError is thrown if the method area cannot meet the new memory allocation requirements.
Runtime Constant Pool
The runtime constant pool is part of the method area. The Constant Pool Table is used to store various literals and symbolic references generated at compile time. This part of the Table is stored in the runtime Constant Pool of the method area after the Class is loaded.
Runtime constant pool relative to the Class file another important feature of the constant pool is dynamic, the Java language does not require constant must only compile time to produce, that is, into the Class files is not preset constant pool can enter into the content of the runtime constant pool method area, during the run can also be new constants in the pool, One feature that developers use most often is the Intern () method of the String class.
Since JDK 7, the pool of string constants that was stored in the permanent generation has been moved to the Java heap. An OutOfMemoryError is raised when the constant pool can no longer allocate memory, consistent with the Java heap exception information.