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

joe darcy joe.darcy at oracle.com
Mon Jun 20 14:58:39 UTC 2016


New spec sounds fine; thanks Paul,

-Joe


On 6/15/2016 8:54 PM, Paul Sandoz wrote:
> Hi Joe, Andrew,
>
>> On 14 Jun 2016, at 02:05, Andrew Haley <aph at redhat.com> wrote:
>>
>> On 14/06/16 05:09, joe darcy wrote:
>>> I suggest also pointing out that a bitwise comparison distinguishes -0.0
>>> from +0.0; they compare as == under the built-in operation.
>> Indeed so, yes.  This is particularly likely to bite people who have
>> a zero created by, say, an algorithm which converges on zero with
>> successive terms which alternate sign.  Eww.
>>
> In a previously unpublished incarnation i did talk about -0.0/+0.0, then i dropped it...
>
> Here is an updated revision of the note:
>
> 1226          * @apiNote
> 1227          * Bitwise comparison of {@code float} values or {@code double} values,
> 1228          * as performed by the numeric and atomic update access modes, differ
> 1229          * from the primitive {@code ==} operator and the {@link Float#equals}
> 1230          * and {@link Double#equals} methods, specifically with respect to
> 1231          * comparing NaN values or comparing {@code -0.0} with {@code +0.0}.
> 1232          * Care should be taken when performing a compare and set or a compare
> 1233          * and exchange operation with such values since the operation may
> 1234          * unexpectedly fail.
> 1235          * There are many possible NaN values that are considered to be
> 1236          * {@code NaN} in Java, although no IEEE 754 floating-point operation
> 1237          * provided by Java can distinguish between them.  Operation failure can
> 1238          * occur if the expected or witness value is a NaN value and it is
> 1239          * transformed (perhaps in a platform specific manner) into another NaN
> 1240          * value, and thus has a different bitwise representation (see
> 1241          * {@link Float#intBitsToFloat} or {@link Double#longBitsToDouble} for more
> 1242          * details).
> 1243          * The values {@code -0.0} and {@code +0.0} have different bitwise
> 1244          * representations but are considered equal when using the primitive
> 1245          * {@code ==} operator.  Operation failure can occur if, for example, a
> 1246          * numeric algorithm computes an expected value to be say {@code -0.0}
> 1247          * and previously computed the witness value to be say {@code +0.0}.
>
> Paul.



More information about the jdk9-dev mailing list