Java Virtual machine memory allocation detailed

Brief introduction

Understanding the benefits of Java Virtual Machine memory distribution

1. Learn the details of Java memory management and help programmers write better-performing programs. For example, when the new thread is created, the JVM will create a dedicated stack for each thread, the stack is the advanced data structure, the characteristics of this way, so that programmers must pay special attention to the recursive method to use as little as possible, and the size of the stack is also a certain limit, if too many recursion, Easily lead to stack overflow.

2. Understand the details of Java memory management and, once a problem occurs in memory management, help to find the root cause of the problem.

3. Understand the inside of Java memory management and help optimize the JVM, so that your application gets the best performance experience.

The architecture of the JVM is as follows

As shown, the JVM's architecture consists of several major subsystems and memory areas:

Class loading Subsystem

is responsible for loading the class from the file system into memory

GC Subsystem

The garbage collector's main studio automatically reclaims memory that is no longer running programs that reference objects, and it may also be responsible for those objects that are still in use to reduce heap fragmentation.

Memory Area

　　Used to store bytecode, objects that are created when the program is run, parameters passed to methods, return values, local variables, and intermediate calculation results.

Execution Engine
1, the simplest: one-time interpretation of bytecode.
2, fast, but memory consumption: "Instant Compiler", the first executed bytecode will be compiled into machine code, put into the cache, later calls can be reused.
3, Adaptive Optimizer, the virtual machine will begin to interpret bytecode, but will monitor the activity of the running program, and record the most frequently used code snippets. When the program runs, the virtual machine compiles only the most frequently used code, and the rest of the code is kept as bytecode because it is not used frequently--the virtual machine continues to interpret them. In general, the Java Virtual machine can be 80%~90% time to execute the optimized local code, only need to compile 10%~20% on the performance of the impact of the code.
4, composed of hardware chips, he uses local methods to execute Java bytecode, the execution engine is actually embedded in the chip.

Program counter (Counter Register)

　It is a small amount of memory space, which can be seen as a signal indicator of the bytecode executed by the yourselves thread.

Each JVM thread has its own PC register, each of which is isolated from each other and stored independently, a memory area called "Thread-private" memory.

At any one time, a JVM thread executes only one method of code. The method is called the current method of the thread.

If the method is a Java method, the PC register holds the address of the bytecode instruction that the JVM is executing.

If the method is native, the value of the PC register is undefined.

This memory area is the only area in the Java Virtual Machine specification that does not stipulate any outofmemoryerror conditions.

Java VM Stack (Java Virtual machine stack)

As with the PC registers, the Java Virtual machine stack is also thread-private. Each JVM thread has its own Java Virtual machine stack, which is created at the same time as the thread and whose life cycle is the same as the thread.

The virtual machine stack describes the memory model that is executed by the Java method: Each time a method is executed, a stack frame is created to store the local variable table, the operand stack, the dynamic link, the method exit, and so on. Each method is called until the completion process corresponds to a stack frame in the virtual machine stack from the stack to the stack.

The JVM stack can be implemented as a fixed size, or it can be dynamically extended based on calculations.

If a fixed-size JVM stack design is used, then the JVM stack capacity of each thread should be selected independently when threads are created. The JVM implementation should provide the means to adjust the initial capacity of the JVM stack, and if you adopt a dynamically expanding and shrinking JVM stack, you should provide the means to adjust the maximum and minimum capacity.

Stackoverflowerror will be thrown if the thread requests a stack depth greater than the depth allowed by the virtual machine;

If the JVM stack can be dynamically scaled, but fails to request enough memory when trying to scale out, throw outofmemoryerror.

Local methods Stack (Native method Stacks)

The local method stack acts similarly to the virtual machine stack, which executes the Java method service for the virtual machine, which is the native method used by the virtual machine.

The virtual machine specification is not mandatory for the language used by methods in the local method stack, usage and data structures, and even some virtual machines (such as hotspot) directly merge the two.

This thing throws the same exception as the virtual machine stack above.

Java heap (Java heaps)

The largest piece of memory managed by a virtual machine, which is also shared by all threads , is created when the virtual machine is started, the meaning of which is to hold an object instance, where almost all object instances and arrays are allocated memory. The objects are managed automatically, which is commonly known as GC (Garbage Collector). That's it, there's a GC carrying it, don't worry about destroying the recycling thing.

