Java Memory Area

java Process memory = Java heap + Native memory
non-JVM-managed memoryNative Memory

From an operating system perspective, the JVM is not fundamentally different from other processes at run time. At the system level, they have the same scheduling mechanism, the same memory allocation method, and the same memory pattern.

In the JVM process space, memory space outside the Java Heap is called the JVM's native memories. Native memory does not have the corresponding parameters to control the size, its size depends on the maximum value of the operating system process (for a 32-bit system is 3~4g, the implementation of various systems is not the same), and the resulting Java bytecode size, the number of threads created, Maintains the state information size of Java objects (for GC) and some third-party packages, such as the native memory used by the JDBC driver. When more and more resources are allocated in native memory, occupy more and more native memory space and reach the native memory limit, the JVM throws an exception and causes the JVM process to exit abnormally. At this point Java Heap is often not up to the limit. Several reasons may cause the JVM to native memory leaks. For example, the JVM is running too many threads to be created and running at the same time. The JVM allocates resources for threads that may deplete the capacity of native memory.

the memory that the JVM manages. Program Counter

This is a small amount of memory space, which can be seen as the line number indicator of the bytecode that the current thread executes. Each thread needs to have a separate program counter, the counters between the threads do not affect each other, we call this type of memory is "thread-private" memory. If the thread is executing a Java method, this counter records the address of the executing virtual machine bytecode instruction, or null (Undefined) If the Natvie method is being executed. This memory area is the only area in the Java Virtual Machine specification that does not stipulate any outofmemoryerror conditions.

Java Virtual machine stack

Like the program counter, the Java Virtual machine stack is also thread-private, with the same life cycle 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 Operation Stack, the dynamic link, the method exit, and so on. Each method is called until the completion of the process, corresponding to a stack frame in the virtual machine stack from the stack to the process of the stack.

Java memory is often differentiated into heap memory (heap) and stack memory (stack), which is coarser, and the division of Java memory areas is actually far more complex. The "stack" refers to the current virtual machine stack, or the local variable table part of the virtual machine stack. The local variable table holds the various basic data types (Boolean, Byte, char, short, int, float, long, double), object reference (reference type) that are known at compile time, and is not equivalent to the object itself and is implemented according to different virtual machines. It may be a reference pointer to the start address of the object, or it may point to a handle representing the object or other location associated with the object, and the ReturnAddress type (the address of a bytecode directive).

Local Method Stack

The local method Stack (Native methods Stacks) is very similar to the virtual machine stack, except that the virtual machine stack executes the Java method service for the virtual machine, while the local method stack is the Native method service used by the virtual machine. The language, usage, and data structure of the methods used in the local method stack in the virtual machine specification are not mandatory, so the virtual machine can implement it freely. Even some virtual machines, such as sun hotspot virtual machines, combine the local method stack and the virtual machine stack directly. As with virtual machine stacks, the local method stack area throws Stackoverflowerror and OutOfMemoryError exceptions. In the Java Virtual Machine specification, there are two exceptions to this area: if the thread requests a stack depth greater than the virtual machine allows, the STACKOVERFLOWERROR exception will be thrown, and if the virtual machine stack can be dynamically extended (most of the current Java virtual machines can be dynamically extended, However, a fixed-length virtual machine stack is also allowed in the Java Virtual Machine specification, which throws a OutOfMemoryError exception when the extension fails to request enough memory.

Java Heap

For most applications, the Java heap (Java heap) is the largest piece of memory managed by a Java virtual machine. The Java heap is a piece of memory that is shared by all threads and created when the virtual machine is started. In this

The only purpose of the storage area is to hold object instances where almost all of the object instances are allocated memory.

According to the Java Virtual Machine specification, the Java heap can be in a physically discontinuous memory space, as long as it is logically contiguous, just like our disk space. When implemented, it can be implemented as a fixed

Size, can also be extensible, but the current mainstream virtual machines are implemented in a scalable way (via-XMX and-xms control). If there is no memory in the heap to complete the instance assignment, and the heap can no longer be expanded

, a OutOfMemoryError exception will be thrown.

Method Area

The method area, like the Java heap, is an area of memory shared by each thread that stores data such as class information, constants, static variables, and code compiled by the immediate compiler that have been loaded by the virtual machine. Although the Java Virtual Machine specification describes the method area as a logical part of the heap, it has an alias called Non-heap (Not a heap), which should be distinguished from the Java heap.

For developers who are accustomed to developing and deploying programs on a hotspot virtual machine, many people are willing to call the method area "permanent generation" (Permanent Generation), which is not inherently equivalent. Just because the design team of the hotspot virtual machine chooses to extend the GC collection to the method area, or use a permanent generation to implement the method area. For other virtual machines (such as Bea JRockit, IBM J9, etc.) there is no concept of a permanent generation.

From JDK7 the permanent generation of the removal work, stored in the permanent generation part of the data has been transferred to the heap or native Memory. But the permanent generation still exists in JDK7, and is not completely removed: the symbolic Reference (Symbols) is transferred to the Native Memory; the literal (interned strings) is transferred to the heap; static variable of Class (class Statics) Transferred to the heap.

this time JDK8 modified the JVM and removed the PermGen memory, so the parameters-xx:permsize and-xx:maxpermsize of the permanent generation were removed, In turn, there is a metaspace, in fact, the two functions are similar, are used to load some kind of information. However, the PermGen is in the JVM memory, and the new metaspace is directly in navite memory, so because Permanent generation By default is very small, the case is not going to happen in theory, because metaspace default size as long as the machine memory is not exceeded, then there is no limit. However , it is possible to limit its size by using the parameter -xx:maxmetaspacesize=2m, which can be reported as a memory overflow over this size.

run a constant-rate pool

the runtime Constant pool is 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. Another important feature of running a constant pool with respect to the class file constants pool is its dynamic nature, and the Java language does not require constants to be generated only at compile time. That is, the content of the constant pool in the class file is not pre-placed in order to enter the method area to run the frequent pool, the runtime may also put new constants into the pool, this feature is used by developers more than the String class intern () method. 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 .

Chang is different in Java6, JAVA7/8, and if you want to monitor memory, you can use the JVISUALVM tool.

before Java7, a constant pool was placed in a permanent generation (PermGen), because PermGen is small by default, so it is easy to permgen memory overflow If the Intern method is used during run time, so Java7 is not recommended for this method before. You can use Xx:maxpermsize=128m This parameter to increase the size of the permanent generation.

moving the symbolic reference and literal of the constant pool from java7 to the heap means that you are no longer confined to fixed memory, and it prepares Java8 to completely remove PermGen. all character objects will be in the heap just like other normal objects. You canadjust the constant pool size by-xx:stringtablesize=1009 This parameter , as it moves into the heap , if a string in the string pool is not referenced by any instance, it will be recycled by GC.

in addition to string constant pools, there are actually integer constant pools, floating-point constant pools, and so on, but all the same, except that constant pools of numeric types cannot add constants manually, and the constants in a constant pool of program initiation are determined, such as constant ranges in an integer constant pool: -128~ 127, only the number of this range can be used in a constant pool.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Java Memory Area