Remove locks of type Object to help lock contention analysis

[David Holmes]

Hi Sean,

The intent with using Object is to avoid introducing unnecessary new 
classes, which increases memory and disk footprint (granted only a 
little but it all adds up).

Further I don't see how this is any different to seeing a bunch of 
records that all indicate java.util.concurrent.locks.ReentrantLock as 
the type of the lock. It is the instance that is important, not the type 
(or not just the type). You can't expect a unique type name for each 
object used for locking.

My 2c.

David Holmes

Sean Chou said the following on 03/09/11 15:07:
> Hi,
>    I found there are code pieces using java.lang.Object as a lock type. It
> appears as follow:
> 
> *//example
> ...
> private Object lock = new Object();
> ...
> public void foo() {
> synchronized(lock) { ... }
> ...
> //end of example*
> 
>    This will give some confusing results when using tools like JLM to
> analyze
> synchronization contention, because tools usually use class name of the lock
> 
> instance to indicate the lock. Here is an example from JLM:
> *
> **//example2
> %MISS GETS NONREC SLOW REC TIER2 TIER3 %UTIL AVER-HTM MON-NAME
> 100 562 562 562 0 0 0 0 3377 [32C7C768] java/lang/Object at 9559CA00 (Object)
> 100 562 562 562 0 0 0 0 3160 [32C7C3D0] java/lang/Object at 951DA530 (Object)
> // <=  which lock is this one representing?
> 100 560 560 560 0 0 0 0 3155 [37B4E854] java/lang/Object at 94BA1C00 (Object)
> 100 58 58 58 0 0 0 0 3100 [355D3AB8]
> org/apache/derby/impl/services/daemon/BasicDaemon at 9DE5B348 (Object)
> 100 28 28 28 0 0 0 0 3892 [355D401C]
> com/ibm/ws/sib/msgstore/persistence/lock/DBLockManagerThread at 9F6E5D18(Object)
> //end of example2*
> 
>    The first three lines indicate three locks of type java.lang.Object, and
> it is impossible to distinguish them.
> 
>    If these locks are changed to a named type as follows,
> 
> //example3
> *...
> private class InterruptLock {}
> private Object lock = new InterruptLock();
> ...
> public void foo() {
> synchronized(lock) { ... } }
> ...*
> //end of example3
> 
>    Exaple2 would be like this:
> 
> //example4
> *%MISS GETS NONREC SLOW REC TIER2 TIER3 %UTIL AVER-HTM MON-NAME
> 0 0 0 0 0 0 0 0 0 [36047598]
> com/ibm/ws/sib/msgstore/list/ReadWriteLock at A1CA04C8 (Object)
> 0 0 0 0 0 0 0 0 0 [360475F4]
> sun/nio/ch/PollSelectorImpl$InterruptLock at A7C06F58 (Object)   // <=  we get
> the lock name after modification
> 0 0 0 0 0 0 0 0 0 [36047650]
> com/ibm/ws/objectpool/ObjectPoolImpl at 9FCAA5F8(Object)
> *
> //end of example4
> 
>    There are several classes found containing these pieces of code:
> *src/share/classes/java/lang/SecurityManager.java
> src/share/classes/java/lang/reflect/Proxy.java
> src/solaris/classes/java/lang/UNIXProcess.java.solaris
> src/solaris/classes/sun/nio/ch/PollSelectorImpl.java*
> 
>    It will bring some enhancement to performance tools if these modification
> can
> be applied. Any comments?
>