RFR (S) 8213137: Remove static initialization of monitor/mutex instances
David Holmes
david.holmes at oracle.com
Wed Nov 7 07:12:15 UTC 2018
Thanks Robbin!
David
On 7/11/2018 5:11 PM, Robbin Ehn wrote:
> 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