Nikola has opened an issue to cover the loopback address range and we're preparing a patch:
https://bugs.openjdk.java.net/browse/JDK-8255264 We've identified some unit tests to include in the patch, does gtest/runtime/test_os_windows.cpp seem the appropriate location for them? Patch (preview): diff --git a/src/java.base/windows/native/libnet/net_util_md.h b/src/java.base/windows/native/libnet/net_util_md.h index b76935db3de..2f873b6295e 100644 --- a/src/java.base/windows/native/libnet/net_util_md.h +++ b/src/java.base/windows/native/libnet/net_util_md.h @@ -90,24 +90,30 @@ struct ipv6bind { /** * With dual socket implementation the * IPv4 addresseses might be mapped as IPv6. - * The IPv4 loopback adapter address will - * be mapped as the following IPv6 ::ffff:127.0.0.1. + * The IPv4 loopback adapter address ranges (127.0.0.0 through 127.255.255.255) will + * be mapped as the following IPv6 ::ffff:127.0.0.0 through ::ffff:127.255.255.255. * For example, this is done by NET_InetAddressToSockaddr. */ #define IN6_IS_ADDR_V4MAPPED_LOOPBACK(x) ( \ - (((x)->s6_words[0] == 0) && \ - ((x)->s6_words[1] == 0) && \ - ((x)->s6_words[2] == 0) && \ - ((x)->s6_words[3] == 0) && \ - ((x)->s6_words[4] == 0) && \ - ((x)->s6_words[5] == 0xFFFF) && \ - ((x)->s6_words[6] == 0x007F) && \ - ((x)->s6_words[7] == 0x0100)) \ + (((x)->s6_words[0] == 0) && \ + ((x)->s6_words[1] == 0) && \ + ((x)->s6_words[2] == 0) && \ + ((x)->s6_words[3] == 0) && \ + ((x)->s6_words[4] == 0) && \ + ((x)->s6_words[5] == 0xFFFF) && \ + (((x)->s6_words[6] & 0x00FF) == 0x007F)) \ +) + +/** + * Check for IPv4 loopback adapter address ranges (127.0.0.0 through 127.255.255.255) + */ +#define IN4_IS_ADDR_NETLONG_LOOPBACK(l) ( \ + ((l & 0xFF000000) == 0x7F000000) \ ) #define IS_LOOPBACK_ADDRESS(x) ( \ ((x)->sa.sa_family == AF_INET) ? \ - (ntohl((x)->sa4.sin_addr.s_addr) == INADDR_LOOPBACK) : \ + (IN4_IS_ADDR_NETLONG_LOOPBACK(ntohl((x)->sa4.sin_addr.s_addr))) : \ ((IN6_IS_ADDR_LOOPBACK(&(x)->sa6.sin6_addr)) || \ (IN6_IS_ADDR_V4MAPPED_LOOPBACK(&(x)->sa6.sin6_addr))) \ ) Cheers Mat ________________________________ From: net-dev <net-dev-r...@openjdk.java.net> on behalf of Nikola Grcevski <nikola.grcev...@microsoft.com> Sent: Thursday, August 6, 2020 7:37 AM To: Alan Bateman <alan.bate...@oracle.com>; net-dev@openjdk.java.net <net-dev@openjdk.java.net> Subject: RE: RFR(s): Improving performance of Windows socket connect on the loopback adapter Yes, please. Thank you, Nikola -----Original Message----- From: Alan Bateman <alan.bate...@oracle.com> Sent: August 6, 2020 9:49 AM To: Nikola Grcevski <nikola.grcev...@microsoft.com>; net-dev@openjdk.java.net Subject: Re: RFR(s): Improving performance of Windows socket connect on the loopback adapter On 04/08/2020 16:36, Nikola Grcevski wrote: > Hi Alan, > >> What cheap is VerifyVersionInfoW? The check is done everytime but the >> overhead might be in the noise. Overall it looks good to me. > I wrote a small benchmark to measure the overhead of the version check > (attached below). > > On my SurfaceBook 2 running Windows 10 Build 19041, the version check > measures about ~2.2us (micro seconds) on average, when the version matches. > > Elapsed time 2244us. (for 1,000 iterations) > > On a Windows 2016 Data Center Server the version check is much smaller > ~0.13us (micro seconds) on average, when the version doesn't match. > > Elapsed time 128us. (for 1,000 iterations) > > I think the overhead is reasonably small compared to everything else. Please > let me know if it's acceptable and if we can proceed. > > Okay. So do you me to sponsor this? -Alan
