Write in front: the blogger is a real combat development after training into the cause of the “hill pig”, nickname from the cartoon “Lion King” in “Peng Peng”, always optimistic, positive attitude towards things around. My technical path from Java full stack engineer all the way to big data development, data mining field, now there are small achievements, I would like to share with you what I have learned in the past, I hope to help you on the way of learning. At the same time, the blogger also wants to build a perfect technical library through this attempt. Any anomalies, errors and matters needing attention related to the technical points of the article will be listed at the end, and everyone is welcome to provide materials in various ways.

  • Please criticize any mistakes in the article and revise them in time.
  • If you have any questions you would like to discuss or learn, please contact me at [email protected].
  • The style of the published article varies from column to column, and all are self-contained. Please correct the deficiencies.

How does the JVM allocate administrative memory?

Keywords: JVM, virtual machine stack, Java heap, method area, runtime constant pool \

The article directories

This article is based on in-depth Understanding of Java Virtual Machines: JVM Advanced Features and Best Practices (3rd edition) and Java Virtual Machine Specification (Java SE 8th Edition), these are two rare good books, I recommend you to buy physical books, will consider opening a sub-column under the “Borrow books to eat” column, if you need to try electronic version can follow me.

First, the JVM memory area

When Java programs run, they first read the compiled class file, and since we define and use structures and objects when we write the source code, the JVM divides the allocated memory into regions when loading.Normally we would roughly divide memory into “stack” and “heap” areas, but for Java virtual machines we should go further.



Different areas created by the JVM, some of which are created when the vm starts and destroyed when the VM exits, such as Method areas and the Java heap. Others, such as PC registers, Java virtual machine stacks, and local method stacks, are thread-specific and are created and destroyed as threads start and end.

1. The PC register

Although the Java Virtual machine supports simultaneous multithreading, at any one time a JVM thread executes code for only one method, the method being executed by the thread is called the current method of that thread, and the corresponding Java virtual machine stack is called the current stack frame. The PC register is a small area of memory that can be thought of as a line number indicator of the bytecode being executed by the current thread, and each JVM thread has its own PC register. The bytecode interpreter works by changing the value of this counter to select the next bytecode instruction to be executed. It is the indicator of program control flow, and basic functions such as branch, loop, jump, exception handling and thread recovery depend on this register. If the current method is not native, the PC register holds the address of the bytecode instruction being executed by the Java VIRTUAL machine. If the method is native, the PC register value is undefined. (For a description of Native, see: 3. Native method Stack)

2. Java VM stack

Each JVM thread has its own private Java virtual machine stack, created at the same time as the thread, to store stack frames, which contain local variables and some unfinished results. In addition, note that: The concepts of Stack, Heap, Java VM Stack, and Java Heap are different. The Java virtual machine itself is also a piece of software written and run by other languages, so this article only discusses the memory area managed by the JVM. The distribution of regions in the stack is not discussed. The Java Virtual Machine specification allows the Java virtual machine stack to be implemented as a fixed size and to be dynamically expanded and contracted based on computation. The Java virtual machine stack describes the memory model of the thread on which Java methods execute: When each method is executed, the Java VIRTUAL machine will create a stack frame, which is used to store the information of local variable table, operand stack, dynamic link, etc. The process from the invocation of each method to the completion of execution corresponds to the process of a stack frame in the virtual machine stack. When a new method is called, a new stack frame is created, and control of the program is transferred to the new method called as the new stack frame. Complete to return in the method, the current stack frame will be sent back before the implementation of this method results to a stack frame (called the stack frame of the new approach), then the virtual machine will discard the current stack frame, the previous frame as the current stack frame, you can use this article to understand the process: a Java method of nested with the recursive call.

  • Local variable scale

Inside each stack frame is a list of variables called a local variable table, the length of which is determined at compile time. A local variable can hold data of type Boolean, byte, CHAR, short, int, float, Reference, or returnAddress. Two local variables can hold data of type long or double. Local variables use indexes for location access. The index value of the first local variable is 0, and the maximum value is less than the length of the local variable table. For long and double, since two consecutive local variables are occupied, the smaller index value of the local variable is used to locate the value.

  • The operand stack

Each stack frame contains a lifO stack called the operand stack. The maximum depth of the operand stack is determined by the compiler. The operand stack is generally referred to as the “operand stack of the current stack frame”. When the stack frame is created, the operand stack is empty. The JVM provides bytecode instructions to copy the value of a constant or variable from the fields of a local variable table or object instance to the operand stack, as well as instructions for fetching data from the operand stack, manipulating data, and pushing the results of operations back onto the stack. When a method is called, the operand stack is also used to prepare the parameters of the calling method and to receive the result returned by the method. At any given time, the stack of operands has a certain stack depth, and a long or double will occupy two units of stack depth, and other data types will occupy one unit of stack depth.

  • Dynamic link

