On Tue, 7 Jul 2026 16:11:12 GMT, Jorn Vernee <[email protected]> wrote:
>> Unsafe was changed recently through: >> https://github.com/openjdk/jdk/pull/31249 to no longer treat any non-zero >> byte read as a `boolean` through Unsafe as `true`, but only treat the >> 'canonical' representation, where only the least significant bit in the byte >> is set, as `true`. >> >> This change inadvertently leaked out through the memory access var handles. >> A user can write a `byte` into a memory segment (on or off-heap), and then >> read it back as a `boolean`, making this behavior change observable. Since >> the fallback linker depends on the previous behavior in the implementation, >> the tier5 test from the title was failing. But, there is really a gap in >> testing here, and we can observe the difference in behavior when just using >> the memory access parts of the API as well. >> >> It is important that the normalization of boolean values is the same in all >> these scenarios: >> - Normalizing a value returned from native code by a downcall >> - Normalizing an argument passed by native code to an upcall stub >> - Normalizing a value read from a memory segment using a var handle or the >> MemorySegment::get accessor >> >> To that end, this patch tweaks the memory segment var handles for boolean >> access to restore the old normalization behavior. I've also added the >> missing testing for this case. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Jorn Vernee has updated the pull request incrementally with two additional > commits since the last revision: > > - Review comments > - Undo byte if blocks This looks reasonable to me. Let me run it through our audit pipelines. make/modules/java.base/gensrc/GensrcVarHandles.gmk line 114: > 112: endif > 113: ifneq ($$(filter boolean byte, $1),) > 114: $1_KEYS += ByteOrBoolean Ah. So `byte` _did_ mean `ByteOrBoolean`! Now it is cleaner. ------------- PR Review: https://git.openjdk.org/jdk/pull/31727#pullrequestreview-4647024288 PR Review Comment: https://git.openjdk.org/jdk/pull/31727#discussion_r3538059386
