During an OOME building a large project i find ~1GB is allocated for org.eclipse.jdt.internal.compiler.ClassFile. That seems unnecessary for several reasons:
First observation was that different Classfile instances had the exact same amount of retained memory:
Also JFR reports 2 ~ GB overhead due to duplicate Arrays used in ClassFile and its members:
Focusing on CharArrayCache one sees the duplicate arrays are mostly filled with 0 bytes and have the initial size of the ContantPools (defined in ConstantPool.UTF8_INITIAL_SIZE / STRING_INITIAL_SIZE ...):
Focusing on ClassFile.header or ClassFile.bytes it is visible that most of those arrays are duplicates - i did not find an explanation for that yet.
Please note that the underlying Problem for OOME seems to be a leak in the current hibernate annotation processor and this ticket is only observation where memory could be reduced in JDT.
During an OOME building a large project i find ~1GB is allocated for org.eclipse.jdt.internal.compiler.ClassFile. That seems unnecessary for several reasons:
First observation was that different Classfile instances had the exact same amount of retained memory:
Also JFR reports 2 ~ GB overhead due to duplicate Arrays used in ClassFile and its members:
Focusing on CharArrayCache one sees the duplicate arrays are mostly filled with 0 bytes and have the initial size of the ContantPools (defined in ConstantPool.UTF8_INITIAL_SIZE / STRING_INITIAL_SIZE ...):
Focusing on ClassFile.header or ClassFile.bytes it is visible that most of those arrays are duplicates - i did not find an explanation for that yet.