JVM runtime data area

JVM runtime data area

According to the JVM specification, THE JVM memory is divided into five parts: virtual machine stack, heap, method area, program counter, and local method stack.

The Runtime Data Area can be divided into two parts according to whether the thread shares the memory. The thread shares the Method Area and the Heap, and the thread shares the VM Stack. Native Method Stack and Program Counter Register.

See the following figure for details:

• Virtual machine stack (Thread private) Each thread has a private stack that is created as the thread is created. The stack holds what are called “stack frames”. Each method creates a stack frame as it executes, storing information about local variables (basic data types and object references), operand stacks, dynamic connections, method exits, and so on. Each method has a stack frame in the virtual machine stack from the time it is called to the time it is executed. Commonly referred to as the stack, generally refers to the virtual machine stack in the local variable table part. The memory required by the local variable table is allocated during compilation. The stack size can be fixed or dynamically expanded, and OutOfMemoryError occurs when the stack size is too large to apply for sufficient memory. A StackOverflowError is raised when the stack call depth is greater than the JVM allows. This is not a constant value.

  // Stack overflow test source code package com.paddx.test.memory; /** * Created by root on 2/28/17. */ public class StackErrorMock { private static int index = 1; public voidcall() {
          index++;
          call();
      }
  
      public static void main(String[] args) {
          StackErrorMock mock = new StackErrorMock();
          try {
              mock.call();
          } catch(Throwable e) {
              System.out.println("Stack deep: "+ index); e.printStackTrace(); }}}Copy the code

  Run three times, you can see that each stack depth is different, the output is as follows:

  

  

  

  Looking at the three resulting graphs, you can see that the Stack deep values are different each time. The reason for this is that we need to go deep into the SOURCE code of the JVM to explore, and we will not repeat it here. In addition to the above errors, there is another type of error in the virtual stack, which throws an OutOfMemoryError when no space is claimed. One small detail to note here is that a catch catches Throwable, not Exception, because StackOverflowError and OutOfMemoryError are not subclasses of Exception.

• The local method stack (thread private) is similar to the virtual machine stack and mainly serves the Native methods used by the virtual machine. StackOverflowError and OutOfMemoryError are also thrown.

• PC register (thread-private) PC register, also known as program counter. The JVM supports multiple threads running at the same time, each with its own program counter. If the JVM method is currently executing, this register holds the address of the currently executing instruction. If the native method is executed, the PC register is empty. This memory region is the only one in the virtual machine that does not specify any OutOfMemoryError cases.

• Heap (Thread Sharing) Heap memory is the part of the JVM that is shared by all threads and is created when the virtual machine is started. Closely related to program development, application system objects are stored in the Java heap. All objects and arrays are allocated on the heap. This space can be reclaimed through GC. For generational GC, the heap is also generational and is the main working area of the GC. OutOfMemoryError is thrown when no space is claimed. Here we simply simulate a heap overflow situation:

  package com.paddx.test.memory;
  import java.util.ArrayList;
  import java.util.List;
  /**
   * Created by root on 2/28/17.
   */
  public class HeapOomMock {
      public static void main(String[] args) {
          List<byte[]> list = new ArrayList<byte[]>();
          int i = 0;
          boolean flag = true;
          while(flag) { try { i++; list.add(new byte[1024 * 1024]); }catch(Throwable e) {e.printstackTrace (); flag =false;
                  System.out.println("Count = "+ i); // Record the number of runs}}}}Copy the code

  First configure the startup parameters of the runtime VIRTUAL machine:

  

  
  Then run the code and the output looks like this:
  
  

  

  
  Note that here we specify a heap size of 16M, so Count=13 is displayed here (this number is not fixed), and why it is 13 or any other number will depend on the GC log.

• Method area (thread shared) Method area is also shared by all threads. It is mainly used to store class information, constant pool, method data, method code, etc. The method area is logically part of the heap, but is often referred to as “non-heap” to distinguish it from the heap. This area of memory reclamation targets constant pool reclamation and type offloading. OutOfMemoryError is thrown when the method area cannot meet memory allocation requirements. In the HotSpot VIRTUAL machine, the method area is implemented with persistent generation, extending GC generation collection to the method area, but this is prone to memory overflow problems. In JDK1.7, the pool of string constants placed in the permanent generation has been moved to the heap. JDK1.8 undoes the permanent generation and introduces the meta space.

Attachments (stack, heap, method area interaction) :

Reference links: segmentfault.com/a/119000000… Blog.csdn.net/universe_an… www.cnblogs.com/mengchunche…