RFR: 8296477: Foreign linker implementation update following JEP 434 [v4]

[Jorn Vernee]

On Tue, 15 Nov 2022 00:33:35 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>     * `VMStorage` looks very similar to `VMReg`. What's the purpose of the new representation?

`VMReg` encodes stack offsets in slots (of 32 bits), which is not enough to represent every call shape on macosx-aarch64. Byte offsets are needed. We also need some size information for that, e.g. to avoid a store of 1 byte to the stack from overwriting other things with a 64-bit write. `VMStorage` also has a channel for that: either a size in bytes, or a register mask (mask of used segments of a register) that can be used to indicate the size if needed. (`VMReg` sort of did that with `BasicType`, but we now erase every sub-int type to `int`, so that no longer works, and it always felt a bit wrong since we're really moving bits between registers, not typed Java values).

See also: https://github.com/openjdk/panama-foreign/pull/699

>     * why do you structure the header files the way you do? `vmstorage.inline.hpp`, `vmstorage_<cpu>.inline.hpp`, `vmstorageBase.inline.hpp` instead of just `vmstorage.hpp`/`vmstorage_<cpu>.hpp`

The CPU header depends on the definition of `VMStorage` to be complete, so I had that include the `vmstorageBase` header, and had the `vmstorage` header include the cpu header. But, looking now, it looks like I can also just include the CPU header at the end of the `vmstorageBase` file, and remove 1 header. I'll do that to make things simpler.

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

PR: https://git.openjdk.org/jdk/pull/11019