Contribution: Lock Contention Profiler for HotSpot
peter.hofer at jku.at
Wed Nov 23 16:06:59 UTC 2016
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:
For the JDK 9 patch (tracing only native locks):
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.
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.
> 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
More information about the hotspot-dev