RFR(S): 8211176: Initialize ObjectMonitor eagerly

[David Holmes]

Hi Mikael,

As discussed offline I think everything actually in 
deferredInitialized() can just be moved into the initialize() method. 
The deferral has existed since the code was added in 2005 and I can't 
see any obvious reason for it being that way.

Thanks,
David

On 26/09/2018 5:29 PM, Mikael Vidstedt wrote:
> 
> 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.
> 
> Cheers,
> Mikael
>