From Kirk.Shoop at microsoft.com Thu Oct 2 18:17:35 2014 From: Kirk.Shoop at microsoft.com (Kirk Shoop (MS OPEN TECH)) Date: Thu, 2 Oct 2014 18:17:35 +0000 Subject: Taking advantage of TCP Loopback fast path in Windows References: <5e4d54a9d0614a779df9f96ee86cffe2@BLUPR03MB440.namprd03.prod.outlook.com> <542277D9.7010905@oracle.com> <1288ffde8bac494494917b5d5e33c761@BL2PR03MB129.namprd03.prod.outlook.com> <542307FC.3040209@oracle.com> <0cc26f0483f149328ab380a6f02e2e2b@BL2PR03MB129.namprd03.prod.outlook.com> <542326A5.9020605@oracle.com> Message-ID: <164bfb9cea6b4a43bfad2c09cd9f2c1c@BL2PR03MB129.namprd03.prod.outlook.com> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] On 24/09/2014 19:21, Kirk Shoop (MS OPEN TECH) wrote: My memory is that setting it on the socket before calling listen did not work. However, we will try again and verify. It would be good to check, it may be that we just need to set it after the listen (in the case of listener oriented channels) and that can also be done locally without extensive changes. We tried the suggestions in this thread and the result is a much smaller patch that works as well as the previous patch. https://openjdkcontrib.blob.core.windows.net/tcploopback/webrev-20141002.zip GetVersionEx is not used and the IOCTL is applied when the socket is constructed. Thanks for sending us back for another look, Kirk From ivan.gerasimov at oracle.com Mon Oct 6 10:41:53 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 06 Oct 2014 14:41:53 +0400 Subject: RFR 8023173: FileOutputStream(FileDescriptor) does not respect append flag on Windows Message-ID: <543271F1.8040505@oracle.com> Hello everybody! The append mode is emulated on Windows, therefore we have to keep a flag indicating that. With the current implementation, the FileDescriptor does not know if the file were opened with O_APPEND, and the flag is maintained at the upper level. This can cause inconsistency, when the FileDescriptor is reused to construct a new FileOutputStream, as there is no information available about the append/non-append mode. Even though the solution is quite straight-forward: moving the flag from FileOutputStream, FileDispatcherImpl and FileChannelImpl to the lower level of FileDescriptor, it touches 20 files across the source-code base. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8023173 WEBREV: http://cr.openjdk.java.net/~igerasim/8023173/0/webrev/ With the fix, all the io/nio tests, including the new one, pass on all available platforms. Would you please help review this fix? Sincerely yours, Ivan From martinrb at google.com Mon Oct 6 17:22:15 2014 From: martinrb at google.com (Martin Buchholz) Date: Mon, 6 Oct 2014 10:22:15 -0700 Subject: RFR 8023173: FileOutputStream(FileDescriptor) does not respect append flag on Windows In-Reply-To: <543271F1.8040505@oracle.com> References: <543271F1.8040505@oracle.com> Message-ID: Thanks for tackling this difficult area! Alan is the most qualified to review, but I'll throw in some comments. The title of the bug in jira doesn't match the one in the webrev - they should be the same. I'm not sure, but it looks like getAppend is called even on non-Windows platforms, but there should be no need? On Mon, Oct 6, 2014 at 3:41 AM, Ivan Gerasimov wrote: > Hello everybody! > > The append mode is emulated on Windows, therefore we have to keep a flag > indicating that. > > With the current implementation, the FileDescriptor does not know if the > file were opened with O_APPEND, and the flag is maintained at the upper > level. > This can cause inconsistency, when the FileDescriptor is reused to > construct a new FileOutputStream, as there is no information available > about the append/non-append mode. > > Even though the solution is quite straight-forward: moving the flag from > FileOutputStream, FileDispatcherImpl and FileChannelImpl to the lower > level of FileDescriptor, it touches 20 files across the source-code base. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8023173 > WEBREV: http://cr.openjdk.java.net/~igerasim/8023173/0/webrev/ > > With the fix, all the io/nio tests, including the new one, pass on all > available platforms. > > Would you please help review this fix? > > Sincerely yours, > Ivan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Tue Oct 7 08:08:20 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 07 Oct 2014 12:08:20 +0400 Subject: RFR 8023173: FileDescriptor should respect append flag In-Reply-To: References: <543271F1.8040505@oracle.com> Message-ID: <54339F74.6060200@oracle.com> Thanks Martin for the comments! On 06.10.2014 21:22, Martin Buchholz wrote: > Thanks for tackling this difficult area! > > Alan is the most qualified to review, but I'll throw in some comments. > > The title of the bug in jira doesn't match the one in the webrev - > they should be the same. > Do you mean the summary in the regression test? I'll update the Jira bug's title, the thread subject and the summary to be the same. > I'm not sure, but it looks like getAppend is called even on > non-Windows platforms, but there should be no need? > There is one place where we need it: in FileChannelImpl.position(), if in append mode, we should return the file size (see JDK-6526860). As the append flag was moved from FileChannelImpl down to FileDescriptor, we need a way to retrieve this information back, so getAppend() had to be introduced. This is applicable to both Windows and Unix. This code seems already to be covered by java/nio/channels/FileChannel/AtomicAppend.java, so I'm not introducing a new test for it. Sincerely yours, Ivan > On Mon, Oct 6, 2014 at 3:41 AM, Ivan Gerasimov > > wrote: > > Hello everybody! > > The append mode is emulated on Windows, therefore we have to keep > a flag indicating that. > > With the current implementation, the FileDescriptor does not know > if the file were opened with O_APPEND, and the flag is maintained > at the upper level. > This can cause inconsistency, when the FileDescriptor is reused to > construct a new FileOutputStream, as there is no information > available about the append/non-append mode. > > Even though the solution is quite straight-forward: moving the > flag from FileOutputStream, FileDispatcherImpl and > FileChannelImpl to the lower level of FileDescriptor, it touches > 20 files across the source-code base. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8023173 > WEBREV: http://cr.openjdk.java.net/~igerasim/8023173/0/webrev/ > > > With the fix, all the io/nio tests, including the new one, pass on > all available platforms. > > Would you please help review this fix? > > Sincerely yours, > Ivan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Tue Oct 7 09:52:26 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 07 Oct 2014 13:52:26 +0400 Subject: RFR [8059840]: (bb) Typo in javadoc for ByteBuffer.wrap() Message-ID: <5433B7DA.9000004@oracle.com> Hello! A minor typo was noticed in the javadoc for ByteBuffer.wrap(). I'm also including the removal of a few word repetitions in the neighboring files. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8059840 WEBREV: http://cr.openjdk.java.net/~igerasim/8059840/0/webrev/ Sincerely yours, Ivan From daniel.fuchs at oracle.com Tue Oct 7 09:57:00 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 07 Oct 2014 11:57:00 +0200 Subject: RFR [8059840]: (bb) Typo in javadoc for ByteBuffer.wrap() In-Reply-To: <5433B7DA.9000004@oracle.com> References: <5433B7DA.9000004@oracle.com> Message-ID: <5433B8EC.1000900@oracle.com> Hi Ivan, Looks good to me. -- daniel On 07/10/14 11:52, Ivan Gerasimov wrote: > Hello! > > A minor typo was noticed in the javadoc for ByteBuffer.wrap(). > I'm also including the removal of a few word repetitions in the > neighboring files. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8059840 > WEBREV: http://cr.openjdk.java.net/~igerasim/8059840/0/webrev/ > > Sincerely yours, > Ivan From ivan.gerasimov at oracle.com Tue Oct 7 09:57:54 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 07 Oct 2014 13:57:54 +0400 Subject: RFR [8059840]: (bb) Typo in javadoc for ByteBuffer.wrap() In-Reply-To: <5433B8EC.1000900@oracle.com> References: <5433B7DA.9000004@oracle.com> <5433B8EC.1000900@oracle.com> Message-ID: <5433B922.8000408@oracle.com> Thanks Daniel! On 07.10.2014 13:57, Daniel Fuchs wrote: > Hi Ivan, > > Looks good to me. > > -- daniel > > On 07/10/14 11:52, Ivan Gerasimov wrote: >> Hello! >> >> A minor typo was noticed in the javadoc for ByteBuffer.wrap(). >> I'm also including the removal of a few word repetitions in the >> neighboring files. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8059840 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8059840/0/webrev/ >> >> Sincerely yours, >> Ivan > > > From sean.coffey at oracle.com Tue Oct 7 11:53:18 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Tue, 07 Oct 2014 12:53:18 +0100 Subject: RFR [8059840]: (bb) Typo in javadoc for ByteBuffer.wrap() In-Reply-To: <5433B8EC.1000900@oracle.com> References: <5433B7DA.9000004@oracle.com> <5433B8EC.1000900@oracle.com> Message-ID: <5433D42E.7030004@oracle.com> quite the eagle eye Ivan.. or clever scripts! ;) src/java.base/share/classes/java/nio/file/FileStore.java > + * @return the attribute value; {@code null} may be a valid for some This still doesn't read right. I think original intent was : + * @return the attribute value; {@code null} may be a valid *value *for some src/java.base/share/classes/java/nio/file/attribute/package-info.java > * The {@link java.nio.file.attribute.FileAttributeView} interface is > ! * extended by several other interfaces that views to specific sets of file > * attributes. {@code FileAttributeViews} are selected by invoking the {@link Not sure if this reads right either. Maybe original intent was : extended by several other interfaces that*display*views to specific sets of file Not sure.. regards, Sean. On 07/10/2014 10:57, Daniel Fuchs wrote: > Hi Ivan, > > Looks good to me. > > -- daniel > > On 07/10/14 11:52, Ivan Gerasimov wrote: >> Hello! >> >> A minor typo was noticed in the javadoc for ByteBuffer.wrap(). >> I'm also including the removal of a few word repetitions in the >> neighboring files. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8059840 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8059840/0/webrev/ >> >> Sincerely yours, >> Ivan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Tue Oct 7 11:56:49 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 7 Oct 2014 12:56:49 +0100 Subject: RFR [8059840]: (bb) Typo in javadoc for ByteBuffer.wrap() In-Reply-To: <5433D42E.7030004@oracle.com> References: <5433B7DA.9000004@oracle.com> <5433B8EC.1000900@oracle.com> <5433D42E.7030004@oracle.com> Message-ID: <1D7AE494-C686-4A53-AED6-EAF9D868C791@oracle.com> On 7 Oct 2014, at 12:53, Se?n Coffey wrote: > quite the eagle eye Ivan.. or clever scripts! ;) > > src/java.base/share/classes/java/nio/file/FileStore.java >> + * @return the attribute value; {@code null} may be a valid for some > This still doesn't read right. I think original intent was : > + * @return the attribute value; {@code null} may be a valid value for some > > src/java.base/share/classes/java/nio/file/attribute/package-info.java >> * The {@link java.nio.file.attribute.FileAttributeView} interface is >> ! * extended by several other interfaces that views to specific sets of file >> * attributes. {@code FileAttributeViews} are selected by invoking the {@link > Not sure if this reads right either. Maybe original intent was : > extended by several other interfaces that display views to specific sets of file Or: extended by several other interfaces that *have* views to specific sets of file -Chris. > > Not sure.. > regards, > Sean. > > On 07/10/2014 10:57, Daniel Fuchs wrote: >> Hi Ivan, >> >> Looks good to me. >> >> -- daniel >> >> On 07/10/14 11:52, Ivan Gerasimov wrote: >>> Hello! >>> >>> A minor typo was noticed in the javadoc for ByteBuffer.wrap(). >>> I'm also including the removal of a few word repetitions in the >>> neighboring files. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8059840 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8059840/0/webrev/ >>> >>> Sincerely yours, >>> Ivan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Oct 7 12:24:30 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 Oct 2014 05:24:30 -0700 Subject: RFR [8059840]: (bb) Typo in javadoc for ByteBuffer.wrap() In-Reply-To: <5433D42E.7030004@oracle.com> References: <5433B7DA.9000004@oracle.com> <5433B8EC.1000900@oracle.com> <5433D42E.7030004@oracle.com> Message-ID: <5433DB7E.1030301@oracle.com> On 07/10/2014 04:53, Se?n Coffey wrote: > quite the eagle eye Ivan.. or clever scripts! ;) > > src/java.base/share/classes/java/nio/file/FileStore.java >> + * @return the attribute value; {@code null} may be a valid for some > This still doesn't read right. I think original intent was : > + * @return the attribute value; {@code null} may be a valid > *value *for some Right, this should be "may be a valid value for some ..." or even "may be valid for some ...". > > src/java.base/share/classes/java/nio/file/attribute/package-info.java >> * The {@link java.nio.file.attribute.FileAttributeView} interface is >> ! * extended by several other interfaces that views to specific sets of file >> * attributes. {@code FileAttributeViews} are selected by invoking the {@link > Not sure if this reads right either. Maybe original intent was : > extended by several other interfaces that*display*views to specific sets of file > > Not sure.. Actually the missing word is "define" or "provide". -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Tue Oct 7 13:41:23 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 07 Oct 2014 17:41:23 +0400 Subject: RFR [8059840]: (bb) Typo in javadoc for ByteBuffer.wrap() In-Reply-To: <5433DB7E.1030301@oracle.com> References: <5433B7DA.9000004@oracle.com> <5433B8EC.1000900@oracle.com> <5433D42E.7030004@oracle.com> <5433DB7E.1030301@oracle.com> Message-ID: <5433ED83.8020501@oracle.com> Ah. I should have been more attentive, and shouldn't have committed too fast. I'll include these additional corrections into the upcoming fix in the nio area. Sincerely yours, Ivan On 07.10.2014 16:24, Alan Bateman wrote: > On 07/10/2014 04:53, Se?n Coffey wrote: >> quite the eagle eye Ivan.. or clever scripts! ;) >> >> src/java.base/share/classes/java/nio/file/FileStore.java >>> + * @return the attribute value; {@code null} may be a valid for some >> This still doesn't read right. I think original intent was : >> + * @return the attribute value; {@code null} may be a valid >> *value *for some > Right, this should be "may be a valid value for some ..." or even "may > be valid for some ...". > > >> >> src/java.base/share/classes/java/nio/file/attribute/package-info.java >>> * The {@link java.nio.file.attribute.FileAttributeView} interface is >>> ! * extended by several other interfaces that views to specific sets of file >>> * attributes. {@code FileAttributeViews} are selected by invoking the {@link >> Not sure if this reads right either. Maybe original intent was : >> extended by several other interfaces that*display*views to specific sets of file >> >> Not sure.. > Actually the missing word is "define" or "provide". > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Oct 7 14:41:22 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 Oct 2014 07:41:22 -0700 Subject: Taking advantage of TCP Loopback fast path in Windows In-Reply-To: <164bfb9cea6b4a43bfad2c09cd9f2c1c@BL2PR03MB129.namprd03.prod.outlook.com> References: <5e4d54a9d0614a779df9f96ee86cffe2@BLUPR03MB440.namprd03.prod.outlook.com> <542277D9.7010905@oracle.com> <1288ffde8bac494494917b5d5e33c761@BL2PR03MB129.namprd03.prod.outlook.com> <542307FC.3040209@oracle.com> <0cc26f0483f149328ab380a6f02e2e2b@BL2PR03MB129.namprd03.prod.outlook.com> <542326A5.9020605@oracle.com> <164bfb9cea6b4a43bfad2c09cd9f2c1c@BL2PR03MB129.namprd03.prod.outlook.com> Message-ID: <5433FB92.3030603@oracle.com> On 02/10/2014 11:17, Kirk Shoop (MS OPEN TECH) wrote: > : > > We tried the suggestions in this thread and the result is a much smaller patch that works as well as the previous patch. > > https://openjdkcontrib.blob.core.windows.net/tcploopback/webrev-20141002.zip > > GetVersionEx is not used and the IOCTL is applied when the socket is constructed. > > Thanks for sending us back for another look, > This looks much better and I can sponsor this. One that we need to decide on is the system property to enable this. You are currently using "windows.enableFastLocalTcpLoopback". In recent time we have been using "jdk.*" for JDK-specific properties. What would you think about renaming it to jdk.net.useFastLocalTcpLookack"? Another thing that I meant to ask is whether we can skip this for UDP sockets. In Net.socket0 for example then I assume it should be "if (stream && fastLookback)". -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kirk.Shoop at microsoft.com Tue Oct 7 15:15:59 2014 From: Kirk.Shoop at microsoft.com (Kirk Shoop (MS OPEN TECH)) Date: Tue, 7 Oct 2014 15:15:59 +0000 Subject: Taking advantage of TCP Loopback fast path in Windows In-Reply-To: <5433FB92.3030603@oracle.com> References: <5e4d54a9d0614a779df9f96ee86cffe2@BLUPR03MB440.namprd03.prod.outlook.com> <542277D9.7010905@oracle.com> <1288ffde8bac494494917b5d5e33c761@BL2PR03MB129.namprd03.prod.outlook.com> <542307FC.3040209@oracle.com> <0cc26f0483f149328ab380a6f02e2e2b@BL2PR03MB129.namprd03.prod.outlook.com> <542326A5.9020605@oracle.com> <164bfb9cea6b4a43bfad2c09cd9f2c1c@BL2PR03MB129.namprd03.prod.outlook.com> <5433FB92.3030603@oracle.com> Message-ID: <86825822cd6b454ea40e7f74bc9403f9@BL2PR03MB129.namprd03.prod.outlook.com> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Tuesday, October 7, 2014 7:41 AM This looks much better and I can sponsor this. Thank you :) One that we need to decide on is the system property to enable this. You are currently using "windows.enableFastLocalTcpLoopback". In recent time we have been using "jdk.*" for JDK-specific properties. What would you think about renaming it to jdk.net.useFastLocalTcpLookack"? Yes, we will change to the name to 'jdk.net.useFastTcpLoopback'. 'windows' was only in the name to declare the scope of the setting. Another thing that I meant to ask is whether we can skip this for UDP sockets. In Net.socket0 for example then I assume it should be "if (stream && fastLookback)". Yes, that makes sense. We will make this change. We will send a link to the new webrev once the changes are made and verified. Kirk -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Wed Oct 8 16:47:42 2014 From: martinrb at google.com (Martin Buchholz) Date: Wed, 8 Oct 2014 09:47:42 -0700 Subject: RFR 8023173: FileDescriptor should respect append flag In-Reply-To: <54339F74.6060200@oracle.com> References: <543271F1.8040505@oracle.com> <54339F74.6060200@oracle.com> Message-ID: Seems OK to me, but I leave it to Alan. On Tue, Oct 7, 2014 at 1:08 AM, Ivan Gerasimov wrote: > Thanks Martin for the comments! > > On 06.10.2014 21:22, Martin Buchholz wrote: > > Thanks for tackling this difficult area! > > Alan is the most qualified to review, but I'll throw in some comments. > > The title of the bug in jira doesn't match the one in the webrev - they > should be the same. > > Do you mean the summary in the regression test? > I'll update the Jira bug's title, the thread subject and the summary to be > the same. > > I'm not sure, but it looks like getAppend is called even on non-Windows > platforms, but there should be no need? > > > There is one place where we need it: in FileChannelImpl.position(), if in > append mode, we should return the file size (see JDK-6526860). > As the append flag was moved from FileChannelImpl down to FileDescriptor, > we need a way to retrieve this information back, so getAppend() had to be > introduced. > This is applicable to both Windows and Unix. > > This code seems already to be covered by > java/nio/channels/FileChannel/AtomicAppend.java, so I'm not introducing a > new test for it. > > Sincerely yours, > Ivan > > On Mon, Oct 6, 2014 at 3:41 AM, Ivan Gerasimov > wrote: > >> Hello everybody! >> >> The append mode is emulated on Windows, therefore we have to keep a flag >> indicating that. >> >> With the current implementation, the FileDescriptor does not know if the >> file were opened with O_APPEND, and the flag is maintained at the upper >> level. >> This can cause inconsistency, when the FileDescriptor is reused to >> construct a new FileOutputStream, as there is no information available >> about the append/non-append mode. >> >> Even though the solution is quite straight-forward: moving the flag from >> FileOutputStream, FileDispatcherImpl and FileChannelImpl to the lower >> level of FileDescriptor, it touches 20 files across the source-code base. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8023173 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8023173/0/webrev/ >> >> With the fix, all the io/nio tests, including the new one, pass on all >> available platforms. >> >> Would you please help review this fix? >> >> Sincerely yours, >> Ivan >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Wed Oct 8 16:53:25 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 08 Oct 2014 20:53:25 +0400 Subject: RFR 8023173: FileDescriptor should respect append flag In-Reply-To: References: <543271F1.8040505@oracle.com> <54339F74.6060200@oracle.com> Message-ID: <54356C05.1090408@oracle.com> On 08.10.2014 20:47, Martin Buchholz wrote: > Seems OK to me, but I leave it to Alan. > Thank you Martin! From Alan.Bateman at oracle.com Wed Oct 8 16:55:28 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 08 Oct 2014 09:55:28 -0700 Subject: RFR 8023173: FileDescriptor should respect append flag In-Reply-To: References: <543271F1.8040505@oracle.com> <54339F74.6060200@oracle.com> Message-ID: <54356C80.7050202@oracle.com> On 08/10/2014 09:47, Martin Buchholz wrote: > Seems OK to me, but I leave it to Alan. > I'm away this week and I told Ivan I would get it when I get back. -Alan. From ivan.gerasimov at oracle.com Wed Oct 8 16:57:55 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 08 Oct 2014 20:57:55 +0400 Subject: RFR 8023173: FileDescriptor should respect append flag In-Reply-To: <54356C80.7050202@oracle.com> References: <543271F1.8040505@oracle.com> <54339F74.6060200@oracle.com> <54356C80.7050202@oracle.com> Message-ID: <54356D13.40502@oracle.com> On 08.10.2014 20:55, Alan Bateman wrote: > On 08/10/2014 09:47, Martin Buchholz wrote: >> Seems OK to me, but I leave it to Alan. >> > I'm away this week and I told Ivan I would get it when I get back. > Thanks, Alan! It certainly can wait. Sincerely yours, Ivan From Kirk.Shoop at microsoft.com Thu Oct 9 17:10:24 2014 From: Kirk.Shoop at microsoft.com (Kirk Shoop (MS OPEN TECH)) Date: Thu, 9 Oct 2014 17:10:24 +0000 Subject: Taking advantage of TCP Loopback fast path in Windows In-Reply-To: <86825822cd6b454ea40e7f74bc9403f9@BL2PR03MB129.namprd03.prod.outlook.com> References: <5e4d54a9d0614a779df9f96ee86cffe2@BLUPR03MB440.namprd03.prod.outlook.com> <542277D9.7010905@oracle.com> <1288ffde8bac494494917b5d5e33c761@BL2PR03MB129.namprd03.prod.outlook.com> <542307FC.3040209@oracle.com> <0cc26f0483f149328ab380a6f02e2e2b@BL2PR03MB129.namprd03.prod.outlook.com> <542326A5.9020605@oracle.com> <164bfb9cea6b4a43bfad2c09cd9f2c1c@BL2PR03MB129.namprd03.prod.outlook.com> <5433FB92.3030603@oracle.com> <86825822cd6b454ea40e7f74bc9403f9@BL2PR03MB129.namprd03.prod.outlook.com> Message-ID: <50d8ca0d089d4fa1bf20155f187bbe07@BL2PR03MB129.namprd03.prod.outlook.com> From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Kirk Shoop (MS OPEN TECH) Sent: Tuesday, October 7, 2014 8:16 AM From: Alan Bateman [mailto:Alan.Bateman at oracle.com] Sent: Tuesday, October 7, 2014 7:41 AM One that we need to decide on is the system property to enable this. You are currently using "windows.enableFastLocalTcpLoopback". In recent time we have been using "jdk.*" for JDK-specific properties. What would you think about renaming it to jdk.net.useFastLocalTcpLookack"? Yes, we will change to the name to 'jdk.net.useFastTcpLoopback'. 'windows' was only in the name to declare the scope of the setting. Another thing that I meant to ask is whether we can skip this for UDP sockets. In Net.socket0 for example then I assume it should be "if (stream && fastLookback)". Yes, that makes sense. We will make this change. We will send a link to the new webrev once the changes are made and verified. ---- Here is the webrev with both changes: https://openjdkcontrib.blob.core.windows.net/tcploopback/webrev-20141008.zip Kirk Developer Microsoft Open Technologies, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcins at microsoft.com Wed Oct 15 00:35:19 2014 From: marcins at microsoft.com (Martin Sawicki (MS OPEN TECH)) Date: Wed, 15 Oct 2014 00:35:19 +0000 Subject: Improving perf of FileChannel.transferTo() on Windows Message-ID: Hello We're proposing an improvement to the OpenJDK which markedly improves the performance of the FileChannel.transferTo API when running on Windows. We have the code figured out and tested internally. Our webrev patch is available here: https://openjdkcontrib.blob.core.windows.net/transferto/webrev-20140918.zip The crux of the change is a Windows implementation of transferTo() that uses the Win32 TransmitFile function to do the copy on a shorter code path in the kernel. As for activating this optimization, we're proposing the conservative approach of keeping it off by default and adding a command line argument to activate it: -Dwindows.enableFastFileTransfer=true | false (IMHO though, it'd be great to eventually just have it on by default). We'd appreciate a review and acceptance of this improvement. Best regards Martin Sawicki (and Kirk Shoop, and Valeriy Kopylov) Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corp. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Oct 15 07:46:24 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Oct 2014 08:46:24 +0100 Subject: Improving perf of FileChannel.transferTo() on Windows In-Reply-To: References: Message-ID: <543E2650.4000800@oracle.com> On 15/10/2014 01:35, Martin Sawicki (MS OPEN TECH) wrote: > : > > The crux of the change is a Windows implementation of transferTo() > that uses the Win32 TransmitFile function to do the copy on a shorter > code path in the kernel. > > There have been attempts in the past to use TransmitFile but they ran into a number of issues, I think it was mostly semantics differences compared to sendfile. It was a long time ago but I think one example was sending HTTP headers via write following by the HTTP body with transferTo. If I recall correctly then TransmitFile bypassed the socket buffer. Do you anything about that? -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kirk.Shoop at microsoft.com Wed Oct 15 16:40:56 2014 From: Kirk.Shoop at microsoft.com (Kirk Shoop (MS OPEN TECH)) Date: Wed, 15 Oct 2014 16:40:56 +0000 Subject: Improving perf of FileChannel.transferTo() on Windows In-Reply-To: <543E2650.4000800@oracle.com> References: <543E2650.4000800@oracle.com> Message-ID: From: Alan Bateman [mailto:Alan.Bateman at oracle.com] There have been attempts in the past to use TransmitFile but they ran into a number of issues, I think it was mostly semantics differences compared to sendfile. It was a long time ago but I think one example was sending HTTP headers via write following by the HTTP body with transferTo. If I recall correctly then TransmitFile bypassed the socket buffer. Do you anything about that? That is good to know. I was not aware of that. Where can I look for previous discussion of this? If TransmitFile does bypass the socket buffer, my first thought is that doing a flush before calling TransmitFile would avoid the issue. I do expect that forcing a flush would cause a perf issue. A mitigation for that would be to only use the flush/transmitfile path when the file to send is large enough to hide the cost of the flush. This would require having access to the file size. Has this been tried before? Valery should chime in if he has more information or thoughts. Kirk Developer Microsoft Open Technologies, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lloyd at redhat.com Wed Oct 15 17:25:00 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 15 Oct 2014 12:25:00 -0500 Subject: Improving perf of FileChannel.transferTo() on Windows In-Reply-To: References: <543E2650.4000800@oracle.com> Message-ID: <543EADEC.4040206@redhat.com> On 10/15/2014 11:40 AM, Kirk Shoop (MS OPEN TECH) wrote: > *From:*Alan Bateman [mailto:Alan.Bateman at oracle.com] > > There have been attempts in the past to use TransmitFile but they ran > into a number of issues, I think it was mostly semantics differences > compared to sendfile. It was a long time ago but I think one example was > sending HTTP headers via write following by the HTTP body with > transferTo. If I recall correctly then TransmitFile bypassed the socket > buffer. Do you anything about that? > > That is good to know. I was not aware of that. Where can I look for > previous discussion of this? > > If TransmitFile does bypass the socket buffer, my first thought is that > doing a flush before calling TransmitFile would avoid the issue. I do > expect that forcing a flush would cause a perf issue. A mitigation for > that would be to only use the flush/transmitfile path when the file to > send is large enough to hide the cost of the flush. This would require > having access to the file size. Has this been tried before? Maybe if flush is a non-blocking operation (I have no idea), if the operation would block, it could just cause the transferTo to return 0, or it could fall back to copying the data through buffers? -- - DML From Alan.Bateman at oracle.com Wed Oct 15 17:49:32 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Oct 2014 18:49:32 +0100 Subject: Improving perf of FileChannel.transferTo() on Windows In-Reply-To: References: <543E2650.4000800@oracle.com> Message-ID: <543EB3AC.7060509@oracle.com> On 15/10/2014 17:40, Kirk Shoop (MS OPEN TECH) wrote: > > That is good to know. I was not aware of that. Where can I look for > previous discussion of this? > > If TransmitFile does bypass the socket buffer, my first thought is > that doing a flush before calling TransmitFile would avoid the issue. > I do expect that forcing a flush would cause a perf issue. A > mitigation for that would be to only use the flush/transmitfile path > when the file to send is large enough to hide the cost of the flush. > This would require having access to the file size. Has this been tried > before? > > I'll see if I can find anything, the discussion and tests using TransmitFile pre-date OpenJDK. Another issue (and it's a long time ago) is when the SocketChannel is configured non-blocking, I think we concluded at the time that TransmitFile wasn't really suited for this case because it works synchronous (blocking) or asynchronously (depending on OVERLAPPED structure). Maybe you've already thought about this case. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Oct 15 18:42:33 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Oct 2014 19:42:33 +0100 Subject: Taking advantage of TCP Loopback fast path in Windows In-Reply-To: <50d8ca0d089d4fa1bf20155f187bbe07@BL2PR03MB129.namprd03.prod.outlook.com> References: <5e4d54a9d0614a779df9f96ee86cffe2@BLUPR03MB440.namprd03.prod.outlook.com> <542277D9.7010905@oracle.com> <1288ffde8bac494494917b5d5e33c761@BL2PR03MB129.namprd03.prod.outlook.com> <542307FC.3040209@oracle.com> <0cc26f0483f149328ab380a6f02e2e2b@BL2PR03MB129.namprd03.prod.outlook.com> <542326A5.9020605@oracle.com> <164bfb9cea6b4a43bfad2c09cd9f2c1c@BL2PR03MB129.namprd03.prod.outlook.com> <5433FB92.3030603@oracle.com> <86825822cd6b454ea40e7f74bc9403f9@BL2PR03MB129.namprd03.prod.outlook.com> <50d8ca0d089d4fa1bf20155f187bbe07@BL2PR03MB129.namprd03.prod.outlook.com> Message-ID: <543EC019.80404@oracle.com> On 09/10/2014 18:10, Kirk Shoop (MS OPEN TECH) wrote: > > ---- > > Here is the webrev with both changes: > I've tweaked your patch a ting bit on a few minor issues. One is so that running with -Djdk.net.useTcpFastLoopback enables the setting. Another one is to just rename from fast_loopback to fastLoopback in a few places to keep it consistent. I also add a new @run tag to one of the loopback stress tests so that it runs the test with this option enabled. I've put a webrev here: http://cr.openjdk.java.net/~alanb/8060170/webrev/ At some point you might want to extend this to work with classic networking. If you are okay with this then I will push it to the jdk9/dev forest listing you as the author. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Oct 17 09:00:15 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Oct 2014 10:00:15 +0100 Subject: RFR 8023173: FileOutputStream(FileDescriptor) does not respect append flag on Windows In-Reply-To: <543271F1.8040505@oracle.com> References: <543271F1.8040505@oracle.com> Message-ID: <5440DA9F.9090304@oracle.com> On 06/10/2014 11:41, Ivan Gerasimov wrote: > Hello everybody! > > The append mode is emulated on Windows, therefore we have to keep a > flag indicating that. > > With the current implementation, the FileDescriptor does not know if > the file were opened with O_APPEND, and the flag is maintained at the > upper level. > This can cause inconsistency, when the FileDescriptor is reused to > construct a new FileOutputStream, as there is no information available > about the append/non-append mode. > > Even though the solution is quite straight-forward: moving the flag > from FileOutputStream, FileDispatcherImpl and FileChannelImpl to the > lower level of FileDescriptor, it touches 20 files across the > source-code base. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8023173 > WEBREV: http://cr.openjdk.java.net/~igerasim/8023173/0/webrev/ > > With the fix, all the io/nio tests, including the new one, pass on all > available platforms. > > Would you please help review this fix? Martin prodded me a few times but I was busy with other things and only getting to this now. At a high level then moving the append down to FileDescriptor make sense but I have a few concerns. On Unix systems then it looks like getAppend is calling into the ioctl to get the file descriptor flags. If I read it correctly then it creates several problems for the usage in FileChannelImpl.position. I just wondering if you consider just leaving the append flag there and just retrieve the value once in the open method. I'm also wondering about the handleWrite implementation on Windows which changes to use additional JNI to retrieve the value of the append flag each time. We should try to avoid this (we want the native methods to be as simple as possible so that we can replace them in the future) so there may be an argument for passing that down as per the current implementation. -Alan. From paul.sandoz at oracle.com Fri Oct 17 09:37:08 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 17 Oct 2014 11:37:08 +0200 Subject: Covariant overrides on the Buffer Hierarchy redux In-Reply-To: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> References: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> Message-ID: <35FE2B2C-7BA2-4A11-AE9D-B5E12C7B5729@oracle.com> Hi, [Including compiler-dev, i am not on that list so please CC me if replying to just that list] I dropped this, then JVMLS got in the way... then J1 got in the way.... so i better get to this before Devoxx gets in the way... Richard, thanks for your continued patience. In the interim Richard made a slight tweak to the patch and some tests were updated to avoid casts: http://cr.openjdk.java.net/~rwarburton/buffer-overrides-3/ This looks good. Reviewed! BUT in the interim some warnings were enabled and now javac fails to compile: /Users/sandoz/Projects/jdk9/dev/langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/util/BaseFileManager.java:245: warning: [cast] redundant cast to CharBuffer return (CharBuffer)CharBuffer.allocate(1).flip(); ^ /Users/sandoz/Projects/jdk9/dev/langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/util/BaseFileManager.java:329: warning: [cast] redundant cast to ByteBuffer put((ByteBuffer)result.flip()); ^ /Users/sandoz/Projects/jdk9/dev/langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/util/BaseFileManager.java:336: warning: [cast] redundant cast to ByteBuffer return (ByteBuffer)result.flip(); ^ /Users/sandoz/Projects/jdk9/dev/langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/util/BaseFileManager.java:352: warning: [cast] redundant cast to ByteBuffer ? (ByteBuffer)cached.clear() ^ /Users/sandoz/Projects/jdk9/dev/langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java:81: warning: [cast] redundant cast to CharBuffer return ((CharBuffer)buffer.compact().flip()).array(); ^ error: warnings found and -Werror specified So Richard has a patch for that too: http://cr.openjdk.java.net/~rwarburton/buffer-overrides-langtools-0/langtools.patch This is required because in the bootstrap compilation phase a JDK without the co-variant overrides can be used. So the current solution is to suppress the warnings. Reviews from langtools gurus are very much appreciated. Ideally it would be nice to push all this under one issue, is that possible? If not i will have to create another issue and of course push to langtools before jdk. A internal CCC is also underway. Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Alan.Bateman at oracle.com Fri Oct 17 09:56:00 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Oct 2014 10:56:00 +0100 Subject: Covariant overrides on the Buffer Hierarchy redux In-Reply-To: <35FE2B2C-7BA2-4A11-AE9D-B5E12C7B5729@oracle.com> References: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> <35FE2B2C-7BA2-4A11-AE9D-B5E12C7B5729@oracle.com> Message-ID: <5440E7B0.6040706@oracle.com> On 17/10/2014 10:37, Paul Sandoz wrote: > Hi, > > [Including compiler-dev, i am not on that list so please CC me if replying to just that list] > > I dropped this, then JVMLS got in the way... then J1 got in the way.... so i better get to this before Devoxx gets in the way... Richard, thanks for your continued patience. > > In the interim Richard made a slight tweak to the patch and some tests were updated to avoid casts: > > http://cr.openjdk.java.net/~rwarburton/buffer-overrides-3/ > > This looks good. Reviewed! I've previously reviewed the changes the buffer changes and it looked good. The additional updates to drop casts in usages and tests also looks good. -Alan From Kirk.Shoop at microsoft.com Fri Oct 17 17:34:16 2014 From: Kirk.Shoop at microsoft.com (Kirk Shoop (MS OPEN TECH)) Date: Fri, 17 Oct 2014 17:34:16 +0000 Subject: Taking advantage of TCP Loopback fast path in Windows In-Reply-To: <543EC019.80404@oracle.com> References: <5e4d54a9d0614a779df9f96ee86cffe2@BLUPR03MB440.namprd03.prod.outlook.com> <542277D9.7010905@oracle.com> <1288ffde8bac494494917b5d5e33c761@BL2PR03MB129.namprd03.prod.outlook.com> <542307FC.3040209@oracle.com> <0cc26f0483f149328ab380a6f02e2e2b@BL2PR03MB129.namprd03.prod.outlook.com> <542326A5.9020605@oracle.com> <164bfb9cea6b4a43bfad2c09cd9f2c1c@BL2PR03MB129.namprd03.prod.outlook.com> <5433FB92.3030603@oracle.com> <86825822cd6b454ea40e7f74bc9403f9@BL2PR03MB129.namprd03.prod.outlook.com> <50d8ca0d089d4fa1bf20155f187bbe07@BL2PR03MB129.namprd03.prod.outlook.com> <543EC019.80404@oracle.com> Message-ID: <8ca5116a3a02458c962a65a978ba579a@BL2PR03MB129.namprd03.prod.outlook.com> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] I've tweaked your patch a ting bit on a few minor issues. One is so that running with -Djdk.net.useTcpFastLoopback enables the setting. Another one is to just rename from fast_loopback to fastLoopback in a few places to keep it consistent. I also add a new @run tag to one of the loopback stress tests so that it runs the test with this option enabled. The changes look good, thanks for adding the test. At some point you might want to extend this to work with classic networking. Yes, that would be a good step. We will put it on the list. If you are okay with this then I will push it to the jdk9/dev forest listing you as the author. Valery and I both worked on this, but if only one author can be listed then use my name. Kirk Developer Microsoft Open Technologies, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kirk.Shoop at microsoft.com Fri Oct 17 17:40:14 2014 From: Kirk.Shoop at microsoft.com (Kirk Shoop (MS OPEN TECH)) Date: Fri, 17 Oct 2014 17:40:14 +0000 Subject: Improving perf of FileChannel.transferTo() on Windows In-Reply-To: <3DE7924A81E09744BF23737394AB479710647451@SINEX14MBXC424.southpacific.corp.microsoft.com> References: <543E2650.4000800@oracle.com> <543EB3AC.7060509@oracle.com> <3DE7924A81E09744BF23737394AB479710647451@SINEX14MBXC424.southpacific.corp.microsoft.com> Message-ID: <6d90597abfe9441f885b8e16a52104d2@BL2PR03MB129.namprd03.prod.outlook.com> From: Valery Kopylov (Akvelon) Issue 2: transferTo() is now working only synchronously. Solution: We could always open socket with WSA_FLAG_OVERLAPPED option - it does not make all socket operations asynchronous by default, just allows that. Then transferTo() is called in overlapping mode or not, depending on socket mode that has been selected in configureBlocking(). How would the Java code calling transferTo be notified that the transferTo had completed? Kirk Developer Microsoft Open Technologies, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Oct 19 12:40:02 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 19 Oct 2014 13:40:02 +0100 Subject: Taking advantage of TCP Loopback fast path in Windows In-Reply-To: <8ca5116a3a02458c962a65a978ba579a@BL2PR03MB129.namprd03.prod.outlook.com> References: <5e4d54a9d0614a779df9f96ee86cffe2@BLUPR03MB440.namprd03.prod.outlook.com> <542277D9.7010905@oracle.com> <1288ffde8bac494494917b5d5e33c761@BL2PR03MB129.namprd03.prod.outlook.com> <542307FC.3040209@oracle.com> <0cc26f0483f149328ab380a6f02e2e2b@BL2PR03MB129.namprd03.prod.outlook.com> <542326A5.9020605@oracle.com> <164bfb9cea6b4a43bfad2c09cd9f2c1c@BL2PR03MB129.namprd03.prod.outlook.com> <5433FB92.3030603@oracle.com> <86825822cd6b454ea40e7f74bc9403f9@BL2PR03MB129.namprd03.prod.outlook.com> <50d8ca0d089d4fa1bf20155f187bbe07@BL2PR03MB129.namprd03.prod.outlook.com> <543EC019.80404@oracle.com> <8ca5116a3a02458c962a65a978ba579a@BL2PR03MB129.namprd03.prod.outlook.com> Message-ID: <5443B122.5020500@oracle.com> On 17/10/2014 18:34, Kirk Shoop (MS OPEN TECH) wrote: > > > If you are okay with this then I will push it to the jdk9/dev forest > listing you as the author. > > Valery and I both worked on this, but if only one author can be listed > then use my name. > > The attribution line allows for multiple contributors to be listed. The changes are now in jdk9/dev: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8 -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Mon Oct 20 12:34:10 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 20 Oct 2014 16:34:10 +0400 Subject: RFR 8023173: FileOutputStream(FileDescriptor) does not respect append flag on Windows In-Reply-To: <5440DA9F.9090304@oracle.com> References: <543271F1.8040505@oracle.com> <5440DA9F.9090304@oracle.com> Message-ID: <54450142.4040207@oracle.com> Thank you Alan for the review! On 17.10.2014 13:00, Alan Bateman wrote: > On 06/10/2014 11:41, Ivan Gerasimov wrote: >> Hello everybody! >> >> The append mode is emulated on Windows, therefore we have to keep a >> flag indicating that. >> >> With the current implementation, the FileDescriptor does not know if >> the file were opened with O_APPEND, and the flag is maintained at the >> upper level. >> This can cause inconsistency, when the FileDescriptor is reused to >> construct a new FileOutputStream, as there is no information >> available about the append/non-append mode. >> >> Even though the solution is quite straight-forward: moving the flag >> from FileOutputStream, FileDispatcherImpl and FileChannelImpl to the >> lower level of FileDescriptor, it touches 20 files across the >> source-code base. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8023173 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8023173/0/webrev/ >> >> With the fix, all the io/nio tests, including the new one, pass on >> all available platforms. >> >> Would you please help review this fix? > Martin prodded me a few times but I was busy with other things and > only getting to this now. > > At a high level then moving the append down to FileDescriptor make > sense but I have a few concerns. > > On Unix systems then it looks like getAppend is calling into the ioctl > to get the file descriptor flags. > If I read it correctly then it creates several problems for the usage > in FileChannelImpl.position. I thought it might look like a data duplication, if we store the append flag both in FileChannelImpl and FileDescriptor. Though, we surely can retrieve the append flag only once and cache it. I updated the webrev with this change. > I just wondering if you consider just leaving the append flag there > and just retrieve the value once in the open method. > > I'm also wondering about the handleWrite implementation on Windows > which changes to use additional JNI to retrieve the value of the > append flag each time. We should try to avoid this (we want the native > methods to be as simple as possible so that we can replace them in the > future) so there may be an argument for passing that down as per the > current implementation. > We would still need to retrieve the flag from native code. For example, the platform specific handleWrite() is called from the native FileOutputStream.writeBytes(), which is called from FileOutputStream.writt(), which is common for all the platforms. Thus, we should either retrieve the append flag from the Java code for any platform, and ignore it later on Unix, or read the flag in the native Windows-only code. Alternatively, we could separate implementations of FileOutputStream.java for different platforms, but that would complicate everything. Hopefully, in the future we could find a way to use FILE_APPEND_DATA, so FileDescriptor.append can be removed altogether with that corresponding JNI code. Here's the updated webrev: http://cr.openjdk.java.net/~igerasim/8023173/1/webrev/ I've also included a few typo fixes left after JDK-8059840. Sincerely yours, Ivan From Alan.Bateman at oracle.com Mon Oct 20 14:55:24 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Oct 2014 15:55:24 +0100 Subject: Improving perf of FileChannel.transferTo() on Windows In-Reply-To: <3DE7924A81E09744BF23737394AB479710647451@SINEX14MBXC424.southpacific.corp.microsoft.com> References: <543E2650.4000800@oracle.com> <543EB3AC.7060509@oracle.com> <3DE7924A81E09744BF23737394AB479710647451@SINEX14MBXC424.southpacific.corp.microsoft.com> Message-ID: <5445225C.6000307@oracle.com> On 17/10/2014 14:45, Valery Kopylov (Akvelon) wrote: > > Hello, > > To make a long story short, we face two potential issues: > > Issue 1: TransmitFile() truncates socket buffer. > > Solution: Currently transferTo() receives position at file and count > of bytes to be transmitted. We could define a threshold: when > transmitted data size exceeds it, we flush socket buffer and use > TransmitFile(), otherwise transferTo() uses other ways of file > transmitting. > > Issue 2: transferTo() is now working only synchronously. > > Solution: We could always open socket with WSA_FLAG_OVERLAPPED option > -- it does not make all socket operations asynchronous by default, > just allows that. Then transferTo() is called in overlapping mode or > not, depending on socket mode that has been selected in > configureBlocking(). > > Alan, do these solutions appear to be acceptable? > > For #1 then I think we just need a guarantee that a write, immediately followed by a transferTo, will send the bytes over the wire in the expected order. I think the original concern with TransmitFile was ambiguity in the docs as to whether it could bypass bytes queued in the socket buffer. For #2 then transferTo is synchronous (there is no asynchronous version at this time). If the target channel is configured blocking then TransmitFile may be an option. However if the target channel is configured non-blocking (which is still synchronous) then it's not clear that it's a match for TransmitFile (assuming that TransmitFile is blocking or asynchronous). -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcins at microsoft.com Mon Oct 20 19:01:33 2014 From: marcins at microsoft.com (Martin Sawicki (MS OPEN TECH)) Date: Mon, 20 Oct 2014 19:01:33 +0000 Subject: Taking advantage of TCP Loopback fast path in Windows In-Reply-To: <5443B122.5020500@oracle.com> References: <5e4d54a9d0614a779df9f96ee86cffe2@BLUPR03MB440.namprd03.prod.outlook.com> <542277D9.7010905@oracle.com> <1288ffde8bac494494917b5d5e33c761@BL2PR03MB129.namprd03.prod.outlook.com> <542307FC.3040209@oracle.com> <0cc26f0483f149328ab380a6f02e2e2b@BL2PR03MB129.namprd03.prod.outlook.com> <542326A5.9020605@oracle.com> <164bfb9cea6b4a43bfad2c09cd9f2c1c@BL2PR03MB129.namprd03.prod.outlook.com> <5433FB92.3030603@oracle.com> <86825822cd6b454ea40e7f74bc9403f9@BL2PR03MB129.namprd03.prod.outlook.com> <50d8ca0d089d4fa1bf20155f187bbe07@BL2PR03MB129.namprd03.prod.outlook.com> <543EC019.80404@oracle.com> <8ca5116a3a02458c962a65a978ba579a@BL2PR03MB129.namprd03.prod.outlook.com> <5443B122.5020500@oracle.com> Message-ID: <1a3487742a9d4c6daa3ce68e70628eaf@BLUPR03MB440.namprd03.prod.outlook.com> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] The attribution line allows for multiple contributors to be listed. The changes are now in jdk9/dev: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8 Alan, thank you for your help with this. How would we go about getting this back-ported to v8 and v7? Best regards Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Mon Oct 20 20:10:38 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 20 Oct 2014 21:10:38 +0100 Subject: Taking advantage of TCP Loopback fast path in Windows In-Reply-To: <1a3487742a9d4c6daa3ce68e70628eaf@BLUPR03MB440.namprd03.prod.outlook.com> References: <5e4d54a9d0614a779df9f96ee86cffe2@BLUPR03MB440.namprd03.prod.outlook.com> <542277D9.7010905@oracle.com> <1288ffde8bac494494917b5d5e33c761@BL2PR03MB129.namprd03.prod.outlook.com> <542307FC.3040209@oracle.com> <0cc26f0483f149328ab380a6f02e2e2b@BL2PR03MB129.namprd03.prod.outlook.com> <542326A5.9020605@oracle.com> <164bfb9cea6b4a43bfad2c09cd9f2c1c@BL2PR03MB129.namprd03.prod.outlook.com> <5433FB92.3030603@oracle.com> <86825822cd6b454ea40e7f74bc9403f9@BL2PR03MB129.namprd03.prod.outlook.com> <50d8ca0d089d4fa1bf20155f187bbe07@BL2PR03MB129.namprd03.prod.outlook.com> <543EC019.80404@oracle.com> <8ca5116a3a02458c962a65a978ba579a@BL2PR03MB129.namprd03.prod.outlook.com> <5443B122.5020500@oracle.com> <1a3487742a9d4c6daa3ce68e70628eaf@BLUPR03MB440.namprd03.prod.outlook.com> Message-ID: On 20 Oct 2014, at 20:01, Martin Sawicki (MS OPEN TECH) wrote: > > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > > The attribution line allows for multiple contributors to be listed. The changes are now in jdk9/dev: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8 > > > Alan, thank you for your help with this. How would we go about getting this back-ported to v8 and v7? A good place to start, take a quick look at the 8 Updates project. http://openjdk.java.net/projects/jdk8u/ -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Mon Oct 20 20:25:20 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 21 Oct 2014 00:25:20 +0400 Subject: RFR 8023173: FileOutputStream(FileDescriptor) does not respect append flag on Windows In-Reply-To: <54450C14.1000308@oracle.com> References: <543271F1.8040505@oracle.com> <5440DA9F.9090304@oracle.com> <54450142.4040207@oracle.com> <54450C14.1000308@oracle.com> Message-ID: <54456FB0.2010702@oracle.com> Thank you Roger! Yes, you're right. Please find the updated webrev here: http://cr.openjdk.java.net/~igerasim/8023173/2/webrev/ Sincerely yours, Ivan On 20.10.2014 17:20, roger riggs wrote: > Hi Ivan, > > This webrev appears removes the ability to interpose on various method > using byte-code injection. For example, FileOutputStream.write(byte). > Do *not *replace delete the Java method calls that call native. > It looks like an optimization but disables some functions that allow > monitoring > of I/O activities such as JFR. > > Thanks, Roger > > > On 10/20/2014 8:34 AM, Ivan Gerasimov wrote: >> Thank you Alan for the review! >> >> On 17.10.2014 13:00, Alan Bateman wrote: >>> On 06/10/2014 11:41, Ivan Gerasimov wrote: >>>> Hello everybody! >>>> >>>> The append mode is emulated on Windows, therefore we have to keep a >>>> flag indicating that. >>>> >>>> With the current implementation, the FileDescriptor does not know >>>> if the file were opened with O_APPEND, and the flag is maintained >>>> at the upper level. >>>> This can cause inconsistency, when the FileDescriptor is reused to >>>> construct a new FileOutputStream, as there is no information >>>> available about the append/non-append mode. >>>> >>>> Even though the solution is quite straight-forward: moving the flag >>>> from FileOutputStream, FileDispatcherImpl and FileChannelImpl to >>>> the lower level of FileDescriptor, it touches 20 files across the >>>> source-code base. >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8023173 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8023173/0/webrev/ >>>> >>>> With the fix, all the io/nio tests, including the new one, pass on >>>> all available platforms. >>>> >>>> Would you please help review this fix? >>> Martin prodded me a few times but I was busy with other things and >>> only getting to this now. >>> >>> At a high level then moving the append down to FileDescriptor make >>> sense but I have a few concerns. >>> >>> On Unix systems then it looks like getAppend is calling into the >>> ioctl to get the file descriptor flags. >>> If I read it correctly then it creates several problems for the >>> usage in FileChannelImpl.position. >> >> I thought it might look like a data duplication, if we store the >> append flag both in FileChannelImpl and FileDescriptor. >> Though, we surely can retrieve the append flag only once and cache it. >> >> I updated the webrev with this change. >> >>> I just wondering if you consider just leaving the append flag there >>> and just retrieve the value once in the open method. >>> >> >>> I'm also wondering about the handleWrite implementation on Windows >>> which changes to use additional JNI to retrieve the value of the >>> append flag each time. We should try to avoid this (we want the >>> native methods to be as simple as possible so that we can replace >>> them in the future) so there may be an argument for passing that >>> down as per the current implementation. >>> >> >> We would still need to retrieve the flag from native code. >> For example, the platform specific handleWrite() is called from the >> native FileOutputStream.writeBytes(), which is called from >> FileOutputStream.writt(), which is common for all the platforms. >> Thus, we should either retrieve the append flag from the Java code >> for any platform, and ignore it later on Unix, or read the flag in >> the native Windows-only code. >> >> Alternatively, we could separate implementations of >> FileOutputStream.java for different platforms, but that would >> complicate everything. >> >> Hopefully, in the future we could find a way to use FILE_APPEND_DATA, >> so FileDescriptor.append can be removed altogether with that >> corresponding JNI code. >> >> Here's the updated webrev: >> http://cr.openjdk.java.net/~igerasim/8023173/1/webrev/ >> >> I've also included a few typo fixes left after JDK-8059840. >> >> Sincerely yours, >> Ivan >> > > > From Alan.Bateman at oracle.com Tue Oct 21 19:50:56 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 Oct 2014 20:50:56 +0100 Subject: Improving perf of FileChannel.transferTo() on Windows In-Reply-To: <3DE7924A81E09744BF23737394AB479710647748@SINEX14MBXC424.southpacific.corp.microsoft.com> References: <543E2650.4000800@oracle.com> <543EB3AC.7060509@oracle.com> <3DE7924A81E09744BF23737394AB479710647451@SINEX14MBXC424.southpacific.corp.microsoft.com> <5445225C.6000307@oracle.com> <3DE7924A81E09744BF23737394AB479710647748@SINEX14MBXC424.southpacific.corp.microsoft.com> Message-ID: <5446B920.5060201@oracle.com> On 21/10/2014 11:56, Valery Kopylov (Akvelon) wrote: > > Please confirm that there are no evidences of socket buffer truncation > by TransmitFile, just ambiguity in the docs. I tried to reproduce it > in a simple application but all bytes were sent successfully and in > correct order. > > If so, we do not need any additional changes above the existing patch. > I can't find too much on the original tests that were done. You may be right that it was just ambiguity in the docs but it would also be good to double check that when the peer is congested and the socket buffer fills that TransitFile will always queue behind the socket buffer. Are you going to update the patch to only use this path when the SocketChannel is configured blocking? -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kirk.Shoop at microsoft.com Tue Oct 21 22:22:04 2014 From: Kirk.Shoop at microsoft.com (Kirk Shoop (MS OPEN TECH)) Date: Tue, 21 Oct 2014 22:22:04 +0000 Subject: Improving perf of FileChannel.transferTo() on Windows In-Reply-To: <5446B920.5060201@oracle.com> References: <543E2650.4000800@oracle.com> <543EB3AC.7060509@oracle.com> <3DE7924A81E09744BF23737394AB479710647451@SINEX14MBXC424.southpacific.corp.microsoft.com> <5445225C.6000307@oracle.com> <3DE7924A81E09744BF23737394AB479710647748@SINEX14MBXC424.southpacific.corp.microsoft.com> <5446B920.5060201@oracle.com> Message-ID: From: Alan Bateman [mailto:Alan.Bateman at oracle.com] On 21/10/2014 11:56, Valery Kopylov (Akvelon) wrote: Please confirm that there are no evidences of socket buffer truncation by TransmitFile, just ambiguity in the docs. I tried to reproduce it in a simple application but all bytes were sent successfully and in correct order. If so, we do not need any additional changes above the existing patch. I can't find too much on the original tests that were done. You may be right that it was just ambiguity in the docs but it would also be good to double check that when the peer is congested and the socket buffer fills that TransitFile will always queue behind the socket buffer. We asked the current owners of TransmitFile about the implementation and received this response: "So, the Winsock app issues a WriteFile() or send() or WSASend(), the call returns (which may return WSA_IO_PENDING or inline success, it doesn't matter), and then the app issues TransmitFile. . . In this case, the data from TransmitFile is going to follow the data from the WriteFile/send/WSASend call. Additionally, if you first issue TransmitFile, and while the TransmitFile request is pending, you issue WriteFile/send/WSASend calls, then also in this case Winsock will ensure to queue the data from WriteFile/send/WSASend calls behind the data from the TransmitFile call. In summary, the data order is preserved by Winsock as long as you issue a mix of TransmitFile/WriteFile/send/WSASend calls in serialized fashion (without necessarily waiting for any pended overlapped calls to be completed). If you issue any of these calls concurrently from multiple threads, then all bets are off in terms of data ordering." Are you going to update the patch to only use this path when the SocketChannel is configured blocking? Yes, we will post a new webrev when we have changed the code to only apply to blocking sockets. Thanks, Kirk Developer Microsoft Open Technologies, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Sat Oct 25 18:14:49 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 25 Oct 2014 22:14:49 +0400 Subject: RFR 8023173: FileDescriptor should respect append flag In-Reply-To: <543271F1.8040505@oracle.com> References: <543271F1.8040505@oracle.com> Message-ID: <544BE899.5090503@oracle.com> Hello everyone! I've changed the fix in order to address the concerns Alan had mentioned. Now, both the Unix and Windows implementations of FileDescriptor class have the append flag. First, it allows such querying the file descriptor in FileChannelImpl.position() that does not involve JNI calls. Second, this flag is passed to the write functions as an argument, so there's no need to retrieve it from the native code. The fix was built on all available platforms. All the tests from io, nio pass. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8023173 WEBREV: http://cr.openjdk.java.net/~igerasim/8023173/3/webrev/ Would you please help review this? Sincerely yours, Ivan From Alan.Bateman at oracle.com Mon Oct 27 07:50:51 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 27 Oct 2014 07:50:51 +0000 Subject: RFR 8023173: FileDescriptor should respect append flag In-Reply-To: <544BE899.5090503@oracle.com> References: <543271F1.8040505@oracle.com> <544BE899.5090503@oracle.com> Message-ID: <544DF95B.8020309@oracle.com> On 25/10/2014 19:14, Ivan Gerasimov wrote: > Hello everyone! > > I've changed the fix in order to address the concerns Alan had mentioned. > > Now, both the Unix and Windows implementations of FileDescriptor class > have the append flag. > First, it allows such querying the file descriptor in > FileChannelImpl.position() that does not involve JNI calls. > Second, this flag is passed to the write functions as an argument, so > there's no need to retrieve it from the native code. > > The fix was built on all available platforms. > All the tests from io, nio pass. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8023173 > WEBREV: http://cr.openjdk.java.net/~igerasim/8023173/3/webrev/ > > Would you please help review this? Thanks, this looks much better and cleaner than the previous iterations. You can probably drop the setting of append in the no-arg FileDescriptor constructor. Also the "final" in FileChannelImpl.position isn't needed. Otherwise this looks good to me and good to have this long standing corner case addressed. -Alan From ivan.gerasimov at oracle.com Mon Oct 27 08:53:49 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 27 Oct 2014 12:53:49 +0400 Subject: RFR 8023173: FileDescriptor should respect append flag In-Reply-To: <544DF95B.8020309@oracle.com> References: <543271F1.8040505@oracle.com> <544BE899.5090503@oracle.com> <544DF95B.8020309@oracle.com> Message-ID: <544E081D.9030501@oracle.com> Thanks Alan! I'll remove redundant initialization and final word before pushing. Sincerely yours, Ivan On 27.10.2014 11:50, Alan Bateman wrote: > On 25/10/2014 19:14, Ivan Gerasimov wrote: >> Hello everyone! >> >> I've changed the fix in order to address the concerns Alan had >> mentioned. >> >> Now, both the Unix and Windows implementations of FileDescriptor >> class have the append flag. >> First, it allows such querying the file descriptor in >> FileChannelImpl.position() that does not involve JNI calls. >> Second, this flag is passed to the write functions as an argument, so >> there's no need to retrieve it from the native code. >> >> The fix was built on all available platforms. >> All the tests from io, nio pass. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8023173 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8023173/3/webrev/ >> >> Would you please help review this? > > Thanks, this looks much better and cleaner than the previous iterations. > > You can probably drop the setting of append in the no-arg > FileDescriptor constructor. Also the "final" in > FileChannelImpl.position isn't needed. > > Otherwise this looks good to me and good to have this long standing > corner case addressed. > > -Alan > > > > From paul.sandoz at oracle.com Mon Oct 27 09:12:11 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 27 Oct 2014 10:12:11 +0100 Subject: Request for review/advice from langtools team Re: Covariant overrides on the Buffer Hierarchy redux In-Reply-To: <35FE2B2C-7BA2-4A11-AE9D-B5E12C7B5729@oracle.com> References: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> <35FE2B2C-7BA2-4A11-AE9D-B5E12C7B5729@oracle.com> Message-ID: Hi, Can someone from langtools kindly chime in with how to move this forward? https://bugs.openjdk.java.net/browse/JDK-4774077 http://cr.openjdk.java.net/~rwarburton/buffer-overrides-3/ http://cr.openjdk.java.net/~rwarburton/buffer-overrides-langtools-0/langtools.patch On Oct 17, 2014, at 11:37 AM, Paul Sandoz wrote: > Hi, > > [Including compiler-dev, i am not on that list so please CC me if replying to just that list] > > ... > So Richard has a patch for that too: > > http://cr.openjdk.java.net/~rwarburton/buffer-overrides-langtools-0/langtools.patch > > This is required because in the bootstrap compilation phase a JDK without the co-variant overrides can be used. So the current solution is to suppress the warnings. Reviews from langtools gurus are very much appreciated. > ? > Ideally it would be nice to push all this under one issue, is that possible? If not i will have to create another issue and of course push to langtools before jdk. > > A internal CCC is also underway. > This has be approved, with the comment that "@since 1.9" should be added to the doc of the new methods, which i have done in my copy of the patch. Thanks, Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From paul.sandoz at oracle.com Wed Oct 29 08:51:37 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 29 Oct 2014 09:51:37 +0100 Subject: Request for review/advice from langtools team Re: Covariant overrides on the Buffer Hierarchy redux In-Reply-To: References: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> <35FE2B2C-7BA2-4A11-AE9D-B5E12C7B5729@oracle.com> Message-ID: On Oct 28, 2014, at 1:59 PM, Joel Borggr?n-Franck wrote: > Hi Paul, > > Sorry for the delay. > > So if I understand this correctly, we get 4 warnings (and because of -Werror a build failure) in langtools when compiling vs Jdk 9, but need the casts because we bootstrap with Jdk 8. > Yes. > Looks good to me but I would prefer if you filed a bug on me for Jdk 10 for removing the SuppressWarnings and added comments pointing to the bug after the @SuppressWarnings annotations. That way I will remember to clean this up when we bootstrap with Jdk 9. > Ok, after i push i will log a new P4 bug and assign it to you. Thanks, Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From joel.franck at oracle.com Tue Oct 28 12:59:43 2014 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 28 Oct 2014 13:59:43 +0100 Subject: Request for review/advice from langtools team Re: Covariant overrides on the Buffer Hierarchy redux In-Reply-To: References: <3D27B84B-20F1-486C-954F-E908DD443DA9@oracle.com> <35FE2B2C-7BA2-4A11-AE9D-B5E12C7B5729@oracle.com> Message-ID: Hi Paul, Sorry for the delay. So if I understand this correctly, we get 4 warnings (and because of -Werror a build failure) in langtools when compiling vs Jdk 9, but need the casts because we bootstrap with Jdk 8. Looks good to me but I would prefer if you filed a bug on me for Jdk 10 for removing the SuppressWarnings and added comments pointing to the bug after the @SuppressWarnings annotations. That way I will remember to clean this up when we bootstrap with Jdk 9. cheers /Joel On 27 okt 2014, at 10:12, Paul Sandoz wrote: > Hi, > > Can someone from langtools kindly chime in with how to move this forward? > > https://bugs.openjdk.java.net/browse/JDK-4774077 > > http://cr.openjdk.java.net/~rwarburton/buffer-overrides-3/ > > http://cr.openjdk.java.net/~rwarburton/buffer-overrides-langtools-0/langtools.patch > > > On Oct 17, 2014, at 11:37 AM, Paul Sandoz wrote: > >> Hi, >> >> [Including compiler-dev, i am not on that list so please CC me if replying to just that list] >> >> > ... > > >> So Richard has a patch for that too: >> >> http://cr.openjdk.java.net/~rwarburton/buffer-overrides-langtools-0/langtools.patch >> >> This is required because in the bootstrap compilation phase a JDK without the co-variant overrides can be used. So the current solution is to suppress the warnings. Reviews from langtools gurus are very much appreciated. >> > > ? > > >> Ideally it would be nice to push all this under one issue, is that possible? If not i will have to create another issue and of course push to langtools before jdk. >> >> A internal CCC is also underway. >> > > This has be approved, with the comment that "@since 1.9" should be added to the doc of the new methods, which i have done in my copy of the patch. > > Thanks, > Paul. From brian.burkhalter at oracle.com Wed Oct 29 21:35:00 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 29 Oct 2014 14:35:00 -0700 Subject: RFR 9 8062501: Modifications of server socket channel accept() methods for instrumentation purposes Message-ID: Hello, Please review this proposed change: Issue: https://bugs.openjdk.java.net/browse/JDK-8062501 Patch: http://cr.openjdk.java.net/~bpb/8062501/webrev.00/ With this change the jdk_nio tests pass on all platforms. This is similar to a previously discussed change to Java I/O: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-August/028301.html Thanks, Brian From chris.hegarty at oracle.com Thu Oct 30 15:38:04 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 30 Oct 2014 15:38:04 +0000 Subject: RFR 9 8062501: Modifications of server socket channel accept() methods for instrumentation purposes In-Reply-To: References: Message-ID: <360C3995-809D-4B9B-9888-558259437848@oracle.com> Apart from the indentation of the new method parameters, this looks fine to me. To keep the style consistent, just indent the params inline with the first param on the previous line. And fix up the throws e.g. private int accept(FileDescriptor ssfd, FileDescriptor newfd, InetSocketAddress[] isaa) throws IOException { return accept0(ssfd, newfd, isaa); } -Chris. On 29 Oct 2014, at 21:35, Brian Burkhalter wrote: > Hello, > > Please review this proposed change: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8062501 > Patch: http://cr.openjdk.java.net/~bpb/8062501/webrev.00/ > > With this change the jdk_nio tests pass on all platforms. > > This is similar to a previously discussed change to Java I/O: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-August/028301.html > > Thanks, > > Brian From brian.burkhalter at oracle.com Thu Oct 30 15:52:39 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 30 Oct 2014 08:52:39 -0700 Subject: RFR 9 8062501: Modifications of server socket channel accept() methods for instrumentation purposes In-Reply-To: <360C3995-809D-4B9B-9888-558259437848@oracle.com> References: <360C3995-809D-4B9B-9888-558259437848@oracle.com> Message-ID: <20A9F1F0-CA46-467E-ACB7-5E197CD5191A@oracle.com> Hi Chris, Thanks for the review. The patch is modified as requested here: http://cr.openjdk.java.net/~bpb/8062501/webrev.01/ Please verify that this is approved to check in to 9. Thanks, Brian On Oct 30, 2014, at 8:38 AM, Chris Hegarty wrote: > Apart from the indentation of the new method parameters, this looks fine to me. > > To keep the style consistent, just indent the params inline with the first param on the previous line. And fix up the throws > > e.g. > > private int accept(FileDescriptor ssfd, FileDescriptor newfd, > InetSocketAddress[] isaa) > throws IOException > { > return accept0(ssfd, newfd, isaa); > } -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Oct 30 17:35:36 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Oct 2014 17:35:36 +0000 Subject: RFR 9 8062501: Modifications of server socket channel accept() methods for instrumentation purposes In-Reply-To: <20A9F1F0-CA46-467E-ACB7-5E197CD5191A@oracle.com> References: <360C3995-809D-4B9B-9888-558259437848@oracle.com> <20A9F1F0-CA46-467E-ACB7-5E197CD5191A@oracle.com> Message-ID: <545276E8.7050504@oracle.com> On 30/10/2014 15:52, Brian Burkhalter wrote: > Hi Chris, > > Thanks for the review. The patch is modified as requested here: > > http://cr.openjdk.java.net/~bpb/8062501/webrev.01/ > > > Please verify that this is approved to check in to 9. > To keep consistent then it would nicer to use "isa" rather than "issa". On formatting then I agree with Chris and would be good to keep it consistent if you can. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Oct 30 17:47:46 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 30 Oct 2014 10:47:46 -0700 Subject: RFR 9 8062501: Modifications of server socket channel accept() methods for instrumentation purposes In-Reply-To: <545276E8.7050504@oracle.com> References: <360C3995-809D-4B9B-9888-558259437848@oracle.com> <20A9F1F0-CA46-467E-ACB7-5E197CD5191A@oracle.com> <545276E8.7050504@oracle.com> Message-ID: <648C4119-37BD-49DD-9F71-F61CDFBB7976@oracle.com> On Oct 30, 2014, at 10:35 AM, Alan Bateman wrote: > To keep consistent then it would nicer to use "isa" rather than "issa?. I think ?isaa? is for ?InternetSocketAddress array? as opposed to "InternetSocketAddress." > On formatting then I agree with Chris and would be good to keep it consistent if you can. Done. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: