Revisit class cache in CachedIntrospectionResults [SPR-11867]

[spring-projects-issues]

Lari Hotari opened SPR-11867 and commented

I'm doing performance tuning with Grails 2.4.1.BUILD-SNAPSHOT which uses Spring 4.0.5 .

The main principle for performance tuning in Grails is to minimize all blocking. I rely on the profiler information about what's causing the most blocking.

After eliminating the blocking problem in AbstractApplicationContext.assert (reported as #16482 , comments in SPR-10307) by simply overriding assertBeanFactoryActive with a no-op method in a subclass of GenericApplicationContext, the top-most blocker is now org.springframework.beans.CachedIntrospectionResults.forClass(Class) method.

---

Affects: 3.2.9, 4.0.5

Issue Links:

• Simplify CachedIntrospectionResults caching arrangements [SPR-10028] #14662 Simplify CachedIntrospectionResults caching arrangements
• Improve the performance of BeanInfo lookups in CachedIntrospectionResults [SPR-9014] #13653 Improve the performance of BeanInfo lookups in CachedIntrospectionResults
• Provide lock free access to BeanFactory methods by calling BF methods on the AbstractApplicationContext instance directly [SPR-11863] #16482 Provide lock free access to BeanFactory methods by calling BF methods on the AbstractApplicationContext instance directly
• Use putIfAbsent in CachedIntrospectionResults.addTypeDescriptor [SPR-12102] #16718 Use putIfAbsent in CachedIntrospectionResults.addTypeDescriptor

Referenced from: commits f27b949, 8307447, fab67b0

Backported to: 3.2.10

[spring-projects-issues]

Lari Hotari commented

In my performance test , this is a very minor source of blocking compared to #16482 (the relative amount of blocking this causes is not even comparable). YMMV :)

[spring-projects-issues]

Stéphane Nicoll commented

Do you know what this does and do you really need this? I know this may not fix the actual performance issue you found but you can disable it (see #13653)

[spring-projects-issues]

Juergen Hoeller commented

CachedIntrospectionResults, GenericTypeAwarePropertyDescriptor and BeanUtils consistently avoid synchronization now. This is a little bit risky since we're using our ConcurrentReferenceHashMap in those very hotspot places now, which is why this is not really a candidate for backporting. Let's rather use the 4.1 release candidate phase to have this tested in many scenarios.

As a side effect, through ConcurrentReferenceHashMap, we're using soft references for non-cache-safe bean classes now. Previously, we used weak references even for the CachedIntrospectionResults reference which led to rather aggressive garbage collection effects. We should consider changing that part to soft references in 4.0.6 and 3.2.10 as well, simply storing them in the existing WeakHashMap there.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Backporting the change to SoftReference values as mentioned above. The synchronization-free use of ConcurrentReferenceHashMap remains 4.1 only.

Juergen