Array of booleans

[Maurizio Cimadamore]

I think we're diverging from the original question (probably also my fault).

The question was: why don't memory access var handle support dereference 
of "JAVA" boolean carriers - as in boolean.class?

The answer is that the JVM spec does not define what the layout of a 
boolean is (it only does so for the Hotspot VM).

So, in other words, I think we need to acknowledge that 
MemoryLayouts.JAVA_INT would be very different from e.g. 
MemoryLayouts.JAVA_BOOLEAN. For that reason, I don't think supporting 
boolean dereference via VarHandle is the right thing to do.

There is another, related question: what about booleans when it comes to 
the CLinker API - should we have a C_BOOL layout?

The answer there is - yeah we might (in fact at some point we had that), 
and for function calls it might even work ok. But when you start working 
with structs which have boolean fields, we go back to the dereference 
problem above (e.g. VarHandle do not support boolean.class as a carrier).

Because of this asymmetry it was decided that it would have been better 
off to leave booleans (even in the linker API) in user land. After all, 
it is fairly easy to adapt method handle and var handle to do the right 
thing under the assumption that a boolean in the ABI and in the VM is 8 bit.

Maurizio

On 18/03/2021 16:02, David Lloyd wrote:
> On Thu, Mar 18, 2021 at 10:53 AM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>
>     On 18/03/2021 15:43, forax at univ-mlv.fr <mailto:forax at univ-mlv.fr>
>     wrote:
>     > ----- Mail original -----
>     >> De: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com
>     <mailto:maurizio.cimadamore at oracle.com>>
>     >> À: "Remi Forax" <forax at univ-mlv.fr <mailto:forax at univ-mlv.fr>>
>     >> Cc: "panama-dev at openjdk.java.net
>     <mailto:panama-dev at openjdk.java.net>'"
>     <panama-dev at openjdk.java.net <mailto:panama-dev at openjdk.java.net>>
>     >> Envoyé: Jeudi 18 Mars 2021 16:31:12
>     >> Objet: Re: Array of booleans
>     >> On 18/03/2021 15:28, forax at univ-mlv.fr
>     <mailto:forax at univ-mlv.fr> wrote:
>     >>> It works with JNI, boolean is mapped into an unsigned 8 bits
>     >>>
>     https://docs.oracle.com/en/java/javase/16/docs/specs/jni/types.html
>     <https://docs.oracle.com/en/java/javase/16/docs/specs/jni/types.html>
>     >> Yeah - it seems to be a case of different specs pointing to
>     different
>     >> decisions :-)
>     >>
>     >> If the format of booleans is truly unspecified at the JVMS
>     level (which
>     >> seems to be the case), then it seems like JNI is taking things
>     a step
>     >> too far?
>     > I don't think you can practically interact with the C world if
>     you do not fully specify the memory layout of all the primitive
>     types of Java, hence jboolean being defined as an unsigned byte.
>
>     True, but note that this is not a problem we have with the linker;
>     the
>     linker supports the C ABI. The only type related to boolean in
>     e.g. the
>     SysV ABI is _Bool, which is not a first-class type.
>
>
> FWIW since C99, _Bool *is* in fact a basic type, defined to have a 
> sizeof 1 and able to hold the values 0 and 1; additionally conversion 
> of any nonzero value from any type converts to 1 (this is opposed to, 
> say, float which would convert 0.5 to (int)1 but (_Bool)0).
>
> Are there really (or are there likely ever to be) execution models 
> that can reasonably support packed boolean arrays particularly?
>
> -- 
> - DML • he/him