Hi Alan, I agree that NetworkInterface would probably benefit from FFM, but FFM isn’t finalized yet. So is it even okay to use FFM in a proposed patch?
More importantly, rewriting NetworkInterface to use FFM would require touching every platform, and I don’t have good ways to test anything other than Windows and Linux. That would also be a much larger effort that I’m not sure I have time for right now. Still, I think there could be some benefit in overhauling the existing JNI code, without touching anything on the Java side. At a minimum, it would make the native code a lot easier to port to FFM at some later date. [Logo Description automatically generated]<http://www.scientificgames.com/> Rich DiCroce Senior Advanced Solutions Architect Scientific Games HAVE FUN. DO GOOD. PLAY HEALTHY. May be privileged. May be confidential. Please delete if not the addressee. From: Alan Bateman <alan.bate...@oracle.com> Sent: Tuesday, February 7, 2023 3:23 PM To: DiCroce, Richard <rich.dicr...@scientificgames.com>; net-dev@openjdk.org Subject: Re: Performance of NetworkInterface methods on Windows WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. On 07/02/2023 20:06, DiCroce, Richard wrote: : I’d also like to get your thoughts on a possible second patch that would be more extensive and might contain some functional changes. The current code is a little messy and uses some ancient APIs. Some initial experiments suggest that newer APIs (available since Vista/Server 2008) would be faster. The current code also invents its own interface naming scheme. Windows now has APIs for that (e.g. ConvertInterfaceLuidToNameW), but switching to those would obviously mean that getName() would return a different value than it does today. getByName() would also need to be adjusted, but I could code it such that it tries the Windows APIs first and then falls back to the existing code, in order to minimize breakage. So, given those caveats, do you think such a patch would have any chance of being accepted? Or would any breaking changes be a no-go? I think it would be good to use the Windows interface names. The reason for the netNNN names is that there wasn't any Win32 APIs to get interface names when this code was originally written for JDK 1.4. It should have been re-visited a long time ago. That said, I think NetworkInterface is a good candidate to re-implement completely in Java using the Panama FFM API so that the existing JNI code can go away. As always, the main issues are getting Reviewer cycles and testing to make sure that there aren't any regressions in unusual configurations. So I think start with the performance improvement at least. -Alan
