CDV ❯ isManaged() checks for uninstrumented types could be faster
-
Bug
-
Status: Resolved
-
2 Major
-
Resolution: Won't Fix
-
Byte Code Transform
-
-
teck
-
Reporter: teck
-
April 02, 2008
-
1
-
Watchers: 2
-
September 06, 2013
-
September 06, 2013
Description
Consider what happens in a get() on shared CHM:
“worker-39” prio=1 tid=0x0000002c2eb58730 nid=0x341f waiting for monitor entry [0x0000000045506000..0x0000000045506e30] at com.tc.object.ClientObjectManagerImpl.basicLookup(ClientObjectManagerImpl.java:852) - waiting to lock <0x0000002adf83ba38> (a com.tc.object.util.IdentityWeakHashMap) at com.tc.object.ClientObjectManagerImpl.lookupExistingOrNull(ClientObjectManagerImpl.java:394) at com.tc.object.bytecode.ManagerImpl.lookupExistingOrNull(ManagerImpl.java:641) at com.tc.object.bytecode.ManagerUtil.lookupExistingOrNull(ManagerUtil.java:251) at java.util.concurrent.ConcurrentHashMap.__tc_isDsoHashRequired(Unknown Source) at java.util.concurrent.ConcurrentHashMap.get(Unknown Source)
If the key instance isn’t Manageable interface (array, uninstrumented, etc) we end up checking the object manager’s pojoToManaged map and it is pretty easy for this become a concurrency bottleneck.
Comments
Fiona OShea 2008-04-03
hari prasad 2008-09-15
Hi, I too got the same problem infact i came across a strange issue, where two threads have locked same object.. pls see the below jstack, i got
“TP-Processor386” daemon prio=10 tid=0x5de48e20 nid=0x1852 waiting for monitor entry [0x5afba000..0x5afbb570] java.lang.Thread.State: BLOCKED (on object monitor) at com.tc.object.ClientObjectManagerImpl.basicLookup(ClientObjectManagerImpl.java:852) - locked <0x64308d40> (a com.tc.object.util.IdentityWeakHashMap) at com.tc.object.ClientObjectManagerImpl.lookupExistingOrNull(ClientObjectManagerImpl.java:394) at com.tc.object.bytecode.ManagerImpl.lookupExistingOrNull(ManagerImpl.java:641) at com.tc.object.bytecode.ManagerUtil.lookupExistingOrNull(ManagerUtil.java:251)
“TP-Processor51” daemon prio=10 tid=0x5d592d70 nid=0x44e4 waiting for monitor entry [0x59b5b000..0x59b5d570] java.lang.Thread.State: BLOCKED (on object monitor) at com.tc.object.ClientObjectManagerImpl.basicLookup(ClientObjectManagerImpl.java:852) - locked <0x64308d40> (a com.tc.object.util.IdentityWeakHashMap) at com.tc.object.ClientObjectManagerImpl.lookupExistingOrNull(ClientObjectManagerImpl.java:394) at com.tc.object.bytecode.ManagerImpl.lookupExistingOrNull(ManagerImpl.java:641) at com.tc.object.bytecode.ManagerUtil.lookupExistingOrNull(ManagerUtil.java:251)
while other threads are waiting for this lock
“TP-Processor356” daemon prio=10 tid=0x5d3f72f0 nid=0x7c76 waiting for monitor entry [0x57eb9000..0x57ebb4f0] java.lang.Thread.State: BLOCKED (on object monitor) at com.tc.object.ClientObjectManagerImpl.basicLookup(ClientObjectManagerImpl.java:852) - waiting to lock <0x64308d40> (a com.tc.object.util.IdentityWeakHashMap) at com.tc.object.ClientObjectManagerImpl.lookupExistingOrNull(ClientObjectManagerImpl.java:394) at com.tc.object.bytecode.ManagerImpl.lookupExistingOrNull(ManagerImpl.java:641) at com.tc.object.bytecode.ManagerUtil.lookupExistingOrNull(ManagerUtil.java:251)
Can you pls look at this, as i feel this is a critical issue.
Fiona OShea 2008-09-15
Hari, can you please add the Terracotta version you are using along with your environment details? Regards Fiona
hari prasad 2008-09-16
yeah sure, its
Terracotta -2.5.2
jdk1.6.0_04
apache-tomcat-6.0.13
Fiona OShea 2008-09-16
I’ve created CDV-908 to track the locking on shared object issue. Please follow the new issue for updates and dev suggestions.
If we can get to this in Pacheco….