We have seen that a thread does spinning in the following scenarios
- When Flat Lock is Busy
- When Inflated Lock is Busy
- When native level Lock is Busy
As earlier mentioned, spinning increases efficiency as we are avoiding expensive context switches and also avoiding the need to immediately move to OS calls to manage Locking. However, CPU consumption is not free. If the system is already busy, spinning can eat away some CPU cycles which could otherwise be utilized elsewhere. For locks that are held for longer time, the spinning does not make sense (say the thread spins for a period X. And the lock is typically held for X+Y).
The following features are introduced in regard to the above:
Eliminate multiple spin
Disable excessive spinning. Suppose an object monitor which is in inflated mode. When a thread fails to acquire that lock in inflated mode with a spin, it does a spin again on JVM system monitor.
We are disabling the secondary spinning that we do on JVM system monitors.
-Xthr:secondarySpinForObjectMonitors is the option to disable this feature and enable spin on JVM system monitors.
This feature decides whether spinning is beneficial for certain set of locks and disables if not necessary. This is enabled by default from IBM Java R626.
This feature is achieved by sampling lock acquiring information, whenever there is contention on the lock. It collects data related to hold times (the period for which the lock is held) and Slow percentages (percentage of lock acquires that made the thread wait to the total lock acquires).
Based on heuristic values obtained in our labs about the above entities, J9 JVM will disable spinning on that particular lock, if it is deemed as unnecessary. Once spinning on a lock is disabled, it is done so for the rest of the application run. Sampling will also be disabled too on that lock during that period.
-Xthr:adaptSpin/-Xthr:noAdaptSpin options are used to enable/disable this feature.