Concurrency Performance
Multithreading is a very popular concept. It allows programs to run multiple tasks at the same time. These multithreaded programs may have more than one unit which can run concurrently. Every unit can handle a different task keeping the use of available resources optimal. This can be managed by multiple threads that can run in parallel.
Java 9 improved contended locking. You may be wondering what is contended locking. Let's explore. Each object has one monitor that can be owned by one thread at a time. Monitors are the basic building blocks of concurrency. In order for a thread to execute a block of code marked as synchronized on an object or a synchronized method declared by an object, it must own this object's monitor. Since there are multiple threads trying to get access to the mentioned monitor, JVM needs to orchestrate the process and only allow one thread at a time. It means the rest of threads go in a wait state. This monitor is then called contended. Because of this provision, the program wastes time in the waiting state.
Also, Java Virtual Machine (JVM) does some work orchestrating the lock contention. Additionally, it has to manage threads, so once the existing thread finishes its execution, it can allow a new thread to go in. This certainly adds overhead and affects performance adversely. Java 9 has taken a few steps to improve in this area. The provision refines the JVM's orchestration, which will ultimately result in performance improvement in highly contested code.
The following benchmarks and tests can be used to check the performance improvements of contented Java object monitors:
CallTimerGrid(This is more of a stress test than a benchmark)Dacapo-bach(earlier dacapo2009)_ avrora_ batik_ fop_ h2_ luindex_ lusearch_ pmd_ sunflow_ tomcat_ tradebeans_ tradesoap_ xalanDerbyContentionModelCountedHighContentionSimulatorLockLoops-JSR166-Doug-Sept2009(earlier LockLoops)PointBaseSPECjbb2013-critical(earlier specjbb2005)SPECjbb2013-maxspecjvm2008volano29(earlier volano2509)
