Array of booleans

[Maurizio Cimadamore]

On 18/03/2021 17:51, John Rose wrote:
> Java booleans are stored in 1-byte containers on all JVMs I know
> of.  The JVMS strongly encourages this by using the same baload
> instruction for both byte[] and boolean[]; packed boolean arrays
> would therefore require a dynamic test.  And it would also be
> hard for a packed boolean array to satisfy the JMM, since no
> hardware we deploy on have bitwise concurrent access to memory,
> short of using CAS-like algorithms.  So, T_BOOLEAN is a byte
> which contains either 0 or 1, or (at worst) has access methods
> which perform either x!=0 or x&1 normalizations.

Thanks for the background.

While I'm acutely aware that there are probably no other options in 
terms to implement the JVMS in a way where booleans are not 8-bit words, 
my point here is an API one; let's flash-forward into a world where the 
MemoryLayout API exits incubation; in such a world, I would expect 
layout accessors such as JAVA_INT, JAVA_LONG, ... to be static fields 
inside the wrapper classes:

class Integer {
      MemoryLayout LAYOUT = ...
}

We can add such static fields for Character, Short, Int, Long, Float, 
Double. Because the layout for these is specified.

But I would find it a bit more troublesome to add a Boolean::LAYOUT 
without some backing spec text somewhere.

And, if we don't have that field, then it becomes less clear when I can 
use a boolean.class carrier in a memory access var handle (as when you 
build a var handle from a layout there's a check which makes sure that 
the carrier you have specified is compatible with the layout being 
accessed).

If the JVMS were to be tightened (as opposed to just describe what 
Hotspot does), I would have no issues adding boolean support in the 
memory access API (and, as a consequence, in the linker API).

Maurizio