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.li...@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 >
