RFR(s): 8023541 Race condition in rmid initialization
stuart.marks at oracle.com
Thu Jan 30 22:02:38 UTC 2014
On 1/30/14 3:13 AM, Paul Sandoz wrote:
> On Jan 30, 2014, at 3:57 AM, Stuart Marks <stuart.marks at oracle.com> wrote:
>> Then, awaitInitialized seems straightforward until you see that the
>> condition is waiting for the value of a final variable to change! JLS sec
>> 17.5  allows all sorts of optimizations for final fields....
> I think you have done the right thing in the latest webrev, even though i
> suspect the runtime does not fully optimize final fields as constants (since
> it is still possible to update final fields, e.g. see System.out).
It might not optimize final fields now (I tried running a test with several JVM
options, but I'm sure there are ones I haven't tried) so things do seem to work.
However, I couldn't convince myself that a *future* optimization wouldn't cause
a problem. I envisioned either a protracted email discussion/argument or a hairy
debugging session. At that point I decided to remove final. :-)
(I'm reminded of the test failures introduced by more-aggressive GC of
narrowly-scoped local variables.)
> It should not be this hard to reason about this stuff, right?
> Hopefully updates to the JMM will make this easier to grok, even though this
> is a naughty case.
Maybe. I'd guess that the new JMM will stick to covering well-behaved programs
(e.g. ones that adhere to safe publication). The difficulty with issues like
this one is that once publication has occurred unsafely, we have to figure out
how to drag it back into the safe area. There are probably too many ways to
write unsafe programs for the JMM to cover them in a simple fashion.
More information about the core-libs-dev