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

David Holmes david.holmes at oracle.com
Tue Nov 6 01:48:54 UTC 2018


Hi Thomas,

Thanks for looking at this.

On 5/11/2018 11:05 PM, Thomas Schatzl wrote:
> Hi,
> 
> On Mon, 2018-11-05 at 11:43 +1000, 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
> 
> Removal of the CodeCacheUnloadingTask lock looks good. I also looked
> through the other changes which seems simple enough to me too, but
> should obviously be looked at from people from the respective areas
> too.
> 
> Some nits:
> 
> Maybe the spacing in mutexLocker.cpp:325 for the JfrThreadSampler_lock
> could be fixed though.

Yes oversight on my part. (Actually I was sure I'd already fixed that as 
soon as I pasted it in ... ??? :( )

webrev updated in place with a few other alignment issues fixed.

> Also the assert in decoder.cpp:94 seems to be as superfluous to me as
> in the other lines where it has been removed.

The assert at 94 replaces the asserts at the other lines. I replaced raw 
uses of _shared_decoder_lock with calls to the function 
shared_decoder_lock(), which embodies the != NULL assert - which is a 
good check to ensure initialization truly does happen sufficiently 
early. In overall effect the assertions remain unchanged.

Thanks,
David

> Thanks,
>    Thomas
> 
> 


More information about the hotspot-dev mailing list