[foreign-memaccess+abi] RFR: 8295265: Refactor handling of special values passed to stubs [v2]

[Maurizio Cimadamore]

On Thu, 13 Oct 2022 12:30:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch refactors the handling of special values passed between stubs and Java code, such as the target address and the return buffer address.
>> 
>> Currently the Java code determines some registers that these values are stored in. This refactor changes that to use placeholders, and lets the stub generation code fill in the actual locations. This allows more special values (such as locations to store preserved thread locals), as well as storing things to a location in the frame, as opposed to a register.
>> 
>> To do this, this patch adds a Java enum and C++ helper class called StubLocations, which gives each special value an index (ordinal). The C++ helper class also has an array which maps this index to the actual location the stub gen code decides to use. This location is then used in shuffling code.
>> 
>> Instead of the ABIDescriptor being used to determine a register for the target address and return buffer address, it now has 2 scratch registers, which don't conflict with arguments being passed. They can be used by the stub gen code.
>> 
>> The patch also contains a minor renaming of a boolean value being used. I've also renamed StorageClasses, and RegType in Java and C++ code respectively to StorageType, to align the 2, since they also need to be kept in sync. The latter is responsible for a lot of changes in this patch.
>> 
>> The stub gen code now also has a special FRAME_DATA storage type, which is used to indicate locations in the stub frame. This is for instance used to store the return buffer address.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stubs on other platforms

The Java code and test changes look good. I eyeballed the VM changes, which seems ok - e.g. they seem to add an extra degree of freedom/indirection where certain locations are "virtualized", so each ABI can decide how to model them using scratch registers or something else. It obviously seems a bit convoluted for now, but reading the description in JDK-8295265 helps a bit understanding why this was needed, and where this is going.

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

Marked as reviewed by mcimadamore (Committer).

PR: https://git.openjdk.org/panama-foreign/pull/740