[foreign-memaccess+abi] RFR: 8287516: Implement fallback Linker [v5]

[Maurizio Cimadamore]

On Thu, 19 Jan 2023 22:06:59 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Implement a [libffi](https://github.com/libffi/libffi) based fallback linker. The fallback linker comes with a native library that can be included in the jdk by configuring with `--enable-fallback-linker`. This requires the libffi library to be available as well. On the zero VM configuration the fallback linker is enabled by default.
>> 
>> CABI is refactored a bit. It now supports explicitly setting the CABI using the `jdk.internal.foreign.CABI` system property (which is very handy for testing). Instead of falling back to `null` when the platform is not supported, we instead fall back to checking if the fallback library is supported (`FALLBACK`), and if not, default to the new `UNSUPPORTED` enum constant, which is then mapped to an `UnsupportedOperationException` in the Linker::nativeLinker implementation.
>> 
>> Checking whether the a full port of the foreign linker is available is done through the new jdk.internal.vm.ForeignLinkerSupport class. This follows the precedent set by Loom's jdk.internal.vm.ContinuationSupport class. The implementation simply returns `true` on platforms where we have a port.
>> 
>> The system lookup is changed to be selected based on the platform, rather than CABI. This allows selecting the right library implementation when running on a zero VM configuration as well. The split is now just between Windows and non-Windows platforms.
>> 
>> Finally, I had to slightly modify `globalDefinitions_zero.hpp` to conditionally define `FFI_GO_CLOSURES`, since I was getting a redefinition error using GCC. The macro is also defined in `ffitarget.h` which is included by `ffi.h`. The define in globalDefinitions comes from this PR: https://github.com/openjdk/jdk/pull/8195 which indicates that the define is only needed on Mac Os X. So I switched out the guard to check for `__APPLE__` instead. (the check whether it is already defined doesn't really do anything, since `FFI_GO_CLOSURES` is defined by including `ffi.h`).
>> 
>> The Java implementation is found in the `jdk.internal.foreign.abi.fallback` package, and consists of the following classes:
>> - `FallbackLinker`. The main entry point, an instance of `Linker`. Contains the code for arranging and executing calls.
>> - `LibFallback`. A thin wrapper around the native `libfallback` library found in the java.base module, which acts as an interface to the libffi library.
>> - `FFIType`. Contains code for creating native `ffi_type` struct instances from memory layouts.
>> - The `TypeClass`, `FFIStatus`, and `FFIABI` supporting enums, which should be pretty self-explanatory.
>> 
>> I've ran the `jdk_foreign` tests in the following configurations:
>> - Windows.
>> - Linux with the fallback linker lib included, but not used.
>> - Linux with fallback linker and running with `-Djdk.internal.foreign.CABI=FALLBACK` (this uses the fallback implementation).
>> - Linux zero VM (uses `FALLBACK` as CABI by default, because we don't have a port for `zero`).
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add note about dependencies

src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FFIType.java line 129:

> 127:         try (Arena verifyArena = Arena.openConfined()) {
> 128:             MemorySegment offsetsOut = verifyArena.allocate(SIZE_T.byteSize() * filteredLayouts.size());
> 129:             LibFallback.getStructOffsets(structType, offsetsOut, abi);

Maybe I'm being paranoid, but libFFI has its own way to determine a struct layout given the struct fields, based on what the ABI types are. But the Panama layout API is more expressive than that, and it allows, theoretically, to pass arguments that have stricter or larger alignment constraints - which can end up in more or less padding being inserted (from clients), and in different struct layout sizes.

So, my question is: should we double check that what we get back from libFFI is actually compatible with what we have in the group layout before proceeding?

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

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