On Tue, 15 Nov 2022 00:33:35 GMT, Vladimir Ivanov <vliva...@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
