RFR: 8350938: ResourceParsingClassHierarchyResolver inflates all Utf8 CP entries

Johannes Döbler duke at openjdk.org
Sat Nov 22 11:02:50 UTC 2025


On Fri, 21 Nov 2025 16:54:48 GMT, Trevor Bond <duke at openjdk.org> wrote:

> Enhance `ResourceParsingClassHierarchyResolver.getClassInfo` to use `ClassReaderImpl` to improve performance. Previously this method inflated and stored all UTF-8 entries in the constant pool and later accessed the array of strings to try finding the name of the superclass. `ClassReaderImpl` instead stores constant pool offsets and later lazily reads/inflates UTF8 entries as needed.
> 
> I’ve ran all tier 1 tests and tests within `test/jdk/jdk/classfile` on the latest version of this change, and they all pass.
> 
> I ran some informal performance testing to see if these changes led to any improvement. I created a .class file with several thousand unique strings in a String array to deliberately enlarge the number of UTF-8 entries in the constant pool. I then benchmarked the performance of running a process nearly identical to `ClassHierarchyInfoTest.testClassLoaderParsingResolver` on this custom class over 200 runs using JMH. The results are as follows.
> 
> | Version | Avg Time (ns/op) | Δ vs Before |
> |--------|------------------:|-------------|
> | **Before** | 1,483,671.539 ± 3,477.744 | — |
> | **After** | 1,380,064.517 ± 3,482.434 | ≈ 7.0% faster |

The new version would always read all classfile bytes, the old one in chunks of 8192 bytes, both stop parsing at this_class position (with or without inflating constant pool entries). 
Maybe the benchmark would not show much difference for typical classfiles (not having thousands of strings). 
But in my eyes removing the logic to parse the constant pool and instead reuse ClassReader is a good thing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28458#issuecomment-3566528520


More information about the core-libs-dev mailing list