There are differences between JDK1.6 and 1.8

Thread private: Thread shared:
Program counter The heap
The virtual machine stack Methods area
Local method stack Direct memory (part of the non-runtime data area)

Program counter

  • A program counter is a small memory space that can be thought of as a line number indicator of the bytecode being executed by the current thread. It is an indicator of program control flow, and basic functions such as branch, loop, jump, exception handling, thread recovery rely on this counter
  • Each thread needs to have an independent program counter, each thread does not affect each other, independent storage, thread private

The program counter has two main functions

  1. The bytecode interpreter changes the program counter to read instructions in turn, thus achieving control of the flow of code, such as sequential execution, selection, looping, exception handling.
  2. In the case of multiple threads, the program counter is used to keep track of where the current thread is executing, so that when the thread is switched back it can know where it was last run.

Note: The program counter is the only one that does not appearOutOfMemoryErrorA memory region whose life cycle is created with the creation of a thread and dies with the end of the thread.

Vm stack (stack)

  • The virtual stack is also thread-private and has the same lifetime as a thread
  • The virtual machine stack describes the thread-memory model of Java method execution, and each time a method is executed, the Java Virtual machine synchronously creates a stack frame. Each method is called until the execution is complete, which corresponds to the process of a stack frame in the virtual machine stack from the stack to the stack.
  • The stack frame contains the local variable table operation tree stack dynamic link method exit
  • A StackOverflowError will be raised if the thread requests a stack depth greater than the virtual machine allows

The local variable table mainly stores various data types known at compile time (Boolean, byte, CHAR, short, int, float, long, double), object reference type (reference type, which is different from the object itself, may be a reference pointer to the starting address of the object. It may also point to a handle representing an object or other location associated with this object.

Local method stack

The role played by the Native method stack is very similar to that of the virtual machine stack. The difference is that the virtual machine stack executes Java methods for the virtual machine, while the Native method stack executes Native methods.

When a local method is executed, a stack frame is also created on the local method stack to hold the local variable table, operand stack, dynamic link, and exit information for the local method.

The heap

The largest chunk of memory managed by a Java virtual machine, the Java heap is an area of memory shared by all threads and created when the virtual machine is started. The sole purpose of this memory area is to hold object instances, and almost all object instances and arrays are allocated memory here.

In the Java world, “almost” all objects are allocated in the heap, but as JIT compile-time and escape analysis techniques mature, on-stack allocation and scalar replacement optimization techniques lead to subtle changes that make all objects allocated on the heap less “absolute”. Escape analysis has been enabled by default since JDK 1.7, and objects can allocate memory directly on the stack if object references in certain methods are not returned or not used outside (that is, not escaped).

Since most collectors now use generational garbage collection algorithms, the Java heap can be subdivided into: new generation and old generation: Eden space, From Survivor, To Survivor space, and so on. The purpose of further partitioning is to better reclaim memory, or to allocate memory faster.

Prior to JDK 7 and JDK 7, heap memory was generally divided into the following three parts:

  1. Young Generation
  2. Old Generation
  3. Permanent Generation

After JDK 8, the method area (HotSpot’s permanent generation) was completely removed (already in JDK1.7) in favor of the meta space, which uses direct memory.

In most cases, the object will be allocated in Eden first. After a Cenozoic garbage collection, if the object is still alive, it will enter S0 or S1 and its age will be increased by 1(the initial age of the object becomes 1 after Eden ->Survivor). When it reaches a certain age (15 by default), it is promoted to the old age. The age threshold at which the object is promoted to the old age.

Methods area

* The method area, like the heap, is an area of memory shared by threads * it is used to store data such as type information that has been loaded by the virtual machine constant static variables code cache compiled by the just-in-time compilerCopy the code

Relationship between method region and permanent generation

The Java Virtual Machine Specification defines the concept of a method area and what it does, not how to implement it. Then, the implementation of the method area must be different on different JVMS. The relationship between a method area and a persistent generation is much like the relationship between an interface and a class in Java that implements the interface, and a persistent generation is the HotSpot VIRTUAL machine’s way of implementing the method area in the VIRTUAL machine specification. In other words, persistent generation is the concept of HotSpot, method area is defined in the Java virtual machine specification, is a specification, and persistent generation is an implementation, one is a standard and one is an implementation, other virtual machine implementations do not have the term persistent generation. For the interview

Method sections are a standard idea, and the persistent generation prior to Java 8 was implementation.

Back in JDK6, the HotSpot team had plans to move away from persistent generation to local memory to implement the method area

In JDK7, remove the string constant pool and static variables from the permanent generation.

By the time of JDK8, the permanent generation was completely abandoned, and the remaining type information in JDK7 was moved into the meta space.