Yes. Core library code close to the JVM in OpenJDK (that in the java.base module, commonly that in java.lang.* close to that in hotspot) often assumes implementation specifics of the JVM. The two are closely coupled. There are other such implementation-specific contracts like @Stable, or “final fields as really final", or certain intrinsics, hidden fields, and much of direct Unsafe usage etc.
Paul. > On Aug 19, 2020, at 9:55 AM, Hans Boehm <hbo...@google.com> wrote: > > If I understand the code correctly, adding the fence should fix this for > current implementations. But it is not correct by current language rules, > and may conceivably break in the future unless the implementation enforces > stronger rules. > > On Wed, Aug 19, 2020 at 6:13 AM Galder Zamarreno <gal...@redhat.com> wrote: > >> On Mon, Aug 10, 2020 at 2:19 PM Doug Lea <d...@cs.oswego.edu> wrote: >> >>> Catching up... >>> >>> As implied in other posts, the minimal fix is to add a trailing release >>> fence (using Unsafe?) to the constructor. >> >> >> FYI I have sent an RFR with the proposed fix ^ >> >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068244.html >> >> >>> Or less delicately, to access >>> only using acquire/release (which will cost a bit on ARM/Power, but >>> probably not noticeable on x86), or most simply (but expensively) to >>> declare the field volatile. >>> >>> Also, as Hans noted, the consensus seems to be that there not enough to >>> be gained by always adding a release fence to constructors. A few errors >>> like this might never occur, but other related anomalies with non-final >>> field accesses would remain. >>> >>> -Doug >>> >>> >>
