Profile the lock usage in openjdk

[Jeremy Manson]

Oh, and you can get an even more coarse measurement of contention from
ThreadMXBean:

http://docs.oracle.com/javase/7/docs/api/java/lang/management/ThreadMXBean.html

Jeremy


On Mon, Mar 3, 2014 at 9:55 PM, Jeremy Manson <jeremymanson at google.com>wrote:

> Of course, if all you want is a coarse measurement, you can use JVMTI.
>  Just have a timer that starts at the first one of these, and stops at the
> second:
>
>
> http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#MonitorContendedEnter
>
> http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#MonitorContendedEntered
>
> We instrument these on a sampling basis across large numbers of
> invocations.  It doesn't perturb the application behavior too much.
>
> Jeremy
>
>
> On Mon, Mar 3, 2014 at 8:14 PM, David Holmes <david.holmes at oracle.com>wrote:
>
>> On 4/03/2014 1:48 PM, Junjie Qian wrote:
>>
>>> Dear all,
>>>
>>> I am one graduate student working on Java VM, and would like to study
>>> the multithread in Java benchmarks. The information I want to get is the
>>> lock contentions in the benchmark, such as fatlock/thinLock/SpinLock
>>> number, or the time spent on waiting for these lock.
>>>
>>> Could you give me some advices on this, as how to insert code in openjdk
>>> to get such info?
>>>
>>
>> You will find that there is already a lot of information gathered within
>> the VM, but some probably only for non-product builds and most only for the
>> contention case where the monitor is inflated. The problem with overly
>> instrumenting the lock code to "measure" contention is that the
>> instrumentation code completely changes the contention patterns. Adding
>> additional instrumentation is non-trivial as you need to handle both
>> interpreted and JIT'd code.
>>
>> David
>>
>>
>>  Thanks!
>>> Best
>>> Junjie
>>>
>>>
>