Performance regression in BuiltinClassLoader?
Eirik Bjørsnøs
eirbjo at gmail.com
Mon Jan 18 19:24:50 UTC 2021
For good measure, I did a JFR recording which revealed that
ExplodedModuleReader was doing file stat in 263 of 277 native method
samples.
Which lie explains all this, since the 15 I used was not shipped with
exploded jmods..
How do I build OpenJDK with packaged modules?
Cheers,
Eirik.
On Mon, Jan 18, 2021 at 7:59 PM Eirik Bjørsnøs <eirbjo at gmail.com> wrote:
>
> I also measured the actual startup time of Spring Petclinic to assess
> real-life impact. Although there is some variance from run to run, it does
> seem to regress:
>
> 15: Typical startup time 7500 - 7800 ms
> 17: Typical startup time: 8100 - 8700 ms
>
> Eirik.
>
> On Mon, Jan 18, 2021 at 7:34 PM Eirik Bjørsnøs <eirbjo at gmail.com> wrote:
>
>>
>> Hello,
>>
>> I've been looking into ZipFile again with the aim to speed up typical
>> enterprise classloading / resource lookups.
>>
>> To test the performance impact of my changes, I made a benchmark which
>> creates an EnterpriseClassLoader (subclass of URLClassLoader) with the jar
>> files in Spring Petclinic (89 jars with ~30k entries total).
>>
>> (This is intentionally implemented using a plain main method with no JMH
>> or warmup since I want to measure a representative cold application startup)
>>
>> The benchmark measures the time needed to call getResource 30K times,
>> once for each entry name.
>>
>> Using 15.0.1, this completes in ~1700 ms
>> Using 17 master, it completes in 12851 ms
>>
>> If I run the benchmark from the classpath instead of as a module, the
>> result is even worse:
>>
>> 15: 1724 ms
>> 17: 21885 ms
>>
>> If also measure GC collections and times, and get the following:
>>
>> 15:
>> Collections: 4
>> Collection time: 12 ms
>>
>> 17:
>> Collections: 24
>> Collection time: 44 ms
>>
>> (However, a JHM with -prof gc indicates that both 17 and 15 allocate
>> ~5.6Kb/getResource after warmup, so not convinced this needs to be
>> allocation related)
>>
>> The EnterpriseClassLoader is a bit clever in that it can perform lookups
>> using different strategies: Regular parent-first, self-only, or use the
>> bootstrap / platform system classloaders directly.
>>
>> Here are the results on 17 using each strategy (benchmark on class path):
>>
>> PARENT_DELEGATION: 23111 ms
>> SELF_ONLY: 428 ms
>> BOOTSTRAP: 8131 ms
>> PLATFORM: 15149 ms
>> SYSTEM: 20628 ms
>>
>> Here are the same results on 15:
>>
>> PARENT_DELEGATION: 1691 ms
>> SELF_ONLY: 393 ms
>> BOOTSTRAP: 579 ms
>> PLATFORM: 908 ms
>> SYSTEM: 1368 ms
>>
>> Note that the delegation chain is Enterprise -> System -> Platform ->
>> Bootstrap.
>>
>> Interesting to note that URLClassLoader itself does not seem to regress
>> much when only looking up its own resources, while delegating up the chain
>> does.
>>
>> Has there been any significant work in class loading / resource lookup
>> since 15.0.1 that could help explain this regression?
>>
>> Eirik.
>>
>>
>>
More information about the core-libs-dev
mailing list