The Java heap can be either fixed size or dynamically scaled as demand (-XMS and-XMX), and shrinks automatically when too much space is not required.

The memory used by the Java heap does not need to be guaranteed to be physically contiguous, as long as it is logically contiguous.

The JVM implementation should provide a means for programmers to adjust the initial capacity of the Java heap, and for a heap that can be dynamically scaled and shrunk, it should provide a means of adjusting its maximum and minimum capacity.

If there is no memory in the heap to complete the instance assignment and the heap cannot be expanded, OutOfMemoryError will be thrown.

Method area

The same as the heap is a memory area shared by each thread that stores data such as class information, constants, static variables, and code compiled by the instant compiler that are loaded by the virtual machine. Although this area is described by the virtual machine specification as a logical part of the heap, its name is non-heap and is used to make a difference with the heap.

The method area is created when the virtual machine is started.

The capacity of a method area can be a fixed size, or it can be scaled dynamically as the requirements of the program execute, and shrink automatically when too much space is not required.

The method area can be discontinuous in the actual memory space.

The Java Virtual machine implementation should provide a means for the programmer or end user to adjust the initial capacity of the method area, and for the dynamic expansion and contraction of the method area, it should provide the means to adjust its maximum and minimum capacity.

The OutOfMemoryError is thrown when the method area does not meet the memory allocation requirements.

Here is a small example to illustrate the relationship between heaps, stacks, and method areas.

1  Public class Test2 {2      Public Static void Main (string[] args) {3          Public New Test2 (); 4         // The JVM loads the Test2 class information into the method area, the new Test2 () instance is saved in the heap, and the  Test2 reference is saved in the stack area . 5     }6 }  

Run a constant pool (runtime Constant)

　It's part of the method area.　 . In addition to information such as the version of the class, fields, methods, interfaces, and so on, there is a constant pool (Constant pool Table) that holds the various literal and symbolic references generated during the compilation period. This section is stored in the run-time pool of the method area after the class is loaded.

Java virtual machines have strict specifications for each part of a class file (which naturally includes Chang), and each byte is used to store which data must conform to the requirements of the specification, so that it is recognized, loaded, and executed by the virtual machine. However, for running a constant pool, the Java Virtual Machine specification does not require any details, and the virtual machines implemented by different providers can implement this memory area as they want. However, in general, in addition to saving the symbolic references described in the class file, the translated direct references are also stored in the run-time-constant pool.

Another important feature of running a constant pool relative to a class file's const pool is dynamic, and the Java language does not require constants to be generated only at compile time, that is, the contents of the constant pool in the class file are not pre-placed to enter the method area to run the const pool, and new constants may be put into the pool during run time. , this feature is the Intern () method of the string class that is used by developers more.

Since the run-time-constant pool is part of the method area, it is naturally constrained by the memory of the method area, which throws a OutOfMemoryError exception when the constant pool is no longer able to request memory.

Direct Memory

Direct memory is not part of the data area when the virtual machine is running, nor is it a memory area defined in the Java VM specification, but this part of memory is also used frequently and may lead to outofmemoryerror exceptions.

In JDK1.4 NiO, Bytebuffer has a method of allocatedirect (int capacity), which is an I/O method based on channel (channels) and buffers (buffer). It can use the native library to directly allocate out-of-heap memory and then manipulate it through a Directbytebuffer object stored in the Java heap as a reference to that memory. This can significantly improve performance in some scenarios because it avoids copying data back and forth in the Java heap and native heap.

Obviously, the allocation of native direct memory is not limited by the size of the Java heap, but, since it is memory, it will certainly be subject to the size of the native total memory (including RAM and swap or paging files) and the processor addressing space. When the server administrator configures the virtual machine parameters, the parameters such as-xmx are usually set according to the actual memory, but the direct memory is often ignored, so that the sum of each memory area is greater than the physical memory limit (including physical and operating system-level limitations). This causes a OutOfMemoryError exception to occur when dynamic scaling occurs.

Acknowledgement

The younger brother learns the Java Virtual machine and did not read the book, mainly is to view the blog and the related document, specially here thanks the following predecessors ' wonderful blog.

1.http://www.cnblogs.com/cratical/archive/2012/08/21/2649985.html

2.http://hllvm.group.iteye.com/group/wiki/3053-jvm

Java Virtual machine memory allocation detailed