Java Runtime memory allocation (run-time data region)

Between Java and C + + there is a "high wall" of dynamic memory allocation and garbage collection technology, and people outside the walls want to go in, but the walls are coming out.

Reference << Deep Understanding Java Virtual Machine Second Edition >> Zhou Zhiming

Reference Links
Xms xmx permsize maxpermsize Difference

Java Parameters list -xmx and-XMS (set the size of the Java heap)-vmargs-xms128m-xmx512m-xx:permsize=64m-xx:maxpermsize=128m-vmargs The following is the parameters of the VM, so the following are actually the parameters of the JVM-xms128m JVM initially allocated heap memory-xmx512m JVM maximum allowable allocation of heap memory, on demand-xx:permsize=64m JVM initial allocation of non heap memory-xx: maxpermsize=128m JVM Maximum allowable allocation of non heap memory, on Demand Java runtime data area

Java virtual machines in the execution of Java programs will be the memory of its management divided into different data areas, areas have their own purposes, as well as the creation and destruction of time, some will start with the VM startup, some will rely on the start and end of the user's thread to build and destroy.

Program Counter

The program counter (Programs Counter Register) is the line number indicator of the bytecode that the current thread executes. The bytecode interpreter needs to use the value of this counter to read the next executed byte code instruction, various branch jumps, exception handling, and so on.

The multithreading of Java virtual Machines is implemented by the way that threads rotate and allocate time slices, so at any given moment, a processor executes only the instructions in one thread. Because it is possible to revert to the correct execution location after a thread switch, each thread needs a program counter, so this part of the counter's memory area is "thread-private" memory.

If the thread is executing a Java method, this counter records the address of the virtual machine byte-code directive, which is Undefined if the native method is being executed. In theory, there is no outofmemoryerror error condition in the native method. Java Virtual machine stack

The Java Virtual machine stack (Java Machine stack) describes the memory model that the Java method executes. belong to the thread-private, the lifecycle is the same as the thread, and each method executes creates a stack frame (stack frame). The stack frame is used to store information such as local variable table, operand stack, dynamic link, method exit, etc. The execution of each method corresponds to a stack frame in the Java Virtual machine stack into the stack of the process. It is noteworthy that during the operation of the method, the space required by the local variable table in the stack frame is not changed, and is determined at compile time.

We usually put Java memory simply into heap memory (HEAP) and stack (stack) memory, stack memory is what we call Java Virtual machine stack.

In the Java Virtual Machine specification, two exceptions are specified for this area, and if the thread requests a stack depth larger than the virtual machine lock allows, the StackOverflow exception is thrown, and the virtual machine stack size is generally dynamically scalable, but can also be set to a fixed size, if the dynamic expansion If the extension cannot be applied to enough memory, a Outofmemoryerro exception is thrown. Local Method Stack

Java Virtual machine stacks are used to perform Java method services for virtual machines. While the local method stack performs the native method service for the virtual machine, the other basic and Java Virtual machine stacks are similar, the language of the local method stack, the usage and data structure can be determined by the virtual machine developer. Virtual machine specification is not mandatory, hotspot virtual machine is the local method stack and virtual machine stack. Both the Java Virtual machine stack and the local method stack can throw stack exceptions and memory exceptions. Java Heap

The Java Heap (JAVAHEAP) is the largest chunk of memory managed by the JVM, and the Java heap is an area shared by all threads, created at the time the JVM was started, with almost all object instances and arrays allocating memory here, but although JIT compiler optimization and escape analysis techniques are ripe, The maturity of technology such as stack allocation, scalar substitution, and the allocation of objects on the heap becomes less "absolute".
The Java heap is also the main area of garbage collector management, and is often referred to as the GC heap (garbage collected Heap). From the point of view of memory recycling, Java heap can be divided into Cenozoic and old age, and then a little bit like Eden Space, from Survivor space, to survivor space, from the point of view of distribution, the Java heap may be divided into multiple thread private allocation buffer (thread Local allocation Bffer,tlab).
The Java heap can be discontinuous in physical space, as long as it is logically contiguous, according to the JVM specification. Extensions can be controlled through (-XMX and-XMS), and OutOfMemoryError exceptions are thrown when the heap cannot complete the extension. method Area (methods ared)

The method area, like the Java heap, is thread-shared and is used to store data such as class information, constants, static variables, and Just-in-time compiler-compiled code that have been loaded by the JVM.

Programmers who develop on hotspot virtual machines tend to refer to the method as a "permanent band (permanent Generation)", which is inherently not equivalent, simply because the GC generational collection extends to the method area, but the fact that the method area is implemented in a permanent generation is not very good, Because this is more easily out of memory overflow, after all, the method area is also a size limit, can be set through (-xx:maxpermsize=128m)

Java virtual machines have a loose limit on the method area, can also be discontinuous memory, and can choose dynamic expansion, and the method area of garbage collection is very low requirements, or even choose not to recycle, but relatively, for method area recovery is still necessary, The reclamation of the method area is mainly for the collection of the constant pool and the unload of the type, and when the method expands it cannot get enough space to throw the OutOfMemoryError error. run a constant-load pool (Runtime Constant)

is a run-time pool part of the method area? class file In addition to the tears of the version, fields, methods and interfaces, and other descriptive information, there is a constant pool, used to store the compilation of the generation of literal and symbolic references, this part of the class load in the method area of the runtime in the Run-time pool of time to store.

The Run-time pool is dynamic, and the Java language does not require constants to be generated at compile time, that is, the contents of a constant pool not preset into a class file to enter a run-time pool. Constants can also be placed in a constant pool during run time, and the most common feature is the S**tring Class intern () method * *. The run-time pool is also subject to outofmemoryerror exceptions. immediate memory (direct Memory)

Direct memory is not part of the Run-time data area, nor is the memory area defined in the Java Virtual Machine specification. After JDK1.4 introduced NiO (New Input/output) class, introduced a channel (Channel) and buffer (buffer) IO mode, it can use the native function library directly allocate heap of memory, 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 scenarios because of the overhead of avoiding copying data back and forth in the Java heap and the native heap.

Direct memory is not part of the Java heap, but part of the operating system is also affected by outofmemoryerror, so direct memory needs to be taken into account when setting memory parameters.