This is the 11th day of my participation in the More text Challenge. For more details, see more text Challenge

During the execution of Java programs, the Java virtual Machine divides the memory area managed by it into several different data areas. These zones have their own purpose and creation and destruction times, some of which persist with the start of the virtual machine process, while others are created and destroyed as user threads are started and destroyed. The memory areas managed by the JVM include the following.

A method of area

The method area belongs to the thread shared area and is used to store data such as type information, constants, static variables, and code cache compiled by the real-time compiler that has been loaded by the VIRTUAL machine. If the amount of data in the method area exceeds this size, an OutOfMemoryError will result.

Before Java 6, people used to call method areas immortal, but in fact the two are not equivalent, and it is only because HotSpot developers are using immortal to implement method areas in order to facilitate garbage collection of method areas that the method areas are called immortal. In Java 7, the string constant pool and static variables were moved out of the “eternal generation”, greatly increasing the maximum capacity of the string constant pool and thus reducing the probability of OutOfMemoryError. After Java 8, the concept of “immortal generations” was abandoned completely and the method area was moved to the Metaspace of local memory.

2 the heap

The Java heap is the largest area of memory managed by the virtual machine and is also a thread shared area. The sole purpose of the Java heap is to store object examples, where “almost” all object instances in Java are allocated memory. The Java heap is an area of memory managed by the garbage collector.

From a memory allocation perspective, the Java heap can be divided into multiple thread-private allocation buffers (TLABS) to improve the efficiency of object allocation. The size of the Java heap for an extensible design can be set with the -xmx and -xms parameters. An OutOfMemoryError is thrown if there is no memory in the Java heap for instance allocation and the heap is no longer growing (physical memory is full and cannot provide heap memory expansion or the heap size has reached the -xmx setting).

3 Program counter

The program counter is used to indicate the bytecode line number executed by the current thread, so it belongs to a thread-private area. In the JVM’s model concept, the bytecode interpreter works by changing this counter value to select the next bytecode instruction to execute. It is the thread control flow indicator, branch, loop, jump, exception handling, thread recovery and other basic functions need the program counter to complete.

If a thread is executing a Java method, the counter records the address of the virtual machine bytecode instruction being executed. If the thread is executing a local method, the counter value is null.

4 Java VM stack

The Java virtual machine stack is also thread private and has the same life cycle as the thread. The virtual machine stack records the memory model of Java method execution. As each method executes, the JVM synchronously creates a stack frame and pushes the stack frame into the virtual machine stack. Method, the corresponding stack frame will be out of the stack. Each stack frame generally consists of the following four parts:

  • Local variable table: Used to store method parameters and local variables defined within the method.
  • Operand stack: The stack of storing operands for bytecode instructions
  • Dynamic connection: Used to hold references to the runtime constant pool
  • Return address: Records the location where the upper-level calling method is called

There are two exceptions: virtual machine stack the request if the thread stack depth is greater than the virtual machine to allow maximum depth, throws StackOverflowError exception; An OutOfMemoryError is thrown when enough memory is not available when the stack is extended.

5. Local method stack

Similar to the virtual machine stack, the difference is that the local method stack serves local calls. Similarly, there are two exceptions in the local method stack: StackOverflowError and OutOfMemoryError.

6. Runtime data memory model