The Java memory region of the JVM
This series is an introduction to the Java Vitrual Machine (Java Virtual Machine) series and is a summary of the in-depth Understanding of Java Virtual Machine (JVM) advanced Features and Best Practices. The first chapter will of course cover the various components of the JVM.
Introduction of the JVM
Before introducing the JVM, it is no doubt necessary to introduce the CONCEPTS of JDK and JRE.
JDK: Java Ddvelopment Kit
JDK, Java Ddvelopment Kit, Java software development Kit It is the core of the entire Java, in addition to the basic Java library, it also contains Java compilation, debugging Java program toolkit, that is to say JDK includes JRE.
JRE: Java RunTime Environment
JRE, Java RunTime Environment, Java RunTime environment The PURPOSE of the JRE is to enable our operating system to run Java programs, and the JRE contains both the JVM and the core class libraries. Therefore, we can know that JDK, JRE, JVM include the following relationship.
History of Java
In 1991, an initiative called the Green Project spawned Oak, Java’s predecessor, a programming framework that was intended to run on a wide range of consumer electronics. In 1995, with the rise of the Internet, Oak found its way into Java. JDK 1.0 was released in 1996, providing a pure interpreted execution Java Virtual Machine (Sun Classic VM) implementation. In 1998, a just-in-time (JIT) compiler was built into the JVM, while JDK1.2 released three virtual machines to handle three different versions (EE, SE, ME). In 1999 the HotSpot virtual machine was born and the JDK was upgraded to version 1.3. ·· The JDK has also been updated, and in 2006, changes were made to the implementation of locking and synchronization, GC, class loading, and so on. In 2018, JDK10 was released at the same time that Google and Oracle fought the Android war and Google lost the lawsuit. JDK has been released to JDK15. The JVM is also changing as Java evolves.
Introduction to THE development of JVM
The ancestor of the virtual machine is the 1996 Sun CLassic/Exact VM, which was the JVM when the Java language first had a commercial formal runtime environment. It was still able to execute Java programs in a pure interpreter mode, and JIT just-in-time compilers had to be plugged in to use it. And because of this, the perception that Java is slow takes root. Here’s how interpreter execution differs from compiler execution:
| Implement way | process |
|---|---|
| Interpreter execution | Input code =>[interpreter interprets execution]=> execution result |
| Compiler execution | Input code =>[compiler compilation]=> Compiled code =>[execution]=> execution result |
The compiler compiles the input code into bytecode (native code) and saves it.
After that, HotSpot VM replaced the Classic VM and became the most popular JVM we use today, but it was not developed by Sun, it was “LongView Technologies”. Of course there are many other VMS in the history of the JVM, but currently we use HotSpot VM most widely and continuously updated with the Java version.
Java VIRTUAL machine memory area
The biggest difference between Java and C++ lies in the memory management method. Java has automatic vm memory management mechanism, dynamic memory allocation and garbage collection technology support, while C++ manages and reclaims all of its own, so Java is less prone to memory leakage and overflow problems. But this is also the downside of Java. When memory leaks and spills occur, knowing how the virtual machine works can help you troubleshoot and fix the problems. The following describes the memory distribution of the Java virtual machine. \
Runtime data area
During the execution of a Java program, the JVM divides the area of memory it manages into different data areas. According to the Java Virtual Machine Specification, there are roughly five areas: program calculator, virtual machine stack, local method stack, heap, and method area. These areas are collectively referred to as run-time data areas.
Program Counter (Proogram Counter Register)
Program counters are small in memory and are indicators of bytecode instructions executed by the current thread. This is analogous to the CPU’s program counter (PC counter). The program counter of the Java virtual machine is mainly used to store the next bytecode instruction (or address) to be executed. The bytecode interpreter selects the next instruction to be executed by changing the point of the counter. Java virtual machine multithreading is implemented by switching threads in turn and allocating processor execution time, that is, only one thread will execute instructions at a time. Therefore, in order to return to the correct execution position after switching, each thread has its own program counter, that is, the program counter is. Note:
- The program counter is the only area that does not specify OOM (Out Of Memoory)
- When a Java method is run, the counter records the address of the instruction; When a local method is run, the value of the counter is null.
Java virtual machine stack
Like the PC Register, the Java Virtual Machine Stack is thread-private and has the same lifecycle as the thread, so this area is also thread-safe. The virtual stack describes the thread-memory model of Java method execution: Each time a method is executed, the JVM synchronizes the creation of a stack frame, which is an important data structure during the execution of a method. The stack frame is used to store local variables, operand stacks, dynamic concatenations, method exits, etc., so we can see how a method is called to completion. That is, the process of the stack frame in and out of the virtual machine stack. Note:
- The stack depth is usually limited, so if the method stack depth is too deep for the virtual machine, the virtual machine will throw
StackOverflowErrorThe exception. - An OOM exception is raised when the Java VM stack dynamically allocates or expands more memory than the remaining memory.
Local method stack
The Native Method stack is similar to the virtual machine stack, except that the virtual machine stack performs Java methods (bytecode) services for the virtual machine, whereas the Native Method stack performs Native methods for the virtual machine.
The Java heap
The Java Heap is the largest portion of memory managed by a virtual machine. Like the “heap” area in C, this is an area of memory shared by all threads and freely allocated dynamically by developers. In Java, the only memory in this area is for object instances. According to the Java Virtual Machine Specification, “all object instances and arrays should be allocated on the heap”, and the Java heap has the characteristics of physical discontinuous, logically continuous storage. In addition, Java heaps are referred to as “GC heaps.” Because it is an area of memory managed by the garbage collector. For GC reactor, based on the generation collection theory design, there are “new generation”, “old age”, “permanent generation” and other regional divisions. Note that these partitions are not real fixed memory layouts, but rather a design style. Note: The Java heap can be either fixed size or extensible (dynamic scaling is preferred), but an OOM exception will be raised when the heap wants to expand and there is no memory allocated for instance.
Methods area
Like the Java heap, the Method Area is also a thread shared memory Area. It is mainly used to store various data that has been loaded by the virtual machine, such as type information, constants, static variables, and code cache compiled by the just-in-time compiler. In the Java Virtual Machine Specification, the method area is also referred to as a “non-heap” to distinguish it from the Java Heap. Its action is similar to the Java heap, but compared to the Java heap, method of area can choose not to realize garbage collection, then this does not mean that permanently retain the data into the area, the area of recycling mainly aims at the constant pool a constant pool (runtime) recycling as well as the type of discharge, especially the latter is difficult to control. Note: Since the method area is similar to the Java heap, it’s easy to imagine that an OOM exception will be thrown when the method area fails to meet the new memory allocation.
Run-time constant pool
The Runtime Constant Pool (Runtime Constant Pool) is used to store literal and symbolic references generated at compile time. The Runtime Constant Pool (Runtime Constant Pool) is used to store literal and symbolic references generated at compile time. This content is stored in the runtime constant pool of the method area after the class is loaded. This concludes our coverage of the large areas of the JVM runtime data area.
conclusion
The blogger is also slowly learning the JVM, the early stage of the JVM run time data area has been through, sorted out the role of these areas and some scenarios will be OOM exceptions, hoping to make everyone have a relatively comprehensive understanding of the JVM.