[jmm-dev] ECOOP, JVMLS

Doug Lea dl at cs.oswego.edu
Tue Aug 5 14:01:19 UTC 2014

On 08/05/2014 03:17 AM, John Rose wrote:
> On Aug 3, 2014, at 5:36 AM, Doug Lea <dl at cs.oswego.edu
> <mailto:dl at cs.oswego.edu>> wrote:
>> * Everyone seems to strongly favor the idea of replacing final-field
>> specs with those that amount to guaranteeing release fences in
>> constructors.  Still lots of details (some depending on core model) to
>> work out though.
> This change makes it easier to define interesting variations on final variables.

Yes, many increasingly common variants.

Aside: Here's some reconstructed history about this.  (Hans and
Jeremy, feel free to correct.) At one point in JSR133, some of us
proposed something along the lines of release-on-construct. The DEC
Alpha folks strenuously objected and showed that it would cause a big
(I vaguely recall 6X) performance hit in their (now long gone) JVM.
And they further argued that use cases relying on it were buggy anyway
because they lacked locks on read side that would be needed possibly
even for final fields in some then-planned Alpha processors.  So we
(mainly Jeremy and Bill) pursued the clever but complicated
freeze/final approach to only cover the minimal required case,
explicitly final fields. We might have done otherwise had we noticed
at the time that:

* JVMs rely (at least sometimes) on sanely released object headers
anyway.  While it might not be logically impossible to do otherwise,
it would either severely limit efficiency of internal GC etc
algorithms or require unknown techniques. (Getting internal release
mechanics under new rules to coincide with those for initializing
assignments (in the absence of leakage etc) might require some JVM
implementation work, but nothing that seems very challenging.)

* Even though most programmers don't consciously say so, most
intuitively believe that construction implies release.  They make more
errors when their intuitions are wrong, especially when they try to
implement various monotonic, semi-final idioms that are otherwise fine
but inexpressible.  Changing rules does open up the moral hazard that
people will overgeneralize to cover more cases than they do, but
that's not a very good argument for keeping current rules.


More information about the jmm-dev mailing list