N6_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.
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
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
Sent: July 31, 2020 1:29 PM
To: Nikola Grcevski ; net-dev@openjdk.java.net
Subject: Re: RFR(s): Improving performance of Windows socket connect on the
loopback adapter
On 28/07/2020 15:03, Nikola Grcevski wrote:
> Hi Alan,
>
> Thanks again for testing this change. I dug deep into th
On 28/07/2020 15:03, Nikola Grcevski wrote:
Hi Alan,
Thanks again for testing this change. I dug deep into the issue yesterday and
got some answers from the Windows Networking team.
The issue is that the flag TCP_INITIAL_RTO_NO_SYN_RETRANSMISSIONS, which we
passed in to completely eliminat
elper. I attempted to use IsWindowsVersionOrGreater, but unfortunately that
API doesn't allow me to specify the build number to detect RS3.
Thanks,
Nikola
-Original Message-
From: Alan Bateman
Sent: July 26, 2020 6:45 AM
To: Nikola Grcevski ; net-dev@openjdk.java.net
Subject: Re: RFR(s): Im
me more testing tomorrow on my end.
Thanks again,
Nikola
-Original Message-
From: Alan Bateman
Sent: July 26, 2020 6:45 AM
To: Nikola Grcevski ; net-dev@openjdk.java.net
Subject: Re: RFR(s): Improving performance of Windows socket connect on the
loopback adapter
On 24/07/2020 16:20,
On 24/07/2020 16:20, Nikola Grcevski wrote:
Thanks Alan, yes I'll need a sponsor for the patch.
I tried the patch in our CI and test/jdk/java/net/Socket/Timeouts.java
is consistently failing on Windows Server 2016 systems, specifically
testTimedConnect2 which expects a "connection refused" wi
ssage-
From: Alan Bateman
Sent: July 24, 2020 6:33 AM
To: Nikola Grcevski ; net-dev@openjdk.java.net
Subject: Re: RFR(s): Improving performance of Windows socket connect on the
loopback adapter
On 23/07/2020 14:06, Nikola Grcevski wrote:
> That's a great idea Alan. If we are OK to merg
On 23/07/2020 14:06, Nikola Grcevski wrote:
That's a great idea Alan. If we are OK to merge this improvement with support
for 127.0.0.1 only,
I'll follow up with another patch for the full range of the loopback adapter
and some tests
for the macro in all 3 modes.
Yes, that approach is okay. Do
Sent: July 23, 2020 4:59 AM
To: Nikola Grcevski ; Alex Menkov
; net-dev@openjdk.java.net
Subject: Re: RFR(s): Improving performance of Windows socket connect on the
loopback adapter
On 23/07/2020 02:52, Nikola Grcevski wrote:
> Hi Alex,
>
> Yes, you are right about that. I didn'
On 23/07/2020 02:52, Nikola Grcevski wrote:
Hi Alex,
Yes, you are right about that. I didn't think about extending the check to more
than 127.0.0.1.
The existing macro was only testing for 127.0.0.1 in both IP4 and IP6 modes, so
if the consensus
is that we want to extend to all of the poss
evski ; Alan Bateman
; net-dev@openjdk.java.net
Subject: Re: RFR(s): Improving performance of Windows socket connect on the
loopback adapter
Hi Nikola,
One note.
src\java.base\windows\native\libnet\net_util_md.h
IN6_IS_ADDR_V4MAPPED_LOOPBACK considers only 127.0.0.1 as loopback address, but
need a
sponsor to get this change merged.
Best,
Nikola
-Original Message-
From: Alan Bateman
Sent: July 21, 2020 11:19 AM
To: Nikola Grcevski ; net-dev@openjdk.java.net
Subject: Re: RFR(s): Improving performance of Windows socket connect on the
loopback adapter
On 21/07/2020 02:34,
sponsor to get this change merged.
Best,
Nikola
-Original Message-
From: Alan Bateman
Sent: July 21, 2020 11:19 AM
To: Nikola Grcevski ; net-dev@openjdk.java.net
Subject: Re: RFR(s): Improving performance of Windows socket connect on the
loopback adapter
On 21/07/2020 02:34, Nikol
On 21/07/2020 02:34, Nikola Grcevski wrote:
Hi Alan and Bernd,
Thanks again for the code review of my changes and the suggestions!
Please find the updated webrev here:
http://cr.openjdk.java.net/~adityam/nikola/fast_connect_loopback_2/
I decided to explicitly check so_rv for success consis
27;ll update
accordingly.
Best,
Nikola
-Original Message-
From: Alan Bateman
Sent: July 19, 2020 2:52 AM
To: Bernd Eckenfels ; Nikola Grcevski
; net-dev@openjdk.java.net
Subject: Re: RFR(s): Improving performance of Windows socket connect on the
loopback adapter
On 18/07/2020 18:43,
On 18/07/2020 18:43, Bernd Eckenfels wrote:
Hello,
I am unsure about the signatures, s is of type SOCKET, why not keep
this — I think I missed why this would be a JNICALL convention.
There are two inconsistencies:
The header file and implementation uses (int) argument, the call casts
to (ji
RFR(s): Improving performance of Windows socket connect on the
loopback adapter
On 17/07/2020 02:10, Nikola Grcevski wrote:
> Thanks for reviewing the patch Alan.
>
> I applied your suggestions in this new webrev here:
>
> http://cr.openjdk.java.net/~adityam/nikola/fast_conne
On 17/07/2020 02:10, Nikola Grcevski wrote:
Thanks for reviewing the patch Alan.
I applied your suggestions in this new webrev here:
http://cr.openjdk.java.net/~adityam/nikola/fast_connect_loopback_1/
I renamed the macro to IN6_IS_ADDR_MAPPED_IP4_LOOPBACK, following how
IN6_IS_ADDR_ANY
is nam
--Original Message-
From: Alan Bateman
Sent: July 16, 2020 4:47 AM
To: Nikola Grcevski ; net-dev@openjdk.java.net
Subject: Re: RFR(s): Improving performance of Windows socket connect on the
loopback adapter
On 16/07/2020 01:02, Nikola Grcevski wrote:
> :
>
> Please find the webrev wi
t: Re: RFR(s): Improving performance of Windows socket connect on the
loopback adapter
On 16/07/2020 05:37, Bernd Eckenfels wrote:
Hello Nikola,
Can you explain why timeouts play a role here at all? Normally when connecting
to a non existing socket it should immediately respond with a TCP RST and
On 16/07/2020 01:02, Nikola Grcevski wrote:
:
Please find the webrev with this improvement here:
http://cr.openjdk.java.net/~adityam/nikola/fast_connect_loopback/
Just a few comments on the first iteration.
Can we move the function prototype to the Windows net_util_md.h? That
would avoid ne
On 16/07/2020 05:37, Bernd Eckenfels wrote:
Hello Nikola,
Can you explain why timeouts play a role here at all? Normally when
connecting to a non existing socket it should immediately respond with
a TCP RST and that should not cause a retry or delay.
Nikola mentioned that he is in contact wi
, that not only the loopback is affected.
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: net-dev im Auftrag von Nikola Grcevski
Gesendet: Thursday, July 16, 2020 2:02:52 AM
An: net-dev@openjdk.java.net
Betreff: RFR(s): Improving performance of Windows socket
Hello net-dev,
During a recent performance investigation of Gradle/Kotlin build daemon
discovery, we found that Windows socket connect on a non-existent service is
taking a lot longer than on Linux and MacOS. The socket timeout and retransmit
defaults on Windows are quite long and it typically
26 matches
Mail list logo
