This is the fifth day of my participation in Gwen Challenge
Methods area
1. An overview of the
- The method area is created as the virtual machine is created, and the memory is not necessarily physically contiguous, but logically contiguous.
- Although the method area is logically part of the heap, some simple implementations do not choose garbage collection or compression, and the method area is treated as a separate piece of space from the Java heap.
- Like the heap, it is shared by threads.
- You can set the size of the method area to determine how many classes the system can contain. If you define too many classes, you will report to OOM.
2. Set the method area memory size
- The method area memory size can be set without a fixed value, and the JVM can adjust it dynamically based on the needs of the application.
- JDK7 and previously used
-XX:PermSzie
To set the initial value, which defaults to 20.75 MB. use-XX:MaxPermSize
To set the maximum space, 32-bit default 64M, 64-bit default 82m. - JDK8 and later can only be used
-XX:MetaspaceSize
and-XX:MaxMetaspaceSize
Specifies the initial and maximum memory. -XX:MetaspaceSize
The default is 21m, which is the initial high water mark. Once this mark is exceeded, the Full GC will trigger and reset the high water mark based on how much space the GC has freed. If not enough space is freed, the high water mark will not be exceeded-XX:MaxMetaspaceSize
In the case of the appropriate increase in the value, if the free space is much, the appropriate decrease in the value, therefore, in the setting-XX:MetaspaceSize
Set the value as high as possible to avoid frequent GC.
3. Internal structure of method area
The main contents of the method area are: type information, runtime constant pool, static variables, just-in-time compiler compiled code cache, etc.
Type information (class, interface, enumeration, annotation) :
- A fully valid name, package name plus class name
- The valid name of the immediate parent class
- Type modifier
- An ordered list of the direct interfaces to the class
- Domain information (member variables), domain name, type, modifier
- Method information, method name, return type, type and number of parameters, modifiers, bytecode, exception table
Constant pool/runtime constant pool:
Constant pool (part of bytecode) :
In Java bytecode files, there is no support for storing data directly, but a constant pool is usually used to hold the data, and a reference to the constant pool is used in the bytecode file. A constant pool can be thought of as a table from which the virtual machine can find the class name, method name, parameter type, literal, and so on to execute.
Runtime constant pool (part of the method area) :
After classes and interfaces are loaded into the virtual machine, the corresponding runtime constant pool is created. The runtime constant pool contains a variety of different constants, including numeric literals determined by the compiler, as well as method and field references obtained after runtime parsing. This is no longer a symbolic address in the constant pool, but a real address.
4. Evolution of the method area
Change process:
-
JDK6 and before: there are permanent generations on which static variables are stored.
-
JDK7: permanent generation exists, but has been phased out, string constant pool, static variables stored in the heap.
-
JDK8: No persistent generation, type information, fields, methods, constants stored in local memory meta-space, but string constant pool and static variables are still in heap space.
Why did you cancel the permanent generation using meta-space substitution?
-
Memory allocation: In the permanent generation version, all memory is allocated by the JVM, and this size is difficult to control. If allocated too little memory and too many dynamically loaded classes, frequent GC and OOM will occur. If allocated too much memory, memory resources will be wasted. The biggest difference between a meta-space and a permanent generation is that the memory allocation is different. The memory of a meta-space is not stored in a VM but used by the local memory. Therefore, the size of a meta-space is limited only by the local memory.
-
Tuning: Tuning in the persistent generation is very difficult. The process of determining whether a class is still in use takes a long time during FullGC.
Why should the string constant pool be adjusted?
- The recovery of data in the persistent generation is very low, and it is only collected with the trigger of the Full GC, resulting in low recovery of StringTable, and the creation of a large number of strings during development, resulting in insufficient memory for the persistent generation. Put it in the heap and it can be recycled in time.