Summary of Java memory regions and constant pools

This article uses the most concise description, to summarize the Java memory region and constant pool related knowledge, if you want to learn more in-depth Java memory region and constant pool, please refer to “In Depth Java VIRTUAL Machine” or excellent online blog.

Runtime data area

The running data area contains the following areas:

  1. Method Area
  2. Java Heap
  3. Native Method Stack
  4. VM Stack
  5. Program Conter Register

The method area and heap are data areas shared by all threads, while the other three areas pick up thread-isolated data areas.

During the execution of Java programs, the Java virtual machine divides the memory it manages into several different areas, each with its own purpose and creation and destruction times.

The method area and heap are created depending on the virtual machine thread being started; Local method stacks, virtual machine stacks, and program counters are all created and destroyed depending on the start and end of the user thread.

Program counter

  1. This area is a small area of memory.
  2. Think of it as a line number indicator of bytecode.
  3. The basic work of branching, loping, jumping, exception handling, thread recovery, and so on is done based on the program counter, because the bytecode interpreter works by checking the value of the program counter for the next byte code command to execute.
  4. This zone is thread-independent and is referred to as “thread-private” memory.
  5. This area is the only one that does not specify any OOM (OutOfMemoryError) cases in the Java Virtual Machine specification.

Java virtual machine stack

  1. This zone is thread private.
  2. The Java virtual machine stack describes the memory model of Java methods.
  3. This area is called “stack memory”, and Java memory cannot be roughly divided into heap memory and stack memory, because the division of Java memory areas is much more complex than this.
  4. This field throws StackOverflowError and OOM (OutOfMemoryError) exceptions. A stack overflow exception is thrown when the thread requests a stack depth greater than the virtual machine allows. Because the VM stack can be dynamically expanded, an OOM exception will be raised if the VM stack cannot allocate sufficient memory.

Memory model for Java methods

As each Java method executes, a stack frame is created and stored on the stack. This stack frame stores information about local variables, operand stacks, dynamic connections, method exits, and so on. When the method ends the call, the stack frame goes off the stack.

Local variable scale

Local variable meter storage:

  1. Basic data types known at compile time (Boolean, CHAR, byte, short, long, flag, int, double).
  2. Object reference.
  3. ReturnAddress (the address that points to a bytecode instruction).

For the local variable scale, note:

  1. The memory space needed for the local variable table is allocated at compile time. When entering a method, how much local variable space the method needs to allocate in the stack frame is completely determined. The size of the local variable table cannot be changed during the method run.

Local method stack

  1. The Native method stack uses the Native method service, and the basic principle is very similar to the Java virtual machine stack.
  2. Sun HotSpot combines the local method stack with the Java virtual machine stack.
  3. The local method stack also throws StackOverflowErrot and OOM exceptions.

The Java heap

  1. The Java heap is the largest chunk of memory managed by the virtual machine. It is thread – shared and is created with the start of the virtual machine thread.
  2. The sole purpose of this region is to store objects. Almost all instance objects are allocated memory in this region. Why not all of them? The java.lang.Object Object of a class allocates memory in the method area.
  3. Almost all object instances and arrays are allocated memory on the heap.
  4. This area is the main area managed by the garbage collector, so it is also referred to as the GC heap.
  5. Java heap can be divided into new generation, old generation, and the new generation can be subdivided into Eden space, From Survivor space, and To Survivor space.
  6. Regions in heap memory are regions of memory that are physically discontinuous but logically contiguous.
  7. This region can be expandable or fixed, and is generally defined as expandable (controlled by -xmx and -xMS).
  8. An OOM exception is raised if there is no memory allocated to the instance in the heap and the memory area cannot be expanded.

Methods area

  1. The method area is an area shared by threads.
  2. The method area stores data such as class information loaded by the virtual machine, constants, static variables, and code compiled by the just-in-time compiler.
  3. The method area is referred to by many as the “permanent generation” because the HotSpot team chose to extend GC into the method area. However, there are plans to move away from persistent generation and towards Native Memory for the method area. In JDK1.7 HotSpot, a pool of string constants is removed from the persistent generation.
  4. Memory regions can be physically discontinuous, but logically continuous, consistent with heap memory.
  5. Method areas are also called “permanent generations” because they always store things that don’t change easily. HotSpot also chooses to extend GC generation collection to the method area, but it is also prone to running out of memory. You can choose not to implement garbage collection, but if you do, it mainly involves collecting constant pools and unloading classes.
  6. If this area cannot meet memory allocation requirements, an OOM exception is raised.

