Yesterday, I spent a lot of time refining the introduction to some of the methods sections of the JVM on JavaGuide.

Mention a mouth, in order to improve the method area of this part of the content of the introduction, I have read a lot of documents, but also specially to pick up the “In-depth understanding of Java virtual Machine (3rd edition)” errata issues, simply see the head pain…

To be honest, there are too many details to make much sense if you dig deep.

This is a common question to ask in Java interviews (usually when the interviewer asks you about the JVM runtime memory), but it’s not always asked in detail.

In this article, I will guide you through 6 common knowledge points/interview questions from the perspective of the interview area:

  1. What is a method area
  2. How does the method region relate to permanent generations and meta-spaces?
  3. What are the common parameters of the method area?
  4. Why replace PermGen with MetaSpace?
  5. What is a runtime constant pool?
  6. What does a string constant pool do?
  7. Why move the string constant pool to the heap in JDK 1.7?

Here is the text.

What is a method area?

A method area is a logical area of the JVM runtime data area and is an area of memory shared by individual threads.

The Java Virtual Machine Specification only defines the concept of a method area and what it does, and it’s up to the virtual machine to figure out how to implement it. That is, the method area implementation is different on different virtual machine implementations.

When a virtual machine wants to use a Class, it needs to read and parse the Class file for relevant information and store the information in the method area. The method area stores data such as class information, field information, method information, constants, static variables, and code cache compiled by the just-in-time compiler that has been loaded by the virtual machine.

How does the method region relate to permanent generations and meta-spaces?

The relationship between the method area and the permanent generation and meta-space is similar to the relationship between interfaces and classes in Java, where the class implements the interface and the class can be regarded as the permanent generation and meta-space, which means that the permanent generation and meta-space are the two implementations of the method area in the HotSpot VIRTUAL Machine to virtual machine specification.

Also, the persistent generation was the method area implementation prior to JDK 1.8, which became the meta-space.

What are the common parameters of the method area?

Before the permanent generation was completely removed in JDK 1.8, the following parameters were used to adjust the method area size.

-XX:PermSize=N // The method area (permanent generation) initial size
-XX:MaxPermSize=N / / method area (permanent) maximum size, more than this value will throw an OutOfMemoryError: Java. Lang. OutOfMemoryError: PermGen
Copy the code

Garbage collection is relatively rare in this area, but data is not “permanent” once it enters the method area.

In JDK 1.8, the method area (HotSpot’s permanent generation) was completely removed (already in JDK1.7) in favor of the meta space, which uses direct memory. Here are some common parameters:

-XX:MetaspaceSize=N // Set the initial (and minimum) size of Metaspace
-XX:MaxMetaspaceSize=N // Set the maximum Metaspace size
Copy the code

A big difference from the permanent generation is that, if the size is not specified, the virtual machine will use up all available system memory as more classes are created.

Why replace PermGen with MetaSpace?

The image below is from Understanding the Java Virtual Machine, 3rd edition 2.2.5

1. The entire permanent generation has a fixed size cap set by the JVM itself and cannot be adjusted, whereas the metasystems use direct memory and are limited by the native available memory. Although the metasystems may still run out, they are less likely to run out than before.

Get the following error: when dimension overflow Java. Lang. OutOfMemoryError: MetaSpace

You can set the maximum meta-space size using the -xx: MaxMetaspaceSize flag. The default value is Unlimited, which means it is limited only by system memory. -xx: MetaspaceSize Resize flag Defines the initial size of the metspace. If this flag is not specified, Metaspace will dynamically resize according to the application requirements at run time.

MaxPermSize (MaxPermSize) : MaxPermSize (MaxPermSize) : MaxPermSize (MaxPermSize) : MaxPermSize (MaxPermSize) : MaxPermSize

3. In JDK8, JRockit never had such a thing as a permanent generation when merging HotSpot and JRockit code. There is no need to set up such a permanent generation after merging.

What is a runtime constant pool?

In addition to the description information of the Class version, fields, methods, interfaces, etc., the Class file also contains the Constant Pool Table for storing various literals and Symbolic references generated at compile time. The constant pool table is stored in the runtime constant pool in the method area after the class is loaded.

A literal is a representation of a fixed value in source code, that is, a literal tells us what its value means. Literals include integer, floating point, and string literals, and symbol references include class symbol references, field symbol references, method symbol references, and interface method symbol references.

The runtime constant pool functions like a symbol table in a traditional programming language, although it contains a wider range of data than a typical symbol table.

Since the runtime constant pool is part of the method area and is naturally limited by the method area memory, OutOfMemoryError is thrown when the constant pool can no longer claim memory.

JDK1.7 and later JVMS have moved the runtime constant pool out of the method area, creating an area in the Java Heap to house the runtime constant pool.

🐛 fix (see: issue747, Reference) :

  1. Prior to JDK1.7, the runtime constant pool contained the string constant pool and static variables in the method area, where the HotSpot virtual machine implemented the method area as a permanent generation.
  2. The JDK1.7 string constant pool and static variables are taken from the method area to the heap. There is no mention of the runtime constant pool, which means that the string constant pool is taken to the heap separately, and what is left of the runtime constant pool remains in the method area, which is the permanent generation in HotSpot.
  3. In JDK1.8 HotSpot, the Metaspace is removed, so the string constant pool and static variables are still in the heap. The runtime constant pool is still in the method area, but the method area implementation is changed from the permanent generation to the Metaspace area.

What does a string constant pool do?

The String constant pool is an area that the JVM has created specifically for strings (the String class) to improve performance and reduce memory consumption. The main purpose is to avoid repeated String creation.

String aa = "ab"; // Put it in the constant pool
String bb = "ab"; // Search from the constant pool
System.out.println(aa==bb);// true
Copy the code

Runtime constant pool logic prior to JDK1.7 contains string constant pools stored in the method area. In JDK1.7, the string constant pool was taken from the method area to the heap.

The string here is actually the string literal we mentioned earlier. When declaring a string literal, the reference is returned directly if the string literal can be found in the string constant pool. If not, an object for the string literal is created in the constant pool and a reference to it is returned.

Related question: Are objects or references stored in the JVM constant pool? – RednaxelaFX – Zhihu

Why move the string constant pool to the heap in JDK 1.7?

This is mainly because the GC collection efficiency of the permanent generation (method area implementation) is so low that GC is only performed during Full GC. Java programs typically have a large number of created strings waiting to be recycled. Putting the string constant pool in the heap makes it more efficient and timely to recycle string memory.

conclusion

An image shows you the changes in the JDK1.6 to JDK1.8 method area.