Runtime memory area

There is a “high wall” between Java and c++ surrounded by dynamic memory allocation and garbage collection techniques. Those on the outside want to get in, but those on the inside want to get out. (Attached is the official document of virtual machine specification. If you are good at English, please refer to it.)

The Java virtual machine defines various runtime data areas that are used during program execution. Some of these data areas are created when the virtual machine is started and destroyed only when the virtual machine exits. Other data areas are separate for each thread. This thread private area is created and destroyed synchronously with the thread’s life and death.

During the execution of Java programs, the virtual machine divides the managed memory into the following data areas.

  • Program counter
  • The virtual machine stack
  • Local method stack
  • The Java heap
  • Methods area
  • Run-time constant pool
  • Direct memory

Each zone has a purpose, a time to create and a time to destroy.

Program counter

The program counter is small in memory and is used to record the line number of bytecode executed by the current thread. Each processor core executes instructions in one thread at any one time. In order for a thread to switch back to the correct execution position, each thread needs a program counter, also known as thread-private memory. When the native method is implemented.

The thread executes a Java method, and this counter records the address of the virtual machine bytecode instruction being executed. This counter is null when executed in native mode.

The virtual machine stack

The virtual machine is often said that Java programmers mouth stack, it is private to the thread of memory, each thread stack, a virtual machine, it describes the Java method performs memory model: each method at the same time of execution will create a stack frame is used to store the local variables of the method, the operand stack, the dynamic linking, export information such as the method. (More on the internal data of stack frames later)

Each method, when called, corresponds to the process of a stack frame being pushed in and out of the virtual machine. You’ve no doubt seen the stack information for throwing exceptions in Java as follows (reduced for space), where each line is a method and also represents a stack frame.

java.io.FileNotFoundException: File doesn't exist: hdfs://[my cluster]/ 
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2080)
at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:108)
at org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:114
at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:94)
at java.lang.Thread.run(Thread.java:745)
Copy the code

In the virtual machine specification, this area specifies two exceptions: a StackOverflowError is raised if the stack depth of a thread request is greater than the depth allowed by the virtual machine; An OutOfMemoryError is thrown when sufficient memory cannot be allocated while the virtual stack is dynamically expanding.

Local method stack

The native method stack serves the same purpose as the virtual machine stack, except that the native method stack serves the virtual machine to execute native methods. The virtual machine specification does not dictate method languages, methods, or data structures. The Sun HotSpot VIRTUAL machine combines the local method stack with the virtual machine method stack. (The Sun HotSpot VIRTUAL machine is the popular one)

The Java heap

The heap is the largest memory managed by the virtual machine, which is shared by all threads and created when the virtual machine is started. The only purpose of a heap is to hold object instances.

The heap is the primary area managed by the garbage collector, also known as the GC heap. From a GC point of view, the Java heap can be subdivided into new generation and old generation, since GC is now mostly generational. More detailed are Eden space, From Survivor space, To Survivor space, etc. From a memory allocation perspective, a thread-shared heap can be partitioned into multiple thread-private allocation buffers.

The Java Virtual Machine specification states that the Java heap can reside in a physically discontinuous memory space, and therefore can be implemented as either fixed size or extensible. It can be controlled by -xmx and -xms. OutOfMemoryError is raised when there is no memory in the heap to allocate for the instance, and it can no longer be extended.

Methods area

An area of memory shared by threads that holds information about classes that have been loaded by the virtual machine, constants, static variables, compiled code, etc. In the HotSpot virtual machine, GC generation collection extends to the method area and does not represent permanent generation. This area of memory reclamation is mainly for constant pool reclamation and class unloading. An OutOfMemoryError is raised when the method area cannot meet the memory allocation.

Run-time constant pool

The runtime constant pool is part of the method area. In addition to the Class version, field, method, interface, and other description information, the Class file contains a constant pool, which is used to store compiled literal and symbolic references.

This memory is dynamic, and new constants can be put in at run time, such as the string.intern () method. When called, returns strings from the pool if the runtime constant pool already contains strings equal to this string object (as determined by equals method). Otherwise, the String is added to the pool and a reference to the String is returned.

Direct memory

Direct memory is not part of the virtual machine run-time data area, nor is it defined in the Java Virtual Machine specification. But will also be used frequently, will also throw OOM. The NIO class, for example, can use the Native library to allocate out-of-heap memory directly, and then operate with a DirectByteBuffer object stored in the heap as a reference to that memory, avoiding copying data back and forth between the Java heap and direct memory.

This memory is not limited by the heap size. When configuring VM parameters, you can set parameters such as -xmx based on site requirements. However, direct memory is often ignored.