JEP 143: Improve Contended Locking
|Status||Proposed to Target|
|Component||hotspot / runtime|
|Discussion||hotspot dash runtime dash dev at openjdk dot java dot net|
|Reviewed by||Karen Kinnear|
|Endorsed by||Mikael Vidstedt|
|Relates to||7117065: RFE: Improve contended locking support|
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.
The primary goal of this project is to improve overall performance of contended Java Monitors as measured by the following benchmarks and tests:
- CallTimerGrid (though more of a stress test than a benchmark)
- Dacapo-bach (was dacapo2009)
- _ avrora
- _ batik
- _ fop
- _ h2
- _ luindex
- _ lusearch
- _ pmd
- _ sunflow
- _ tomcat
- _ tradebeans
- _ tradesoap
- _ xalan
- LockLoops-JSR166-Doug-Sept2009 (was LockLoops)
- SPECjbb2013-critical (was specjbb2005)
- volano29 (was volano2509)
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.
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
Improving contended locking will significantly benefit real world applications, in addition to industry benchmarks such as Volano and DaCapo.
This project will explore performance improvements in the following areas related to contended Java Monitors:
- field reordering and cache line alignment
- speed up PlatformEvent unpark()
- fast Java Monitor Enter operations
- fast Java Monitor Exit operations
- fast Java Monitor Notify/NotifyAll operations
- adaptive spin improvements and SpinPause on SPARC
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.
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.
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:
- to have the same or better peak ObjectMonitor usage for small to medium configuratio
- to have no memory leaks
- 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.
- JCP: None
- Other JDK components: None
- Compatibility: None
- Security: None
- Portability: Normal porting work to other platforms.
- User Interface: None
- Documentation: None
- Internationalization: None
- Localization: None
- Legal: None
- Other: None