RFR: 8347408: Create an internal method handle adapter for system calls with errno [v8]
ExE Boss
duke at openjdk.org
Tue Jan 14 21:38:47 UTC 2025
On Tue, 14 Jan 2025 15:59:42 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:
>>
>> 
>>
>> This is a >10x improvement on the happy path.
>>
>>
>> Tested and passed tiers 1-3.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>
> Wip
src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4617:
> 4615: * {@code newType.parameterCount()}, and call {@code #O} the number
> 4616: * of outgoing parameters (the value {@code target.type().parameterCount()}).
> 4617: * Then the length of the reordering array must be {@code #O },
Suggestion:
* Then the length of the reordering array must be {@code #O},
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/22391#discussion_r1915629373
More information about the core-libs-dev
mailing list