Startup performance regression due to CGLIB class load attempts in Spring 6.1.x

[rahulsh1]

A considerable startup regression over 30+ seconds was found in the Spring refresh phase after the migration to Spring 6.1.16 from Spring 5.3.x with no other changes.

For every Configuration/Proxy bean discovered by Spring 6.x, three classpath lookups are triggered. Since these classes are not on the classpath, it causes a full classpath scan, ultimately resulting in a lookup failure (causing the delay).

One such example for the lookup for an application bean:

com.app.FooConfigBean$$SpringCGLIB$$0
com.app.FooConfigBean$$SpringCGLIB$$FastClass$$0
com.app.FooConfigBean$$SpringCGLIB$$FastClass$$1

Stack Trace for com.app.FooConfigBean$$SpringCGLIB$$0 lookup:

at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:534)
at java.base/java.lang.Class.forName(Class.java:513)
at org.springframework.cglib.core.ReflectUtils.loadClass(ReflectUtils.java:569)
at org.springframework.cglib.core.AbstractClassGenerator.generate(AbstractClassGenerator.java:351)
at org.springframework.cglib.proxy.Enhancer.generate(Enhancer.java:575)
at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData.lambda$new$1(AbstractClassGenerator.java:107)
at org.springframework.cglib.core.internal.LoadingCache.lambda$createEntry$1(LoadingCache.java:52)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at org.springframework.cglib.core.internal.LoadingCache.createEntry(LoadingCache.java:57)
at org.springframework.cglib.core.internal.LoadingCache.get(LoadingCache.java:34)
at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:130)
at org.springframework.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:317)
at org.springframework.cglib.proxy.Enhancer.createHelper(Enhancer.java:562)
at org.springframework.cglib.proxy.Enhancer.createClass(Enhancer.java:407)
at org.springframework.context.annotation.ConfigurationClassEnhancer.createClass(ConfigurationClassEnhancer.java:156)
at org.springframework.context.annotation.ConfigurationClassEnhancer.enhance(ConfigurationClassEnhancer.java:113)
at org.springframework.context.annotation.ConfigurationClassPostProcessor.enhanceConfigurationClasses(ConfigurationClassPostProcessor.java:534)
at org.springframework.context.annotation.ConfigurationClassPostProcessor.postProcessBeanFactory(ConfigurationClassPostProcessor.java:311)
at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(PostProcessorRegistrationDelegate.java:363)
at org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(PostProcessorRegistrationDelegate.java:153)
at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:789)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:607)

Stack Trace for com.app.FooConfigBean$$SpringCGLIB$$FastClass$$0 lookup

at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:534)
at java.base/java.lang.Class.forName(Class.java:513)
at org.springframework.cglib.core.ReflectUtils.loadClass(ReflectUtils.java:569)
at org.springframework.cglib.core.AbstractClassGenerator.generate(AbstractClassGenerator.java:351)
at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData.lambda$new$1(AbstractClassGenerator.java:107)
at org.springframework.cglib.core.internal.LoadingCache.lambda$createEntry$1(LoadingCache.java:52)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at org.springframework.cglib.core.internal.LoadingCache.createEntry(LoadingCache.java:57)
at org.springframework.cglib.core.internal.LoadingCache.get(LoadingCache.java:34)
at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:130)
at org.springframework.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:317)
at org.springframework.cglib.reflect.FastClass$Generator.create(FastClass.java:70)
at org.springframework.cglib.proxy.MethodProxy.helper(MethodProxy.java:148)
at org.springframework.cglib.proxy.MethodProxy.init(MethodProxy.java:89)
at org.springframework.cglib.proxy.MethodProxy.create(MethodProxy.java:63)
at com.app.FooConfigBean$$SpringCGLIB$$0.CGLIB$STATICHOOK1(<generated>)
at com.app.FooConfigBean$$SpringCGLIB$$0.<clinit>(<generated>)

Given this behavior has changed with Spring 6.x, is there a way to bypass these class lookups that will never be found on the current classpath?

This situation is reminiscent of the BeanInfo/Customizer lookups, which also caused a similar regression that could be disabled.

[jhoeller]

That regression is in all of Spring 6.x actually, introduced right in 6.0. These CGLIB class load attempts aim to find AOT-generated proxy classes, and we currently unconditionally look for them (expecting it to be a cheap enough operation). In practice, we only need to look for them in AOT-processed application, so we might attach this behavior to that runtime mode only.

Note that we might only be fixing this in Spring 6.2.6. The Spring 6.1.x line is approaching the end of its OSS support in late June, and any behavior that could cause regressions for other people is better off in 6.2.x only.

[jhoeller]

This turned out to be somewhat inconsistent between AOP proxies and configuration classes, so I'm using the opportunity to fully align this for 6.2.6, backporting it to 6.1.19 since it might also fix inconsistency issues in custom ClassLoader scenarios: We consistently perform a CGLIB class load attempt in case of spring.aot.enabled=true (or running in a native image) at runtime now, as long as the CGLIB cache is turned on as well (which it is not in case of a reloadable class). Otherwise, we generate the current class in the given ClassLoader directly.

[jhoeller]

@rahulsh1 this internal revision is available in the latest 6.2.6 and 6.1.19 snapshots now, avoiding those loadClass attempts completely in non-AOT scenarios like yours. Please give it a try at your earliest convenience!

[jhoeller]

@rahulsh1 out of curiosity, in which kind of deployment arrangement have you noticed such a dramatic performance regression through class-load attempts? Is there some special ClassLoader setup involved, or is this simply through the size of your deployment?