Runtime data area

These two images are a great way to build up a picture of the JVM runtime data area, so let’s take a step back and demystify the runtime data area.

Program counter

Before talking about the program counter, I have to talk about the CPU operation related knowledge, we all know that the CPU operation is the need for context, at the same time, the CPU is actually a chip constantly executing instructions, calculations, in order to make the CPU function normal operation, we need to have registers and program counter to cooperate with the CPU work. This is the bottom of the computer.

To the upper application program is also inseparable from the lower logic, the thread is the CPU’s most basic dispatching unit, so if the thread wants to make the CPU run, then must provide the corresponding guidance for the CPU, so the program counter is so come. It is an indicator of program control flow.

We note that the program counter is private, in other words, we do not want A thread to use B threads of the program counter, it is reasonable, because developers in the development process can control each thread painstakingly to do something, for example, A thread is responsible for looking for user information, B thread is responsible for the order, if A thread to run B thread code, isn’t it ridiculous? The same is true for virtual machine stacks and native method stacks.

The virtual machine stack

The virtual machine stack describes the memory model of Java threads.

Added a virtual machine virtual machine stack of nouns, namely a stack, and each method in the implementation will be the JVM when added to the stack in the stack (virtual machine), and the method in the JVM USES a call stack frame to represent the data structure, the key point of this section is not speak stack frame, if readers want to know, I will specifically talk about the data structure. What we need to know is that in order for the JVM to remember what the current thread did and in what state, the stack frame needs to record local variables, method return addresses, and so on.

Local method stack

This is similar to the virtual stack, because the JVM itself is actually developed by CPP, and some methods in JDK source code call native methods (i.e. non-Java code methods) directly, so you need a native method stack to record this process.

The Java heap

This is the star name of the JVM runtime data area. This is the area where a large number of objects live. Almost all new objects are stored here.

Since the Java heap holds almost all objects, this location must be the workspace of the garbage collector, so the Java heap is also referred to as the GC heap.

Methods area

When it comes to methods, that’s interesting.

The method area, like the Java heap, is shared by all threads. It is used to store:

  • The type information
  • constant
  • A static variable
  • Immediate compiler compiled code cache and other data
  • Run-time constant pool

In addition, I would like to focus on how the method area has changed in the JDK. 89

The method area is initially implemented in the Permanent generation in the Java heap, but objects in the permanent generation, as the name implies, are difficult to clean up. Therefore, the garbage collector does not collect the permanent generation very early, making it prone to memory leaks.

To solve this problem, the official plan is to move the method area from permanent generation to operating system memory, also known as meta-space. Permanent generation was officially phased out in JDK 6, string constant pools, static variables, etc. were removed in JDK 7, and the concept disappeared in JDK 8.

As shown below: