On Wed, 13 Aug 2025 14:14:30 GMT, Per Minborg <pminb...@openjdk.org> wrote:
>> This PR proposes to use overlapping memory areas in >> `SegmentBulkOperations::copy`, similar to what is proposed for >> `SegmentBulkOperations::fill` in https://github.com/openjdk/jdk/pull/25383. >> >> This PR passes `tier1`, `tier2`, and `tier3`testing on multiple platforms. > > Per Minborg has updated the pull request incrementally with one additional > commit since the last revision: > > Break out the default branch There's a couple of caveats when it comes to FFM and memory model. As observed, a memory segment can wrap a Java array. Now, if access to the memory segment uses a layout that matches the array element/alignment, all the standard JMM guarantees apply. That said, once you have a segment wrapping, say a `long[]`, you can also do "partial reads/writes" -- e.g. you can only read parts of a `long` element. This is the "new" thing, and something for which we're considering adding some extra javadoc text: https://bugs.openjdk.org/browse/JDK-8357630 (We have some candidate text discussed with John Rose). The reverse can also happen -- e.g. if a segment wraps a `byte[]` it is possible to read multiple element at once, by e.g. reading an int layout. But this could already happen with the `ByteBuffer` API, so nothing new here. Of course mis-aligned access can result in more partial read/writes -- e.g. an unaligned 8 byte access can be implemented as two 4-byte partial accesses, or a 4 byte partial access, followed by 2 byte partial access, followed by two 1-byte partial accesses (or any other combination). What you get here is unspecified. All this said, I believe the question @eme64 is asking has more to do with `MemorySegment::copy` -- e.g. what kind of guarantees do we want to provide here? Should `copy` have the same semantics as a loop that moves bytes from one segment to another element-wise? If so, then we have a problem (as pointed out): the fact that the new implementation sometimes rewrites certain portions of the destination segments might create some semantics differences, esp. when it comes to visibility of updates in other threads. E.g. replacing a for loop with `MemorySegment::copy` might not always work as expected. IMHO this is up to the javadoc for `MemorySegment::copy` (and other related bulk operations) to decide. E.g. while it would be nice if we could just say that updating a segment with a bulk operation has exactly the same semantics as updating the segment with a loop, we might need to relax things if we want to let free rein to the implementation to do more smarts. And, in the specific context of this PR, we would have to weight as to whether adding the extra javadoc clarification (and subsequent additional user model complexity) is worth shaving half a nanosecond off the bulk copy. My general feeling is that the long term strategy here is to wait until we have better autovectorization support and/or vector API integrated, at which point we can replace all this with much more idiomatic code? (If so, then perhaps there isn't a lot of value in chasing smaller improvements in the interim?) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26672#issuecomment-3187850721
