Tim, thank you for reply. I totally agree with you with one little addition
to
"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"
or it has reference to portable type in its element which is not shared yet.
Original idea was intended mostly to improve performance of web frameworks
which operate with arrays containing elements of their own (non-portable)
types.
Unfortunately idea can't help with many widely used types from Java, e.g.
with Strings. Since them are literals from terracotta point of view (didn't
knew about it) and can't be known whether them are shared or not, am I
right?
On Fri, May 11, 2012 at 12:35 AM, Tim Eck <t...@terracottatech.com> wrote:
> 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(CustomConcurrentHashMap.java:637)
> at
> com.google.common.collect.CustomConcurrentHashMap$Impl.get(CustomConcurrentHashMap.java:1330)
> at
> com.tc.object.ClientObjectManagerImpl.basicLookup(ClientObjectManagerImpl.java:913)
> at
> com.tc.object.ClientObjectManagerImpl.lookupExistingOrNull(ClientObjectManagerImpl.java:390)
> at
> com.tc.object.bytecode.ManagerImpl.lookupExistingOrNull(ManagerImpl.java:415)
> at
> com.tc.object.bytecode.ManagerImpl.lookupExistingOrNull(ManagerImpl.java:71)
> at
> com.tc.object.bytecode.ManagerUtil.lookupExistingOrNull(ManagerUtil.java:314)
> 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(ArrayManager.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
>
>
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
