[foreign-memaccess+abi] RFR: 8274157: java.foreign: Add method MemorySegment::isOverlapping

[Maurizio Cimadamore]

On Tue, 28 Sep 2021 23:32:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> If you are reluctant to return actual addresses, you could return the 4 values as relative offsets where either A_lo == 0, or B_lo == 0, or A_lo == B_lo == 0.
>>> 
>>> I thought I saw in one of your refactorings where you eliminated both MemoryAccess and MemoryCopy, a new general purpose copy(seg A, LayoutA, offsetA, seg B, LayoutB, offsetB, length) or something like that (I can't find it at this moment). If the layouts can describe repeating elements of any size, doesn't this solve the copy problem and possibly eliminate the need for the isOverlapping() method?
>> 
>> The MemorySegment::copy you are referring to takes a pair of ValueLayouts, which cannot be arbitrarily big. In fact, not even the underlying `Unsafe.copyMemorySwap` can work with arbitrary element sizes.
>> 
>> That said, I'm still trying to understand what exactly you want to do; if you want to copy elements of N bytes from a slice to another - why isn't copying bytes enough (since the bulk copy already can deal with overlapping addresses)? Do you want to "swap" entire structs as part of the copy (that would be inefficient!).
>
> Reading from older emails - I'm starting to have doubts about whether the overlap predicate in this PR does anything for you. You want to protect against the case whether two segments are mapping of _the same file_, but in different address spaces. So there might not even be an address overlap. This is what the spec is calling out, I think: since there's no address overlap, Unsafe doesn't know how to protect against that. But that is a much lower level kind of overlap, which has nothing to do with the one provided here - do you agree? If the address space is the same - e.g. plain segments allocated with `malloc`, what bulk copy does is already enough.

Ok, I guess I now figured out what you mean; you basically want to implement something that has same correctness guarantees as `System.arraycopy` which works on _arbitrary_ element sizes, not just 8/16/32/64 byte sizes. The copy method we have is good (in the sense that you can also copy by bytes, or by int/long words), but if you also need multi-bit swap (where multi > 64) then you are out of luck (but I'm curious about this use case of extreme swappiness :-) ).

It is possible, in the future, that with the help of the vector API, we might be able to indeed lift the restriction, and provide a bulk copy (written in Java :-) ) which works on elements bigger than 64 bits. In the meantime, we have two options:

* you "take the hit" when dealing with element sizes > 64bit (meaning in these case you will need extra buffer)
* we provide enough primitives which allow you (or others) to implement other copy routines which support similar guarantees as `System.arraycopy`

Another issue: note that the `MemoryAddress::segmentOffset` has also gone in the API refresh, and I believe your plan was probably to rely on it to do the computations; we could add it back if that was really an issue. Or we could come up with similar methods which work on segments instead (e.g. return the start/end offset of a segment into another segment - which combined with an overlapping slice region would probably do what you need to do).

I don't know how common this issue is in your API, so I can't judge. The general feeling I get is that an overlapping predicate without some other ways to compute offsets between slices is not very useful - and so, in that case it would be better to do nothing.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/585