• Bug
  • Status: Open
  • 2 Major
  • Resolution:
  • Byte Code Transform
  • prodmgmt
  • Reporter: teck
  • April 02, 2008
  • 1
  • Watchers: 2
  • March 19, 2010

Description

AtomicLong and AtomicInteger have special class adapters for use in the IBM JDK. From what I can gather, trying to add the Manageable interface (and/or the $__tc_managed field) causes seg faults in those classes. To work around the problem, these types end up using the client object manager to determine if they are managed – that check is a bottleneck.

This is an example stack trace coming though a Random (which uses AtomicLong):

“worker-100” prio=1 tid=0x0000002c302fc820 nid=0x345c waiting for monitor entry [0x0000000049243000..0x0000000049243bb0] 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.ClientObjectManagerImpl.isManaged(ClientObjectManagerImpl.java:451) at com.tc.object.bytecode.ManagerImpl.isManaged(ManagerImpl.java:694) at com.tc.object.bytecode.ManagerUtil.isManaged(ManagerUtil.java:385) at com.tcclient.util.DSOUnsafe.compareAndSwapLong(DSOUnsafe.java) at java.util.concurrent.atomic.AtomicLong.compareAndSet(AtomicLong.java:110) at java.util.Random.next(Random.java:141) at java.util.Random.nextDouble(Random.java:380) at java.lang.Math.random(Math.java:694)

Comments

Fiona OShea 2008-04-03

IBM JDK, should decide what we want to do with this

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.