On Fri, 21 Nov 2025 16:54:48 GMT, Trevor Bond <[email protected]> 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
