JEP 143: Improve Contended Locking

AuthorDan Daugherty
OwnerDaniel Daugherty
Created2011/11/30 20:00
Updated2014/07/24 17:38
TypeFeature
StatusProposed to Target
Componenthotspot / runtime
ScopeImplementation
Discussionhotspot dash runtime dash dev at openjdk dot java dot net
EffortM
DurationL
Priority4
Reviewed byKaren Kinnear
Endorsed byMikael Vidstedt
Release9
Issue8046133
Relates to7117065: RFE: Improve contended locking support

Summary

The purpose of this project is the productization of bug fixes and contended Java Monitor performance improvements developed by Oracle Labs. This project is based on the port done by members of the Hotspot Runtime team back in late 2010.

Goals

The primary goal of this project is to improve overall performance of contended Java Monitors as measured by the following benchmarks and tests:

Non-Goals

It is not a goal of this project to address any performance improvements for internal VM Monitors or Mutexes; Java Monitors and internal VM Monitors/Mutexes are implemented by different code. While some of the concepts in this project might be applicable to internal VM Monitors/Mutexes, the code is not directly applicable.

It is not a goal of this project to improve contended Java Monitor performance on every benchmark or test; in some cases there may be a performance degradation in a specific benchmark or test. That performance degradation might be considered acceptable in order to gain a performance improvement on another benchmark or test.

Success Metrics

This project will be considered a success if there are demonstrable performance gains as measured by the above benchmarks without offsetting significant performance regressions.

There must not be a non-trivial performance regression for uncontended locks

Motivation

Improving contended locking will significantly benefit real world applications, in addition to industry benchmarks such as Volano and DaCapo.

Description

This project will explore performance improvements in the following areas related to contended Java Monitors:

The original body of work also included changes for "faster hashcode"; since Java object hashcode support is not directly related to contended Java Monitors, that work will not be included as part of this project.

This project will also generate fixes for various bugs discovered during the course of the work; these bug fixes will be managed independently of the performance improvement work so that the fixes can be integrated sooner.

This project is covered by the following "umbrella" bug for administrative simplicity:

JDK-6607129 Reduce L2$ coherence miss traffic in contended lock spin loop - specifically for derby on ctn-family

However, as sub-tasks or bug fixes are completed the work will be integrated using a separate bug ID. This allows the entire project to be referred to via one bug ID (JDK-6607129) while allowing incremental improvements to be made available more quickly than waiting for the entire project to complete.

Testing

Functional Testing

There does not appear to be a specific set of functional tests exclusively for Java Monitors nor is one necessary. Java Monitors are so widely used by even the simplest of Java programs that almost any functional breakage in Java Monitors should be obvious.

Stress Tests

There needs to be a set of well known stress tests for Java Monitors. These can be targeted stress tests for specific Java Monitor scenarios or tests generally known to be heavy users of Java Monitors run with specific stress inducing options.

Note: Use '-XX:-UseBiasedLocking -XX:+UseHeavyMonitors' to bypass both biased locking and stack based locking; forces the use of ObjectMonitor objects.

field reordering and cache line alignment sub-task stress tests

Stress test should focus on generating high numbers of active ObjectMonitor objects. The targets of the stress testing are peak ObjectMonitor usage, the ObjectMonitor block allocation algorithm and the ObjectMonitor free list management code. The following are the goals:

  1. to have the same or better peak ObjectMonitor usage for small to medium configuratio
  2. to have no memory leaks
  3. to have no data structure management failures

speed up PlatformEvent unpark() sub-task stress tests

Stress test should focus on high numbers of concurrent waiters and/or concurrent enter-exit threads. The mix of enter-wait-exit and enter-exit threads should be configurable. The target of the stress testing is the successor mechanism.

Goal: no hangs due to lost unpark operations

fast Java Monitor Enter operations sub-task stress tests

Stress test should focus on correctness of enter-exit operations with a scalable number of parallel threads. The target of the stress testing is Java Monitor ownership.

Goal: No ownership conflicts where more than one thread thinks it owns the Java Monitor.

fast Java Monitor Exit operations sub-task stress tests

Should be covered by the stress tests for the "speed up PlatformEvent unpark()" and "fast Java Monitor Enter operations" sub-tasks.

fast Java Monitor Notify/NotifyAll operations sub-task stress tests

Stress test should focus on correctness of enter-wait-exit operations with a scalable number of parallel threads. The target of the stress testing is Java Monitor ownership after wait() completes and the Java Monitor is re-entered. Goal: No ownership conflicts where more than one thread thinks it owns the Java Monitor.

adaptive spin improvements and SpinPause on SPARC sub-task stress tests

From a stress point of view, should be covered by the testing for the other sub-tasks.

Impact