BCEL-186. This enhancement is to provide an option to cache ConstantUtf8 instances that have the same value.
Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass instances
We use BCEL library to inspect Java class. Thank you for the great library.
When our tool checks classes in ~200 jar files, it creates more than 2 million BCEL ConstantUtf8 instances. I suspect many of them share the same values such as "java.lang.String".
Without cache, my tool created 2,6 million ConstantUtf8 instances (before failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files.
With the cache, my tool created just 0.6 million ConstantUtf8 instances. It didn't throw the OutOfMemoryError.
Old commit that made ConstantUtf8.getInstance https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383&r2=1481382&pathrev=1481383
The ConstantUtf8.getInstance has been unused in BCEL since
- Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 200 JAR files as its input class path in ClassDumper.createClassRepository(source code URL)
- reads JavaClasses one by one in ClassDumper.listClassesInJar (source code URL) through the ClassPathRepository.
Stacktrace from the ClassDumper.listClassesInJar to BCEL's ConstantUtf8.getInstance would look like this:
- Use the JavaClass instances to check if any symbol references (entries in constant pool Java Virtual Machine Specification 4.4. The Constant Pool: CONSTANT_Class, CONSTANT_Fieldref, CONSTANT_Methodref, and CONSTANT_InterfaceMethodref) has invalid referent in the class path.