JRockit and Lock Profiling

http://download.oracle.com/docs/cd/E13188_01/jrockit/docs142/usingJRA/looking.html#1056684


Lock Profiling

You can enable the JRockit Runtime Analyzer to collect and analyze information about the locks
and the contention that has occurred while the runtime analyzer was recording. To do this, add
the following option when you start your application:


-Djrockit.lockprofiling=true


When lock profiling has been enabled, you can view information about Java locks on the Lock
Profiling tab in Mission Control.


You can dump at any time the lock profiling:

jrcmd 3863 lockprofile_print

Class, Lazy Banned, Thin Uncontended, Thin Contended, Lazy Reservation, Lazy lock, Lazy Reverted, Lazy Coop-Reverted, Thin Recursive, Fat Uncontended, Fat Contended, Fat Recursive, Fat Contended Sleep, Reserve Bit Uncontended, Reserve Bit Contended
[I, false, 546, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
java/util/WeakHashMap$Entry, false, 266, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
weblogic/timers/internal/TimerManagerImpl, false, 4398, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
sun/text/resources/DateFormatZoneData, false, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0


The alternative is:
you examine the thread dumps, looking for a pattern like:

-- Blocked trying to get lock: oracle/toplink/sessions/DatabaseLogin@0x2b9dd61a9968[fat lock]

The target of your search should be the [fat lock] with a number of locks on the same monitor (oracle/toplink/sessions/DatabaseLogin@0x2b9dd61a9968)

Plotting the number of threads waiting on the monitor, against the time of the thread dump, can prove whether a lock is really problematic.


About JRA Overhead when Recording
The overhead while recording is very low—typically less than two percent. If you enable Java lock profiling with the system property – Djrockit.lockprofiling=true the overhead could be considerable greater, typically between 3% and 25% depending upon the application.

More on the topic:

http://download.oracle.com/docs/cd/E13188_01/jrockit/docs142/usingJRA/applocks.html