Each stack frame contains a reference to the runtime constant pool of the current method’s type to dynamically link the current method’s code. In a class file, a method that calls other methods or accesses a member variable is represented by symbolic references. Dynamic linking converts these symbolic references to a direct reference to the actual method. \

3. Local method stack

Since it is sometimes necessary to call methods written in other languages (such as C language), it is necessary to use the traditional C stack to support the execution of native methods. Native is a modifier in the Java language, and if a method is modified by native, it means that the method is a Java interface that calls non-Java code. When defining a native method, it is not necessary to specify the method body, which is similar to the method declaration in the interface. The specific method implementation will be loaded in DLL or other library files at runtime. The function of the local method stack is very similar to that of the Java virtual machine stack, except that the Java virtual machine stack serves the execution of Java methods by the virtual machine, whereas the local method stack serves the invocation of local methods by the virtual machine.

4. The Java heap

The Java heap is the largest area of memory managed by the JVM and is shared by all threads, created when the virtual machine is started. The Java heap mainly stores instances of objects, including instances of array types. Objects stored in the Java heap are managed by an automatic memory management system, the garbage collector, and do not need to be manually destroyed and freed. In addition, the region corresponding to the Java heap does not need to be contiguous.

5. Methods area

The method area, like the Java heap, is an area of memory shared by threads that stores structural information about classes that have been loaded by the virtual machine, including runtime constant pools, constructors and common methods, static variables, and so on. The method area is created when the virtual machine is started, and although the method area is logically part of the heap, you can choose not to implement garbage collection and compression in this area. The Java Virtual Machine Specification (Java SE Version 8) also does not limit the memory location of the implementation method area or the management policy for compiled code. The size of the method area can be fixed, or it can expand dynamically as the program executes and automatically shrink when no more space is needed. Method areas can be discontinuous in real memory space. From Understanding the Java Virtual Machine in Depth: Advanced JVM Features and Best Practices (version 3) : In JDK 6, the HotSpot development team had a plan to abandon the permanent generation and gradually adopt Native Memory to implement the method area. In JDK 7, HotSpot has removed the string constant pool, static variables and so on from the permanent generation. In JDK 8, HotSpot has removed the string constant pool from the permanent generation. Finally, the concept of permanent generation is completely abandoned, and replaced by Metaspace, which is implemented in local memory like JRockit and J9. All remaining content (mainly type information) of permanent generation in JDK 7 is moved into Metaspace. The structure defined in many classes is stored in the same location as the structure defined in the class.

  • Different versions of the JVM manage the method area differently
  • There are various Java VMS that can run Java programs and manage different areas
  • HotSpot VM and JRockit VM have been merged in Oracle JDK8



The method area itself is one of the areas managed by JVM allocation. As we have seen from the above statement,With The Oracle JDK8 version, the method area is no longer implemented using persistent generation, and the contents of the method area are all moved to the local memory meta-space.

6. Runtime constant pool

First of all, run-time constant pools are not the same as constant pools! The runtime constant pool is part of the method area and is a runtime representation of the constant pool table for every class or interface in a class file. It contains several different constants: numeric literals known at compile time and method or field references that can only be obtained after parsing at run time. After the Java Virtual machine loads the class and interface, the corresponding runtime constant pool is created. The Java Virtual machine maintains a constant pool for each type, which is a runtime data structure in the Java Virtual machine. All references in the runtime constant pool are initially symbolic references, and there are specifications and formats for symbolic references of different structures (classes, interfaces, arrays, and so on). Because symbolic references to constant pools at run time are complex and the explanation of constant pools involves the loading mechanism of classes, it will not be covered in this article and will be covered in other articles (including the specified policy for string constants).

Two, common structure storage location

After reading the previous content, we can memorize a wave of conclusions, knowing some of the underlying things helps us to explain or memorize certain usages and characteristics.

1. Common member variables

Since ordinary member variables are used after the object is created, the values or references of the primitive data types (independent of the type of the member variable) are stored in the corresponding instance space, in the Java heap.

2. Static member variables and static code blocks

Static member variables and static code blocks are structures that use static declarations directly under the class and are stored in the method area.

Constructors and dynamic code blocks

Constructors are also method-like structures that are executed when called by new, while dynamic code blocks appear in constructors when compiled and are stored in the method area.

  • Before compiling
public class Person{

    {
        System.out.println("init");
    }

    public Person(a){
        System.out.println("default");
    }

    public Person(int a){
        System.out.println("another"); }}Copy the code
  • The compiled



4. Ordinary and static methods

Normal methods and static methods, although called and used differently, are essentially method structures that need only be loaded once for a class and stored in the method area.

5. Method local variables

For variables defined in a method, due to the existence of a local variable table, the basic data type is stored directly in the JVM stack. For variables of reference type, only reference is stored in the JVM stack, and the corresponding instance is stored in the Java heap.

Scan the QR code below and join the official fan wechat group. You can communicate with me directly and have more benefits