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