Possible subtle memory model error in ClassValue
paul.sandoz at oracle.com
Wed Aug 19 17:28:30 UTC 2020
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.
> On Aug 19, 2020, at 9:55 AM, Hans Boehm <hboehm at 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 <galder at redhat.com> wrote:
>> On Mon, Aug 10, 2020 at 2:19 PM Doug Lea <dl at 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 ^
>>> 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.
More information about the core-libs-dev