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

[Maurizio Cimadamore]

On Fri, 26 May 2023 18:38:48 GMT, Glavo <duke at openjdk.org> wrote:

> So, what I hope to do is not treat the struct value as a record **object**, but rather treat the struct value as a record **variable**.

I have no problem believing that a simple record such as point can scalarize well, and that access to components can be fast. But again, a struct can contain other structs, unions and arrays. And once you pull that stuff in, I think the kind of optimizations you have in mind don't scale that well. As I said, in case of a struct bigger than 64 or 128, most ABIs will just want to copy all its bytes onto the stack (or on a combination on registers and stack). Now, if I have a segment that is easy to do. If you have a record that means pulling every single record components, recursively (chasing arrays and records in records). There's lots of indirections to follow in order to be able to "put back" all the bytes that needs to be copied. I don't think something like this is likely to scale in the general case.

So, while "returning a record" might provide acceptable performance, in the case where everything is inlined and the all the components are scalarized (and maybe the JIT figures out you are only going to use a couple out of the many ones you have). But if there's no inlining, scalarization, things will become a lot worse than just wrapping in a memory segment.
As for "passing a record", there's no smart speculation possible, since we have to copy all the record components in places dictated by the ABI - meaning we have to read everything (and follow the indirections and take the memory hits).

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

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