• 1. The Program Counter Register is a small memory space that can be regarded as a line number indicator of the bytecode executed by the current thread. The bytecode interpreter works by changing the value of this counter to select the next bytecode instruction to execute.

• 2. Bytecode instructions, branches, loops, jumps, exception handling, thread recovery and other basic functions rely on this counter.

• 3. Each thread has an independent program counter, counters between each thread do not affect each other, independent storage. As shown in the figure above, we call this type of memory area: thread private memory.

• 4. 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 is null (Undefined).

• 5. This memory region is the only one in the Java Virtual machine that does not regulate any OutOfMemoryError cases.

A stack frame is a data structure used to support virtual machine method invocation and method execution. It is the stack element of the virtual machine stack in the data area when the virtual machine is running. Stack frames are used to store information about local variables, operand stacks, dynamic links, method returns, etc. The process of each method from invocation to completion corresponds to the process of a stack frame in and out of the virtual machine stack. In an active thread, only the stack frame at the top of the stack is valid, called the current stack frame, and the method associated with this stack frame is called the current method. All bytecode instructions run by the execution engine operate only on the current stack frame.

Let’s look at the local variable table a little bit, and we’ll focus on the stack structure later. The local variable table stores the basic data types known at compile time (Boolean, byte, char, short, int, float, long, double). The object reference type and the returnAddress type (which points to the address of a bytecode instruction) are stored in stacks, as many sources on the Trivia web refer to basic data and object references. Of course, this statement is correct, but it is not precise, it can only be said that this statement is aimed at local variables. Local variables are stored in the local variable table and are born and die with the thread. And data is not shared between threads. However, if they are member variables, or references to objects defined outside the method, they are stored in the heap. Because in the heap, threads share data, and the name in the stack frame clearly demarcates the boundary: local variable table!

• 1. The Java heap is an area of memory shared by all threads. It is created when the VIRTUAL machine is started and is the largest chunk of memory managed by the virtual machine. The only purpose of this memory area is to hold object instances and arrays. Almost all object instances and arrays are allocated in this area.

• 2. The Java heap is the primary area managed by the garbage collector, also known as the GC garbage heap. The GC algorithm will be analyzed exclusively later. From the point of view of memory collection, the Java heap can be subdivided into: new generation, old generation; From a memory allocation perspective, a Java heap shared by threads can be divided into multiple thread private allocation buffers (TLabs); No matter how you divide it up, it doesn’t matter what you store. In any region, you still store object instances and arrays.

• 3. OutOfMemoryError is raised if there is no memory in the heap to complete the instance allocation and the heap cannot be extended.

• 4. Memory leak and overflow Memory leak: Memory is allocated dynamically to temporary objects in a program, but the objects are not collected by the GC. That is, the allocated objects are reachable but no longer useful, and there is less and less memory available. Memory overflow: An error that occurs when a program fails to allocate enough memory. A memory overflow usually occurs when there is no memory space for new Java objects after the old generation or permanent generation garbage collection. Memory leaks are a cause of memory overflow, not the only one.

1. The Constant Pool Table is used to store literal and symbolic references generated at compile time. This part of the Constant Table is stored in the runtime Constant Pool after the Class is loaded into the method area.

• Literals: Close to the Java language level of constant concepts, such as text strings, constant values declared final, etc. Final modifies member variables and class variables! “Class variables are static (member) variables,” which are local variables except for final modifications.

• Symbolic references: Concepts that are aspects of compilation principles, including 1. Fully qualified names of classes and interfaces (i.e., paths, package names + class names). 2. Field name and descriptor. 3. Method name and descriptor. When the virtual machine is running, the corresponding symbolic quotes need to be retrieved from the constant pool and parsed and translated into a specific memory address during class creation or runtime (direct reference).

2. In addition to saving symbolic references described in the Class file, compiled direct references are also stored in the runtime constant pool.

3. The Java language does not require that constants be generated only at compile time. That is, a constant that is not in the constant pool of a Class file can be added to the method area’s runtime constant pool. (We’ll examine the String class later.)

4. OutofMemoryError is thrown when the constant pool cannot allocate memory.