RFR(s): 8023541 Race condition in rmid initialization

[Stuart Marks]

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 [1] 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.

s'marks