RFR (S) 8213137: Remove static initialization of monitor/mutex instances

[Robbin Ehn]

Thanks David, looks good!

/Robbin

On 2018-11-05 02:43, David Holmes wrote:
> This impacts GC, compiler, runtime and serviceability.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8213137
> webrev: http://cr.openjdk.java.net/~dholmes/8213137/webrev/
> 
> To facilitate changes to the Mutex/Monitor code we need to ensure there are no 
> statically initialized Monitor/Mutex instances in the VM - as the constructors 
> may rely on VM initialization that has not happened when C++ initializers execute.
> 
> There were 6 locally defined "lock" members of classes that were statically 
> initialized, and these are across all areas of the VM:
> 
>   - Decoder::_shared_decoder_lock
>   - DCmdFactory::_dcmdFactory_lock
>   - JfrThreadSampler::_transition_block_lock
>   - NMethodSweeper::_stat_lock
>   - ThreadsSMRSupport::_delete_lock
>   - CodeCacheUnloadingTask::_lock
> 
> The last is actually now unused and so is just deleted. The rest join all other 
> Monitor/Mutex instances defined in the global list in MutexLocker and 
> initialized in mutex_init(). I've verified that none of the monitor/mutex 
> instances can be used prior to mutex_init, by code inspection - more details in 
> the bug report.
> 
> I investigated asserting that a Monitor/Mutex is only constructed during 
> mutex_init() but assertions don't fail cleanly during C++ static initialization 
> - the result is that during the build jmod goes into an infinite loop printing 
> out "[Too many errors, abort]".
> 
> Tested using tier1-3
> 
> Thanks,
> David