Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revisit class cache in CachedIntrospectionResults [SPR-11867] #16486

Closed
spring-projects-issues opened this issue Jun 11, 2014 · 4 comments
Closed
Assignees
Labels
status: backported An issue that has been backported to maintenance branches type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Jun 11, 2014

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:

Referenced from: commits f27b949, 8307447, fab67b0

Backported to: 3.2.10

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Jun 11, 2014

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
Copy link
Collaborator Author

spring-projects-issues commented Jun 12, 2014

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
Copy link
Collaborator Author

spring-projects-issues commented Jun 29, 2014

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
Copy link
Collaborator Author

spring-projects-issues commented Jul 1, 2014

Juergen Hoeller commented

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

Juergen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: backported An issue that has been backported to maintenance branches type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants