JVM memory model and performance tuning __JVM

JVM memory model and memory error

Java Virtual machine managed memory will contain several runtime data regions: Program counter, method area, stack area, heap area, local method stack.

(1) The program counter is a smaller memory space, which can be regarded as the line number indicator of the byte code executed by the current thread. In the virtual machine conceptual model, the bytecode interpreter works by changing the value of this counter to read the next byte code instruction that needs to be executed. Each thread has a separate program counter to hold the state of the thread. Each thread's counters do not affect each other, isolated storage, which we call "thread-private" memory. If the thread executes a Java method, this counter records the address of the executing virtual machine byte-code directive. If the native method is executed, this counter value is empty.
This memory area is the only area that does not specify any outofmemoryerror in the Java Virtual Machine specification.

(2) The virtual machine stack is also thread-private, and its lifecycle is the same as that of the thread. The virtual machine stack describes the memory model executed by the Java method: Each method executes to create a stack frame for storing information such as local variable tables, operand stacks, dynamic links, method exits, and so on. Each method from the call to the execution of the completion of the process, corresponds to a stack frame from the stack to the stacks of the process.
In the Java Virtual Machine specification, two exceptions are specified for this area: if the thread requests a stack depth greater than the virtual machine allows, it throws a Stackoverflowerror exception; if the virtual machine stack dynamic expansion cannot request enough memory, The OutOfMemoryError exception is thrown.

(3) The local method stack plays a similar role to the virtual machine stack, except that the local method area serves the native method. As with virtual machine stacks, the local method stack area also throws Stackoverflowerror and OutOfMemoryError exceptions.

The

(4) Java heap is typically the largest piece of memory managed by a virtual machine and is shared by all threads in an area of memory that is created when the virtual machine is started. The memory area holds an object instance. The Java heap is the main area of garbage collector administration. From the point of view of memory recycling, because the current GC basic use of generational collection algorithm, so in the Java heap can also be subdivided into: the Cenozoic and the old age. From the point of view of memory allocation, the Java heap may be divided into multiple thread-private allocation buffers (thread local allocation buffer). The
throws a OutOfMemoryError exception if no memory completes the instance allocation in the heap, and the heap cannot be extended again.

The

(5) method area , like the Java heap, is an area of memory shared by individual threads that stores data such as class information, constants, static variables, and Just-in-time compiler-compiled code that has been loaded by the virtual machine. A running constant pool is part of a method area. class file except for the version of the class, fields, methods, interfaces, and so on, there is another information that is a constant pool that holds the various literal and symbolic references generated by the compiler, which are stored in the Run-time pool of the class loading the LIFO method area. Since the runtime is a part of the method area and is naturally limited by the method area memory, a OutOfMemoryError exception is thrown when the constant pool can no longer be applied to memory. The
Permanent generation perm space is also the method area, which is the implementation of the JVM specification. When the dynamic loading of more classes (such as more JSP page), prone to memory overflow. has been removed in the jdk8.
Direct Memory is not part of a virtual Run-time data area, nor is it a memory area defined in the Java Virtual Machine specification, but this part of memory is also used frequently and can cause outofmemoryerror anomalies to occur.
A new NiO class is added to the jdk1.4, introducing a channel (Channel) and buffer (buffered) I/O, which can directly allocate heap memory using the native function library, It then operates as a reference to this memory through a Directbytebuffer object stored in the Java heap, which can significantly improve performance in some situations because it avoids replicating data back and forth in the Java heap and the native heap. The allocation of native direct memory is not limited by the size of the Java heap, but since memory is certainly limited by the total native memory size and processor addressing space. When you configure virtual machine parameters, you set-XMX parameter information based on actual memory, but often ignore direct memory, making each memory region more complex than the physical memory limit. This results in a OutOfMemoryError exception when dynamic expansion occurs.
After jdk1.8, the virtual machine is removed from the permanent generation of Perm space, instead of metaspace, the dimension is not in the virtual machine, but the local memory is used directly. JVM Monitoring Tools

JDK command line tools
There are many virtual machine monitoring tools in the JDK's Bin directory, most of which are surprisingly small, because most of these command-line tools are a thin layer of packaging for the Tools.jar class library. The JKD development team has chosen to use Java code to implement these monitoring tools for a reason: When an application is deployed to a production environment, it can be limited either by direct contact with the physical server or by remote telnet to the server. With the help of the interface inside the Tools.jar class library, we can implement powerful monitoring and analysis performance directly in the application. The Command line monitoring tool is described as follows:
(1) JPS, showing all virtual machine processes within the specified system.
(2) Jstat, used to collect all aspects of the virtual machine running data.
(3) Jinfo, display virtual machine configuration information.
(4) Jmap, generate memory dump snapshots of virtual machines.
(5) Jhat, Memory Dump snapshot analysis tool, you can display objects in the heap as HTML, including the number of objects, size, and so on, and support the object query language.
(6) Jstack, displays the virtual machine's thread snapshot.

Visualization Tools
In addition to providing command-line tools, the JDK has two powerful visualization tools, Jconsole and JVISUALVM. The latter, called Oracle's main-driven multiple-in-one fault-handling tool, has been separated from the JDK as an Open-source project that can be independently developed. Introduction to Performance tuning

Most people will use some virtual machine parameters or commands (such as configuration heap memory size, configure garbage collector, etc.) to do simple tuning, but in fact, performance tuning is a complex thing, to do a comprehensive tuning needs to be comprehensive consideration of hardware and software. Here is an introduction to the impact of the garbage collector on applications.

Garbage collection is divided into lightweight garbage collection (Minor gc,major GC) and full GC. Lightweight garbage collection is responsible for recycling the new generation of garbage objects, the general running time is relatively short. The full GC will take a long time to execute after the older generation is filled. Especially when heap memory allocations are too large, the full GC may execute for a long time. When the GC executes, the program is paused, giving the user a feeling that there is no response. Therefore, the frequency of full GC execution must be controlled, and the full GC frequency will be reduced to not affect user use.

In most forms of Web applications, the life cycle of the main object should be request-level or page-level, with few long life objects of session-level and global-level. Therefore, the full GC is rarely present. In this way the use of large heap of memory, the corresponding speed of the site will be more assured.

The following problems are encountered with large heap of memory:
(1) Long pauses caused by memory recovery.
(2) To ensure that the program is stable enough, because this application if the heap overflow can hardly produce heap dump file (because to produce more than 10 GB and even larger dump file), even if the snapshot is almost impossible to analyze.
Therefore, it is a common way to establish logical cluster to utilize hardware resources.

The heap has been a contentious field. First introduced in JDK 7update 4, the G1 (garbage) collector is designed to better support a heap larger than 4GB and hopes to replace the CMS in the future. Compared to the CMS collector, the G1 collector has a lower delay but less throughput performance than CMS.

Reference book: "Deep understanding of Java Virtual machines"