On Thu, 19 Jun 2025 08:19:55 GMT, Per Minborg <pminb...@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

Reply via email to