Possible subtle memory model error in ClassValue

[Paul Sandoz]

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 <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 ^
>> 
>> 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
>>> 
>>> 
>>