JEP 143: Improve Contended Locking
| Author | Dan Daugherty |
| Organization | Oracle |
| Created | 2011/11/30 |
| Updated | 2013/5/1 |
| Type | Feature |
| State | Candidate |
| Component | vm/rt |
| Scope | Impl |
| RFE | 7117065 |
| Internal-refs | Oracle:A360:696512 |
| Discussion | hotspot dash runtime dash dev at openjdk dot java dot net |
| Start | 2012/Q2 |
| Effort | M |
| Duration | L |
| Reviewed-by | Karen Kinnear |
| Endorsed-by | Mikael Vidstedt |
Summary
Evaluate HotSpot’s support for contended locking and implement profitable solutions, based upon advance work already done by Oracle Labs.
Goals
Significantly improve contended-locking performance in HotSpot.
Motivation
Improving contended locking will significantly benefit real world applications, in addition to industry benchmarks such as Volano and DaCapo.
Description
Improving contended locking performance first requires establishing a baseline measurement using the existing codebase, a specific benchmark (or set of benchmarks), and target hardware. Subsequently, this fixed baseline can be used to measure the benefit of any speculative improvements. Much of this project’s work will be to fold in prior work done by Oracle Labs and then explore any additional opportunities. Also, a significant effort will be made to ensure that any change will not cause regressions in either performance or functionality. As the project progresses, specific improvements will be more fully documented.
Testing
Relevant Performance and Functional tests need to be identified for this work for smoke testing. The complete set of Oracle tests needs to pass on a variety of configurations and JVM options. This feature requires significant bake time to expose as many bugs as possible before release. As with any performance improvement, subtle timing changes can cause entire subsystems to behave very differently. Thus, conservative measures will be taken to ensure only rock-solid changes are integrated to master. Some major wins may be at the expense of slight regressions on other benchmarks. This will be evaluated on a case-by-case basis.
Risks and Assumptions
This feature requires extended bake time. It must be delivered well before the final code freeze for the release. This cannot be a last-minute delivery, or delivered late in the release. Key measures will be taken to ensure significant benefit on modern hardware, is not at the expense of performance on older hardware.

