Possible subtle memory model error in ClassValue

[Hans Boehm]

There is no guarantee that the address dependency enforces ordering if
there is no final field involved. This may matter in the future, since
ARM's Scalable Vector Extension does not guarantee ordering for
address-dependent loads, if both loads are vector loads. I expect there are
cases in which it would be profitable and safe, by the actual JMM rules, to
use these.

What bothers me most about effectively generalizing the JMM rules to
reflect current implementations is that

x = 1;  // Initialization of non-final field in constructor
assert x == 1;

can fail, as can more interesting code that uses x after initialization in
the constructor. The current rules are messy, but generally kind of make
sense for final fields. The generalization to non-final fields is
significantly stranger.

Hans

On Sun, Aug 9, 2020 at 7:53 AM Andrew Haley <aph at redhat.com> wrote:

> On 8/7/20 10:35 PM, John Rose wrote:
>
>  > (Here’s a tidbit of JMM politics: I once heard Doug Lea considering
>  > whether maybe all fields should be treated more like final fields.
>  > I don’t know if this is still a live idea, but it would make this
>  > bug go way, since nearly all constructors would then get fences of
>  > some sort.)
>
> I'd support that: accidental unsafe publication like this is a really
> counter-intuitive language feature.
>
>  > Bottom line:  Add a release fence before type.cVM is set, and add
>  > a (no-op on x86) acquire fence in getCache.
>
> A StoreStore fence would be enough here, and cheaper on some systems.
> The memory dependency ordering from the load of classValueMap to the
> load of classValueMap.cache means we don't need an acquire fence.
>
> After all, final fields have the needed guarantee, only StoreStore
> fences, and no load fences.
>
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
>