Maybe I'm missing something, but I don't quite see how you can infer
whether a given array instance is clustered or not based on its elements.
One quick case is primitive arrays or arrays of terracotta literals
(String, etc) - nothing to consult in those cases. Even with an
application class type you can certainly have an unclustered array
instance with references to clustered instances:
Assume the "f" parameter is a clustered instance of Foo
void(Foo f) {
Foo[] array = new Foo[1];
array[0] = f;
array[0] = null;
}
In this code the array is simply a method local and cannot be clustered,
but it can certainly reference a clustered Foo object.
Kind of along the same lines I don't see that the state of instrumented or
not of the element type answers the question of whether a particular array
instance is clustered. I probably need to think about this last one a bit
more. I'm not actually sure if an array of an uninstrumented type with all
null references is portable or not.
Thinking a little more as I type, perhaps you can infer that an array is
not (yet) clustered if it has a non-null reference to a non-portable type
in one of its elements. That could help fast track things to avoid the
synchronization.
From: tc-dev-boun...@lists.terracotta.org
[mailto:tc-dev-boun...@lists.terracotta.org] On Behalf Of Michael N.
Mikhulya
Sent: Tuesday, May 08, 2012 7:47 AM
To: tc-dev@lists.terracotta.org
Subject: [tc-dev] Array related optimization ideas
Hi guys,
I found that my application waste a lot of time in code like following:
Stack trace 1:
at java.lang.System.identityHashCode(Native Method)
at
com.google.common.collect.MapMaker$Strength$1.hash(MapMaker.java:346)
at
com.google.common.collect.MapMaker$StrategyImpl.hashKey(MapMaker.java:528)
at
com.google.common.collect.CustomConcurrentHashMap$Impl.hash(CustomConcurre
ntHashMap.java:637)
at
com.google.common.collect.CustomConcurrentHashMap$Impl.get(CustomConcurren
tHashMap.java:1330)
at
com.tc.object.ClientObjectManagerImpl.basicLookup(ClientObjectManagerImpl.
java:913)
at
com.tc.object.ClientObjectManagerImpl.lookupExistingOrNull(ClientObjectMan
agerImpl.java:390)
at
com.tc.object.bytecode.ManagerImpl.lookupExistingOrNull(ManagerImpl.java:4
15)
at
com.tc.object.bytecode.ManagerImpl.lookupExistingOrNull(ManagerImpl.java:7
1)
at
com.tc.object.bytecode.ManagerUtil.lookupExistingOrNull(ManagerUtil.java:3
14)
at java.util.Arrays.sort(Arrays.java:1078)
at java.util.Collections.sort(Collections.java:117)
Stack trace 2:
at java.lang.Object.hashCode(Native Method)
at
com.tc.object.bytecode.hook.impl.ArrayManager.hash(ArrayManager.java:593)
at
com.tc.object.bytecode.hook.impl.ArrayManager.getObject(ArrayManager.java:
78)
at
com.tc.object.bytecode.hook.impl.ArrayManager.objectArrayChanged(ArrayMana
ger.java:154)
at
com.tc.object.bytecode.ManagerUtil.objectArrayChanged(ManagerUtil.java:995
)
at
java.util.AbstractCollection.toArray(AbstractCollection.java:171)
at java.util.regex.Pattern.split(Pattern.java:1027)
at java.lang.String.split(String.java:2292)
I found that it is a known long standing issue:
- http://forums.terracotta.org/forums/posts/list/4379.page
- https://jira.terracotta.org/jira/browse/CDV-788
As I can see from sources both ClientObjectManagerImpl and ArrayManager
use some sort of synchronization inside.
I would like to suggest some simple optimizations which doesn't require
complex changes in code.
Before calculating hashCode and making any lookups with synchronization we
can make simple checks which in many cases can avoid expensive operations.
These simple checks are:
1. Clustered array should contains clustered elements. So we can check
whether its first element is clustered or not.
Checking whether element is clustered or not costs almost nothing. Also
spare arrays (arrays with null elements) are rather seldom, so in many
cases we will avoid synchronization.
2. We can check whether element type is instrumented or not. If it is not
instrumented then there is no need to make any synchronization.
Guys, what are you thinking about these ideas? Is it worth to implement
them?
With best regards,
Michael Mikhulya
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
