Profile the lock usage in openjdk

[Junjie Qian]

Dear all,

First thank you so much for your suggestions!
I need to spent some time on these documents, and try to work with them first.
I will let you know if I have any updates or problems on it.

Thanks!
Best
Junjie



On Tuesday, March 4, 2014 12:02 AM, Jeremy Manson <jeremymanson at google.com> wrote:

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
>>>
>>>
>