Contribution: Lock Contention Profiler for HotSpot

[Peter Hofer]

Hi Andrew,

I finally got around to measuring the change in execution times between 
disabling the profiler in a patched OpenJDK and an entirely unmodified 
OpenJDK. I did this for the benchmarks of the DaCapo and scalabench suites.

For many benchmarks, there is some difference even when the profiler is
not enabled. Still, the disabled case was not something that we 
optimized for. I think that most, if not all of that cost can be shaved
off by revisiting changes to frequent code paths and to the object layouts.

Here are the results for the JDK 8u patch:
> http://ssw.jku.at/General/Staff/PH/lct/unmodified-vs-disabled/jdk8u.pdf

For the JDK 9 patch (tracing only native locks):
> http://ssw.jku.at/General/Staff/PH/lct/unmodified-vs-disabled/jdk9-nativeonly.pdf

I measured this on a openSUSE 13.2 system with a single Intel Core
i7-4790K processor, using a fixed Java heap size of 8 GB.

Cheers,
  Peter

On 11/04/2016 03:21 PM, Andrew Dinn wrote:
> On 04/11/16 12:04, Peter Hofer wrote:
>    . . .
>>> Have you measured the overhead this change produces when running with
>>> contention detection disabled? (i.e. do we pay to have this feature even
>>> when we don't use it).
>>
>> We measured only the overhead relative to an unmodified OpenJDK build.
>>
>> Our profiler observes only lock contention, which is generally handled
>> via slow paths in the VM code, so this is where we added the code to
>> record events. I don't expect this code to cause much overhead when
>> disabled. However, we added fields to several data structures, which
>> might make a difference.
>
> Yes, increased footprint (in code as well as object space) would be as
> much a concern as increased execution time.
>
>> I'll run some more benchmarks and report my findings.
>
> Thanks very much.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>