useconcmarksweepgc - java.lang.outofmemoryerror: metaspace

Java8 metaspace y uso del montón

Question

Tengo este código para generar clase dinámicamente y cargarlo.

import javassist.CannotCompileException;
import javassist.ClassPool;
public class PermGenLeak {
private static final String PACKAGE_NAME = "com.jigarjoshi.permgenleak.";
public static void main(String[] args) throws CannotCompileException, InterruptedException {
for (int i = 0; i < Integer.MAX_VALUE; i++) {
ClassPool pool = ClassPool.getDefault();
pool.makeClass(PACKAGE_NAME + i).toClass();
Thread.sleep(3);
}
}
}

Lancé esta clase contra Java 7 (jdk1.7.0_60) y, como se esperaba, llenó PermGenSpace y el montón no se utilizó _{La imagen muestra las horas extraordinarias de uso de Permgen y al final se finalizó la JVM.}

Ahora, el mismo código se ejecutó contra Java 8 (jdk1.8.0_40-ea) y, como se esperaba, siguió expandiendo la memoria nativa (Metaspace), pero sorprendentemente para 1 g de Metaspace consumió 3 g de Heap en OldGen (casi 3x de Metaspace se mantuvo con el tiempo)

_{La imagen muestra las horas extra de uso de Metaspace y el ejemplo de uso de la memoria del sistema.}

Este correo electrónico de Jon Masamitsu y este boleto de JEP dice

las estadísticas internas de String y Class y algunos datos misceláneos se han movido a Heap

¿Qué hace exactamente este aumento en el montón a medida que carga más clases en Metaspace?

Answer 1

¿Qué hace exactamente este aumento en el montón a medida que carga más clases en Metaspace?

Mi hipótesis es que esto es basura "común" que se crea con su ejemplo. Supongo que

• El código javaassist crea objetos de pila regulares. En su mayoría son "grandes" y eso hace que se asignen directamente al montón OldGen. O algo más causa eso.

  ( ACTUALIZACIÓN : mirando la respuesta de @apangin, ahora sospecho que comenzaron en el montón de YoungGen y fueron titulares ...)

• Cuando se llama a classLoader.defineClass bajo el capó, crea objetos en el metaspacio desde la matriz de bytes que contiene el archivo de clase.

• El uso de OldGen permanece ... porque aún nada ha activado un GC completo.

Si ajustara su ejemplo para que las clases estuvieran disponibles y luego forzara un GC completo, esperaría (espero) ver que el uso de OldHeap disminuya, lo que indica que se trata de basura "normal" en lugar de una fuga de almacenamiento.

Answer 2

Ejecute jmap -histo PID para ver qué objetos consumen el espacio de jmap -histo PID .
Cuando ejecuté tu ejemplo, vi el montón lleno de objetos auxiliares de Javassist:

 num #instances #bytes class name
----------------------------------------------
1: 592309 312739152 [Ljavassist.bytecode.ConstInfo;
2: 6515673 208501536 java.util.HashMap$Node
3: 2964403 169188824 [C
4: 1777622 102165184 [Ljava.lang.Object;
5: 4146200 99508800 javassist.bytecode.Utf8Info
6: 3553889 85293336 java.util.ArrayList
7: 2964371 71144904 java.lang.String
8: 593075 56944008 java.lang.Class
9: 592332 47388032 [Ljava.util.HashMap$Node;
10: 592309 37907776 javassist.bytecode.ClassFile
11: 592308 37907712 javassist.CtNewClass
12: 1185118 28555808 [B
13: 592342 28432416 java.util.HashMap
14: 1184624 28430976 javassist.bytecode.ClassInfo
15: 592309 28430832 [[Ljavassist.bytecode.ConstInfo;
16: 592322 23692880 javassist.bytecode.MethodInfo
17: 592315 23692600 javassist.bytecode.CodeAttribute
18: 592434 18957888 java.util.Hashtable$Entry
19: 592309 18953888 javassist.bytecode.ConstPool
20: 592308 18953856 java.lang.ref.WeakReference
21: 592318 14215632 javassist.bytecode.MethodrefInfo
22: 592318 14215632 javassist.bytecode.NameAndTypeInfo
23: 592315 14215560 javassist.bytecode.ExceptionTable
24: 592309 14215416 javassist.bytecode.LongVector
25: 592309 14215416 javassist.bytecode.SourceFileAttribute
26: 592507 9487584 [I
27: 8 6292528 [Ljava.util.Hashtable$Entry;
28: 212 18656 java.lang.reflect.Method
29: 407 13024 java.util.concurrent.ConcurrentHashMap$Node
30: 124 8928 java.lang.reflect.Field