JDK-8213723 : More Monitor/mutex initialization management
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 12
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-11-12
  • Updated: 2019-05-28
  • Resolved: 2018-11-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 12
12 b21Fixed
Related Reports
Relates :  
JDK-8213137 - Remove static initialization of monitor/mutex instances
Description
JDK-8213137 dealt with the issue of Mutex/monitor instances initialized through C++ static initializers, by moving them to the global set of mutexes/monitors managed by MutexLocker. But there are still Mutex/Monitor instances embedded in other classes whose initialization may be problematic.

In particular on Solaris we have a problem. The NMT _query_lock is created during VM argument parsing, which is after os::init(), but on Solaris os::solaris::synchronization_init() is called from os::init_2() which is after argument parsing - because sync init on Solaris depends on the arguments: UseLWPSynchronization and UsePthreads.

An assert needs to be added to ensure we don't accidentally initialize other instances too early.
Comments
I think adding the assert in the Monitor constructor is a good idea to identify possible Mutex/Monitors that are created before os::init_2(). If we identify cases like NMT_query_lock we can always move its initialization to mutex_init(), since even if the lock is used before mutex_init(), we can always use them with the MutexLockerEx wrapper which should take care of the case when they are NULL.
13-11-2018
The NMT _query_lock can be made a global lock in MutexLocker: DCMDQuery_lock. This is safe as a DCmd can only be used after its factory is registered and the DCMDFactory_lock is already a global lick in MutexLocker. We can add an assertion in the Monitor constructors for os::mutex_init_done() and we can set that in os::init_2() once it is safe and before any local mutex creation. Eventually we will have to deal with Solaris causing a delay in this being safe but that involves converting Solaris to use pthreads for everything.
13-11-2018