JEP 143: Improve Contended Locking

AuthorDan Daugherty
OrganizationOracle
Created2011/11/30
Updated2013/5/1
TypeFeature
StateCandidate
Componentvm/rt
ScopeImpl
RFE7117065
Internal-refsOracle:A360:696512
Discussionhotspot dash runtime dash dev at openjdk dot java dot net
Start2012/Q2
EffortM
DurationL
Reviewed-byKaren Kinnear
Endorsed-byMikael 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.