On Tue, 30 Jun 2026 16:01:39 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). > > src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template > line 427: > >> 425: SegmentVarHandle handle = (SegmentVarHandle)ob; >> 426: AbstractMemorySegmentImpl bb = handle.checkSegment(obb, base, >> false); >> 427: #if[!byte] > > I went through these to check if something needed to be changed, but these > accessors are not supported for `byte` in the first place (everything in the > `#if[AtomicAdd]` and `#if[BitWise]` blocks), i.e. `#if[byte]` is never true > here, so I've gone ahead and cleaned up these redundant ifs. Yeah, I think it was local reasoning: "bytes do not care about endianness". So it looks future-proofing for the case if we get `byte` flavors for these at some point. Leave it in, if it does not block the fix? It will remove most of the hunks in this patch, AFAICS, simplifying it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31727#discussion_r3520591621
