RFR 8158039 VarHandle float/double field/array access should support CAS/set/add atomics

[David Holmes]

Catching up after very long vacation.

For the record I still think this is misguided. The only atomic op you 
can do with float/double is a CAS (and that doesn't operate at the 
semantic level only raw bits). Everything else has to be emulated by 
CAS-loop as no hardware support for atomic FP ops exists.

We made a deliberate choice not to support float/double in j.u.c.atomic 
back with JSR-166 and _nothing_ has changed since then.

Regards,
David
-----

Paul Sandoz paul.sandoz at oracle.com
Tue Jun 14 00:12:14 UTC 2016
> Hi,
> 
> Here is an updated webrev.
> 
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.jdk/webrev/
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8158039-float-double-field-array-cas.hotspot/webrev/
> 
> Changes
> 
> - the Unsafe.getAndAdd for float/double operate in the bit-domain.
> 
> - documentation added to the factory methods:
> 
> 1221          * <p>
> 1222          * If the field type is {@code float} or {@code double} then numeric
> 1223          * and atomic update access modes compare values using their bitwise
> 1224          * representation (see {@link Float#floatToRawIntBits} and
> 1225          * {@link Double#doubleToRawLongBits}, respectively).
> 1226          * <p>
> 1227          * @apiNote
> 1228          * Bitwise comparison of {@code float} values or {@code double} values,
> 1229          * as performed by the numeric and atomic update access modes, differ
> 1230          * from the primitive {@code ==} operator and the {@link Float#equals}
> 1231          * and {@link Double#equals} methods, notably with respect to
> 1232          * {@code NaN}.  There are many possible NaN values that are considered
> 1233          * to be {@code NaN} in Java, although no IEEE 754 floating-point
> 1234          * operation provided by Java can distinguish between them.  As such
> 1235          * care should be taken when performing a compare and set or a compare
> 1236          * and exchange operation with NaN values since the operation may
> 1237          * unexpectedly fail.  Failure can occur if the expected or witness
> 1238          * value is a NaN value and it is transformed (perhaps in a platform
> 1239          * specific manner) into another NaN value, and thus has a different
> 1240          * bitwise representation (see {@link Float#intBitsToFloat} or
> 1241          * Double#longBitsToDouble for more details).
> 
> (I also updated the documentation on array/ByteBuffer view methods but did not bother with the api note)
> 
> Paul.