RFR (S) 8213137: Remove static initialization of monitor/mutex instances
erik.osterlund at oracle.com
Wed Nov 7 08:00:04 UTC 2018
I noticed that for each lock except Decoder::shared_decoder_lock() you
removed the static lock and its static getter, rerouting references from
them to the new locks managed in the mutexLocker files.
Was there a particular reason why the getter for shared_decoder_lock()
in particular remains, instead of just referencing the
Decoder_shared_decoder_lock directly, as you did for all other locks?
I suppose that by removing the getter, we would miss out on the assert
that the lock is not NULL. But on the other hand, 1) nobody else checks
if their global lock from mutexLocker is null, 2) if it ever was null,
we would immediately get a SIGSEGV upon use, so I don't think that is
I also noticed that all other locks managed by the mutexLocker files
have a CamelCase_lock convention. These locks are the first to break
that convention. On the other hand, I have no idea why we have that
convention in the first place, so I'm not necessarily opposed to that. I
thought I'd at least check if this was intended or accidental.
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
More information about the hotspot-dev