RFR: jsr166 jdk9 integration wave 9

[Martin Buchholz]

Another way of looking at it:

Machines like the types "int" and "double".

Use of float instead of double in an API is almost always a mistake, except
to save space for arrays of values.
Similarly, it's never worth optimizing a boolean or byte value to actually
take up less than 4 bytes, except when storing them in arrays.
We don't currently have AtomicBooleanArray (AtomicBitSet?) or
AtomicByteArray, although we've gotten to the point where we _could_ have
them.


On Thu, Aug 11, 2016 at 3:59 PM, Martin Buchholz <martinrb at google.com>
wrote:

>
>
> On Thu, Aug 11, 2016 at 2:12 PM, Aleksey Shipilev <
> aleksey.shipilev at gmail.com> wrote:
>
>> On 08/11/2016 11:56 PM, Martin Buchholz wrote:
>> > I can imagine a machine that has a native cas instruction, but no native
>> > exchange instruction, but no one ever got fired for optimizing for x86.
>>
>> ...which would be less of an issue once we switch to proper-boolean
>> VarHandles, not the int-simulation. This way, implementations may choose
>> how to implement boolean getAndSet. Probably in Unsafe, but that would
>> still be lower and more reusable than in AtomicBoolean alone.
>>
>
> I like the current int simulation, at least for AtomicBoolean.  You'll
> never save space by switching to boolean, because of alignment, and you
> don't have to worry about machines without byte-sized instructions.  But
> like I always say, "no one ever got fired for optimizing for x86"!
>