RFR: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs

[Darragh Clarke]

On Thu, 19 Jun 2025 08:19:55 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR aims to Panamize the Java Kqueue implementation, This is based on the work that was previously shared in https://github.com/openjdk/jdk/pull/22307 , The main change since then is that this branch takes advantage of the changes made in https://github.com/openjdk/jdk/pull/25043 to allow for better performance during errno handling.
>> 
>> These changes feature a lot of Jextract generated files, though alterations have been made in relation to Errno handling and performance improvements.
>> 
>> I will update this description soon to include performance metrics on a few microbenchmarks, though currently it's roughly 2% to 3% slower with the changes, which is somewhat expected, though there are still a few ideas of possible performance improvements that could be tried. Any suggestions or comments in that area are more than welcome however.
>
> src/java.base/macosx/classes/jdk/internal/ffi/generated/BindingUtils.java line 45:
> 
>> 43:     public static final AddressLayout C_POINTER = ValueLayout.ADDRESS
>> 44:             .withTargetLayout(MemoryLayout.sequenceLayout(Long.MAX_VALUE, JAVA_BYTE));
>> 45:     public static final ValueLayout.OfLong C_LONG = ValueLayout.JAVA_LONG;
> 
> This is `int` on Windows. So, we could perhaps use `Linker.nativeLinker().canonicalLayouts().get("long")` here? "size_t" and "wchar_t" are other canonical layouts that may differ across platforms.

I think this is a good idea and would allow us to make BindingUtils shared,
Though I wonder if it's best to move BindingUtils to be shared, or if its worth merging it into FFMUtils. I'd favour the second option

> src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kqueue_h.java line 263:
> 
>> 261:         var adapted$ = kevent64.ADAPTED;
>> 262:         try {
>> 263:             if (FFMUtils.TRACE_DOWNCALLS) {
> 
> I wonder what the price of this `if` branch might be (if any)? The javac compiler probably sees the 
> 
> `public static final boolean TRACE_DOWNCALLS = false;` as constant foldable and can eliminate the code at compile time.

I think that's a good question, I can do some testing with it removed to see if theres any gain to be had

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2159147090
PR Review Comment: https://git.openjdk.org/jdk/pull/25546#discussion_r2140347487