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 <marti...@google.com> wrote: > > > On Thu, Aug 11, 2016 at 2:12 PM, Aleksey Shipilev < > aleksey.shipi...@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"! >
