RFR(S): 8211176: Initialize ObjectMonitor eagerly
Andrew Dinn
adinn at redhat.com
Thu Sep 27 10:13:13 UTC 2018
Hi Mikael,
Fortuitously, I have just been looking through this code so I have a
vague understanding of how the lazy init works.
On 26/09/18 22:29, 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/
I'm not clear about how the split between ObjectMonitor::init() and
ObjectMonitor::init_2() works.
I notice that you have replaced the previous call to DeferredInitialize
in EnterI with an assert that InitDone is true, ensuring that no monitor
is entered before the basic setup done by init() has been done. However,
this provides no guarantee that init_2() has been called when EnterI is
entered. If there is a possibility that EnterI may be called before
init_2() then this raises the potential for a problem because EnterI
might try to update perf data (e.g. on line 555 it increments the
FutileWakeups count).
Am I right to assume you factored out the initialization done by
init_2() in order to allow other necessary initalization required to
allow the perf mon setup to work?
Is there some guarantee that means EnterI will not update the perf
counters if it does get called in between init() and init_2()?
Alternatively, sis it not supposed to be called before init_2() is
executed? If so then would it not be better to assign InitDone to true
in init_2()?
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
More information about the hotspot-runtime-dev
mailing list