On Thu, 13 Mar 2025 15:21:33 GMT, Per Minborg <pminb...@openjdk.org> wrote:

>> As we advance, 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 adding a JDK internal method handle adapter that can 
>> be used to handle system calls with `errno`, `GetLastError`, and 
>> `WSAGetLastError`.
>> 
>> It relies on an efficient carrier-thread-local cache of memory regions to 
>> allide allocations.
>> 
>> 
>> Here are some benchmarks that ran on a platform thread and virtual threads 
>> respectively (M1 Mac):
>> 
>> 
>> Benchmark                                                  Mode  Cnt   Score 
>>   Error  Units
>> CaptureStateUtilBench.OfVirtual.adaptedSysCallFail         avgt   30  24.330 
>> ? 0.820  ns/op
>> CaptureStateUtilBench.OfVirtual.adaptedSysCallSuccess      avgt   30   8.257 
>> ? 0.117  ns/op
>> CaptureStateUtilBench.OfVirtual.explicitAllocationFail     avgt   30  41.415 
>> ? 1.013  ns/op
>> CaptureStateUtilBench.OfVirtual.explicitAllocationSuccess  avgt   30  21.720 
>> ? 0.463  ns/op
>> CaptureStateUtilBench.OfVirtual.tlAllocationFail           avgt   30  23.636 
>> ? 0.182  ns/op
>> CaptureStateUtilBench.OfVirtual.tlAllocationSuccess        avgt   30   8.234 
>> ? 0.156  ns/op
>> CaptureStateUtilBench.adaptedSysCallFail                   avgt   30  23.918 
>> ? 0.487  ns/op
>> CaptureStateUtilBench.adaptedSysCallSuccess                avgt   30   4.946 
>> ? 0.089  ns/op
>> CaptureStateUtilBench.explicitAllocationFail               avgt   30  42.280 
>> ? 1.128  ns/op
>> CaptureStateUtilBench.explicitAllocationSuccess            avgt   30  21.809 
>> ? 0.413  ns/op
>> CaptureStateUtilBench.tlAllocationFail                     avgt   30  24.422 
>> ? 0.673  ns/op
>> CaptureStateUtilBench.tlAllocationSuccess                  avgt   30   5.182 
>> ? 0.152  ns/op
>> 
>> 
>> Adapted system call:
>> 
>>         return (int) ADAPTED_HANDLE.invoke(0, 0); // Uses a MH-internal pool
>> ```        
>> Explicit allocation:
>> 
>>         try (var arena = Arena.ofConfined()) {
>>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0);
>>         }
>> ```        
>> Thread Local allocation:
>> 
>>         try (var arena = POOLS.take()) {
>>             return (int) HANDLE.invoke(arena.allocate(4), 0, 0); // Uses a 
>> manually specified pool
>>         }
>> ```        
>> The adapted system call exhibits a ~4x performance improvement ove...
>
> Per Minborg has updated the pull request with a new target base due to a 
> merge or a rebase. The pull request now contains 34 commits:
> 
>  - Merge master
>  - Add test for woven allocation
>  - Merge branch 'master' into errno-util3
>  - Use lazy initialization of method handles
>  - Clean up visibility
>  - Merge branch 'master' into errno-util3
>  - Add @ForceInline annotations
>  - Add out of order test for VTs
>  - Allow memory reuse for several arenas
>  - Remove file
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/4e51a8c9...6d782a84

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

> 63:     //   returnType in {int.class | long.class}
> 64:     //   stateName can be anything non-null but should be in 
> {"GetLastError" | "WSAGetLastError"} | "errno")}
> 65:     private record BasicKey(Class<?> returnType, String stateName) {

Please at least add an `hashCode` - this avoids a hefty overhead from code 
generation in ObjectMethods.bootstrap, unavoidable whenever we put entries into 
a hash map.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23765#discussion_r2056408940

Reply via email to