[foreign-memaccess+abi] RFR: 8291639: Improve the ability to visualize a MemorySegment in human readable forms [v3]

[Maurizio Cimadamore]

On Fri, 26 May 2023 17:05:22 GMT, Glavo <duke at openjdk.org> wrote:

> Maybe my thinking is too idealistic. My thought is that in theory the JIT compiler also understands the calling convention, so it can optimize in conjunction with scalar replacement (or Valhalla), use registers to pass parameters and accept return values ​​as much as possible, so that the call cost is close to native.

Heh - believe me, I get where you are coming from. But my feeling is that what you are thinking about a world where instances of value classes are "flat" and have a layout which overlaps exactly with the layout of their corresponding struct in C. This is **not** the case, at least to date, with value types. E.g. the JVM will reserve the right of insert extra padding, align fields, pretty much in every way it wants. So there's no guarantee that a record (even if a value record) is going to be "bulk-copy compatible" with a memory segment.

What Valhalla is experimenting with, in the context of the vector API [1] is an approach by which some "selected" carriers within the JDK will be known to the VM to have a layout that is "bulk-copy compatible". For such carrier types, we might be able to support multi-byte reads and writes (e.g. using vector operations) and Unsafe might well provide support for such a thing. But these types will be only usable by the JDK - user-defined value types will not, in general, obey the same properties, and will not provide enough guarantees to the FFM API.

What Valhalla might provide is:
* better Java carriers for e.g. Long128 (and also vector types) - this is useful, as some C types are bigger than 64 bits
* proper ways to express types such as Complex<T> and Unsigned<T>
* a much more lightweight way to map structs to segment wrappers (e.g. a value class which wraps a segment with getters/setters)

All these things are all "pieces of the puzzle" to define native interop that is both efficient and easy to use for developers. But we would like to get there in a layered fashion. Memory segments seem to provide the "lingua franca" that allows the linker to go about its business. Once we have all these other useful (and cheap!) types at our disposal, surely jextract can use a combination of tactics to make its bindings more user-friendly. And, if some of the jextract idioms sediments and seems useful enough, it would certainly be possible to capture it at the level of the FFM API itself, as something that sits immediately on top of Linker.

[1] - https://github.com/openjdk/valhalla/pull/790

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

PR Comment: https://git.openjdk.org/panama-foreign/pull/833#issuecomment-1564705169