Memory partition

Method Area (Program Counter Register)

  • Before JDK1.8, the method area represented an area in the JVM where classes were loaded from “.class “files. There was also something like a constant pool in this area, but after JDK1.8, it was called” Metaspace “, which can be thought of as “metadata space”
  • The method area, like the heap, is shared by all threads and stores Meta data loaded by the virtual machine, including class information, constants, static variables, and code compiled by the just-in-time compiler. The important thing to note here is that the runtime constant pool is also in the method area.
  • According to the Java Virtual Machine specification, OutOfMemoryError is thrown when the method area cannot meet memory allocation requirements. Due to the early implementation of HotSpot JVMS, which extended CG generation collection to the method area, many would refer to the method area as permanent generation. Oracle JDK8 has removed permanent generations and added Metaspace

Program Counter Register

Program Counter Register. In the JVM specification, each thread has its own Program Counter. This is a relatively small memory space that stores the ADDRESS of the JVM instructions for the Java method being executed by the current thread, the line number of the bytecode. This counter is empty if the Native method is being executed. This memory area is the only one that does not specify any OOM condition in the Java Virtual machine specification

Java Virtual Machine Stack (Java Virtal Machine Stack)

Each thread creates a virtual stack when it is created. The life cycle is the same as that of the thread. When the thread exits, the virtual stack of the thread is reclaimed. The virtual machine keeps a stack frame inside the stack, each method call will be pressed, the JVM on the stack frame only out of the stack and push two operations, the method call at the end of the stack operation.

This area stores local variation tables, basic types of data known at compilation time, object references, method exits and other information

Java Heap Memory

Almost all Java object instances created are allocated directly to the heap. The heap is shared by all threads, and areas on the heap are further divided by the garbage collector, such as new generation and old generation. When a Java virtual machine starts up, you can specify the size of the heap area with a parameter like “Xmx”

Other memory areas

In fact, in the JDK many underlying APIS, such as IO related, NIO related, network Socket related

If you look at its internal source code, you will find that many places are not Java code, but to call some methods in the local operating system by using native methods.

You may be calling methods written in C, or some underlying class library

Public native int hashCode();

When calling this native method, there will be a local method stack corresponding to the thread, which is similar to the Java virtual machine stack, and also stores various Native sides

Method of local variable scale and so on.

There is also an area, which is not part of the JVM, where memory can be allocated outside the Java heap through the allocateDirect API in NIO. Then, virtual through Java

DirectByteBuffer in the machine to reference and manipulate the off-heap memory space.

Many technologies use this approach, as there are scenarios where off-heap memory allocation can improve performance.

Core memory regions are concatenated

The sample code

public class HelloWorld {
    public static void main(String[] args) {
        Demo demo = newDemo(); demo.load(); }}public class Demo {
    private long count;

    public void load(a) {
        boolean isFinish = false; }}Copy the code

The JVM process starts and loads the HelloWorld class into memory. There is then a main thread that starts executing the main() method in HelloWorld

2, The main thread is associated with a program counter, so which line of instruction it executes is recorded here

3. Second, when the main thread executes the main() method, it pushes a stack frame of the main() method into the Java virtual machine stack associated with the main thread.

The Demo class is then loaded into memory. An instance of the Demo object is then created and allocated to Java heap memory. A “Demo” variable is introduced into the local variable table in the main() stack frame. Let him reference the address of the Demo object in the Java heap memory

5. Next, the main thread executes the methods in the Demo object, pushing the stack frames corresponding to the methods it executes into its Own Java virtual machine stack

6. After executing the method, remove the corresponding stack frame from the Java virtual machine stack

The following figure can be drawn according to the above text to describe the process: