RE: Backporting the TCP loopback fast path (Windows) improvement to OpenJDK v7

2015-01-26 Thread Valery Kopylov (Akvelon) 
Sean,

Thank you for your changes! However, instead of checking for WSAEINVAL we 
propose to check for Windows version.
There are two potential issues our approach helps to avoid:

1.   On Win8 the only error code WSAEOPNOTSUPP means that loopback can't be 
set. All other errors should throw an exception.

2.   Since Windows 7 returns WSAEOPNOTSUPP and WinXP returns WSAEINVAL, we 
can't be completely sure that all older versions that use jdk7 return one of 
these two codes.

Please find a patch with implemented Windows version check in attachment.
Are such changes suitable for you?


Best regards,
Valeriy Kopylov,
Software Engineer,
Akvelon,
Skype: Valeriy.Kopylov

From: Martin Sawicki (MS OPEN TECH)
Sent: Saturday, January 24, 2015 03:21
To: Seán Coffey; Valery Kopylov (Akvelon); jdk7u-...@openjdk.java.net
Cc: Kirk Shoop (MS OPEN TECH); OpenJDK Network Dev list
Subject: RE: Backporting the TCP loopback fast path (Windows) improvement to 
OpenJDK v7

Sorry about the delay. Valeryi has prepared a patch - he'll be responding soon.

From: Seán Coffey [mailto:sean.cof...@oracle.com]
Sent: Friday, January 23, 2015 5:55 AM
To: Valery Kopylov (Akvelon); Martin Sawicki (MS OPEN TECH); 
jdk7u-...@openjdk.java.net
Cc: Kirk Shoop (MS OPEN TECH); OpenJDK Network Dev list
Subject: Re: Backporting the TCP loopback fast path (Windows) improvement to 
OpenJDK v7

Valeriy,

I didn't see a follow up on this. I've modified the patch so that we cater for 
a possible WSAEINVAL error to be returned from the NET_EnableFastTcpLoopback 
call. Latest webrev :
http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u.v2/webrev/

changes only in 
http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u.v2/webrev/src/windows/native/sun/nio/ch/Net.c.cdiff.html

Good to push ? I'll try and get this into 7u80 but can't guarantee that now 
given that we've entered the rampdown/stabilization phase.

regards,
Sean.
On 15/01/15 12:09, Seán Coffey wrote:
Valeriy,

I used the jdk7u patch that was attached to the mail request. It applied 
cleanly. I've posted webrev here for reference (patch there also):
http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u/webrev/

The new WSAIoctl call would appear to be failing with WSAEINVAL. The 
NET_EnableFastTcpLoopback call already tests for WSAEOPNOTSUPP - maybe we 
should test for WSAEINVAL also and perhaps return silently if windows don't 
support the option. Or maybe - we state this as desired behaviour - i.e this 
option is suitable for modern windows kernels - your note below would 
contradict what I'm seeing though.

The test passes for me on Windows 7 and fails on Windows XP.

regards,
Sean.

On 15/01/2015 11:15, Valery Kopylov (Akvelon) wrote:
Hi Sean,

Our TCP loopback implementation should process the option correctly on older 
windows kernels. I tried to reproduce the issue, but it works fine on my side. 
So I have an assumption that part of the code present on jdk9 patch has been 
lost and this causes such errors.
Did you use the patch for jdk7 sent by Martin or perform the backporting from 
jdk8 or 9 by yourself?
Could you please send me output of "hg diff" command in jdk folder?


Best regards,
Valeriy Kopylov

-Original Message-
From: Seán Coffey [mailto:sean.cof...@oracle.com]
Sent: Tuesday, January 13, 2015 22:31
To: Martin Sawicki (MS OPEN TECH); 
jdk7u-...@openjdk.java.net
Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH); Alan Bateman
Subject: Re: Backporting the TCP loopback fast path (Windows) improvement to 
OpenJDK v7

Hi Martin,

I've run into a problem in backporting this to JDK 7u. The test fails on our 
build/test systems. (windows XP) -
reason: User specified action: run main/othervm
-Djdk.net.useFastTcpLoopback StressLoopback elapsed time (seconds):
0.64
STDOUT:
STDERR:
java.net.SocketException: Invalid argument: fastLoopback
at sun.nio.ch.Net.socket0(Native Method)
at sun.nio.ch.Net.serverSocket(Net.java:445)
at 
sun.nio.ch.AsynchronousServerSocketChannelImpl.(AsynchronousServerSocketChannelImpl.java:71)
at 
sun.nio.ch.WindowsAsynchronousServerSocketChannelImpl.(WindowsAsynchronousServerSocketChannelImpl.java:69)
at 
sun.nio.ch.WindowsAsynchronousChannelProvider.openAsynchronousServerSocketChannel(WindowsAsynchronousChannelProvider.java:83)
at 
java.nio.channels.AsynchronousServerSocketChannel.open(AsynchronousServerSocketChannel.java:140)
at 
java.nio.channels.AsynchronousServerSocketChannel.open(AsynchronousServerSocketChannel.java:161)
at StressLoopback.main(StressLoopback.java:42)
This seems to be from the fact that the new SIO_LOOPBACK_FAST_PATH IOCTL code 
is only supported on more modern windows systems. I'm wondering if we should 
change the src code to not attempt to use this option on older windows kernels 
or if I should just modify the testcase to not run the test on older windows 
systems ?

