RFR (S) 8213137: Remove static initialization of monitor/mutex instances
Robbin Ehn
robbin.ehn at oracle.com
Wed Nov 7 07:11:18 UTC 2018
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
More information about the hotspot-dev
mailing list