RFR(s): 8191859: SoftReference clock/timestamp should be declared volatile

[Martin Buchholz]

These fields have been this way for a very long time, probably
intentionally non-volatile.
Is there an observable problem being solved here?
I see that out-of-thin-air longs are theoretically possible, but very rare
in practice on current platforms.
If all you're trying to do is to ensure atomicity and that the reads/writes
don't get optimized away by the jit, then consider using "opaque"
VarHandles instead.

I was surprised there was no bug subcomponent for java.lang.ref

On Fri, Nov 24, 2017 at 5:13 AM, Per Liden <per.liden at oracle.com> wrote:

> The clock and timestamp fields in SoftReference should be declared
> volatile. These fields are read or updated by the VM, (possibly)
> concurrently with the execution of Java threads.
>
> To be more specific, the timestamp field is read by the GC during
> reference discovery, e.g. during G1/CMS concurrent mark. The clock is
> updated by the GC, typically after reference processing has completed.
>
> Webrev: http://cr.openjdk.java.net/~pliden/8191859/webrev.0/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191859
>
> /Per
>