regards,
Sean.



On 09/01/2015 16:25, Martin Sawicki

Re: Backporting the TCP loopback fast path (Windows) improvement to OpenJDK v7

2015-01-26 Thread Seán Coffey 

Valeriy,

those changes look fine to me and I've verified that they run through 
testing fine also. webrev here for reference :

http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u.v3/webrev/

Can I have a jdk7u reviewer for this change ?

Regards,
Sean.

On 26/01/15 10:26, Valery Kopylov (Akvelon) wrote:


Sean,

Thank you for your changes! However, instead of checking for WSAEINVAL 
we propose to check for Windows version.


There are two potential issues our approach helps to avoid:

1.On Win8 the only error code WSAEOPNOTSUPP means that loopback can’t 
be set. All other errors should throw an exception.


2.Since Windows 7 returns WSAEOPNOTSUPP and WinXP returns WSAEINVAL, 
we can’t be completely sure that all older versions that use jdk7 
return one of these two codes.


Please find a patch with implemented Windows version check in attachment.

Are such changes suitable for you?

Best regards,

Valeriy Kopylov,

Software Engineer,

Akvelon,

Skype: Valeriy.Kopylov

*From:*Martin Sawicki (MS OPEN TECH)
*Sent:* Saturday, January 24, 2015 03:21
*To:* Seán Coffey; Valery Kopylov (Akvelon); jdk7u-...@openjdk.java.net
*Cc:* Kirk Shoop (MS OPEN TECH); OpenJDK Network Dev list
*Subject:* RE: Backporting the TCP loopback fast path (Windows) 
improvement to OpenJDK v7


Sorry about the delay. Valeryi has prepared a patch – he’ll be 
responding soon.


*From:*Seán Coffey [mailto:sean.cof...@oracle.com]
*Sent:* Friday, January 23, 2015 5:55 AM
*To:* Valery Kopylov (Akvelon); Martin Sawicki (MS OPEN TECH); 
jdk7u-...@openjdk.java.net 

*Cc:* Kirk Shoop (MS OPEN TECH); OpenJDK Network Dev list
*Subject:* Re: Backporting the TCP loopback fast path (Windows) 
improvement to OpenJDK v7


Valeriy,

I didn't see a follow up on this. I've modified the patch so that we 
cater for a possible WSAEINVAL error to be returned from the 
NET_EnableFastTcpLoopback call. Latest webrev :
http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u.v2/webrev/ 



changes only in 
http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u.v2/webrev/src/windows/native/sun/nio/ch/Net.c.cdiff.html 



Good to push ? I'll try and get this into 7u80 but can't guarantee 
that now given that we've entered the rampdown/stabilization phase.


regards,
Sean.

On 15/01/15 12:09, Seán Coffey wrote:

Valeriy,

I used the jdk7u patch that was attached to the mail request. It
applied cleanly. I've posted webrev here for reference (patch
there also):
http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u/webrev/


The new WSAIoctl call would appear to be failing with WSAEINVAL.
The NET_EnableFastTcpLoopback call already tests for WSAEOPNOTSUPP
- maybe we should test for WSAEINVAL also and perhaps return
silently if windows don't support the option. Or maybe - we state
this as desired behaviour - i.e this option is suitable for modern
windows kernels - your note below would contradict what I'm seeing
though.

The test passes for me on Windows 7 and fails on Windows XP.

regards,
Sean.

On 15/01/2015 11:15, Valery Kopylov (Akvelon) wrote:

Hi Sean,

Our TCP loopback implementation should process the option
correctly on older windows kernels. I tried to reproduce the
issue, but it works fine on my side. So I have an assumption that
part of the code present on jdk9 patch has been lost and this
causes such errors.
Did you use the patch for jdk7 sent by Martin or perform the
backporting from jdk8 or 9 by yourself?
Could you please send me output of "hg diff" command in jdk folder?


Best regards,
Valeriy Kopylov

-Original Message-
From: Seán Coffey [mailto:sean.cof...@oracle.com]
Sent: Tuesday, January 13, 2015 22:31
To: Martin Sawicki (MS OPEN TECH); jdk7u-...@openjdk.java.net

Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH); Alan Bateman
Subject: Re: Backporting the TCP loopback fast path (Windows)
improvement to OpenJDK v7

Hi Martin,

I've run into a problem in backporting this to JDK 7u. The test
fails on our build/test systems. (windows XP) -

reason: User specified action: run main/othervm
-Djdk.net.useFastTcpLoopback StressLoopback elapsed time (seconds):
0.64
STDOUT:
STDERR:
java.net.SocketException: Invalid argument: fastLoopback
at sun.nio.ch.Net.socket0(Native Method)
at sun.nio.ch.Net.serverSocket(Net.java:445)
at

sun.nio.ch.AsynchronousServerSocketChannelImpl.(AsynchronousServerSocketChannelImpl.java:71)
at

sun.nio.ch.WindowsAsynchronousServerSocketChannelImpl.(WindowsAsynchronousServerSocketChannelImpl.ja