Non-runtime data area – direct memory

  1. Direct memory is not part of the runtime data area and is not included in the Java definition specification, but improper use can also cause OOM exceptions.
  2. The new NIO class in JDK 1.4 introduces a Channel and Buffer based I/O approach that uses Native libraries to allocate out-of-heap memory directly. It then operates via a DirectByteBuffer object stored in the Java heap as a reference to this memory.

Run-time constant pool? Static constant pool (class file constant pool)? String constant pool? What’s the difference? Here’s a look at three confusing concepts.

Constant pools in Java

Class file constant pool

Constant Pool table constant pool table constant pool table constant pool table Used to hold the various literals and Symbolic References generated by the compiler, this is what we call the class file constant pool. Literals are what we call constant concepts, such as text strings, constant values declared final, and so on. Reference is a set of symbols to describe the referenced target, symbols can be any form of literal, as long as can use without ambiguity positioning to the target can be (it and direct reference to differentiate the direct reference is generally to approach the local pointer, relative offset or a can handle to indirect positioning to the target). It generally includes the following three types of constants:

  • Fully qualified names of classes and interfaces
  • The name and descriptor of the field
  • The name and descriptor of the method

(For data structures of each constant type, see Chapter 6 of Understanding the Java Virtual Machine in Depth.)

  1. The class constant pool is what each class has at compile time, where symbolic references to constants are stored.

Run-time constant pool

  1. The runtime constant pool is part of the method area.
  2. In addition to the description information about the Class version, fields, methods, and interfaces, the Class file also contains the Constant Pool Table.
  3. The constant pool stores compile-time literal and symbolic references, which in JDK1.6 and earlier versions are stored in the runtime constant pool in the method area after the class is loaded.
  4. The run-time constant pool differs from a constant-like pool in that it is dynamic, meaning that constants are not necessarily generated at compile time. Constants can also be generated at run time, for example by calling the String.intern() method at run time, or new constants can be added to the run-time constant pool.
  5. Run-time constant pooling is the dumping of symbolic references from each class constant pool to the run-time constant pool after the class is loaded. That is, each class has a run-time constant pool. After the class is parsed, symbolic references are replaced with direct references, consistent with the reference values in the global constant pool.

String.intern () function:

Checks for strings in the String constant pool and returns a String reference from the pool; If it does not exist in the pool, it is added to the pool and its reference is returned. The main reason for this is to avoid constantly creating new string objects in the heap.

String constant pool

  1. The string constant pool has only one copy per VM, and holds references to string constants.
  2. String literal pool — String Pool, also known as String Literal Pool.
  3. The contents of the string pool are generated in the heap after the class is loaded, validated, and ready, and then the reference value of that string object instance is stored in the String pool.
  4. String pools hold reference values rather than specific instance objects, which are stored in a space allocated to the heap.

For string pool:

The string pool implemented in HotSpot VM is a StringTable class, which is a hash table that holds references to the resident string (often quoted) rather than the resident string instance itself. That is, if some string instance in the heap is referenced by this StringTable, it is given the status of “resident string.” This StringTable has only one copy per HotSpot VM instance, shared by all classes.

JDK versions and constant pool location changes

  1. Prior to JDK1.6, the runtime constant pool was in the method area; In JDK1.7, the runtime constant pool is in the heap; In JDK1.8, the runtime constant pool is in Metaspace, a relatively independent Metaspace between the method area and the heap area, not in the heap area.
  2. Problems caused by different versions because OOM: JDK1.6 version — Java. Lang. OutOfMemoryError: PermGen space. JDK1.7 version of Java. Lang. OutOfMemoryError: Java heap space; JDK1.8 version of Java. Lang. OutOfMemoryError: Metaspace;