[infinispan-issues] [JBoss JIRA] (ISPN-2414) Optimise memory hotspots for local caches
Galder Zamarreño (JIRA)
jira-events at lists.jboss.org
Fri Oct 19 08:32:08 EDT 2012
[ https://issues.jboss.org/browse/ISPN-2414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Galder Zamarreño updated ISPN-2414:
-----------------------------------
Fix Version/s: 5.1.9.Final
> Optimise memory hotspots for local caches
> -----------------------------------------
>
> Key: ISPN-2414
> URL: https://issues.jboss.org/browse/ISPN-2414
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 5.2.0.CR1, 5.2.0.Final, 5.1.9.Final
>
> Attachments: Screen Shot 2012-10-17 at 1.21.48 PM.png, Screen Shot 2012-10-17 at 1.25.45 PM.png, Screen Shot 2012-10-17 at 1.30.09 PM.png, Screen Shot 2012-10-17 at 1.33.46 PM.png
>
>
> Several small memory hotspots have been discovered during some performance testing of local caches. Optimise them.
> 1. Collections.EmptySet.Iterator: Screen%20Shot%202012-10-17%20at%201.21.48%20PM.png
> - First of all, iterating over an empty set returns a brand new iterator instance all the time. WTF?
> - Second, why does get() have to call unlockAll()? We do not acquire locks on get (unless it has a FORCE_WRITE_LOCK flag on it), right?
> 2. ThreadLocal.set: Screen%20Shot%202012-10-17%20at%201.25.45%20PM.png
> - Is this neeeded at all?
> - If it's needed for any use case, can it be optimised away to avoid using it for a local cache where no marshaller is used, and where no cluster cache loader is used?
> 3. AbstractInvocationContext instances: Screen%20Shot%202012-10-17%20at%201.30.09%20PM.png
> - Why is this expensive? Is it cos the reference to the ClassLoader?
> - If it's the ClassLoader ref, can we move this away for local caches?
> 4. AbstractFlagAffectedCommand instances: Screen%20Shot%202012-10-17%20at%201.33.46%20PM.png
> - Might be worth thinking how can we shrink these commands for local, unflagged, operations, such as get?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the infinispan-issues
mailing list