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

Martin Buchholz martinrb at google.com
Fri Nov 24 22:56:40 UTC 2017

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

More information about the core-libs-dev mailing list