Jvm runtime data area




  • Method area: Method area stores data such as class information loaded by the VIRTUAL machine, constants, static variables, and code compiled by the immediate compiler. Is part of the JVM specification, is not an actual implementation, and is not the same in actual implementation (HotSpot has changed before 1.7 and after 1.7). OutOfMemoryError is thrown when the method area cannot meet memory allocation requirements.
  • Java heap: The Java heap is used to hold the contents of object instances and arrays. Is the primary area managed by the garbage collector. It can be subdivided into: New generation and old age; The new generation can be divided into Eden, from Survivor, to Survivor. OutOfMemoryError is thrown if there is no memory in the heap to complete the instance allocation and the heap can no longer be extended.
  • Java Virtual Machine stack: Each Java virtual machine thread has its own private Java virtual machine stack, which is created at the same time as the thread and is used to store stack frames. Java virtual machine stack is the memory model of Java method execution. Each method from invocation to completion of execution corresponds to the process of a stack frame in the virtual machine stack and out of the stack. Stack frames store information about local variables, operand stacks, dynamic links, method exits, etc. They are created as a method is called and destroyed as a method ends. In the Java Virtual Machine specification, two exceptions are specified for this area: a StackOverflowError is thrown if the stack depth of a thread request is greater than the depth allowed by the virtual machine; If the virtual stack can scale dynamically (and most Java virtual machines currently do, although the Java Virtual Machine specification also allows fixed-length virtual stacks), an OutOfMemoryError will be thrown when sufficient memory cannot be allocated while scaling.
  • Native method stack: The Native method stack is very similar to the virtual machine stack, except that the virtual machine stack serves Java methods, while the Native method stack serves Native methods. The HotSpot VIRTUAL machine directly blends the local method stack with the virtual machine stack. Like the virtual stack, the local method stack area throws StackOverflowError and OutOfMemoryError exceptions.
  • Program counter: The Java virtual machine can support multiple threads running at the same time. Each Java virtual machine thread has its own program counter (PC register). At any one time, a Java virtual machine thread will execute only one method of code. The program counter then records the address of the Java bytecode executed by the current thread. When the Native method is executed, the program counter is empty. The program counter is the only area in the JVM specification that does not specify an OOM (OutOfMemory) result.
  • In addition to the JVM’s memory regions mentioned above, there are also direct memory regions, which are not part of the JVM’s managed memory region, but are outside of it. This area is also used in Java development, and may cause memory overflow. If you use this area, you must pay attention to memory reclamation. If you are familiar with NIO, you probably know that NIO can use Native Methods to use direct memory areas. ex: DirectByteBuffer


From persistent generation to metaspace





  • The persistent generation is physically on contiguous memory of the heap, but metaspace no longer occupies the MEMORY of the JVM, but directly occupies local memory
  • Persistent generation is determined at application startup and is difficult to tune; Metaspace directly occupies local memory. In theory, as long as the local memory is large enough, it can be used indefinitely, but metaspace can also be set to the maximum memory usage.
  • Each class loader has a dedicated storage space in Metaspace, and if the GC finds that a class loader is no longer alive, it reclaims the associated space entirely and returns it to the operating system.


  • String constants are stored in persistent generations, which are prone to performance problems and memory overflow.
  • It is difficult to determine the size of information about classes and methods, so it is difficult to specify the size of permanent generation. If the size is too small, it is easy to overflow the permanent generation, while if the size is too large, it is easy to overflow the old generation.
  • Persistent generation introduces unnecessary complexity to the GC and is inefficient for collection.
  • Some improvements that were previously limited to persistent generation may be possible in the future. For example, Oracle may combine HotSpot with JRockit.