RFR: 8347408: Create an internal method handle adapter for system calls with errno [v6]

[Maurizio Cimadamore]

On Mon, 13 Jan 2025 10:11:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Going forward, converting older JDK code to use the relatively new FFM API requires system calls that can provide `errno` and the likes to explicitly allocate a MemorySegment to capture potential error states. This can lead to negative performance implications if not designed carefully and also introduces unnecessary code complexity.
>> 
>> Hence, this PR proposes to add a _JDK internal_ method handle adapter that can be used to handle system calls with `errno`, `GetLastError`, and `WSAGetLastError`.
>> 
>> It currently relies on a thread-local cache of MemorySegments to allide allocations. If, in the future, a more efficient thread-associated allocation scheme becomes available, we could easily migrate to that one.
>> 
>> Here are some benchmarks:
>> 
>> 
>> Benchmark                              Mode  Cnt   Score   Error  Units
>> CaptureStateUtilBench.explicitFail     avgt   30  42.061 ? 1.261  ns/op
>> CaptureStateUtilBench.explicitSuccess  avgt   30  23.142 ? 0.739  ns/op
>> CaptureStateUtilBench.tlFail           avgt   30  23.580 ? 0.267  ns/op
>> CaptureStateUtilBench.tlSuccess        avgt   30   1.753 ? 0.016  ns/op
>> 
>> 
>> Explicit allocation:
>> 
>>         try (var arena = Arena.ofConfined()) {
>>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>>         }
>> 
>> 
>> Thread Local (tl):
>> 
>>         return (int) ADAPTED_HANDLE.invoke(arena.allocate(4), 0, 0);
>> 
>> 
>> The graph below shows the difference in latency for a successful call:
>> 
>> ![image](https://github.com/user-attachments/assets/3cf122bb-0ed6-4dd6-ab6d-dcada0147efb)
>> 
>> This is a >10x improvement on the happy path.
>> 
>> 
>> Tested and passed tiers 1-3.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Clean up benchmark
>  - Fix allocation problem in benchmark

src/java.base/share/classes/jdk/internal/foreign/CaptureStateUtil.java line 214:

> 212:     // Used reflectively by `getAsIntHandle(MemoryLayout layout)`
> 213:     private static int getStateAsInt(VarHandle handle) {
> 214:         if (Thread.currentThread().isVirtual() && ContinuationSupport.isSupported()) {

Shouldn't we pin for the entire duration of the native call + errno retrieval? Otherwise, can't we end up in a situation where we have a back to back native call where the second native call overwrites the errno state of the first?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1913019319