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

Thomas Schatzl thomas.schatzl at oracle.com
Mon Nov 5 13:05:23 UTC 2018


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

Some nits:

Maybe the spacing in mutexLocker.cpp:325 for the JfrThreadSampler_lock
could be fixed though.
Also the assert in decoder.cpp:94 seems to be as superfluous to me as
in the other lines where it has been removed.


More information about the hotspot-dev mailing list