JVM Method Area Memory reclamation

Many people think that the method area (or the permanent generation in the Hotspot virtual machine) is not garbage collected, and the Java Virtual Machine specification does say that virtual machines can not be required to implement garbage collection in the method area, and that the "price/performance" of garbage collection in the method area is generally low: in the heap, especially in the Cenozoic, Regular applications do a garbage collection generally can reclaim 70%~95% space, and the garbage collection efficiency of the permanent generation is much lower than this.

The garbage collection of the permanent generation mainly recycles two parts: obsolete constants and useless classes.

First of all, there are two major types of constants in a constant pool in a method area: literal and symbolic references. Literals Compare constant concepts similar to those of the Java language hierarchy, such as text strings, constant values declared final, and so on. Symbolic references, however, fall into the concept of compilation principles, including the following three types of constants:

1. Fully qualified name of class and interface

2. Name and descriptor of the field

3. The name and descriptor of the method

Reclaiming obsolete constants is very similar to reclaiming objects in the Java heap. For example, if a string "ABC" has entered a constant pool in the case of a constant pool literal, the current system does not have any string object called "abc", in other words, there is no string object referencing the "ABC" constant in the constant pool. There is no other place to quote this literal, and if a memory recycle occurs at this time, and if necessary, the "ABC" Constant will be "please" out of the constant pool. The symbolic references to other classes (interfaces), methods, and fields in a constant pool are similar.

It is relatively straightforward to determine whether a constant is an "obsolete constant", and the condition to determine whether a class is a "useless class" is much more harsh. Classes need to meet the following 3 conditions to be considered "useless classes":

All instances of the class have been reclaimed, that is, no instances of the class exist in the Java heap.

The ClassLoader that loaded the class have been recycled.

The corresponding Java.lang.Class object of this class is not referenced anywhere and cannot be used to access the class's methods at any place.

Virtual machines can recycle the useless classes that meet the above 3 criteria, which is simply "yes", not the same as the object, and will inevitably be recycled if not used. Whether the class is recycled, the hotspot virtual machine provides control of the-XNOCLASSGC parameters, and can also use-verbose:class and-xx:+traceclassloading,-xx:+ Traceclassunloading view load and unload information for a class.

Scenarios that use bytecode frameworks such as reflection, dynamic proxies, cglib, and dynamic generation of custom classloader such as JSPs and OSGi require virtual machines to have class offload capabilities to ensure that the permanent generation does not overflow.

JVM Method Area Memory reclamation