RFR(S): 8211176: Initialize ObjectMonitor eagerly

Mikael Vidstedt mikael.vidstedt at oracle.com
Wed Sep 26 21:29:29 UTC 2018

Please review this change which removes ObjectMonitor::DeferredInitialize in favor of explicit/eager initialization:

bug: https://bugs.openjdk.java.net/browse/JDK-8211176
webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211176/webrev.00/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8211176/webrev.00/open/webrev/>

* Background (from the issue)

ObjectMonitor::DeferredInitialize is called lazily/on demand when the first object monitor instance is used. 

Before JDK-8210848 it contained code to process command line arguments etc., but after JDK-8210848 the only part that remains is setting up some spin related settings. The only dependency that code has is that os::is_MP() returns the actual number of processors, which is done in os::init(). 

The ObjectMonitor initialization can and should be done explicitly instead.

I have manually verified that os::init() sets up os::_processor_count on all the different platforms. I have tried my best to verify that anything happening between setting up that variable, and the call to ObjectMonitor::init() does not create and/or use ObjectMonitors. The InitDone asserts in ObjectMonitor should help capture unless there is some race during startup, but since this happens very early during startup it seems unlikely. Please let me know if there’s something I’m missing.

* Testing

I have run some basic (tier1) testing, and I’m in the process of running additional tests (tier2 + tier3). Let me know if you have suggestions on additional tests to run.


More information about the hotspot-runtime-dev mailing list