On 1/30/14 3:13 AM, Paul Sandoz wrote:
On Jan 30, 2014, at 3:57 AM, Stuart Marks <stuart.ma...@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
