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 :::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 :::127.0.0.0 through
:::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] == 0x) && \
- ((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] == 0x) && \
+ (((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 & 0xFF00) == 0x7F00) \
)
#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 on behalf of Nikola Grcevski
Sent: Thursday, August 6, 2020 7:37 AM
To: Alan Bateman ; 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
Sent: August 6, 2020 9:49 AM
To: Nikola Grcevski ; 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
