[jmm-dev] final reads/writes

[Doug Lea]

Continuing my quest to introduce issues early and often...

Assuming that we go ahead with the idea of ensuring a release fence
upon construction (normally free, because piggybacked with those
required anyway for object headers), rather than only in the presence
of final fields, do we need to say anything special about final fields?

I can't quite rule it out. Thoughts welcome.

Background: Optimizers like to remove unnecessary reads
(and computations based on them). It seems that any plausible
memory model will allow cases based on the idea that if you can
identify a readsFrom source for a value, and you've already
read it, then no additional ordering constraints could
force you to re-read, so don't.

In a more ideal world, "final" would allow a more aggressive
version: If you've  (implicitly) identified ANY readsFrom source,
that's good enough, because there is only one. Unfortunately, "final"
doesn't strictly mean this in JVMs -- there are cheats
sometimes allowing further updates to final variables. And in
practice JVMs are conservative enough to allow those cheats
to work, despite some wording in the JSR133 JMM allowing them
not to work.

Additionally, JDK8 hotspot introduced the @Stable annotation
that in essence says: if the value is nonnull, then it is the final
written value. And similar cases arise in which there may be
bookkeeping to track "Freeze after writing" status
(https://www.cs.indiana.edu/cgi-bin/techreports/TRNNN.cgi?trnum=TR710),
and a possible JDK9 proposal for explicitly "frozen" arrays.

The question at hand is: Does a memory model itself need to say
anything explicitly about any of these?

-Doug