Performance regression for custom autowireBean calls with many properties [SPR-11875]

[spring-projects-issues]

Trask Stalnaker opened SPR-11875 and commented

Autowiring in our application became a large bottleneck after updating to Spring 3.2.

Please see benchmark of autowiring an object with 100 setters at https://github.com/trask/spring-autowire-benchmark

This used to take 2 microseconds in spring 3.1.4, but now takes 400 microseconds in spring 3.2.0+.

The regression appears to be caused by the fix for #13596, which disables caching of property descriptors in order to fix a memory leak.

What do you think of using org.springframework.util.ConcurrentReferenceHashMap for the property descriptor cache in order to keep the benefit of caching, while still addressing the memory leak reported in #13596?

---

Affects: 3.2 GA, 4.0.5

Issue Links:

• org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireBean() causes ClassLoader leak [SPR-8956] #13596 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireBean() causes ClassLoader leak
• Memory leak when using annotation based auto-wiring in child context [SPR-11520] #16145 Memory leak when using annotation based auto-wiring in child context
• Optimize performance of autowiring for Groovy/Grails [SPR-11864] #16483 Optimize performance of autowiring for Groovy/Grails
• ReflectionUtils slow down application startup on WebSphere [SPR-11882] #16501 ReflectionUtils slow down application startup on WebSphere
• Remove synchronization around filteredPropertyDescriptorsCache in case of non-existing entry [SPR-12106] #16722 Remove synchronization around filteredPropertyDescriptorsCache in case of non-existing entry

Referenced from: commits f4062bc, c32d559, 974bd43

Backported to: 3.2.10

0 votes, 8 watchers

[spring-projects-issues]

Trask Stalnaker commented

I submitted pull request #570 for this. Please let me know if you'd like any changes to it. Thanks.

#570

[spring-projects-issues]

Juergen Hoeller commented

I eventually resolved this in a different way: We keep using a strong filteredPropertyDescriptorsCache but initialize the allowCaching field with a CacheUtils.isCacheSafe check, along the lines of #16145. This should also be applicable to #13596 where the problem only really came in through generated classes from short-lived child ClassLoaders... and it should re-enable caching for scenarios with regular classes like yours.

Juergen

[spring-projects-issues]

Trask Stalnaker commented

Hi Juergen, this fixes the benchmark I provided, but unfortunately in our app many of the classes we autowire are groovy entities and so isCacheSafe() returns false since they are loaded by a (long-lived) GroovyClassLoader. Is there any chance to handle this scenario as well? Thanks.

[spring-projects-issues]

Craig commented

I think Trask Stalnaker is right - this issue still impacts Groovy (particularly Grails).
In AbstractAutowireCapableBeanFactory:

bd.allowCaching = ClassUtils.isCacheSafe(beanClass, getBeanClassLoader());

When beanClass is a Groovy class, beanClass.getClassLoader() will always be a decedent of getBeanClassLoader(). Since ClassUtils.isCacheSafe would only return true if beanClass.getClassLoader() is a parent of getBeanClassLoader(), no Groovy classes will ever be cached.

Juergen Hoeller can you please re-open this issue and perhaps a better solution can be found?

[spring-projects-issues]

Lari Hotari commented

This issue is related to #16483 . That issue references a solution that is used in Grails for optimizing autowire-by-name performance. There are some draw-backs in that solution, but that has suited Grails.

[spring-projects-issues]

Juergen Hoeller commented

I'll leave this issue marked as resolved. Let's rather handle the Groovy case in a dedicated follow-up issue, along the lines of Lari's reference.

Juergen