Unsafe boolean operations need to normalize off-heap values.
Specifically, when loading a T_BOOLEAN value via Unsafe.getBoolean, if the value can come from off-heap storage, the JVM should normalize the byte value from the range 0..255 to the range 0..1.
The code behind Unsafe.putBoolean (MemoryAccess::put in unsafe.cpp) takes a Java boolean and extracts the low-order bit from its representation, storing that as a byte in the range 0..1. (See MemoryAccess::normalize.)
There should be a corresponding normalize operation for booleans on load, at least in the case where the value might be off-heap. This is true if and only if the base address, sometimes called "obj", is NULL.
The normalize operation must be a no-op when applied to already-normalized values in the range 0..1.
Surprisingly, in the case of off-heap values, it should perform the JNI-specific test (x != 0), not just a bit extraction ((x & 1) != 0). The motivation for this is that off-heap values are subject to JNI rules, as described by JDK-8149170 (Better byte behavior for native arguments).
Luckily, this JNI-oriented normalization is a no-op after the JVM's (x&1) operation. This means it is harmless to apply the JNI normalization to JVM-stored values, and useful to apply it to values possibly stored by C code.
Specifically, when loading a T_BOOLEAN value via Unsafe.getBoolean, if the value can come from off-heap storage, the JVM should normalize the byte value from the range 0..255 to the range 0..1.
The code behind Unsafe.putBoolean (MemoryAccess::put in unsafe.cpp) takes a Java boolean and extracts the low-order bit from its representation, storing that as a byte in the range 0..1. (See MemoryAccess::normalize.)
There should be a corresponding normalize operation for booleans on load, at least in the case where the value might be off-heap. This is true if and only if the base address, sometimes called "obj", is NULL.
The normalize operation must be a no-op when applied to already-normalized values in the range 0..1.
Surprisingly, in the case of off-heap values, it should perform the JNI-specific test (x != 0), not just a bit extraction ((x & 1) != 0). The motivation for this is that off-heap values are subject to JNI rules, as described by JDK-8149170 (Better byte behavior for native arguments).
Luckily, this JNI-oriented normalization is a no-op after the JVM's (x&1) operation. This means it is harmless to apply the JNI normalization to JVM-stored values, and useful to apply it to values possibly stored by C code.