From mark.sheppard at oracle.com Thu Jan 2 08:26:36 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Thu, 02 Jan 2014 16:26:36 +0000 Subject: RFR: java/net/MulticastSocket/SetGetNetworkInterfaceTest.java throws java.net.SocketException: Cannot assign requested address In-Reply-To: <52C05677.80508@oracle.com> References: <52B87F2C.5030209@oracle.com> <52C05677.80508@oracle.com> Message-ID: <52C5933C.8010906@oracle.com> Hi Alan, added an ExceptionDescribe to native code and an -Xcheck:jni to the cmd line options to produce the following: WARNING in native method: JNI call made with exception pending at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method) at java.net.AbstractPlainDatagramSocketImpl.setOption(AbstractPlainDatagramSocketImpl.java:309) at java.net.MulticastSocket.setNetworkInterface(MulticastSocket.java:554) - locked <0x000000076c8c78e8> (a java.lang.Object) at SetGetNetworkInterfaceTest.main(SetGetNetworkInterfaceTest.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) at java.lang.Thread.run(Thread.java:744) and ExceptionDescribe outputs Exception in thread "MainThread" java.net.SocketException: Cannot assign requested address at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method) at java.net.AbstractPlainDatagramSocketImpl.setOption(AbstractPlainDatagramSocketImpl.java:309) at java.net.MulticastSocket.setNetworkInterface(MulticastSocket.java:554) at SetGetNetworkInterfaceTest.main(SetGetNetworkInterfaceTest.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) at java.lang.Thread.run(Thread.java:744) regards Mark On 29/12/2013 17:05, Alan Bateman wrote: > On 23/12/2013 18:21, Mark Sheppard wrote: >> Hi, >> Please oblige and review the following changes: >> >> http://cr.openjdk.java.net/~msheppar/8027903/webrev/ >> >> which address the issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8027903 >> >> The test failure was found to be due to an interface configured with >> an IPv6 address and >> no IPv4 address. The native code was calling >> mcast_set_if_by_addr_v4(...), which >> raised an exception. > Do you know what the exception is? Just wondering what exception is > being cleared/ignored. > > -Alan From chris.hegarty at oracle.com Thu Jan 2 08:47:37 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 2 Jan 2014 16:47:37 +0000 Subject: RFR: java/net/MulticastSocket/SetGetNetworkInterfaceTest.java throws java.net.SocketException: Cannot assign requested address In-Reply-To: <52C5933C.8010906@oracle.com> References: <52B87F2C.5030209@oracle.com> <52C05677.80508@oracle.com> <52C5933C.8010906@oracle.com> Message-ID: <570F6474-9136-4F84-BD50-54FD4700C23C@oracle.com> Thanks Mark, On 2 Jan 2014, at 16:26, Mark Sheppard wrote: > Hi Alan, > added an ExceptionDescribe to native code and an -Xcheck:jni to the cmd line options to produce the > following: > > WARNING in native method: JNI call made with exception pending > at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method) > at java.net.AbstractPlainDatagramSocketImpl.setOption(AbstractPlainDatagramSocketImpl.java:309) > at java.net.MulticastSocket.setNetworkInterface(MulticastSocket.java:554) > - locked <0x000000076c8c78e8> (a java.lang.Object) > at SetGetNetworkInterfaceTest.main(SetGetNetworkInterfaceTest.java:54) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) > at java.lang.Thread.run(Thread.java:744) > > and ExceptionDescribe outputs > > Exception in thread "MainThread" java.net.SocketException: Cannot assign requested address > at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method) > at java.net.AbstractPlainDatagramSocketImpl.setOption(AbstractPlainDatagramSocketImpl.java:309) > at java.net.MulticastSocket.setNetworkInterface(MulticastSocket.java:554) > at SetGetNetworkInterfaceTest.main(SetGetNetworkInterfaceTest.java:54) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) > at java.lang.Thread.run(Thread.java:744) This is what I would expect to see. The changes look good to me. If the IPv6 version completes successfully then there clearly is no reason to throw an exception. If it does not, then there will be a new exception on the stack. -Chris. > > > regards > Mark > > On 29/12/2013 17:05, Alan Bateman wrote: >> On 23/12/2013 18:21, Mark Sheppard wrote: >>> Hi, >>> Please oblige and review the following changes: >>> >>> http://cr.openjdk.java.net/~msheppar/8027903/webrev/ >>> >>> which address the issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8027903 >>> >>> The test failure was found to be due to an interface configured with an IPv6 address and >>> no IPv4 address. The native code was calling mcast_set_if_by_addr_v4(...), which >>> raised an exception. >> Do you know what the exception is? Just wondering what exception is being cleared/ignored. >> >> -Alan > From Alan.Bateman at oracle.com Thu Jan 2 09:08:55 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 02 Jan 2014 17:08:55 +0000 Subject: RFR: java/net/MulticastSocket/SetGetNetworkInterfaceTest.java throws java.net.SocketException: Cannot assign requested address In-Reply-To: <52C5933C.8010906@oracle.com> References: <52B87F2C.5030209@oracle.com> <52C05677.80508@oracle.com> <52C5933C.8010906@oracle.com> Message-ID: <52C59D27.80103@oracle.com> On 02/01/2014 16:26, Mark Sheppard wrote: > Hi Alan, > added an ExceptionDescribe to native code and an -Xcheck:jni to the > cmd line options to produce the > following: Thanks, it is clearer now. What you have is okay but I guess I'm just concerned that mcast_set_if_by_if_v4 can potentially fail for reasons other than setsockopt failing. Also the IPv6 mcast functions are more complicated and can potential fail for many reasons. I realize this is going beyond the scope of what you are looking at but would it make sense for these mcast functions to return an int (0 for success, non-0 when they fail) and only return with a pending JNI exception if a JNI function has failed. In other words? In other words, move the throwing of the network/SocketException to the caller so that it clearer to anyone reading the code where the errors are handled. That would give you something like: rc = mcast_set_if_by_addr_v4(...) if ((*env)->ExceptionOccurred(env)) return; I'm not suggesting this has to be done now but I think the real issue here is that this code needs a bit of a clean-up (as it has grow over time). -Alan From chris.hegarty at oracle.com Thu Jan 2 22:58:37 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 03 Jan 2014 06:58:37 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20140103065950.CE6EF62FEB@hg.openjdk.java.net> Changeset: 18080cca998a Author: dl Date: 2014-01-03 06:22 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/18080cca998a 8031133: AbstractMap should specify its default implementation using @implSpec Reviewed-by: chegar, alanb ! src/share/classes/java/util/AbstractMap.java Changeset: 33a60ce1e35d Author: chegar Date: 2014-01-03 06:23 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/33a60ce1e35d Merge ! src/share/classes/java/util/AbstractMap.java From dmavrodiev at gmail.com Fri Jan 3 03:04:18 2014 From: dmavrodiev at gmail.com (Dimitar Mavrodiev) Date: Fri, 3 Jan 2014 13:04:18 +0200 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 Message-ID: Greetings all, I've fixed this and created a test to cover it, is there a sponsor who could push this through? Here's a link to the webrev https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/index.html. It's a simple fix that correctly consumes the bytes from a SOCKS reply which represent an IPv6 address or a domain name. I also had to fix SocksServer as it was not correctly constructing a String representation of an IPv6 address from byte[]. I didn't find it necessary to cover the case of DOMAIN_NAME in the test as name resolution happens locally and not on the SOCKS server, which is perhaps worth another fix. Best, Dimitar Mavrodiev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140103/3569cd93/attachment.html From sean.coffey at oracle.com Fri Jan 3 08:47:54 2014 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 03 Jan 2014 16:47:54 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20140103164849.42D2E62FFC@hg.openjdk.java.net> Changeset: 46c727d6ecc2 Author: aefimov Date: 2013-12-30 16:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46c727d6ecc2 8025051: Update resource files for TimeZone display names Reviewed-by: okutsu, mfang ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! test/java/util/Calendar/GenericTimeZoneNamesTest.sh ! test/sun/util/resources/TimeZone/Bug6317929.java + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_de.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_de_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_es.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_es_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_fr.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_fr_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_it.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_it_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_ja.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_ja_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_ko.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_ko_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_pt_BR.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_pt_BR_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_sv.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_sv_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_zh_CN.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_zh_CN_short.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_zh_TW.properties + test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNames_zh_TW_short.properties Changeset: c0970860803e Author: coffeys Date: 2014-01-03 16:45 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0970860803e Merge From joe.darcy at oracle.com Fri Jan 3 11:39:28 2014 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 03 Jan 2014 19:39:28 +0000 Subject: hg: jdk8/tl/jdk: 8030212: Several api.java.util.stream tests got "NaN" value instead of "Infinity" or "-Infinity" Message-ID: <20140103193957.9AB6C6235D@hg.openjdk.java.net> Changeset: 68de5492a06d Author: darcy Date: 2014-01-03 11:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68de5492a06d 8030212: Several api.java.util.stream tests got "NaN" value instead of "Infinity" or "-Infinity" Reviewed-by: mduigou, psandoz ! src/share/classes/java/util/DoubleSummaryStatistics.java ! src/share/classes/java/util/stream/Collectors.java ! src/share/classes/java/util/stream/DoublePipeline.java ! test/java/util/stream/TestDoubleSumAverage.java From Alan.Bateman at oracle.com Sun Jan 5 03:09:04 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 05 Jan 2014 11:09:04 +0000 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: References: Message-ID: <52C93D4F.1050301@oracle.com> On 03/01/2014 11:04, Dimitar Mavrodiev wrote: > Greetings all, > > I've fixed this and created a test to cover it, is there a sponsor who > could push this through? Here's a link to the webrev > https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/index.html. > > It's a simple fix that correctly consumes the bytes from a SOCKS reply > which represent an IPv6 address or a domain name. I also had to fix > SocksServer as it was not correctly constructing a String > representation of an IPv6 address from byte[]. > > I didn't find it necessary to cover the case of DOMAIN_NAME in the > test as name resolution happens locally and not on the SOCKS server, > which is perhaps worth another fix. > Thanks for the patch and I see that your OCA has been processed. I checked section 5 of RFC 1928 and it does indeed appear that the DOMAINNAME (0x03) and IP V6 address (0x04) cases were not implemented correctly. Your patch looks right. In passing, I see that the constants for SOCKS are defined in an interface (which is an anti-pattern) and we should clean that up at some point (not necessary for this patch of course). On the test then I think it will need to check that IPv6 is enabled as part of the setup, otherwise it looks like it will fail. I realize that IPv6 is enabled by default everywhere these days but we regularly test on machine that don't have it configured. One other thing about the test is that it will require a GPL header. Would you have cycles to expand the SOCKS test infrastructure to cover the DOMAIN_NAME case? I ask about that case because it was the lack of test coverage that meant this mis-handling slipped through (although I don't think it is actually used and doesn't appear to have been noticed before). Otherwise, I think this is a good (and I would be happy to sponsor it). -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140105/c9397a28/attachment.html From dmavrodiev at gmail.com Mon Jan 6 08:18:09 2014 From: dmavrodiev at gmail.com (Dimitar Mavrodiev) Date: Mon, 6 Jan 2014 18:18:09 +0200 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: <52CAD6D6.7000000@oracle.com> References: <52C93D4F.1050301@oracle.com> <52CABB44.8050801@oracle.com> <52CAD13F.2000408@oracle.com> <52CAD6D6.7000000@oracle.com> Message-ID: Yes, I've disabled IPv6 and it came out as successful in the report. Is it possible that jtreg behaves differently across different OSes? I am using it on Linux and OSX, the bug report mentions Windows. On Mon, Jan 6, 2014 at 6:16 PM, Chris Hegarty wrote: > On 06/01/14 16:05, Dimitar Mavrodiev wrote: > >> The jtreg version I am using(4.1 fcs b05) seems to be correctly handling >> it. What jtreg version should I be using? >> > > See https://bugs.openjdk.java.net/browse/JDK-8026362 for a an example of > this. > > Did you try to run your test without ::1 enabled? > > -Chris. > > >> >> On Mon, Jan 6, 2014 at 5:52 PM, Alan Bateman > > wrote: >> >> On 06/01/2014 15:21, Dimitar Mavrodiev wrote: >> >> Thanks, Chris. >> >> I've removed the dependency on the internal HttpServer. Here's >> another webrev >> https://googledrive.com/host/__0B2CI6Ih--1t5bVVwbVlBRmpVMDg/ >> __2/index.html >> > 2/index.html>. >> >> >> I'm not 100% sure how jtreg handles TestNG tests throwing >> SkipException. If it doesn't then it probably means adding a flag so >> that the test passes silently when IPv6 is not enabled. >> >> -Alan >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140106/4870aab7/attachment.html From michael.x.mcmahon at oracle.com Mon Jan 6 02:06:32 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 06 Jan 2014 10:06:32 +0000 Subject: RFR: 8029354: URLPermission. throws llegalArgumentException: Invalid characters in hostname Message-ID: <52CA8028.3070802@oracle.com> http://cr.openjdk.java.net/~michaelm/8029354/9/webrev.1/ This is the forward port to JDK 9. The patch from 8 applies cleanly. Thanks, Michael From chris.hegarty at oracle.com Mon Jan 6 08:31:08 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 06 Jan 2014 16:31:08 +0000 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: References: <52C93D4F.1050301@oracle.com> <52CABB44.8050801@oracle.com> <52CAD13F.2000408@oracle.com> <52CAD6D6.7000000@oracle.com> Message-ID: <52CADA4C.8000606@oracle.com> On 06/01/14 16:18, Dimitar Mavrodiev wrote: > Yes, I've disabled IPv6 and it came out as successful in the report. Is > it possible that jtreg behaves differently across different OSes? I am > using it on Linux and OSX, the bug report mentions Windows. It is possible, but I don't see any special handling for SkipException in the jtreg source. I also cannot find any use of it in the any of the OpenJDK JDK 9 repositories. Maybe just to be safe you could print a warning message and simply return? -Chris. > > > On Mon, Jan 6, 2014 at 6:16 PM, Chris Hegarty > wrote: > > On 06/01/14 16:05, Dimitar Mavrodiev wrote: > > The jtreg version I am using(4.1 fcs b05) seems to be correctly > handling > it. What jtreg version should I be using? > > > See https://bugs.openjdk.java.net/__browse/JDK-8026362 > for a an example > of this. > > Did you try to run your test without ::1 enabled? > > -Chris. > > > > On Mon, Jan 6, 2014 at 5:52 PM, Alan Bateman > > >> wrote: > > On 06/01/2014 15:21, Dimitar Mavrodiev wrote: > > Thanks, Chris. > > I've removed the dependency on the internal HttpServer. > Here's > another webrev > https://googledrive.com/host/____0B2CI6Ih--1t5bVVwbVlBRmpVMDg/____2/index.html > > > >. > > > I'm not 100% sure how jtreg handles TestNG tests throwing > SkipException. If it doesn't then it probably means adding > a flag so > that the test passes silently when IPv6 is not enabled. > > -Alan > > > From dmavrodiev at gmail.com Mon Jan 6 08:39:11 2014 From: dmavrodiev at gmail.com (Dimitar Mavrodiev) Date: Mon, 6 Jan 2014 18:39:11 +0200 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: <52CADA4C.8000606@oracle.com> References: <52C93D4F.1050301@oracle.com> <52CABB44.8050801@oracle.com> <52CAD13F.2000408@oracle.com> <52CAD6D6.7000000@oracle.com> <52CADA4C.8000606@oracle.com> Message-ID: Ok, better safe than sorry. Here's the webrev https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/3/index.html. Best, Dimitar On Mon, Jan 6, 2014 at 6:31 PM, Chris Hegarty wrote: > On 06/01/14 16:18, Dimitar Mavrodiev wrote: > >> Yes, I've disabled IPv6 and it came out as successful in the report. Is >> it possible that jtreg behaves differently across different OSes? I am >> using it on Linux and OSX, the bug report mentions Windows. >> > > It is possible, but I don't see any special handling for SkipException in > the jtreg source. I also cannot find any use of it in the any of the > OpenJDK JDK 9 repositories. Maybe just to be safe you could print a warning > message and simply return? > > -Chris. > > >> >> On Mon, Jan 6, 2014 at 6:16 PM, Chris Hegarty > > wrote: >> >> On 06/01/14 16:05, Dimitar Mavrodiev wrote: >> >> The jtreg version I am using(4.1 fcs b05) seems to be correctly >> handling >> it. What jtreg version should I be using? >> >> >> See https://bugs.openjdk.java.net/__browse/JDK-8026362 >> >> for a an example >> of this. >> >> Did you try to run your test without ::1 enabled? >> >> -Chris. >> >> >> >> On Mon, Jan 6, 2014 at 5:52 PM, Alan Bateman >> >> > >> >> wrote: >> >> On 06/01/2014 15:21, Dimitar Mavrodiev wrote: >> >> Thanks, Chris. >> >> I've removed the dependency on the internal HttpServer. >> Here's >> another webrev >> https://googledrive.com/host/____0B2CI6Ih-- >> 1t5bVVwbVlBRmpVMDg/____2/index.html >> > 1t5bVVwbVlBRmpVMDg/__2/index.html> >> >> >> > 1t5bVVwbVlBRmpVMDg/__2/index.html >> > 2/index.html>>. >> >> >> I'm not 100% sure how jtreg handles TestNG tests throwing >> SkipException. If it doesn't then it probably means adding >> a flag so >> that the test passes silently when IPv6 is not enabled. >> >> -Alan >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140106/818b08d9/attachment.html From dmavrodiev at gmail.com Mon Jan 6 07:21:20 2014 From: dmavrodiev at gmail.com (Dimitar Mavrodiev) Date: Mon, 6 Jan 2014 17:21:20 +0200 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: <52CABB44.8050801@oracle.com> References: <52C93D4F.1050301@oracle.com> <52CABB44.8050801@oracle.com> Message-ID: Thanks, Chris. I've removed the dependency on the internal HttpServer. Here's another webrev https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/2/index.html. Best, Dimitar On Mon, Jan 6, 2014 at 4:18 PM, Chris Hegarty wrote: > The source changes look good to me too. > > I see Alan has commented on the test, and I agree. Trivially, can you also > remove the dependency on the old internal HttpServer, and use the newer > com.sun.net.httpserver API. It is easier to user, and more robust. You can > see an example here [1]. > > -Chris. > > [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/test/ > sun/net/www/protocol/http/StreamingOutputStream.java. > > > > On 05/01/14 11:09, Alan Bateman wrote: > >> On 03/01/2014 11:04, Dimitar Mavrodiev wrote: >> >>> Greetings all, >>> >>> I've fixed this and created a test to cover it, is there a sponsor who >>> could push this through? Here's a link to the webrev >>> https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/index.html. >>> >>> It's a simple fix that correctly consumes the bytes from a SOCKS reply >>> which represent an IPv6 address or a domain name. I also had to fix >>> SocksServer as it was not correctly constructing a String >>> representation of an IPv6 address from byte[]. >>> >>> I didn't find it necessary to cover the case of DOMAIN_NAME in the >>> test as name resolution happens locally and not on the SOCKS server, >>> which is perhaps worth another fix. >>> >>> Thanks for the patch and I see that your OCA has been processed. >> >> I checked section 5 of RFC 1928 and it does indeed appear that the >> DOMAINNAME (0x03) and IP V6 address (0x04) cases were not implemented >> correctly. Your patch looks right. In passing, I see that the constants >> for SOCKS are defined in an interface (which is an anti-pattern) and we >> should clean that up at some point (not necessary for this patch of >> course). >> >> On the test then I think it will need to check that IPv6 is enabled as >> part of the setup, otherwise it looks like it will fail. I realize that >> IPv6 is enabled by default everywhere these days but we regularly test >> on machine that don't have it configured. One other thing about the test >> is that it will require a GPL header. Would you have cycles to expand >> the SOCKS test infrastructure to cover the DOMAIN_NAME case? I ask about >> that case because it was the lack of test coverage that meant this >> mis-handling slipped through (although I don't think it is actually used >> and doesn't appear to have been noticed before). >> >> Otherwise, I think this is a good (and I would be happy to sponsor it). >> >> -Alan. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140106/84ad0760/attachment-0001.html From joe.darcy at oracle.com Mon Jan 6 11:36:09 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 06 Jan 2014 11:36:09 -0800 Subject: JDK 9 RFR of JDK-8031201: Fix casting lint issues in java.net Message-ID: <52CB05A9.9080202@oracle.com> Hello, Please review the simple patch below to address JDK-8031201: Fix casting lint issues in java.net (The various ObjectInputStream.GetField.get methods which have a default parameter, have an property-typed return value already.) Thanks, -Joe diff -r 9af7c1225730 src/share/classes/java/net/Inet6Address.java --- a/src/share/classes/java/net/Inet6Address.java Mon Jan 06 11:00:12 2014 +0000 +++ b/src/share/classes/java/net/Inet6Address.java Mon Jan 06 11:34:25 2014 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -604,9 +604,9 @@ ObjectInputStream.GetField gf = s.readFields(); byte[] ipaddress = (byte[])gf.get("ipaddress", null); - int scope_id = (int)gf.get("scope_id", -1); - boolean scope_id_set = (boolean)gf.get("scope_id_set", false); - boolean scope_ifname_set = (boolean)gf.get("scope_ifname_set", false); + int scope_id = gf.get("scope_id", -1); + boolean scope_id_set = gf.get("scope_id_set", false); + boolean scope_ifname_set = gf.get("scope_ifname_set", false); String ifname = (String)gf.get("ifname", null); if (ifname != null && !"".equals (ifname)) { From daniel.fuchs at oracle.com Mon Jan 6 10:40:18 2014 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Mon, 06 Jan 2014 18:40:18 +0000 Subject: hg: jdk8/tl/jdk: 8030850: Setting .level=FINEST in logging configuration file doesn't work Message-ID: <20140106184132.99103623E5@hg.openjdk.java.net> Changeset: d77a1c9fd5b8 Author: dfuchs Date: 2013-12-22 11:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d77a1c9fd5b8 8030850: Setting .level=FINEST in logging configuration file doesn't work Summary: setLevel(INFO) was called too early on root logger, causing the value found in configuration file to be later ignored. Reviewed-by: mchung ! src/share/classes/java/util/logging/LogManager.java + test/java/util/logging/RootLogger/RootLevelInConfigFile.java + test/java/util/logging/RootLogger/rootlogger.properties From Alan.Bateman at oracle.com Mon Jan 6 11:42:41 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 06 Jan 2014 19:42:41 +0000 Subject: JDK 9 RFR of JDK-8031201: Fix casting lint issues in java.net In-Reply-To: <52CB05A9.9080202@oracle.com> References: <52CB05A9.9080202@oracle.com> Message-ID: <52CB0731.9080106@oracle.com> On 06/01/2014 19:36, Joe Darcy wrote: > Hello, > > Please review the simple patch below to address > > JDK-8031201: Fix casting lint issues in java.net > This looks okay to me. -Alan From chris.hegarty at oracle.com Mon Jan 6 11:44:32 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 6 Jan 2014 19:44:32 +0000 Subject: JDK 9 RFR of JDK-8031201: Fix casting lint issues in java.net In-Reply-To: <52CB05A9.9080202@oracle.com> References: <52CB05A9.9080202@oracle.com> Message-ID: <44FA8991-BF8A-4B7E-A5C1-1C1160CA3E21@oracle.com> Looks good to me Joe. -Chris. On 6 Jan 2014, at 19:36, Joe Darcy wrote: > Hello, > > Please review the simple patch below to address > > JDK-8031201: Fix casting lint issues in java.net > > (The various ObjectInputStream.GetField.get methods which have a default parameter, have an property-typed return value already.) > > Thanks, > > -Joe > > diff -r 9af7c1225730 src/share/classes/java/net/Inet6Address.java > --- a/src/share/classes/java/net/Inet6Address.java Mon Jan 06 11:00:12 2014 +0000 > +++ b/src/share/classes/java/net/Inet6Address.java Mon Jan 06 11:34:25 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -604,9 +604,9 @@ > > ObjectInputStream.GetField gf = s.readFields(); > byte[] ipaddress = (byte[])gf.get("ipaddress", null); > - int scope_id = (int)gf.get("scope_id", -1); > - boolean scope_id_set = (boolean)gf.get("scope_id_set", false); > - boolean scope_ifname_set = (boolean)gf.get("scope_ifname_set", false); > + int scope_id = gf.get("scope_id", -1); > + boolean scope_id_set = gf.get("scope_id_set", false); > + boolean scope_ifname_set = gf.get("scope_ifname_set", false); > String ifname = (String)gf.get("ifname", null); > > if (ifname != null && !"".equals (ifname)) { > From chris.hegarty at oracle.com Mon Jan 6 06:18:44 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 06 Jan 2014 14:18:44 +0000 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: <52C93D4F.1050301@oracle.com> References: <52C93D4F.1050301@oracle.com> Message-ID: <52CABB44.8050801@oracle.com> The source changes look good to me too. I see Alan has commented on the test, and I agree. Trivially, can you also remove the dependency on the old internal HttpServer, and use the newer com.sun.net.httpserver API. It is easier to user, and more robust. You can see an example here [1]. -Chris. [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/test/sun/net/www/protocol/http/StreamingOutputStream.java. On 05/01/14 11:09, Alan Bateman wrote: > On 03/01/2014 11:04, Dimitar Mavrodiev wrote: >> Greetings all, >> >> I've fixed this and created a test to cover it, is there a sponsor who >> could push this through? Here's a link to the webrev >> https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/index.html. >> >> It's a simple fix that correctly consumes the bytes from a SOCKS reply >> which represent an IPv6 address or a domain name. I also had to fix >> SocksServer as it was not correctly constructing a String >> representation of an IPv6 address from byte[]. >> >> I didn't find it necessary to cover the case of DOMAIN_NAME in the >> test as name resolution happens locally and not on the SOCKS server, >> which is perhaps worth another fix. >> > Thanks for the patch and I see that your OCA has been processed. > > I checked section 5 of RFC 1928 and it does indeed appear that the > DOMAINNAME (0x03) and IP V6 address (0x04) cases were not implemented > correctly. Your patch looks right. In passing, I see that the constants > for SOCKS are defined in an interface (which is an anti-pattern) and we > should clean that up at some point (not necessary for this patch of course). > > On the test then I think it will need to check that IPv6 is enabled as > part of the setup, otherwise it looks like it will fail. I realize that > IPv6 is enabled by default everywhere these days but we regularly test > on machine that don't have it configured. One other thing about the test > is that it will require a GPL header. Would you have cycles to expand > the SOCKS test infrastructure to cover the DOMAIN_NAME case? I ask about > that case because it was the lack of test coverage that meant this > mis-handling slipped through (although I don't think it is actually used > and doesn't appear to have been noticed before). > > Otherwise, I think this is a good (and I would be happy to sponsor it). > > -Alan. > From Alan.Bateman at oracle.com Mon Jan 6 07:52:31 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 06 Jan 2014 15:52:31 +0000 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: References: <52C93D4F.1050301@oracle.com> <52CABB44.8050801@oracle.com> Message-ID: <52CAD13F.2000408@oracle.com> On 06/01/2014 15:21, Dimitar Mavrodiev wrote: > Thanks, Chris. > > I've removed the dependency on the internal HttpServer. Here's another > webrev > https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/2/index.html. I'm not 100% sure how jtreg handles TestNG tests throwing SkipException. If it doesn't then it probably means adding a flag so that the test passes silently when IPv6 is not enabled. -Alan From chris.hegarty at oracle.com Mon Jan 6 08:16:22 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 06 Jan 2014 16:16:22 +0000 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: References: <52C93D4F.1050301@oracle.com> <52CABB44.8050801@oracle.com> <52CAD13F.2000408@oracle.com> Message-ID: <52CAD6D6.7000000@oracle.com> On 06/01/14 16:05, Dimitar Mavrodiev wrote: > The jtreg version I am using(4.1 fcs b05) seems to be correctly handling > it. What jtreg version should I be using? See https://bugs.openjdk.java.net/browse/JDK-8026362 for a an example of this. Did you try to run your test without ::1 enabled? -Chris. > > > On Mon, Jan 6, 2014 at 5:52 PM, Alan Bateman > wrote: > > On 06/01/2014 15:21, Dimitar Mavrodiev wrote: > > Thanks, Chris. > > I've removed the dependency on the internal HttpServer. Here's > another webrev > https://googledrive.com/host/__0B2CI6Ih--1t5bVVwbVlBRmpVMDg/__2/index.html > . > > I'm not 100% sure how jtreg handles TestNG tests throwing > SkipException. If it doesn't then it probably means adding a flag so > that the test passes silently when IPv6 is not enabled. > > -Alan > > From dmavrodiev at gmail.com Mon Jan 6 06:05:06 2014 From: dmavrodiev at gmail.com (Dimitar Mavrodiev) Date: Mon, 6 Jan 2014 16:05:06 +0200 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: <52C93D4F.1050301@oracle.com> References: <52C93D4F.1050301@oracle.com> Message-ID: Hi Alan, I wasn't aware that tests might run on machines without the IPv6 stack. Now the test is skipped should there be no IPv6 address configured on the loopback iface. I've also expanded the test to cover the case of DOMAIN_NAME, but I came across some infrastructure problems. It turned out that if the underlying OS had both the IPv6 and IPv4 loopback addresses map to the same name (localhost, as it is on OSX 10.9.x) the test would fail(Connection reset), if they mapped to different names(as it is on Linux - Ubuntu 13.10, RHEL 5.5) the test would succeed. I've decided to skip the test in case of the former. What do you think? Here's the webrev https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/1/index.html. You can find the previous webrev on the following link https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/0/index.html . Best, Dimitar On Sun, Jan 5, 2014 at 1:09 PM, Alan Bateman wrote: > On 03/01/2014 11:04, Dimitar Mavrodiev wrote: > > Greetings all, > > I've fixed this and created a test to cover it, is there a sponsor who > could push this through? Here's a link to the webrev > https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/index.html. > > It's a simple fix that correctly consumes the bytes from a SOCKS reply > which represent an IPv6 address or a domain name. I also had to fix > SocksServer as it was not correctly constructing a String representation of > an IPv6 address from byte[]. > > I didn't find it necessary to cover the case of DOMAIN_NAME in the test > as name resolution happens locally and not on the SOCKS server, which is > perhaps worth another fix. > > Thanks for the patch and I see that your OCA has been processed. > > I checked section 5 of RFC 1928 and it does indeed appear that the > DOMAINNAME (0x03) and IP V6 address (0x04) cases were not implemented > correctly. Your patch looks right. In passing, I see that the constants for > SOCKS are defined in an interface (which is an anti-pattern) and we should > clean that up at some point (not necessary for this patch of course). > > On the test then I think it will need to check that IPv6 is enabled as > part of the setup, otherwise it looks like it will fail. I realize that > IPv6 is enabled by default everywhere these days but we regularly test on > machine that don't have it configured. One other thing about the test is > that it will require a GPL header. Would you have cycles to expand the > SOCKS test infrastructure to cover the DOMAIN_NAME case? I ask about that > case because it was the lack of test coverage that meant this mis-handling > slipped through (although I don't think it is actually used and doesn't > appear to have been noticed before). > > Otherwise, I think this is a good (and I would be happy to sponsor it). > > -Alan. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140106/60272fa8/attachment-0001.html From dmavrodiev at gmail.com Mon Jan 6 08:05:18 2014 From: dmavrodiev at gmail.com (Dimitar Mavrodiev) Date: Mon, 6 Jan 2014 18:05:18 +0200 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: <52CAD13F.2000408@oracle.com> References: <52C93D4F.1050301@oracle.com> <52CABB44.8050801@oracle.com> <52CAD13F.2000408@oracle.com> Message-ID: The jtreg version I am using(4.1 fcs b05) seems to be correctly handling it. What jtreg version should I be using? On Mon, Jan 6, 2014 at 5:52 PM, Alan Bateman wrote: > On 06/01/2014 15:21, Dimitar Mavrodiev wrote: > >> Thanks, Chris. >> >> I've removed the dependency on the internal HttpServer. Here's another >> webrev https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/ >> 2/index.html. >> > I'm not 100% sure how jtreg handles TestNG tests throwing SkipException. > If it doesn't then it probably means adding a flag so that the test passes > silently when IPv6 is not enabled. > > -Alan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140106/58be3528/attachment.html From Alan.Bateman at oracle.com Tue Jan 7 01:57:05 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 Jan 2014 09:57:05 +0000 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: References: <52C93D4F.1050301@oracle.com> <52CABB44.8050801@oracle.com> <52CAD13F.2000408@oracle.com> <52CAD6D6.7000000@oracle.com> <52CADA4C.8000606@oracle.com> Message-ID: <52CBCF71.5020704@oracle.com> On 06/01/2014 16:39, Dimitar Mavrodiev wrote: > Ok, better safe than sorry. Here's the webrev > https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/3/index.html. Can you verify that it passes okay when you run jtreg with -vmoption:-Djava.net.preferIPv4Stack=true . I ask because I don't see a check in testSocksOverIPv6 and it looks like it will always try to connect to ::1. -Alan. From dmavrodiev at gmail.com Tue Jan 7 04:29:23 2014 From: dmavrodiev at gmail.com (Dimitar Mavrodiev) Date: Tue, 7 Jan 2014 14:29:23 +0200 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: <52CBCF71.5020704@oracle.com> References: <52C93D4F.1050301@oracle.com> <52CABB44.8050801@oracle.com> <52CAD13F.2000408@oracle.com> <52CAD6D6.7000000@oracle.com> <52CADA4C.8000606@oracle.com> <52CBCF71.5020704@oracle.com> Message-ID: Hi Alan, I've fixed that. Here's the webrev https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/4/index.html. I've made some changes in the test to ensure that the inet6 address family is available, there's also a flag controlling if the test should run. It now runs if the IPv6 stack is available and there is an IPv6 address assigned on the loopback iface. -Dimitar On Tue, Jan 7, 2014 at 11:57 AM, Alan Bateman wrote: > On 06/01/2014 16:39, Dimitar Mavrodiev wrote: > >> Ok, better safe than sorry. Here's the webrev >> https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/3/index.html. >> > Can you verify that it passes okay when you run jtreg with > -vmoption:-Djava.net.preferIPv4Stack=true . I ask because I don't see a > check in testSocksOverIPv6 and it looks like it will always try to connect > to ::1. > > -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140107/ae9bca34/attachment.html From roger.riggs at oracle.com Tue Jan 7 09:29:07 2014 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Tue, 07 Jan 2014 17:29:07 +0000 Subject: hg: jdk8/tl/jdk: 8031103: java.time.Duration has wrong Javadoc Comments in toDays() and toHours() Message-ID: <20140107172936.C23DA6242B@hg.openjdk.java.net> Changeset: 1b503dd54b95 Author: rriggs Date: 2014-01-07 11:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1b503dd54b95 8031103: java.time.Duration has wrong Javadoc Comments in toDays() and toHours() Summary: Correct specification for Duration.toDays, toHours Reviewed-by: lancea, alanb ! src/share/classes/java/time/Duration.java From joe.darcy at oracle.com Tue Jan 7 09:36:33 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 07 Jan 2014 09:36:33 -0800 Subject: JDK 9 RFR of 8031326: Use Class rather than Class in java.net method signatures Message-ID: <52CC3B21.4060002@oracle.com> Hello, Please review these changes to remove use of raw Class in some method signatures in java.net: JDK-8031326: Use Class rather than Class in java.net method signatures Patch below. Thanks, -Joe --- a/src/share/classes/java/net/URL.java Tue Jan 07 09:17:56 2014 -0800 +++ b/src/share/classes/java/net/URL.java Tue Jan 07 09:20:09 2014 -0800 @@ -1055,7 +1055,7 @@ /** * Gets the contents of this URL. This method is a shorthand for: *
-     *     openConnection().getContent(Class[])
+     *     openConnection().getContent(classes)
       * 
* * @param classes an array of Java types @@ -1066,7 +1066,7 @@ * @see java.net.URLConnection#getContent(Class[]) * @since 1.3 */ - public final Object getContent(Class[] classes) + public final Object getContent(Class[] classes) throws java.io.IOException { return openConnection().getContent(classes); } diff -r b54fa34779b6 src/share/classes/java/net/URLConnection.java --- a/src/share/classes/java/net/URLConnection.java Tue Jan 07 09:17:56 2014 -0800 +++ b/src/share/classes/java/net/URLConnection.java Tue Jan 07 09:20:09 2014 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -760,7 +760,7 @@ * @see java.net.URLConnection#setContentHandlerFactory(java.net.ContentHandlerFactory) * @since 1.3 */ - public Object getContent(Class[] classes) throws IOException { + public Object getContent(Class[] classes) throws IOException { // Must call getInputStream before GetHeaderField gets called // so that FileNotFoundException has a chance to be thrown up // from here without being caught. From Alan.Bateman at oracle.com Tue Jan 7 09:44:43 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 Jan 2014 17:44:43 +0000 Subject: JDK 9 RFR of 8031326: Use Class rather than Class in java.net method signatures In-Reply-To: <52CC3B21.4060002@oracle.com> References: <52CC3B21.4060002@oracle.com> Message-ID: <52CC3D0B.8060905@oracle.com> On 07/01/2014 17:36, Joe Darcy wrote: > Hello, > > Please review these changes to remove use of raw Class in some method > signatures in java.net: > > JDK-8031326: Use Class rather than Class in java.net method > signatures > > Patch below. This looks okay to me. -Alan. From chris.hegarty at oracle.com Tue Jan 7 09:47:05 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 7 Jan 2014 17:47:05 +0000 Subject: JDK 9 RFR of 8031326: Use Class rather than Class in java.net method signatures In-Reply-To: <52CC3B21.4060002@oracle.com> References: <52CC3B21.4060002@oracle.com> Message-ID: <48966B93-9797-413C-9624-A0B5D67A4ACD@oracle.com> Approved. -Chris. On 7 Jan 2014, at 17:36, Joe Darcy wrote: > Hello, > > Please review these changes to remove use of raw Class in some method signatures in java.net: > > JDK-8031326: Use Class rather than Class in java.net method signatures > > Patch below. > > Thanks, > > -Joe > > --- a/src/share/classes/java/net/URL.java Tue Jan 07 09:17:56 2014 -0800 > +++ b/src/share/classes/java/net/URL.java Tue Jan 07 09:20:09 2014 -0800 > @@ -1055,7 +1055,7 @@ > /** > * Gets the contents of this URL. This method is a shorthand for: > *
> -     *     openConnection().getContent(Class[])
> +     *     openConnection().getContent(classes)
>      * 
> * > * @param classes an array of Java types > @@ -1066,7 +1066,7 @@ > * @see java.net.URLConnection#getContent(Class[]) > * @since 1.3 > */ > - public final Object getContent(Class[] classes) > + public final Object getContent(Class[] classes) > throws java.io.IOException { > return openConnection().getContent(classes); > } > diff -r b54fa34779b6 src/share/classes/java/net/URLConnection.java > --- a/src/share/classes/java/net/URLConnection.java Tue Jan 07 09:17:56 2014 -0800 > +++ b/src/share/classes/java/net/URLConnection.java Tue Jan 07 09:20:09 2014 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -760,7 +760,7 @@ > * @see java.net.URLConnection#setContentHandlerFactory(java.net.ContentHandlerFactory) > * @since 1.3 > */ > - public Object getContent(Class[] classes) throws IOException { > + public Object getContent(Class[] classes) throws IOException { > // Must call getInputStream before GetHeaderField gets called > // so that FileNotFoundException has a chance to be thrown up > // from here without being caught. > From michael.x.mcmahon at oracle.com Tue Jan 7 10:04:02 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 07 Jan 2014 18:04:02 +0000 Subject: JDK 9 RFR of 8031326: Use Class rather than Class in java.net method signatures In-Reply-To: <52CC3D0B.8060905@oracle.com> References: <52CC3B21.4060002@oracle.com> <52CC3D0B.8060905@oracle.com> Message-ID: <52CC4192.6080007@oracle.com> On 07/01/14 17:44, Alan Bateman wrote: > On 07/01/2014 17:36, Joe Darcy wrote: >> Hello, >> >> Please review these changes to remove use of raw Class in some method >> signatures in java.net: >> >> JDK-8031326: Use Class rather than Class in java.net >> method signatures >> >> Patch below. > This looks okay to me. > > -Alan. I was thinking originally, there must be something more specific than Class that applies to these types (related to the ContentHandler types). But, it looks like there isn't. So, it looks ok to me too. Michael. From Alan.Bateman at oracle.com Tue Jan 7 13:36:32 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 Jan 2014 21:36:32 +0000 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: References: <52C93D4F.1050301@oracle.com> <52CABB44.8050801@oracle.com> <52CAD13F.2000408@oracle.com> <52CAD6D6.7000000@oracle.com> <52CADA4C.8000606@oracle.com> <52CBCF71.5020704@oracle.com> Message-ID: <52CC7360.1040507@oracle.com> On 07/01/2014 12:29, Dimitar Mavrodiev wrote: > Hi Alan, > > I've fixed that. Here's the webrev > https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/4/index.html. > Thanks for the update, it seems to be okay now for IPv6 disabled case. One thing I do see though is that the test fails intermittently on Windows (in my case Windows Server 2012) when IPv6 is enabled. The typical output is attached. I haven't dug into yet. -Alan [TestNG] Running: java/net/Socks/SocksIPv6Test.java config SocksIPv6Test.setUp(): success test SocksIPv6Test.testSocksOverIPv6(): failure java.net.SocketException: Reply from SOCKS server has bad length at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:505) at java.net.Socket.connect(Socket.java:585) at java.net.Socket.connect(Socket.java:534) at sun.net.NetworkClient.doConnect(NetworkClient.java:180) at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) at sun.net.www.http.HttpClient.(HttpClient.java:211) at sun.net.www.http.HttpClient.New(HttpClient.java:308) at sun.net.www.http.HttpClient.New(HttpClient.java:326) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1122) at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1101) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:942) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:940) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessController.doPrivileged(AccessController.java:713) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:939) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:886) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1466) at sun.net.www.protocol.http.HttpURLConnection.access$200(HttpURLConnection.java:90) at sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1386) at sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1384) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessController.doPrivileged(AccessController.java:713) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1383) at SocksIPv6Test.testSocksOverIPv6(SocksIPv6Test.java:133) From dmavrodiev at gmail.com Wed Jan 8 02:08:29 2014 From: dmavrodiev at gmail.com (Dimitar Mavrodiev) Date: Wed, 8 Jan 2014 12:08:29 +0200 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: <52CC7360.1040507@oracle.com> References: <52C93D4F.1050301@oracle.com> <52CABB44.8050801@oracle.com> <52CAD13F.2000408@oracle.com> <52CAD6D6.7000000@oracle.com> <52CADA4C.8000606@oracle.com> <52CBCF71.5020704@oracle.com> <52CC7360.1040507@oracle.com> Message-ID: Unfortunately I don't have a Windows environment. I'll try to setup one and look into this. -Dimitar On Tue, Jan 7, 2014 at 11:36 PM, Alan Bateman wrote: > On 07/01/2014 12:29, Dimitar Mavrodiev wrote: > >> Hi Alan, >> >> I've fixed that. Here's the webrev https://googledrive.com/host/ >> 0B2CI6Ih--1t5bVVwbVlBRmpVMDg/4/index.html. >> >> Thanks for the update, it seems to be okay now for IPv6 disabled case. > > One thing I do see though is that the test fails intermittently on Windows > (in my case Windows Server 2012) when IPv6 is enabled. The typical output > is attached. I haven't dug into yet. > > -Alan > > [TestNG] Running: > java/net/Socks/SocksIPv6Test.java > > config SocksIPv6Test.setUp(): success > test SocksIPv6Test.testSocksOverIPv6(): failure > java.net.SocketException: Reply from SOCKS server has bad length > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:505) > at java.net.Socket.connect(Socket.java:585) > at java.net.Socket.connect(Socket.java:534) > at sun.net.NetworkClient.doConnect(NetworkClient.java:180) > at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) > at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) > at sun.net.www.http.HttpClient.(HttpClient.java:211) > at sun.net.www.http.HttpClient.New(HttpClient.java:308) > at sun.net.www.http.HttpClient.New(HttpClient.java:326) > at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient( > HttpURLConnection.java:1122) > at sun.net.www.protocol.http.HttpURLConnection.plainConnect0( > HttpURLConnection.java:1101) > at sun.net.www.protocol.http.HttpURLConnection$6.run( > HttpURLConnection.java:942) > at sun.net.www.protocol.http.HttpURLConnection$6.run( > HttpURLConnection.java:940) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.AccessController.doPrivileged( > AccessController.java:713) > at sun.net.www.protocol.http.HttpURLConnection.plainConnect( > HttpURLConnection.java:939) > at sun.net.www.protocol.http.HttpURLConnection.connect( > HttpURLConnection.java:886) > at sun.net.www.protocol.http.HttpURLConnection.getInputStream0( > HttpURLConnection.java:1466) > at sun.net.www.protocol.http.HttpURLConnection.access$200( > HttpURLConnection.java:90) > at sun.net.www.protocol.http.HttpURLConnection$9.run( > HttpURLConnection.java:1386) > at sun.net.www.protocol.http.HttpURLConnection$9.run( > HttpURLConnection.java:1384) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.AccessController.doPrivileged( > AccessController.java:713) > at sun.net.www.protocol.http.HttpURLConnection.getInputStream( > HttpURLConnection.java:1383) > at SocksIPv6Test.testSocksOverIPv6(SocksIPv6Test.java:133) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140108/d7675b35/attachment.html From paul.sandoz at oracle.com Thu Jan 9 02:50:48 2014 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 09 Jan 2014 10:50:48 +0000 Subject: hg: jdk8/tl/jdk: 8031187: DoubleStream.count is incorrect for a stream containing > Integer.MAX_VALUE elements Message-ID: <20140109105107.5E7D86248A@hg.openjdk.java.net> Changeset: 630a92015993 Author: psandoz Date: 2014-01-09 10:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/630a92015993 8031187: DoubleStream.count is incorrect for a stream containing > Integer.MAX_VALUE elements Reviewed-by: darcy ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/IntPipeline.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountLargeTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java From roger.riggs at oracle.com Fri Jan 10 07:37:29 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 10 Jan 2014 10:37:29 -0500 Subject: RFR: (8030875) Macros for checking and returning on exceptions Message-ID: <52D013B9.40101@oracle.com> Please review: To enable native code checking consistently for thrown exceptions, the macros in net_util.h and java/util/jar/pack/coding.cpp are made consolidated and promoted to jni_util.h webrev: http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ [1] https://bugs.openjdk.java.net/browse/JDK-8030875 From chris.hegarty at oracle.com Fri Jan 10 07:49:17 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 10 Jan 2014 15:49:17 +0000 Subject: RFR: (8030875) Macros for checking and returning on exceptions In-Reply-To: <52D013B9.40101@oracle.com> References: <52D013B9.40101@oracle.com> Message-ID: <52D0167D.2000003@oracle.com> Thank you Roger, much appreciated. I think Dan has a change in flight that could be simplified a bit by using these. -Chris. On 10/01/14 15:37, roger riggs wrote: > Please review: > > To enable native code checking consistently for thrown exceptions, > the macros in net_util.h and java/util/jar/pack/coding.cpp are > made consolidated and promoted to jni_util.h > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ > > [1] https://bugs.openjdk.java.net/browse/JDK-8030875 From Alan.Bateman at oracle.com Fri Jan 10 08:45:04 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Jan 2014 16:45:04 +0000 Subject: RFR: (8030875) Macros for checking and returning on exceptions In-Reply-To: <52D013B9.40101@oracle.com> References: <52D013B9.40101@oracle.com> Message-ID: <52D02390.60403@oracle.com> On 10/01/2014 15:37, roger riggs wrote: > Please review: > > To enable native code checking consistently for thrown exceptions, > the macros in net_util.h and java/util/jar/pack/coding.cpp are > made consolidated and promoted to jni_util.h > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ This looks okay to me. It would be good if Kumar takes a look at this too because it results in a mix of macros in the pack code. -Alan From michael.x.mcmahon at oracle.com Fri Jan 10 09:20:49 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 10 Jan 2014 17:20:49 +0000 Subject: RFR: (8030875) Macros for checking and returning on exceptions In-Reply-To: <52D013B9.40101@oracle.com> References: <52D013B9.40101@oracle.com> Message-ID: <52D02BF1.4080908@oracle.com> On 10/01/14 15:37, roger riggs wrote: > Please review: > > To enable native code checking consistently for thrown exceptions, > the macros in net_util.h and java/util/jar/pack/coding.cpp are > made consolidated and promoted to jni_util.h > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ > > [1] https://bugs.openjdk.java.net/browse/JDK-8030875 Looks fine to me Michael. From mandy.chung at oracle.com Fri Jan 10 09:41:40 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 10 Jan 2014 09:41:40 -0800 Subject: RFR: (8030875) Macros for checking and returning on exceptions In-Reply-To: <52D013B9.40101@oracle.com> References: <52D013B9.40101@oracle.com> Message-ID: <52D030D4.6020800@oracle.com> On 1/10/2014 7:37 AM, roger riggs wrote: > Please review: > > To enable native code checking consistently for thrown exceptions, > the macros in net_util.h and java/util/jar/pack/coding.cpp are > made consolidated and promoted to jni_util.h > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ > Looks good. Thanks for doing this Roger. Minor nit: the convention in jni.h seems to name functions that take JNIEnv* parameter with the "JNU_" prefix and so might be better to rename CHECK_EXCEPTION to JNU_CheckedException. Mandy From roger.riggs at oracle.com Fri Jan 10 09:59:22 2014 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 10 Jan 2014 12:59:22 -0500 Subject: RFR: (8030875) Macros for checking and returning on exceptions In-Reply-To: <52D030D4.6020800@oracle.com> References: <52D013B9.40101@oracle.com> <52D030D4.6020800@oracle.com> Message-ID: <52D034FA.5090301@oracle.com> Hi Mandy, Good point; I'll create another issue to do that update. (I should have waited a bit longer for comments.) Roger On 1/10/2014 12:41 PM, Mandy Chung wrote: > On 1/10/2014 7:37 AM, roger riggs wrote: >> Please review: >> >> To enable native code checking consistently for thrown exceptions, >> the macros in net_util.h and java/util/jar/pack/coding.cpp are >> made consolidated and promoted to jni_util.h >> >> webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ >> > > Looks good. Thanks for doing this Roger. Minor nit: the convention > in jni.h seems to name functions that take JNIEnv* parameter with the > "JNU_" prefix and so might be better to rename CHECK_EXCEPTION to > JNU_CheckedException. > > Mandy > From dmavrodiev at gmail.com Sat Jan 11 04:58:48 2014 From: dmavrodiev at gmail.com (Dimitar Mavrodiev) Date: Sat, 11 Jan 2014 14:58:48 +0200 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: References: <52C93D4F.1050301@oracle.com> <52CABB44.8050801@oracle.com> <52CAD13F.2000408@oracle.com> <52CAD6D6.7000000@oracle.com> <52CADA4C.8000606@oracle.com> <52CBCF71.5020704@oracle.com> <52CC7360.1040507@oracle.com> Message-ID: Hi Alan, I finally had the chance to put together a windows build environment(Win7) and I'm now seeing the same error crop up every once in a while. To isolate the problem I replaced the socks server (jdk/test/java/net/Socks/SocksServer.java) I've been using in my test with JSocks and the test now runs successfully (I ran it at least a dozen of times). The culprit for these intermittent failures on Windows seems to be jdk/test/java/net/Socks/SocksServer.java, I haven't exactly located the problem yet. -Dimitar On Wed, Jan 8, 2014 at 12:08 PM, Dimitar Mavrodiev wrote: > Unfortunately I don't have a Windows environment. I'll try to setup one > and look into this. > > -Dimitar > > > On Tue, Jan 7, 2014 at 11:36 PM, Alan Bateman wrote: > >> On 07/01/2014 12:29, Dimitar Mavrodiev wrote: >> >>> Hi Alan, >>> >>> I've fixed that. Here's the webrev https://googledrive.com/host/ >>> 0B2CI6Ih--1t5bVVwbVlBRmpVMDg/4/index.html. >>> >>> Thanks for the update, it seems to be okay now for IPv6 disabled case. >> >> One thing I do see though is that the test fails intermittently on >> Windows (in my case Windows Server 2012) when IPv6 is enabled. The typical >> output is attached. I haven't dug into yet. >> >> -Alan >> >> [TestNG] Running: >> java/net/Socks/SocksIPv6Test.java >> >> config SocksIPv6Test.setUp(): success >> test SocksIPv6Test.testSocksOverIPv6(): failure >> java.net.SocketException: Reply from SOCKS server has bad length >> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:505) >> at java.net.Socket.connect(Socket.java:585) >> at java.net.Socket.connect(Socket.java:534) >> at sun.net.NetworkClient.doConnect(NetworkClient.java:180) >> at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) >> at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) >> at sun.net.www.http.HttpClient.(HttpClient.java:211) >> at sun.net.www.http.HttpClient.New(HttpClient.java:308) >> at sun.net.www.http.HttpClient.New(HttpClient.java:326) >> at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient( >> HttpURLConnection.java:1122) >> at sun.net.www.protocol.http.HttpURLConnection.plainConnect0( >> HttpURLConnection.java:1101) >> at sun.net.www.protocol.http.HttpURLConnection$6.run( >> HttpURLConnection.java:942) >> at sun.net.www.protocol.http.HttpURLConnection$6.run( >> HttpURLConnection.java:940) >> at java.security.AccessController.doPrivileged(Native Method) >> at java.security.AccessController.doPrivileged( >> AccessController.java:713) >> at sun.net.www.protocol.http.HttpURLConnection.plainConnect( >> HttpURLConnection.java:939) >> at sun.net.www.protocol.http.HttpURLConnection.connect( >> HttpURLConnection.java:886) >> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0( >> HttpURLConnection.java:1466) >> at sun.net.www.protocol.http.HttpURLConnection.access$200( >> HttpURLConnection.java:90) >> at sun.net.www.protocol.http.HttpURLConnection$9.run( >> HttpURLConnection.java:1386) >> at sun.net.www.protocol.http.HttpURLConnection$9.run( >> HttpURLConnection.java:1384) >> at java.security.AccessController.doPrivileged(Native Method) >> at java.security.AccessController.doPrivileged( >> AccessController.java:713) >> at sun.net.www.protocol.http.HttpURLConnection.getInputStream( >> HttpURLConnection.java:1383) >> at SocksIPv6Test.testSocksOverIPv6(SocksIPv6Test.java:133) >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140111/2097ec81/attachment.html From alan.bateman at oracle.com Mon Jan 13 08:21:07 2014 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 13 Jan 2014 16:21:07 +0000 Subject: hg: jdk8/tl/jaxws: 8027908: serialVersionUID of javax.xml.bind.TypeConstraintException accidently changed Message-ID: <20140113162119.3F8986240B@hg.openjdk.java.net> Changeset: bd943bdbce05 Author: alanb Date: 2014-01-13 16:17 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/bd943bdbce05 8027908: serialVersionUID of javax.xml.bind.TypeConstraintException accidently changed Reviewed-by: alanb Contributed-by: iaroslav.savytskyi at oracle.com ! src/share/jaxws_classes/javax/xml/bind/TypeConstraintException.java From chris.hegarty at oracle.com Mon Jan 13 11:29:07 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 13 Jan 2014 19:29:07 +0000 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: References: <52C93D4F.1050301@oracle.com> <52CABB44.8050801@oracle.com> <52CAD13F.2000408@oracle.com> <52CAD6D6.7000000@oracle.com> <52CADA4C.8000606@oracle.com> <52CBCF71.5020704@oracle.com> <52CC7360.1040507@oracle.com> Message-ID: On 13 Jan 2014, at 19:23, Dimitar Mavrodiev wrote: > Hi Chris, > > I can't open the link, but yet I wouldn't mind if you folded your patch into mine. How embarrassing. Our public facing server is temporarily offline so I copied the webrev to a temporary server just to verify it, then obviously forgot it was an internal link. Sorry about this. I?ll repost a mail when the public server is back online. -Chris. > > Thanks, > Dimitar > > Sent from my mobile device. > > On Jan 13, 2014 9:11 PM, "Chris Hegarty" wrote: > Hi Dimitar, > > Thank you for following up with this. I came to the same conclusion as you earlier today, though I noticed it because the test SocksServer was sending a single byte at a time, for the initial reply. > > I took your latest patch and applied a few minor cleanups, as follows: > http://t4.ie.oracle.com/~chhegar/webrevs/7100957/webrev.00/webrev/ > > If you agree, I?ll fold my patch into yours, run the changes through our automated build and test system, then push if all passes ok. > > -Chris. > > On 13 Jan 2014, at 18:21, Dimitar Mavrodiev wrote: > > > Hi Alan, > > > > I believe to have found and fixed what was causing the failures on Windows. Here's the webrev https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/5/index.html. > > > > I modified java.net.SocksSocketImpl#readSocksReply(..) so that it doesn't give up on reading after the 3rd attempt, but instead keeps on trying until a timeout occurs or end of stream is reached (much like DataInputStream#readFully(..)). > > > > -Dimitar > > > > On Sat, Jan 11, 2014 at 2:58 PM, Dimitar Mavrodiev wrote: > > Hi Alan, > > > > I finally had the chance to put together a windows build environment(Win7) and I'm now seeing the same error crop up every once in a while. > > > > To isolate the problem I replaced the socks server (jdk/test/java/net/Socks/SocksServer.java) I've been using in my test with JSocks and the test now runs successfully (I ran it at least a dozen of times). The culprit for these intermittent failures on Windows seems to be jdk/test/java/net/Socks/SocksServer.java, I haven't exactly located the problem yet. > > > > -Dimitar > > > > > > On Wed, Jan 8, 2014 at 12:08 PM, Dimitar Mavrodiev wrote: > > Unfortunately I don't have a Windows environment. I'll try to setup one and look into this. > > > > -Dimitar > > > > > > On Tue, Jan 7, 2014 at 11:36 PM, Alan Bateman wrote: > > On 07/01/2014 12:29, Dimitar Mavrodiev wrote: > > Hi Alan, > > > > I've fixed that. Here's the webrev https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/4/index.html. > > > > Thanks for the update, it seems to be okay now for IPv6 disabled case. > > > > One thing I do see though is that the test fails intermittently on Windows (in my case Windows Server 2012) when IPv6 is enabled. The typical output is attached. I haven't dug into yet. > > > > -Alan > > > > [TestNG] Running: > > java/net/Socks/SocksIPv6Test.java > > > > config SocksIPv6Test.setUp(): success > > test SocksIPv6Test.testSocksOverIPv6(): failure > > java.net.SocketException: Reply from SOCKS server has bad length > > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:505) > > at java.net.Socket.connect(Socket.java:585) > > at java.net.Socket.connect(Socket.java:534) > > at sun.net.NetworkClient.doConnect(NetworkClient.java:180) > > at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) > > at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) > > at sun.net.www.http.HttpClient.(HttpClient.java:211) > > at sun.net.www.http.HttpClient.New(HttpClient.java:308) > > at sun.net.www.http.HttpClient.New(HttpClient.java:326) > > at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1122) > > at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1101) > > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:942) > > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:940) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.security.AccessController.doPrivileged(AccessController.java:713) > > at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:939) > > at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:886) > > at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1466) > > at sun.net.www.protocol.http.HttpURLConnection.access$200(HttpURLConnection.java:90) > > at sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1386) > > at sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1384) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.security.AccessController.doPrivileged(AccessController.java:713) > > at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1383) > > at SocksIPv6Test.testSocksOverIPv6(SocksIPv6Test.java:133) > > > > > > > > > From dmavrodiev at gmail.com Mon Jan 13 11:23:52 2014 From: dmavrodiev at gmail.com (Dimitar Mavrodiev) Date: Mon, 13 Jan 2014 21:23:52 +0200 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: References: <52C93D4F.1050301@oracle.com> <52CABB44.8050801@oracle.com> <52CAD13F.2000408@oracle.com> <52CAD6D6.7000000@oracle.com> <52CADA4C.8000606@oracle.com> <52CBCF71.5020704@oracle.com> <52CC7360.1040507@oracle.com> Message-ID: Hi Chris, I can't open the link, but yet I wouldn't mind if you folded your patch into mine. Thanks, Dimitar Sent from my mobile device. On Jan 13, 2014 9:11 PM, "Chris Hegarty" wrote: > Hi Dimitar, > > Thank you for following up with this. I came to the same conclusion as you > earlier today, though I noticed it because the test SocksServer was sending > a single byte at a time, for the initial reply. > > I took your latest patch and applied a few minor cleanups, as follows: > http://t4.ie.oracle.com/~chhegar/webrevs/7100957/webrev.00/webrev/ > > If you agree, I?ll fold my patch into yours, run the changes through our > automated build and test system, then push if all passes ok. > > -Chris. > > On 13 Jan 2014, at 18:21, Dimitar Mavrodiev wrote: > > > Hi Alan, > > > > I believe to have found and fixed what was causing the failures on > Windows. Here's the webrev > https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/5/index.html. > > > > I modified java.net.SocksSocketImpl#readSocksReply(..) so that it > doesn't give up on reading after the 3rd attempt, but instead keeps on > trying until a timeout occurs or end of stream is reached (much like > DataInputStream#readFully(..)). > > > > -Dimitar > > > > On Sat, Jan 11, 2014 at 2:58 PM, Dimitar Mavrodiev > wrote: > > Hi Alan, > > > > I finally had the chance to put together a windows build > environment(Win7) and I'm now seeing the same error crop up every once in a > while. > > > > To isolate the problem I replaced the socks server > (jdk/test/java/net/Socks/SocksServer.java) I've been using in my test with > JSocks and the test now runs successfully (I ran it at least a dozen of > times). The culprit for these intermittent failures on Windows seems to be > jdk/test/java/net/Socks/SocksServer.java, I haven't exactly located the > problem yet. > > > > -Dimitar > > > > > > On Wed, Jan 8, 2014 at 12:08 PM, Dimitar Mavrodiev > wrote: > > Unfortunately I don't have a Windows environment. I'll try to setup one > and look into this. > > > > -Dimitar > > > > > > On Tue, Jan 7, 2014 at 11:36 PM, Alan Bateman > wrote: > > On 07/01/2014 12:29, Dimitar Mavrodiev wrote: > > Hi Alan, > > > > I've fixed that. Here's the webrev > https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/4/index.html. > > > > Thanks for the update, it seems to be okay now for IPv6 disabled case. > > > > One thing I do see though is that the test fails intermittently on > Windows (in my case Windows Server 2012) when IPv6 is enabled. The typical > output is attached. I haven't dug into yet. > > > > -Alan > > > > [TestNG] Running: > > java/net/Socks/SocksIPv6Test.java > > > > config SocksIPv6Test.setUp(): success > > test SocksIPv6Test.testSocksOverIPv6(): failure > > java.net.SocketException: Reply from SOCKS server has bad length > > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:505) > > at java.net.Socket.connect(Socket.java:585) > > at java.net.Socket.connect(Socket.java:534) > > at sun.net.NetworkClient.doConnect(NetworkClient.java:180) > > at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) > > at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) > > at sun.net.www.http.HttpClient.(HttpClient.java:211) > > at sun.net.www.http.HttpClient.New(HttpClient.java:308) > > at sun.net.www.http.HttpClient.New(HttpClient.java:326) > > at > sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1122) > > at > sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1101) > > at > sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:942) > > at > sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:940) > > at java.security.AccessController.doPrivileged(Native Method) > > at > java.security.AccessController.doPrivileged(AccessController.java:713) > > at > sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:939) > > at > sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:886) > > at > sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1466) > > at > sun.net.www.protocol.http.HttpURLConnection.access$200(HttpURLConnection.java:90) > > at > sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1386) > > at > sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1384) > > at java.security.AccessController.doPrivileged(Native Method) > > at > java.security.AccessController.doPrivileged(AccessController.java:713) > > at > sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1383) > > at SocksIPv6Test.testSocksOverIPv6(SocksIPv6Test.java:133) > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140113/8b1564a3/attachment.html From dmavrodiev at gmail.com Mon Jan 13 10:21:00 2014 From: dmavrodiev at gmail.com (Dimitar Mavrodiev) Date: Mon, 13 Jan 2014 20:21:00 +0200 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: References: <52C93D4F.1050301@oracle.com> <52CABB44.8050801@oracle.com> <52CAD13F.2000408@oracle.com> <52CAD6D6.7000000@oracle.com> <52CADA4C.8000606@oracle.com> <52CBCF71.5020704@oracle.com> <52CC7360.1040507@oracle.com> Message-ID: Hi Alan, I believe to have found and fixed what was causing the failures on Windows. Here's the webrev https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/5/index.html. I modified java.net.SocksSocketImpl#readSocksReply(..) so that it doesn't give up on reading after the 3rd attempt, but instead keeps on trying until a timeout occurs or end of stream is reached (much like DataInputStream#readFully(..)). -Dimitar On Sat, Jan 11, 2014 at 2:58 PM, Dimitar Mavrodiev wrote: > Hi Alan, > > I finally had the chance to put together a windows build environment(Win7) > and I'm now seeing the same error crop up every once in a while. > > To isolate the problem I replaced the socks server > (jdk/test/java/net/Socks/SocksServer.java) I've been using in my test with > JSocks and the test now runs successfully (I ran it at least a dozen of > times). The culprit for these intermittent failures on Windows seems to be > jdk/test/java/net/Socks/SocksServer.java, I haven't exactly located the > problem yet. > > -Dimitar > > > On Wed, Jan 8, 2014 at 12:08 PM, Dimitar Mavrodiev wrote: > >> Unfortunately I don't have a Windows environment. I'll try to setup one >> and look into this. >> >> -Dimitar >> >> >> On Tue, Jan 7, 2014 at 11:36 PM, Alan Bateman wrote: >> >>> On 07/01/2014 12:29, Dimitar Mavrodiev wrote: >>> >>>> Hi Alan, >>>> >>>> I've fixed that. Here's the webrev https://googledrive.com/host/ >>>> 0B2CI6Ih--1t5bVVwbVlBRmpVMDg/4/index.html. >>>> >>>> Thanks for the update, it seems to be okay now for IPv6 disabled case. >>> >>> One thing I do see though is that the test fails intermittently on >>> Windows (in my case Windows Server 2012) when IPv6 is enabled. The typical >>> output is attached. I haven't dug into yet. >>> >>> -Alan >>> >>> [TestNG] Running: >>> java/net/Socks/SocksIPv6Test.java >>> >>> config SocksIPv6Test.setUp(): success >>> test SocksIPv6Test.testSocksOverIPv6(): failure >>> java.net.SocketException: Reply from SOCKS server has bad length >>> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:505) >>> at java.net.Socket.connect(Socket.java:585) >>> at java.net.Socket.connect(Socket.java:534) >>> at sun.net.NetworkClient.doConnect(NetworkClient.java:180) >>> at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) >>> at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) >>> at sun.net.www.http.HttpClient.(HttpClient.java:211) >>> at sun.net.www.http.HttpClient.New(HttpClient.java:308) >>> at sun.net.www.http.HttpClient.New(HttpClient.java:326) >>> at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient( >>> HttpURLConnection.java:1122) >>> at sun.net.www.protocol.http.HttpURLConnection.plainConnect0( >>> HttpURLConnection.java:1101) >>> at sun.net.www.protocol.http.HttpURLConnection$6.run( >>> HttpURLConnection.java:942) >>> at sun.net.www.protocol.http.HttpURLConnection$6.run( >>> HttpURLConnection.java:940) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at java.security.AccessController.doPrivileged( >>> AccessController.java:713) >>> at sun.net.www.protocol.http.HttpURLConnection.plainConnect( >>> HttpURLConnection.java:939) >>> at sun.net.www.protocol.http.HttpURLConnection.connect( >>> HttpURLConnection.java:886) >>> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0( >>> HttpURLConnection.java:1466) >>> at sun.net.www.protocol.http.HttpURLConnection.access$200( >>> HttpURLConnection.java:90) >>> at sun.net.www.protocol.http.HttpURLConnection$9.run( >>> HttpURLConnection.java:1386) >>> at sun.net.www.protocol.http.HttpURLConnection$9.run( >>> HttpURLConnection.java:1384) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at java.security.AccessController.doPrivileged( >>> AccessController.java:713) >>> at sun.net.www.protocol.http.HttpURLConnection.getInputStream( >>> HttpURLConnection.java:1383) >>> at SocksIPv6Test.testSocksOverIPv6(SocksIPv6Test.java:133) >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140113/f1a862be/attachment-0001.html From chris.hegarty at oracle.com Mon Jan 13 11:11:15 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 13 Jan 2014 19:11:15 +0000 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: References: <52C93D4F.1050301@oracle.com> <52CABB44.8050801@oracle.com> <52CAD13F.2000408@oracle.com> <52CAD6D6.7000000@oracle.com> <52CADA4C.8000606@oracle.com> <52CBCF71.5020704@oracle.com> <52CC7360.1040507@oracle.com> Message-ID: Hi Dimitar, Thank you for following up with this. I came to the same conclusion as you earlier today, though I noticed it because the test SocksServer was sending a single byte at a time, for the initial reply. I took your latest patch and applied a few minor cleanups, as follows: http://t4.ie.oracle.com/~chhegar/webrevs/7100957/webrev.00/webrev/ If you agree, I?ll fold my patch into yours, run the changes through our automated build and test system, then push if all passes ok. -Chris. On 13 Jan 2014, at 18:21, Dimitar Mavrodiev wrote: > Hi Alan, > > I believe to have found and fixed what was causing the failures on Windows. Here's the webrev https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/5/index.html. > > I modified java.net.SocksSocketImpl#readSocksReply(..) so that it doesn't give up on reading after the 3rd attempt, but instead keeps on trying until a timeout occurs or end of stream is reached (much like DataInputStream#readFully(..)). > > -Dimitar > > On Sat, Jan 11, 2014 at 2:58 PM, Dimitar Mavrodiev wrote: > Hi Alan, > > I finally had the chance to put together a windows build environment(Win7) and I'm now seeing the same error crop up every once in a while. > > To isolate the problem I replaced the socks server (jdk/test/java/net/Socks/SocksServer.java) I've been using in my test with JSocks and the test now runs successfully (I ran it at least a dozen of times). The culprit for these intermittent failures on Windows seems to be jdk/test/java/net/Socks/SocksServer.java, I haven't exactly located the problem yet. > > -Dimitar > > > On Wed, Jan 8, 2014 at 12:08 PM, Dimitar Mavrodiev wrote: > Unfortunately I don't have a Windows environment. I'll try to setup one and look into this. > > -Dimitar > > > On Tue, Jan 7, 2014 at 11:36 PM, Alan Bateman wrote: > On 07/01/2014 12:29, Dimitar Mavrodiev wrote: > Hi Alan, > > I've fixed that. Here's the webrev https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/4/index.html. > > Thanks for the update, it seems to be okay now for IPv6 disabled case. > > One thing I do see though is that the test fails intermittently on Windows (in my case Windows Server 2012) when IPv6 is enabled. The typical output is attached. I haven't dug into yet. > > -Alan > > [TestNG] Running: > java/net/Socks/SocksIPv6Test.java > > config SocksIPv6Test.setUp(): success > test SocksIPv6Test.testSocksOverIPv6(): failure > java.net.SocketException: Reply from SOCKS server has bad length > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:505) > at java.net.Socket.connect(Socket.java:585) > at java.net.Socket.connect(Socket.java:534) > at sun.net.NetworkClient.doConnect(NetworkClient.java:180) > at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) > at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) > at sun.net.www.http.HttpClient.(HttpClient.java:211) > at sun.net.www.http.HttpClient.New(HttpClient.java:308) > at sun.net.www.http.HttpClient.New(HttpClient.java:326) > at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1122) > at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1101) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:942) > at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:940) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.AccessController.doPrivileged(AccessController.java:713) > at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:939) > at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:886) > at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1466) > at sun.net.www.protocol.http.HttpURLConnection.access$200(HttpURLConnection.java:90) > at sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1386) > at sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1384) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.AccessController.doPrivileged(AccessController.java:713) > at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1383) > at SocksIPv6Test.testSocksOverIPv6(SocksIPv6Test.java:133) > > > > From david.holmes at oracle.com Mon Jan 13 18:51:46 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Jan 2014 12:51:46 +1000 Subject: RFR: (8030875) Macros for checking and returning on exceptions In-Reply-To: <52D013B9.40101@oracle.com> References: <52D013B9.40101@oracle.com> Message-ID: <52D4A642.7090404@oracle.com> Hi Roger, On 11/01/2014 1:37 AM, roger riggs wrote: > Please review: > > To enable native code checking consistently for thrown exceptions, > the macros in net_util.h and java/util/jar/pack/coding.cpp are > made consolidated and promoted to jni_util.h > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ Do these macro definitions not cause "empty statement" warnings from the compiler? (Existing ones have the same problem I guess) Also I don't see any use of the CHECK_EXCEPTION macros? In fact the bulk of changes here seem completely unrelated to the "exception" aspect of this CR. Cheers, David > [1] https://bugs.openjdk.java.net/browse/JDK-8030875 From chris.hegarty at oracle.com Tue Jan 14 00:28:46 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 14 Jan 2014 08:28:46 +0000 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: References: <52C93D4F.1050301@oracle.com> <52CABB44.8050801@oracle.com> <52CAD13F.2000408@oracle.com> <52CAD6D6.7000000@oracle.com> <52CADA4C.8000606@oracle.com> <52CBCF71.5020704@oracle.com> <52CC7360.1040507@oracle.com> Message-ID: On 13 Jan 2014, at 19:29, Chris Hegarty wrote: > On 13 Jan 2014, at 19:23, Dimitar Mavrodiev wrote: > >> Hi Chris, >> >> I can't open the link, but yet I wouldn't mind if you folded your patch into mine. > > How embarrassing. Our public facing server is temporarily offline so I copied the webrev to a temporary server just to verify it, then obviously forgot it was an internal link. Sorry about this. I?ll repost a mail when the public server is back online. http://cr.openjdk.java.net/~chegar/7100957/webrev.00/webrev/ -Chris. > > -Chris. > >> >> Thanks, >> Dimitar >> >> Sent from my mobile device. >> >> On Jan 13, 2014 9:11 PM, "Chris Hegarty" wrote: >> Hi Dimitar, >> >> Thank you for following up with this. I came to the same conclusion as you earlier today, though I noticed it because the test SocksServer was sending a single byte at a time, for the initial reply. >> >> I took your latest patch and applied a few minor cleanups, as follows: >> http://t4.ie.oracle.com/~chhegar/webrevs/7100957/webrev.00/webrev/ >> >> If you agree, I?ll fold my patch into yours, run the changes through our automated build and test system, then push if all passes ok. >> >> -Chris. >> >> On 13 Jan 2014, at 18:21, Dimitar Mavrodiev wrote: >> >>> Hi Alan, >>> >>> I believe to have found and fixed what was causing the failures on Windows. Here's the webrev https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/5/index.html. >>> >>> I modified java.net.SocksSocketImpl#readSocksReply(..) so that it doesn't give up on reading after the 3rd attempt, but instead keeps on trying until a timeout occurs or end of stream is reached (much like DataInputStream#readFully(..)). >>> >>> -Dimitar >>> >>> On Sat, Jan 11, 2014 at 2:58 PM, Dimitar Mavrodiev wrote: >>> Hi Alan, >>> >>> I finally had the chance to put together a windows build environment(Win7) and I'm now seeing the same error crop up every once in a while. >>> >>> To isolate the problem I replaced the socks server (jdk/test/java/net/Socks/SocksServer.java) I've been using in my test with JSocks and the test now runs successfully (I ran it at least a dozen of times). The culprit for these intermittent failures on Windows seems to be jdk/test/java/net/Socks/SocksServer.java, I haven't exactly located the problem yet. >>> >>> -Dimitar >>> >>> >>> On Wed, Jan 8, 2014 at 12:08 PM, Dimitar Mavrodiev wrote: >>> Unfortunately I don't have a Windows environment. I'll try to setup one and look into this. >>> >>> -Dimitar >>> >>> >>> On Tue, Jan 7, 2014 at 11:36 PM, Alan Bateman wrote: >>> On 07/01/2014 12:29, Dimitar Mavrodiev wrote: >>> Hi Alan, >>> >>> I've fixed that. Here's the webrev https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/4/index.html. >>> >>> Thanks for the update, it seems to be okay now for IPv6 disabled case. >>> >>> One thing I do see though is that the test fails intermittently on Windows (in my case Windows Server 2012) when IPv6 is enabled. The typical output is attached. I haven't dug into yet. >>> >>> -Alan >>> >>> [TestNG] Running: >>> java/net/Socks/SocksIPv6Test.java >>> >>> config SocksIPv6Test.setUp(): success >>> test SocksIPv6Test.testSocksOverIPv6(): failure >>> java.net.SocketException: Reply from SOCKS server has bad length >>> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:505) >>> at java.net.Socket.connect(Socket.java:585) >>> at java.net.Socket.connect(Socket.java:534) >>> at sun.net.NetworkClient.doConnect(NetworkClient.java:180) >>> at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) >>> at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) >>> at sun.net.www.http.HttpClient.(HttpClient.java:211) >>> at sun.net.www.http.HttpClient.New(HttpClient.java:308) >>> at sun.net.www.http.HttpClient.New(HttpClient.java:326) >>> at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1122) >>> at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1101) >>> at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:942) >>> at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:940) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at java.security.AccessController.doPrivileged(AccessController.java:713) >>> at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:939) >>> at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:886) >>> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1466) >>> at sun.net.www.protocol.http.HttpURLConnection.access$200(HttpURLConnection.java:90) >>> at sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1386) >>> at sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1384) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at java.security.AccessController.doPrivileged(AccessController.java:713) >>> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1383) >>> at SocksIPv6Test.testSocksOverIPv6(SocksIPv6Test.java:133) >>> >>> >>> >>> >> > From dmavrodiev at gmail.com Tue Jan 14 00:47:04 2014 From: dmavrodiev at gmail.com (Dimitar Mavrodiev) Date: Tue, 14 Jan 2014 10:47:04 +0200 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: References: <52C93D4F.1050301@oracle.com> <52CABB44.8050801@oracle.com> <52CAD13F.2000408@oracle.com> <52CAD6D6.7000000@oracle.com> <52CADA4C.8000606@oracle.com> <52CBCF71.5020704@oracle.com> <52CC7360.1040507@oracle.com> Message-ID: Hi Chris, I agree with those changes. Thank you and Alan for sponsoring this patch. On Tue, Jan 14, 2014 at 10:28 AM, Chris Hegarty wrote: > On 13 Jan 2014, at 19:29, Chris Hegarty wrote: > > > On 13 Jan 2014, at 19:23, Dimitar Mavrodiev > wrote: > > > >> Hi Chris, > >> > >> I can't open the link, but yet I wouldn't mind if you folded your patch > into mine. > > > > How embarrassing. Our public facing server is temporarily offline so I > copied the webrev to a temporary server just to verify it, then obviously > forgot it was an internal link. Sorry about this. I?ll repost a mail when > the public server is back online. > > http://cr.openjdk.java.net/~chegar/7100957/webrev.00/webrev/ > > -Chris. > > > > > -Chris. > > > >> > >> Thanks, > >> Dimitar > >> > >> Sent from my mobile device. > >> > >> On Jan 13, 2014 9:11 PM, "Chris Hegarty" > wrote: > >> Hi Dimitar, > >> > >> Thank you for following up with this. I came to the same conclusion as > you earlier today, though I noticed it because the test SocksServer was > sending a single byte at a time, for the initial reply. > >> > >> I took your latest patch and applied a few minor cleanups, as follows: > >> http://t4.ie.oracle.com/~chhegar/webrevs/7100957/webrev.00/webrev/ > >> > >> If you agree, I?ll fold my patch into yours, run the changes through > our automated build and test system, then push if all passes ok. > >> > >> -Chris. > >> > >> On 13 Jan 2014, at 18:21, Dimitar Mavrodiev > wrote: > >> > >>> Hi Alan, > >>> > >>> I believe to have found and fixed what was causing the failures on > Windows. Here's the webrev > https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/5/index.html. > >>> > >>> I modified java.net.SocksSocketImpl#readSocksReply(..) so that it > doesn't give up on reading after the 3rd attempt, but instead keeps on > trying until a timeout occurs or end of stream is reached (much like > DataInputStream#readFully(..)). > >>> > >>> -Dimitar > >>> > >>> On Sat, Jan 11, 2014 at 2:58 PM, Dimitar Mavrodiev < > dmavrodiev at gmail.com> wrote: > >>> Hi Alan, > >>> > >>> I finally had the chance to put together a windows build > environment(Win7) and I'm now seeing the same error crop up every once in a > while. > >>> > >>> To isolate the problem I replaced the socks server > (jdk/test/java/net/Socks/SocksServer.java) I've been using in my test with > JSocks and the test now runs successfully (I ran it at least a dozen of > times). The culprit for these intermittent failures on Windows seems to be > jdk/test/java/net/Socks/SocksServer.java, I haven't exactly located the > problem yet. > >>> > >>> -Dimitar > >>> > >>> > >>> On Wed, Jan 8, 2014 at 12:08 PM, Dimitar Mavrodiev < > dmavrodiev at gmail.com> wrote: > >>> Unfortunately I don't have a Windows environment. I'll try to setup > one and look into this. > >>> > >>> -Dimitar > >>> > >>> > >>> On Tue, Jan 7, 2014 at 11:36 PM, Alan Bateman > wrote: > >>> On 07/01/2014 12:29, Dimitar Mavrodiev wrote: > >>> Hi Alan, > >>> > >>> I've fixed that. Here's the webrev > https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/4/index.html. > >>> > >>> Thanks for the update, it seems to be okay now for IPv6 disabled case. > >>> > >>> One thing I do see though is that the test fails intermittently on > Windows (in my case Windows Server 2012) when IPv6 is enabled. The typical > output is attached. I haven't dug into yet. > >>> > >>> -Alan > >>> > >>> [TestNG] Running: > >>> java/net/Socks/SocksIPv6Test.java > >>> > >>> config SocksIPv6Test.setUp(): success > >>> test SocksIPv6Test.testSocksOverIPv6(): failure > >>> java.net.SocketException: Reply from SOCKS server has bad length > >>> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:505) > >>> at java.net.Socket.connect(Socket.java:585) > >>> at java.net.Socket.connect(Socket.java:534) > >>> at sun.net.NetworkClient.doConnect(NetworkClient.java:180) > >>> at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) > >>> at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) > >>> at sun.net.www.http.HttpClient.(HttpClient.java:211) > >>> at sun.net.www.http.HttpClient.New(HttpClient.java:308) > >>> at sun.net.www.http.HttpClient.New(HttpClient.java:326) > >>> at > sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1122) > >>> at > sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1101) > >>> at > sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:942) > >>> at > sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:940) > >>> at java.security.AccessController.doPrivileged(Native Method) > >>> at > java.security.AccessController.doPrivileged(AccessController.java:713) > >>> at > sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:939) > >>> at > sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:886) > >>> at > sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1466) > >>> at > sun.net.www.protocol.http.HttpURLConnection.access$200(HttpURLConnection.java:90) > >>> at > sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1386) > >>> at > sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1384) > >>> at java.security.AccessController.doPrivileged(Native Method) > >>> at > java.security.AccessController.doPrivileged(AccessController.java:713) > >>> at > sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1383) > >>> at SocksIPv6Test.testSocksOverIPv6(SocksIPv6Test.java:133) > >>> > >>> > >>> > >>> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140114/68295101/attachment-0001.html From Alan.Bateman at oracle.com Tue Jan 14 01:19:20 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Jan 2014 09:19:20 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: Message-ID: <52D50118.3080000@oracle.com> On 14/01/2014 08:40, Volker Simonis wrote: > Hi, > > could you please review the following changes for the ppc-aix-port > stage/stage-9 repositories (the changes are planned for integration > into ppc-aix-port/stage-9 and subsequent backporting to > ppc-aix-port/stage): I'd like to review this but I won't have time until later in the week. From an initial look then there are a few things are not pretty (the changes to fix the AIX problems with I/O cancellation in particular) and I suspect that some refactoring is going to be required to handle some of this cleanly. A minor comment is that bug synopsis doesn't really communicate what these changes are about. -Alan. From volker.simonis at gmail.com Tue Jan 14 00:40:55 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Jan 2014 09:40:55 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests Message-ID: Hi, could you please review the following changes for the ppc-aix-port stage/stage-9 repositories (the changes are planned for integration into ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): http://cr.openjdk.java.net/~simonis/webrevs/8031581/ I've build and smoke tested without any problems on Linux/x86_64 and PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. With these changes (and together with the changes from "8028537: PPC64: Updated jdk/test scripts to understand the AIX os and environment" and "8031134 : PPC64: implement printing on AIX") our port passes all but the following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 baseline from www.java.net/download/jdk8/testresults/testresults.html?): java/net/Inet6Address/B6558853.java java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) java/nio/channels/Selector/RacyDeregister.java sun/security/krb5/auto/Unreachable.java (only on IPv6) Thank you and best regards, Volker Following a detailed description of the various changes: src/share/native/java/util/zip/zip_util.c src/share/native/sun/management/DiagnosticCommandImpl.c - According to ISO C it is perfectly legal for malloc to return zero if called with a zero argument. Fix various places where malloc can potentially correctly return zero because it was called with a zero argument. - Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a compiler warning on Linux, but on AIX it prevents a VM crash later on because the return value of malloc() will be casted to int which is especially bad if that pointer was bigger than 32-bit. make/CompileJavaClasses.gmk - Also use PollingWatchService on AIX. make/lib/NioLibraries.gmk src/aix/native/sun/nio/ch/AixNativeThread.c - Put the implementation for the native methods of NativeThread into AixNativeThread.c on AIX. src/solaris/native/sun/nio/ch/PollArrayWrapper.c src/solaris/native/sun/nio/ch/Net.c src/aix/classes/sun/nio/ch/AixPollPort.java src/aix/native/sun/nio/ch/AixPollPort.c src/aix/native/java/net/aix_close.c - On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, ...) are defined to different values than on other operating systems. The problem is however, that these constants are hardcoded as public final static members of various, shared Java classes. We therefore have to map them from Java to native every time before calling one of the native poll functions and back to Java after the call on AIX in order to get the right semantics. src/share/classes/java/nio/file/CopyMoveHelper.java - As discussed on the core-libs mailing list (see http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) it is not necessary to call Files.getFileAttributeView() with any linkOptions because at that place we've already checked that the target file can not be a symbolic link. This change makes the implementation more robust on platforms which support symbolic links but do not support the O_NOFOLLOW flag to the open system call. It also makes the JDK pass the demo/zipfs/basic.sh test on AIX. src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java - Support "compound text" on AIX in the same way like on other Unix platforms. src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider - Define the correct attach provider for AIX. src/solaris/native/java/net/net_util_md.h src/solaris/native/sun/nio/ch/FileDispatcherImpl.c src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c - AIX needs a workaround for I/O cancellation (see: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). "..The close() subroutine is blocked until all subroutines which use the file descriptor return to usr space. For example, when a thread is calling close and another thread is calling select with the same file descriptor, the close subroutine does not return until the select call returns...". To fix this problem, we have to use the various NET_ wrappers which are declared in net_util_md.h and defined in aix_close.c and we also need some additional wrappers for fcntl(), read() and write() on AIX. While the current solution isn't really nice because it introduces some more AIX-specifc sections in shared code, I think it is the best way to go for JDK 8 because it imposes the smallest possible changes and risks for the existing platforms. I'm ready to change the code to unconditionally use the wrappers for all platforms and implement the wrappers empty on platforms which don't need any wrapping. I think it would also be nice to clean up the names (e.g. NET_Read() is currently a wrapper for recv()and the NET_ prefix is probably not appropriate any more so maybe change it to something like IO_). But again, I'll prefer to keep that as a follow up change for JDK9. - Calling fsync() on a "read-only" file descriptor on AIX will result in an error (i.e. "EBADF: The FileDescriptor parameter is not a valid file descriptor open for writing."). To prevent this error we have to query if the corresponding file descriptor is writeable. Notice that at that point we can not access the writable attribute of the corresponding file channel so we have to use fcntl(). src/solaris/classes/java/lang/UNIXProcess.java.aix - On AIX the implementation is especially tricky, because the close()system call will block if another thread is at the same time blocked in a file operation (e.g. 'read()') on the same file descriptor. We therefore combine the AIX ProcessPipeInputStream implemenatation with the DeferredCloseInputStream approach used on Solaris (see UNIXProcess.java.solaris). This means that every potentially blocking operation on the file descriptor increments a counter before it is executed and decrements it once it finishes. The 'close()' operation will only be executed if there are no pending operations. Otherwise it is deferred after the last pending operation has finished. src/share/transport/socket/socketTransport.c - On AIX we have to call shutdown() on a socket descriptor before closing it, otherwise the close() call may be blocked. This is the same problem as described before. Unfortunately the JDI framework doesn't use the same IO wrappers like other class library components so we can not easily use the NET_ abstractions from aix_close.c here. - Without this small change all JDI regression tests will fail on AIX because of the way how the tests act as a "debugger" which launches another VM (the "debugge") which connects itself back to the debugger. In this scenario the "debugge" can not shut down itself because one thread will always be blocked in the close() call on one of the communication sockets. src/solaris/native/java/net/NetworkInterface.c - Set the scope identifier for IPv6 addresses on AIX. src/solaris/native/java/net/net_util_md.c - It turns out that we do not always have to replace SO_REUSEADDR on AIX by SO_REUSEPORT. Instead we can simply use the same approach like BSD and only use SO_REUSEPORT additionally, if several datagram sockets try to bind to the same port. - Also fixed a comment and removed unused local variables. - Fixed the obviously inverted assignment newTime = prevTime; which should read prevTime = newTime;. Otherwise prevTime will never change and the timeout will be potential reached too fast. src/solaris/native/sun/management/OperatingSystemImpl.c - AIX does not understand /proc/self so we have to query the real process ID to access the proc file system. src/solaris/native/sun/nio/ch/DatagramChannelImpl.c - On AIX, connect() may legally return EAFNOSUPPORT if called on a socket with the address family set to AF_UNSPEC. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140114/866bb06d/attachment-0001.html From volker.simonis at gmail.com Tue Jan 14 01:56:55 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Jan 2014 10:56:55 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D50118.3080000@oracle.com> References: <52D50118.3080000@oracle.com> Message-ID: Hi Alan, On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman wrote: > On 14/01/2014 08:40, Volker Simonis wrote: > >> Hi, >> >> could you please review the following changes for the ppc-aix-port >> stage/stage-9 repositories (the changes are planned for integration into >> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> > > I'd like to review this but I won't have time until later in the week. Thanks, that would be great. > From an initial look then there are a few things are not pretty (the > changes to fix the AIX problems with I/O cancellation in particular) and I > suspect that some refactoring is going to be required to handle some of > this cleanly. I agree, but as I wrote, this change is intended to finally go into both jdk9 and jkd8u and I didn't wanted to do to much refactoring for jdk8u. Once its in and we have a working port I'd be happy to work on refactoring the code but I think this should be done in jdk9 where we have more time and less risks of changing the behaviour on the existing platforms. > A minor comment is that bug synopsis doesn't really communicate what these > changes are about. > > This is the last "bulk change" which address issues in several different areas of the class library. Follow up changes will be more specific with better bug synopsis (I promise :). Regards, Volker > -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140114/0f098ab3/attachment-0001.html From Alan.Bateman at oracle.com Tue Jan 14 02:51:44 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Jan 2014 10:51:44 +0000 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: References: <52CAD13F.2000408@oracle.com> <52CAD6D6.7000000@oracle.com> <52CADA4C.8000606@oracle.com> <52CBCF71.5020704@oracle.com> <52CC7360.1040507@oracle.com> Message-ID: <52D516C0.2090405@oracle.com> On 14/01/2014 08:28, Chris Hegarty wrote: > On 13 Jan 2014, at 19:29, Chris Hegarty wrote: > >> On 13 Jan 2014, at 19:23, Dimitar Mavrodiev wrote: >> >>> Hi Chris, >>> >>> I can't open the link, but yet I wouldn't mind if you folded your patch into mine. >> How embarrassing. Our public facing server is temporarily offline so I copied the webrev to a temporary server just to verify it, then obviously forgot it was an internal link. Sorry about this. I?ll repost a mail when the public server is back online. > http://cr.openjdk.java.net/~chegar/7100957/webrev.00/webrev/ > The Buffered*, flush and try-with-resource changes look good. So will there be a combined webrev with everything? Also about about Dimi's change to readSocksReply to handle fragmentation, should that be included too? -Alan. From chris.hegarty at oracle.com Tue Jan 14 02:53:46 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 14 Jan 2014 10:53:46 +0000 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: <52D516C0.2090405@oracle.com> References: <52CAD13F.2000408@oracle.com> <52CAD6D6.7000000@oracle.com> <52CADA4C.8000606@oracle.com> <52CBCF71.5020704@oracle.com> <52CC7360.1040507@oracle.com> <52D516C0.2090405@oracle.com> Message-ID: <3D81B22E-73D3-43B3-9238-AB9A65CC23BF@oracle.com> On 14 Jan 2014, at 10:51, Alan Bateman wrote: > On 14/01/2014 08:28, Chris Hegarty wrote: >> On 13 Jan 2014, at 19:29, Chris Hegarty wrote: >> >>> On 13 Jan 2014, at 19:23, Dimitar Mavrodiev wrote: >>> >>>> Hi Chris, >>>> >>>> I can't open the link, but yet I wouldn't mind if you folded your patch into mine. >>> How embarrassing. Our public facing server is temporarily offline so I copied the webrev to a temporary server just to verify it, then obviously forgot it was an internal link. Sorry about this. I?ll repost a mail when the public server is back online. >> http://cr.openjdk.java.net/~chegar/7100957/webrev.00/webrev/ >> > The Buffered*, flush and try-with-resource changes look good. So will there be a combined webrev with everything? Also about about Dimi's change to readSocksReply to handle fragmentation, should that be included too? Yes, it is in my patch queue. I just created the diffs on top of that. I will fold the patches into one and can re-post the updated webrev. -Chris. > > -Alan. From david.holmes at oracle.com Tue Jan 14 03:29:48 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Jan 2014 21:29:48 +1000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: Message-ID: <52D51FAC.8060800@oracle.com> Just a note on this part (I havent looked at the code): > On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, ...) are defined to different values than on other operating systems. The problem is however, that these constants are hardcoded as public final static members of various, shared Java classes. Sounds like this should be handled the same way that the other "system constants" are handled - you can either store a platform file in the repo (for cross-compiling) or you generate the class containing the constants at build time. David On 14/01/2014 6:40 PM, Volker Simonis wrote: > Hi, > > could you please review the following changes for the ppc-aix-port > stage/stage-9 repositories (the changes are planned for integration into > ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > > http://cr.openjdk.java.net/~simonis/webrevs/8031581/ > > I've build and smoke tested without any problems on Linux/x86_64 and > PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. > > With these changes (and together with the changes from "8028537: PPC64: > Updated jdk/test scripts to understand the AIX os and environment" and > "8031134 : PPC64: implement printing on AIX") our port passes all but > the following 7 jtreg regression tests on AIX (compared to the > Linux/x86_64 baseline from > www.java.net/download/jdk8/testresults/testresults.html > ?): > > java/net/Inet6Address/B6558853.java > java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) > java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java > java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) > java/nio/channels/Selector/RacyDeregister.java > sun/security/krb5/auto/Unreachable.java (only on IPv6) > > Thank you and best regards, > Volker > > > Following a detailed description of the various changes: > > > src/share/native/java/util/zip/zip_util.c > src/share/native/sun/management/DiagnosticCommandImpl.c > > * According to ISO C it is perfectly legal for malloc to return zero > if called with a zero argument. Fix various places where malloc can > potentially correctly return zero because it was called with a zero > argument. > * Also fixed |DiagnosticCommandImpl.c| to include |stdlib.h|. This > only fixes a compiler warning on Linux, but on AIX it prevents a VM > crash later on because the return value of |malloc()| will be casted > to |int| which is especially bad if that pointer was bigger than > 32-bit. > > > make/CompileJavaClasses.gmk > > * Also use |PollingWatchService| on AIX. > > > make/lib/NioLibraries.gmk > src/aix/native/sun/nio/ch/AixNativeThread.c > > * Put the implementation for the native methods of |NativeThread| into > |AixNativeThread.c| on AIX. > > > src/solaris/native/sun/nio/ch/PollArrayWrapper.c > src/solaris/native/sun/nio/ch/Net.c > src/aix/classes/sun/nio/ch/AixPollPort.java > src/aix/native/sun/nio/ch/AixPollPort.c > src/aix/native/java/net/aix_close.c > > * On AIX, the constants used for the polling events (i.e. |POLLIN|, > |POLLOUT|, ...) are defined to different values than on other > operating systems. The problem is however, that these constants are > hardcoded as public final static members of various, shared Java > classes. We therefore have to map them from Java to native every > time before calling one of the native poll functions and back to > Java after the call on AIX in order to get the right semantics. > > > src/share/classes/java/nio/file/CopyMoveHelper.java > > * As discussed on the core-libs mailing list (see > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) > it is not necessary to call |Files.getFileAttributeView()| with any > |linkOptions| because at that place we've already checked that the > target file can not be a symbolic link. This change makes the > implementation more robust on platforms which support symbolic links > but do not support the |O_NOFOLLOW| flag to the |open| system call. > It also makes the JDK pass the |demo/zipfs/basic.sh| test on AIX. > > > src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java > > * Support "compound text" on AIX in the same way like on other Unix > platforms. > > > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > > * Define the correct attach provider for AIX. > > > src/solaris/native/java/net/net_util_md.h > src/solaris/native/sun/nio/ch/FileDispatcherImpl.c > src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c > > * AIX needs a workaround for I/O cancellation (see: > http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). > "..The |close()| subroutine is blocked until all subroutines which > use the file descriptor return to usr space. For example, when a > thread is calling close and another thread is calling select with > the same file descriptor, the close subroutine does not return until > the select call returns...". To fix this problem, we have to use the > various |NET_| wrappers which are declared in |net_util_md.h| and > defined in |aix_close.c| and we also need some additional wrappers > for |fcntl()|, |read()| and |write()| on AIX. > While the current solution isn't really nice because it introduces > some more AIX-specifc sections in shared code, I think it is the > best way to go for JDK 8 because it imposes the smallest possible > changes and risks for the existing platforms. I'm ready to change > the code to unconditionally use the wrappers for all platforms and > implement the wrappers empty on platforms which don't need any > wrapping. I think it would also be nice to clean up the names (e.g. > |NET_Read()| is currently a wrapper for |recv()| and the |NET_| > prefix is probably not appropriate any more so maybe change it to > something like |IO_|). But again, I'll prefer to keep that as a > follow up change for JDK9. > * Calling |fsync()| on a "read-only" file descriptor on AIX will > result in an error (i.e. "EBADF: The FileDescriptor parameter is not > a valid file descriptor open for writing."). To prevent this error > we have to query if the corresponding file descriptor is writeable. > Notice that at that point we can not access the |writable| attribute > of the corresponding file channel so we have to use |fcntl()|. > > > src/solaris/classes/java/lang/UNIXProcess.java.aix > > * On AIX the implementation is especially tricky, because the > |close()| system call will block if another thread is at the same > time blocked in a file operation (e.g. 'read()') on the same file > descriptor. We therefore combine the AIX |ProcessPipeInputStream| > implemenatation with the |DeferredCloseInputStream| approach used on > Solaris (see |UNIXProcess.java.solaris|). This means that every > potentially blocking operation on the file descriptor increments a > counter before it is executed and decrements it once it finishes. > The 'close()' operation will only be executed if there are no > pending operations. Otherwise it is deferred after the last pending > operation has finished. > > > src/share/transport/socket/socketTransport.c > > * On AIX we have to call |shutdown()| on a socket descriptor before > closing it, otherwise the |close()| call may be blocked. This is the > same problem as described before. Unfortunately the JDI framework > doesn't use the same IO wrappers like other class library components > so we can not easily use the |NET_| abstractions from |aix_close.c| > here. > * Without this small change all JDI regression tests will fail on AIX > because of the way how the tests act as a "debugger" which launches > another VM (the "debugge") which connects itself back to the > debugger. In this scenario the "debugge" can not shut down itself > because one thread will always be blocked in the |close()| call on > one of the communication sockets. > > > src/solaris/native/java/net/NetworkInterface.c > > * Set the scope identifier for IPv6 addresses on AIX. > > > src/solaris/native/java/net/net_util_md.c > > * It turns out that we do not always have to replace |SO_REUSEADDR| on > AIX by |SO_REUSEPORT|. Instead we can simply use the same approach > like BSD and only use |SO_REUSEPORT| additionally, if several > datagram sockets try to bind to the same port. > * Also fixed a comment and removed unused local variables. > * Fixed the obviously inverted assignment |newTime = prevTime;| which > should read |prevTime = newTime;|. Otherwise |prevTime| will never > change and the timeout will be potential reached too fast. > > > src/solaris/native/sun/management/OperatingSystemImpl.c > > * AIX does not understand |/proc/self| so we have to query the real > process ID to access the proc file system. > > > src/solaris/native/sun/nio/ch/DatagramChannelImpl.c > > * On AIX, |connect()| may legally return |EAFNOSUPPORT| if called on a > socket with the address family set to |AF_UNSPEC|. > > From roger.riggs at oracle.com Tue Jan 14 07:54:37 2014 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 14 Jan 2014 10:54:37 -0500 Subject: RFR: (8030875) Macros for checking and returning on exceptions In-Reply-To: <52D4A642.7090404@oracle.com> References: <52D013B9.40101@oracle.com> <52D4A642.7090404@oracle.com> Message-ID: <52D55DBD.3030502@oracle.com> Hi David, The CHECK_RETURN macros have existed in java.net for some time and I have not seen any empty statement warnings. The CHECK_EXCEPTION macros are new and does not have any uses yet. I don't plan to do any wholesale modification of current sources. The macros always produce a valid statement; (though my c/c++ may be a bit rusty). (Note that it has been requested to rename the macros to include a JNU_prefix to be consistent with other macros in jni_util.h. I will propose a separate set of changes for that). Roger On 1/13/2014 9:51 PM, David Holmes wrote: > Hi Roger, > >> webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ > > Do these macro definitions not cause "empty statement" warnings from > the compiler? (Existing ones have the same problem I guess) > > Also I don't see any use of the CHECK_EXCEPTION macros? In fact the > bulk of changes here seem completely unrelated to the "exception" > aspect of this CR. > > Cheers, > David > >> [1] https://bugs.openjdk.java.net/browse/JDK-8030875 From chris.hegarty at oracle.com Tue Jan 14 08:23:25 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 14 Jan 2014 16:23:25 +0000 Subject: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6 In-Reply-To: <3D81B22E-73D3-43B3-9238-AB9A65CC23BF@oracle.com> References: <52CAD13F.2000408@oracle.com> <52CAD6D6.7000000@oracle.com> <52CADA4C.8000606@oracle.com> <52CBCF71.5020704@oracle.com> <52CC7360.1040507@oracle.com> <52D516C0.2090405@oracle.com> <3D81B22E-73D3-43B3-9238! -AB9A65CC23BF@oracle.com> Message-ID: <1B7F90C8-4417-47F1-8EC4-4C7E10076ABC@oracle.com> On 14 Jan 2014, at 10:53, Chris Hegarty wrote: > On 14 Jan 2014, at 10:51, Alan Bateman wrote: > >> On 14/01/2014 08:28, Chris Hegarty wrote: >>> On 13 Jan 2014, at 19:29, Chris Hegarty wrote: >>> >>>> On 13 Jan 2014, at 19:23, Dimitar Mavrodiev wrote: >>>> >>>>> Hi Chris, >>>>> >>>>> I can't open the link, but yet I wouldn't mind if you folded your patch into mine. >>>> How embarrassing. Our public facing server is temporarily offline so I copied the webrev to a temporary server just to verify it, then obviously forgot it was an internal link. Sorry about this. I?ll repost a mail when the public server is back online. >>> http://cr.openjdk.java.net/~chegar/7100957/webrev.00/webrev/ >>> >> The Buffered*, flush and try-with-resource changes look good. So will there be a combined webrev with everything? Also about about Dimi's change to readSocksReply to handle fragmentation, should that be included too? > > Yes, it is in my patch queue. I just created the diffs on top of that. I will fold the patches into one and can re-post the updated webrev. For the archives: http://cr.openjdk.java.net/~chegar/7100957/webrev.01/ -Chris. > > -Chris. > >> >> -Alan. > From martinrb at google.com Tue Jan 14 14:20:27 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 14 Jan 2014 14:20:27 -0800 Subject: RFR: (8030875) Macros for checking and returning on exceptions In-Reply-To: <52D55DBD.3030502@oracle.com> References: <52D013B9.40101@oracle.com> <52D4A642.7090404@oracle.com> <52D55DBD.3030502@oracle.com> Message-ID: On Tue, Jan 14, 2014 at 7:54 AM, roger riggs wrote: > Hi David, > > The CHECK_RETURN macros have existed in java.net for some time and > I have not seen any empty statement warnings. > > The CHECK_EXCEPTION macros are new and does not have any uses yet. > I don't plan to do any wholesale modification of current sources. > > The macros always produce a valid statement; (though my c/c++ may be a > bit rusty). > > Macros should not generally be complete statements, including semicolons; then the source code looks like this: FOO() which looks (including to emacs) like someone forgot the trailing semicolon. Instead, these macros should be written using the "well-known" do ( ... ) while (0) idiom, e.g. #define CHECK_NULL(x) do { if ((x) == NULL) return; } while (0) > (Note that it has been requested to rename the macros to include a > JNU_prefix > to be consistent with other macros in jni_util.h. I will propose a > separate set of changes for that). > > Roger > > > On 1/13/2014 9:51 PM, David Holmes wrote: > >> Hi Roger, >> >> >> webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/ >>> >> >> Do these macro definitions not cause "empty statement" warnings from the >> compiler? (Existing ones have the same problem I guess) >> >> Also I don't see any use of the CHECK_EXCEPTION macros? In fact the bulk >> of changes here seem completely unrelated to the "exception" aspect of this >> CR. >> >> Cheers, >> David >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8030875 >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140114/2d0728c8/attachment.html From david.holmes at oracle.com Tue Jan 14 22:24:32 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Jan 2014 16:24:32 +1000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D51FAC.8060800@oracle.com> Message-ID: <52D629A0.4080806@oracle.com> On 15/01/2014 12:10 AM, Volker Simonis wrote: > On Tue, Jan 14, 2014 at 12:29 PM, David Holmes > wrote: > > Just a note on this part (I havent looked at the code): > > > On AIX, the constants used for the polling events (i.e. POLLIN, > POLLOUT, ...) are defined to different values than on other > operating systems. The problem is however, that these constants > are hardcoded as public final static members of various, shared > Java classes. > > > Sounds like this should be handled the same way that the other > "system constants" are handled - you can either store a platform > file in the repo (for cross-compiling) or you generate the class > containing the constants at build time. > > > Hi David, > > thanks for your comments. That sound like a good idea but I'm not sure > if it would make sense to duplicate the following files: > > src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java: > src/solaris/classes/sun/nio/ch/Port.java > > because of this. Do you have a concrete example where Java-classes are > being generated with different constants in the class library build? There are two files generated: UnixConstants.java (or SolarisConstants.java) for general I/O type values SocketOptionRegistry.java for socket options. See jdk/make/gensrc/GensrcMisc.gmk. > Both solutions would result in different class files on Aix and other > Unix variants. What do you think about assigning the concrete values > depending on 'os.name ' in the static initializers of > the corresponding classes? I think that shouldn't introduce too much > overhead and I could get rid of all the ugly conversion code. I'm not a fan of runtime checks of this kind though if it is only a very samll number of values it might be okay. Another option would be to make those classes into "templates" as done with Version.java.template and substitute the right values at build time. But I'll let Alan and net-dev folk come back with their preferred technique for this. Cheers, David > > Regards, > Volker > > David > > > On 14/01/2014 6:40 PM, Volker Simonis wrote: > > Hi, > > could you please review the following changes for the ppc-aix-port > stage/stage-9 repositories (the changes are planned for > integration into > ppc-aix-port/stage-9 and subsequent backporting to > ppc-aix-port/stage): > > http://cr.openjdk.java.net/~__simonis/webrevs/8031581/ > > > I've build and smoke tested without any problems on Linux/x86_64 and > PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. > > With these changes (and together with the changes from "8028537: > PPC64: > Updated jdk/test scripts to understand the AIX os and > environment" and > "8031134 : PPC64: implement printing on AIX") our port passes > all but > the following 7 jtreg regression tests on AIX (compared to the > Linux/x86_64 baseline from > www.java.net/download/jdk8/__testresults/testresults.html > > >?): > > > java/net/Inet6Address/__B6558853.java > java/nio/channels/__AsynchronousChannelGroup/__Basic.java > (sporadically) > java/nio/channels/__AsynchronousChannelGroup/__GroupOfOne.java > java/nio/channels/__AsynchronousChannelGroup/__Unbounded.java > (sporadically) > java/nio/channels/Selector/__RacyDeregister.java > sun/security/krb5/auto/__Unreachable.java (only on IPv6) > > Thank you and best regards, > Volker > > > Following a detailed description of the various changes: > > > src/share/native/java/util/__zip/zip_util.c > src/share/native/sun/__management/__DiagnosticCommandImpl.c > > * According to ISO C it is perfectly legal for malloc to > return zero > > if called with a zero argument. Fix various places where > malloc can > potentially correctly return zero because it was called > with a zero > argument. > * Also fixed |DiagnosticCommandImpl.c| to include |stdlib.h|. > This > > only fixes a compiler warning on Linux, but on AIX it > prevents a VM > crash later on because the return value of |malloc()| will > be casted > to |int| which is especially bad if that pointer was bigger > than > 32-bit. > > > make/CompileJavaClasses.gmk > > * Also use |PollingWatchService| on AIX. > > > make/lib/NioLibraries.gmk > src/aix/native/sun/nio/ch/__AixNativeThread.c > > * Put the implementation for the native methods of > |NativeThread| into > > |AixNativeThread.c| on AIX. > > > src/solaris/native/sun/nio/ch/__PollArrayWrapper.c > src/solaris/native/sun/nio/ch/__Net.c > src/aix/classes/sun/nio/ch/__AixPollPort.java > src/aix/native/sun/nio/ch/__AixPollPort.c > src/aix/native/java/net/aix___close.c > > * On AIX, the constants used for the polling events (i.e. > |POLLIN|, > |POLLOUT|, ...) are defined to different values than on other > > operating systems. The problem is however, that these > constants are > hardcoded as public final static members of various, shared > Java > classes. We therefore have to map them from Java to native > every > time before calling one of the native poll functions and > back to > Java after the call on AIX in order to get the right semantics. > > > src/share/classes/java/nio/__file/CopyMoveHelper.java > > * As discussed on the core-libs mailing list (see > > http://mail.openjdk.java.net/__pipermail/core-libs-dev/2013-__December/024119.html > ) > it is not necessary to call |Files.getFileAttributeView()| > with any > |linkOptions| because at that place we've already checked > that the > target file can not be a symbolic link. This change makes the > implementation more robust on platforms which support > symbolic links > but do not support the |O_NOFOLLOW| flag to the |open| > system call. > It also makes the JDK pass the |demo/zipfs/basic.sh| test > on AIX. > > > src/share/classes/sun/nio/cs/__ext/ExtendedCharsets.java > > * Support "compound text" on AIX in the same way like on > other Unix > platforms. > > > > src/share/classes/sun/tools/__attach/META-INF/services/com.__sun.tools.attach.spi.__AttachProvider > > * Define the correct attach provider for AIX. > > > src/solaris/native/java/net/__net_util_md.h > src/solaris/native/sun/nio/ch/__FileDispatcherImpl.c > src/solaris/native/sun/nio/ch/__ServerSocketChannelImpl.c > > * AIX needs a workaround for I/O cancellation (see: > > http://publib.boulder.ibm.com/__infocenter/pseries/v5r3/index.__jsp?topic=/com.ibm.aix.__basetechref/doc/basetrf1/__close.htm > ). > "..The |close()| subroutine is blocked until all > subroutines which > use the file descriptor return to usr space. For example, > when a > thread is calling close and another thread is calling > select with > the same file descriptor, the close subroutine does not > return until > the select call returns...". To fix this problem, we have > to use the > various |NET_| wrappers which are declared in > |net_util_md.h| and > defined in |aix_close.c| and we also need some additional > wrappers > for |fcntl()|, |read()| and |write()| on AIX. > > While the current solution isn't really nice because it > introduces > some more AIX-specifc sections in shared code, I think it > is the > best way to go for JDK 8 because it imposes the smallest > possible > changes and risks for the existing platforms. I'm ready to > change > the code to unconditionally use the wrappers for all > platforms and > implement the wrappers empty on platforms which don't need any > wrapping. I think it would also be nice to clean up the > names (e.g. > |NET_Read()| is currently a wrapper for |recv()| and the |NET_| > prefix is probably not appropriate any more so maybe change > it to > something like |IO_|). But again, I'll prefer to keep that as a > > follow up change for JDK9. > * Calling |fsync()| on a "read-only" file descriptor on AIX will > > result in an error (i.e. "EBADF: The FileDescriptor > parameter is not > a valid file descriptor open for writing."). To prevent > this error > we have to query if the corresponding file descriptor is > writeable. > Notice that at that point we can not access the |writable| > attribute > of the corresponding file channel so we have to use |fcntl()|. > > > src/solaris/classes/java/lang/__UNIXProcess.java.aix > > * On AIX the implementation is especially tricky, because the > > |close()| system call will block if another thread is at > the same > time blocked in a file operation (e.g. 'read()') on the > same file > descriptor. We therefore combine the AIX > |ProcessPipeInputStream| > implemenatation with the |DeferredCloseInputStream| > approach used on > Solaris (see |UNIXProcess.java.solaris|). This means that every > > potentially blocking operation on the file descriptor > increments a > counter before it is executed and decrements it once it > finishes. > The 'close()' operation will only be executed if there are no > pending operations. Otherwise it is deferred after the last > pending > operation has finished. > > > src/share/transport/socket/__socketTransport.c > > * On AIX we have to call |shutdown()| on a socket descriptor > before > > closing it, otherwise the |close()| call may be blocked. > This is the > same problem as described before. Unfortunately the JDI > framework > doesn't use the same IO wrappers like other class library > components > so we can not easily use the |NET_| abstractions from > |aix_close.c| > here. > * Without this small change all JDI regression tests will > fail on AIX > > because of the way how the tests act as a "debugger" which > launches > another VM (the "debugge") which connects itself back to the > debugger. In this scenario the "debugge" can not shut down > itself > because one thread will always be blocked in the |close()| > call on > one of the communication sockets. > > > src/solaris/native/java/net/__NetworkInterface.c > > * Set the scope identifier for IPv6 addresses on AIX. > > > src/solaris/native/java/net/__net_util_md.c > > * It turns out that we do not always have to replace > |SO_REUSEADDR| on > AIX by |SO_REUSEPORT|. Instead we can simply use the same > approach > > like BSD and only use |SO_REUSEPORT| additionally, if several > datagram sockets try to bind to the same port. > * Also fixed a comment and removed unused local variables. > * Fixed the obviously inverted assignment |newTime = > prevTime;| which > > should read |prevTime = newTime;|. Otherwise |prevTime| > will never > change and the timeout will be potential reached too fast. > > > src/solaris/native/sun/__management/__OperatingSystemImpl.c > > * AIX does not understand |/proc/self| so we have to query > the real > > process ID to access the proc file system. > > > src/solaris/native/sun/nio/ch/__DatagramChannelImpl.c > > * On AIX, |connect()| may legally return |EAFNOSUPPORT| if > called on a > > socket with the address family set to |AF_UNSPEC|. > > > From staffan.larsen at oracle.com Wed Jan 15 00:57:31 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Jan 2014 09:57:31 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: Message-ID: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Volker, I?ve look at the following files: src/share/native/sun/management/DiagnosticCommandImpl.c: nit: ?legel? -> ?legal? (two times) In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if you allow dcmd_info_array to become NULL, then jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to check that. src/solaris/native/sun/management/OperatingSystemImpl.c No comments. src/share/transport/socket/socketTransport.c No comments. src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider No comments. Thanks, /Staffan On 14 jan 2014, at 09:40, Volker Simonis wrote: > Hi, > > could you please review the following changes for the ppc-aix-port stage/stage-9 repositories (the changes are planned for integration into ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > > http://cr.openjdk.java.net/~simonis/webrevs/8031581/ > > I've build and smoke tested without any problems on Linux/x86_64 and PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. > > With these changes (and together with the changes from "8028537: PPC64: Updated jdk/test scripts to understand the AIX os and environment" and "8031134 : PPC64: implement printing on AIX") our port passes all but the following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 baseline from www.java.net/download/jdk8/testresults/testresults.html?): > > java/net/Inet6Address/B6558853.java > java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) > java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java > java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) > java/nio/channels/Selector/RacyDeregister.java > sun/security/krb5/auto/Unreachable.java (only on IPv6) > > Thank you and best regards, > Volker > > > Following a detailed description of the various changes: > src/share/native/java/util/zip/zip_util.c > src/share/native/sun/management/DiagnosticCommandImpl.c > > According to ISO C it is perfectly legal for malloc to return zero if called with a zero argument. Fix various places where malloc can potentially correctly return zero because it was called with a zero argument. > Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a compiler warning on Linux, but on AIX it prevents a VM crash later on because the return value of malloc() will be casted to int which is especially bad if that pointer was bigger than 32-bit. > make/CompileJavaClasses.gmk > > Also use PollingWatchService on AIX. > make/lib/NioLibraries.gmk > src/aix/native/sun/nio/ch/AixNativeThread.c > > Put the implementation for the native methods of NativeThread into AixNativeThread.c on AIX. > src/solaris/native/sun/nio/ch/PollArrayWrapper.c > src/solaris/native/sun/nio/ch/Net.c > src/aix/classes/sun/nio/ch/AixPollPort.java > src/aix/native/sun/nio/ch/AixPollPort.c > src/aix/native/java/net/aix_close.c > > On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, ...) are defined to different values than on other operating systems. The problem is however, that these constants are hardcoded as public final static members of various, shared Java classes. We therefore have to map them from Java to native every time before calling one of the native poll functions and back to Java after the call on AIX in order to get the right semantics. > src/share/classes/java/nio/file/CopyMoveHelper.java > > As discussed on the core-libs mailing list (see http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) it is not necessary to call Files.getFileAttributeView() with any linkOptions because at that place we've already checked that the target file can not be a symbolic link. This change makes the implementation more robust on platforms which support symbolic links but do not support the O_NOFOLLOW flag to the open system call. It also makes the JDK pass the demo/zipfs/basic.sh test on AIX. > src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java > > Support "compound text" on AIX in the same way like on other Unix platforms. > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > > Define the correct attach provider for AIX. > src/solaris/native/java/net/net_util_md.h > src/solaris/native/sun/nio/ch/FileDispatcherImpl.c > src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c > > AIX needs a workaround for I/O cancellation (see: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). "..The close() subroutine is blocked until all subroutines which use the file descriptor return to usr space. For example, when a thread is calling close and another thread is calling select with the same file descriptor, the close subroutine does not return until the select call returns...". To fix this problem, we have to use the various NET_ wrappers which are declared in net_util_md.h and defined in aix_close.c and we also need some additional wrappers for fcntl(), read() and write() on AIX. > While the current solution isn't really nice because it introduces some more AIX-specifc sections in shared code, I think it is the best way to go for JDK 8 because it imposes the smallest possible changes and risks for the existing platforms. I'm ready to change the code to unconditionally use the wrappers for all platforms and implement the wrappers empty on platforms which don't need any wrapping. I think it would also be nice to clean up the names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix is probably not appropriate any more so maybe change it to something like IO_). But again, I'll prefer to keep that as a follow up change for JDK9. > Calling fsync() on a "read-only" file descriptor on AIX will result in an error (i.e. "EBADF: The FileDescriptor parameter is not a valid file descriptor open for writing."). To prevent this error we have to query if the corresponding file descriptor is writeable. Notice that at that point we can not access the writable attribute of the corresponding file channel so we have to use fcntl(). > src/solaris/classes/java/lang/UNIXProcess.java.aix > > On AIX the implementation is especially tricky, because the close() system call will block if another thread is at the same time blocked in a file operation (e.g. 'read()') on the same file descriptor. We therefore combine the AIX ProcessPipeInputStream implemenatation with the DeferredCloseInputStream approach used on Solaris (see UNIXProcess.java.solaris). This means that every potentially blocking operation on the file descriptor increments a counter before it is executed and decrements it once it finishes. The 'close()' operation will only be executed if there are no pending operations. Otherwise it is deferred after the last pending operation has finished. > src/share/transport/socket/socketTransport.c > > On AIX we have to call shutdown() on a socket descriptor before closing it, otherwise the close() call may be blocked. This is the same problem as described before. Unfortunately the JDI framework doesn't use the same IO wrappers like other class library components so we can not easily use the NET_ abstractions from aix_close.c here. > Without this small change all JDI regression tests will fail on AIX because of the way how the tests act as a "debugger" which launches another VM (the "debugge") which connects itself back to the debugger. In this scenario the "debugge" can not shut down itself because one thread will always be blocked in the close() call on one of the communication sockets. > src/solaris/native/java/net/NetworkInterface.c > > Set the scope identifier for IPv6 addresses on AIX. > src/solaris/native/java/net/net_util_md.c > > It turns out that we do not always have to replace SO_REUSEADDR on AIX by SO_REUSEPORT. Instead we can simply use the same approach like BSD and only use SO_REUSEPORT additionally, if several datagram sockets try to bind to the same port. > Also fixed a comment and removed unused local variables. > Fixed the obviously inverted assignment newTime = prevTime; which should read prevTime = newTime;. Otherwise prevTime will never change and the timeout will be potential reached too fast. > src/solaris/native/sun/management/OperatingSystemImpl.c > > AIX does not understand /proc/self so we have to query the real process ID to access the proc file system. > src/solaris/native/sun/nio/ch/DatagramChannelImpl.c > > On AIX, connect() may legally return EAFNOSUPPORT if called on a socket with the address family set to AF_UNSPEC. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140115/691071b6/attachment-0001.html From Alan.Bateman at oracle.com Wed Jan 15 01:03:17 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Jan 2014 09:03:17 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D629A0.4080806@oracle.com> References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> Message-ID: <52D64ED5.4020409@oracle.com> On 15/01/2014 06:24, David Holmes wrote: > > I'm not a fan of runtime checks of this kind though if it is only a > very samll number of values it might be okay. > > Another option would be to make those classes into "templates" as done > with Version.java.template and substitute the right values at build time. > > But I'll let Alan and net-dev folk come back with their preferred > technique for this. > I plan to spend time on Volker's webrev later in the week (just too busy with other things right now). For the translation issue then it's an oversight in the original implementation, it just hasn't come up before (to my knowledge anyway). The simplest solution here maybe to to just move them to sun.net.ch.Net and have them initialized to their native value. In general then I'm not too concerned about that one, it's the changes to support async close on AIX that are leaping out at me. -Alan From staffan.larsen at oracle.com Wed Jan 15 11:02:26 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Jan 2014 20:02:26 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: Yes, that looks like a good solution. /Staffan On 15 jan 2014, at 17:34, Volker Simonis wrote: > Hi Staffan, > > thanks for the review. Please find my comments inline: > > On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen wrote: > Volker, > > I?ve look at the following files: > > src/share/native/sun/management/DiagnosticCommandImpl.c: > nit: ?legel? -> ?legal? (two times) > In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if you allow dcmd_info_array to become NULL, then jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to check that. > > Good catch. I actually had problems with malloc returning NULL in 'getDiagnosticCommandArgumentInfoArray()' and then changed all other potentially dangerous locations which used the same pattern. > > However I think if the 'dcmd_info_array' has zero length it would be perfectly fine to return a zero length array. So what about the following solution: > > dcmdInfoCls = (*env)->FindClass(env, > "sun/management/DiagnosticCommandInfo"); > num_commands = (*env)->GetArrayLength(env, commands); > if (num_commands = 0) { > result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); > if (result == NULL) { > JNU_ThrowOutOfMemoryError(env, 0); > } > else { > return result; > } > } > dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); > if (dcmd_info_array == NULL) { > JNU_ThrowOutOfMemoryError(env, NULL); > } > jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); > result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); > > That seems easier and saves me from handling the exception. > > What do you think? > > src/solaris/native/sun/management/OperatingSystemImpl.c > No comments. > > src/share/transport/socket/socketTransport.c > No comments. > > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > No comments. > > > Thanks, > /Staffan > > > > On 14 jan 2014, at 09:40, Volker Simonis wrote: > >> Hi, >> >> could you please review the following changes for the ppc-aix-port stage/stage-9 repositories (the changes are planned for integration into ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> >> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ >> >> I've build and smoke tested without any problems on Linux/x86_64 and PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. >> >> With these changes (and together with the changes from "8028537: PPC64: Updated jdk/test scripts to understand the AIX os and environment" and "8031134 : PPC64: implement printing on AIX") our port passes all but the following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 baseline from www.java.net/download/jdk8/testresults/testresults.html?): >> >> java/net/Inet6Address/B6558853.java >> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) >> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java >> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) >> java/nio/channels/Selector/RacyDeregister.java >> sun/security/krb5/auto/Unreachable.java (only on IPv6) >> >> Thank you and best regards, >> Volker >> >> >> Following a detailed description of the various changes: >> src/share/native/java/util/zip/zip_util.c >> src/share/native/sun/management/DiagnosticCommandImpl.c >> >> According to ISO C it is perfectly legal for malloc to return zero if called with a zero argument. Fix various places where malloc can potentially correctly return zero because it was called with a zero argument. >> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a compiler warning on Linux, but on AIX it prevents a VM crash later on because the return value of malloc() will be casted to int which is especially bad if that pointer was bigger than 32-bit. >> make/CompileJavaClasses.gmk >> >> Also use PollingWatchService on AIX. >> make/lib/NioLibraries.gmk >> src/aix/native/sun/nio/ch/AixNativeThread.c >> >> Put the implementation for the native methods of NativeThread into AixNativeThread.c on AIX. >> src/solaris/native/sun/nio/ch/PollArrayWrapper.c >> src/solaris/native/sun/nio/ch/Net.c >> src/aix/classes/sun/nio/ch/AixPollPort.java >> src/aix/native/sun/nio/ch/AixPollPort.c >> src/aix/native/java/net/aix_close.c >> >> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, ...) are defined to different values than on other operating systems. The problem is however, that these constants are hardcoded as public final static members of various, shared Java classes. We therefore have to map them from Java to native every time before calling one of the native poll functions and back to Java after the call on AIX in order to get the right semantics. >> src/share/classes/java/nio/file/CopyMoveHelper.java >> >> As discussed on the core-libs mailing list (see http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) it is not necessary to call Files.getFileAttributeView() with any linkOptions because at that place we've already checked that the target file can not be a symbolic link. This change makes the implementation more robust on platforms which support symbolic links but do not support the O_NOFOLLOW flag to the open system call. It also makes the JDK pass the demo/zipfs/basic.sh test on AIX. >> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java >> >> Support "compound text" on AIX in the same way like on other Unix platforms. >> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >> >> Define the correct attach provider for AIX. >> src/solaris/native/java/net/net_util_md.h >> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c >> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c >> >> AIX needs a workaround for I/O cancellation (see: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). "..The close() subroutine is blocked until all subroutines which use the file descriptor return to usr space. For example, when a thread is calling close and another thread is calling select with the same file descriptor, the close subroutine does not return until the select call returns...". To fix this problem, we have to use the various NET_ wrappers which are declared in net_util_md.h and defined in aix_close.c and we also need some additional wrappers for fcntl(), read() and write() on AIX. >> While the current solution isn't really nice because it introduces some more AIX-specifc sections in shared code, I think it is the best way to go for JDK 8 because it imposes the smallest possible changes and risks for the existing platforms. I'm ready to change the code to unconditionally use the wrappers for all platforms and implement the wrappers empty on platforms which don't need any wrapping. I think it would also be nice to clean up the names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix is probably not appropriate any more so maybe change it to something like IO_). But again, I'll prefer to keep that as a follow up change for JDK9. >> Calling fsync() on a "read-only" file descriptor on AIX will result in an error (i.e. "EBADF: The FileDescriptor parameter is not a valid file descriptor open for writing."). To prevent this error we have to query if the corresponding file descriptor is writeable. Notice that at that point we can not access the writable attribute of the corresponding file channel so we have to use fcntl(). >> src/solaris/classes/java/lang/UNIXProcess.java.aix >> >> On AIX the implementation is especially tricky, because the close() system call will block if another thread is at the same time blocked in a file operation (e.g. 'read()') on the same file descriptor. We therefore combine the AIX ProcessPipeInputStream implemenatation with the DeferredCloseInputStream approach used on Solaris (see UNIXProcess.java.solaris). This means that every potentially blocking operation on the file descriptor increments a counter before it is executed and decrements it once it finishes. The 'close()' operation will only be executed if there are no pending operations. Otherwise it is deferred after the last pending operation has finished. >> src/share/transport/socket/socketTransport.c >> >> On AIX we have to call shutdown() on a socket descriptor before closing it, otherwise the close() call may be blocked. This is the same problem as described before. Unfortunately the JDI framework doesn't use the same IO wrappers like other class library components so we can not easily use the NET_ abstractions from aix_close.c here. >> Without this small change all JDI regression tests will fail on AIX because of the way how the tests act as a "debugger" which launches another VM (the "debugge") which connects itself back to the debugger. In this scenario the "debugge" can not shut down itself because one thread will always be blocked in the close() call on one of the communication sockets. >> src/solaris/native/java/net/NetworkInterface.c >> >> Set the scope identifier for IPv6 addresses on AIX. >> src/solaris/native/java/net/net_util_md.c >> >> It turns out that we do not always have to replace SO_REUSEADDR on AIX by SO_REUSEPORT. Instead we can simply use the same approach like BSD and only use SO_REUSEPORT additionally, if several datagram sockets try to bind to the same port. >> Also fixed a comment and removed unused local variables. >> Fixed the obviously inverted assignment newTime = prevTime; which should read prevTime = newTime;. Otherwise prevTime will never change and the timeout will be potential reached too fast. >> src/solaris/native/sun/management/OperatingSystemImpl.c >> >> AIX does not understand /proc/self so we have to query the real process ID to access the proc file system. >> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c >> >> On AIX, connect() may legally return EAFNOSUPPORT if called on a socket with the address family set to AF_UNSPEC. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140115/7a8e80d0/attachment-0001.html From staffan.larsen at oracle.com Wed Jan 15 11:03:01 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Jan 2014 20:03:01 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: <9DE753A4-E6E0-435D-8FB9-5C93CD3184D4@oracle.com> On 15 jan 2014, at 18:27, Volker Simonis wrote: > On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis > wrote: >> Hi Staffan, >> >> thanks for the review. Please find my comments inline: >> >> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen >> wrote: >>> >>> Volker, >>> >>> I?ve look at the following files: >>> >>> src/share/native/sun/management/DiagnosticCommandImpl.c: >>> nit: ?legel? -> ?legal? (two times) >>> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if >>> you allow dcmd_info_array to become NULL, then >>> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to >>> check that. >> >> >> Good catch. I actually had problems with malloc returning NULL in >> 'getDiagnosticCommandArgumentInfoArray()' and then changed all other >> potentially dangerous locations which used the same pattern. >> >> However I think if the 'dcmd_info_array' has zero length it would be >> perfectly fine to return a zero length array. So what about the following >> solution: >> >> dcmdInfoCls = (*env)->FindClass(env, >> "sun/management/DiagnosticCommandInfo"); >> num_commands = (*env)->GetArrayLength(env, commands); > > Sorry, of course I wanted to say "if (num_commands == 0)" here! I understood as much :-) > >> if (num_commands = 0) { >> result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); >> if (result == NULL) { >> JNU_ThrowOutOfMemoryError(env, 0); >> } >> else { >> return result; >> } >> } >> dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); >> if (dcmd_info_array == NULL) { >> JNU_ThrowOutOfMemoryError(env, NULL); >> } >> jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); >> result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); >> >> That seems easier and saves me from handling the exception. >> >> What do you think? >> >>> src/solaris/native/sun/management/OperatingSystemImpl.c >>> No comments. >>> >>> src/share/transport/socket/socketTransport.c >>> No comments. >>> >>> >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >>> No comments. >>> >>> >>> Thanks, >>> /Staffan >>> >>> >>> >>> On 14 jan 2014, at 09:40, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following changes for the ppc-aix-port >>> stage/stage-9 repositories (the changes are planned for integration into >>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ >>> >>> I've build and smoke tested without any problems on Linux/x86_64 and >>> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. >>> >>> With these changes (and together with the changes from "8028537: PPC64: >>> Updated jdk/test scripts to understand the AIX os and environment" and >>> "8031134 : PPC64: implement printing on AIX") our port passes all but the >>> following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 >>> baseline from www.java.net/download/jdk8/testresults/testresults.html?): >>> >>> java/net/Inet6Address/B6558853.java >>> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) >>> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java >>> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) >>> java/nio/channels/Selector/RacyDeregister.java >>> sun/security/krb5/auto/Unreachable.java (only on IPv6) >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> Following a detailed description of the various changes: >>> >>> src/share/native/java/util/zip/zip_util.c >>> src/share/native/sun/management/DiagnosticCommandImpl.c >>> >>> According to ISO C it is perfectly legal for malloc to return zero if >>> called with a zero argument. Fix various places where malloc can potentially >>> correctly return zero because it was called with a zero argument. >>> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a >>> compiler warning on Linux, but on AIX it prevents a VM crash later on >>> because the return value of malloc() will be casted to int which is >>> especially bad if that pointer was bigger than 32-bit. >>> >>> make/CompileJavaClasses.gmk >>> >>> Also use PollingWatchService on AIX. >>> >>> make/lib/NioLibraries.gmk >>> src/aix/native/sun/nio/ch/AixNativeThread.c >>> >>> Put the implementation for the native methods of NativeThread into >>> AixNativeThread.c on AIX. >>> >>> src/solaris/native/sun/nio/ch/PollArrayWrapper.c >>> src/solaris/native/sun/nio/ch/Net.c >>> src/aix/classes/sun/nio/ch/AixPollPort.java >>> src/aix/native/sun/nio/ch/AixPollPort.c >>> src/aix/native/java/net/aix_close.c >>> >>> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, >>> ...) are defined to different values than on other operating systems. The >>> problem is however, that these constants are hardcoded as public final >>> static members of various, shared Java classes. We therefore have to map >>> them from Java to native every time before calling one of the native poll >>> functions and back to Java after the call on AIX in order to get the right >>> semantics. >>> >>> src/share/classes/java/nio/file/CopyMoveHelper.java >>> >>> As discussed on the core-libs mailing list (see >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) >>> it is not necessary to call Files.getFileAttributeView() with any >>> linkOptions because at that place we've already checked that the target file >>> can not be a symbolic link. This change makes the implementation more robust >>> on platforms which support symbolic links but do not support the O_NOFOLLOW >>> flag to the open system call. It also makes the JDK pass the >>> demo/zipfs/basic.sh test on AIX. >>> >>> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java >>> >>> Support "compound text" on AIX in the same way like on other Unix >>> platforms. >>> >>> >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >>> >>> Define the correct attach provider for AIX. >>> >>> src/solaris/native/java/net/net_util_md.h >>> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c >>> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c >>> >>> AIX needs a workaround for I/O cancellation (see: >>> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). >>> "..The close() subroutine is blocked until all subroutines which use the >>> file descriptor return to usr space. For example, when a thread is calling >>> close and another thread is calling select with the same file descriptor, >>> the close subroutine does not return until the select call returns...". To >>> fix this problem, we have to use the various NET_ wrappers which are >>> declared in net_util_md.h and defined in aix_close.c and we also need some >>> additional wrappers for fcntl(), read() and write() on AIX. >>> While the current solution isn't really nice because it introduces some >>> more AIX-specifc sections in shared code, I think it is the best way to go >>> for JDK 8 because it imposes the smallest possible changes and risks for the >>> existing platforms. I'm ready to change the code to unconditionally use the >>> wrappers for all platforms and implement the wrappers empty on platforms >>> which don't need any wrapping. I think it would also be nice to clean up the >>> names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix >>> is probably not appropriate any more so maybe change it to something like >>> IO_). But again, I'll prefer to keep that as a follow up change for JDK9. >>> Calling fsync() on a "read-only" file descriptor on AIX will result in an >>> error (i.e. "EBADF: The FileDescriptor parameter is not a valid file >>> descriptor open for writing."). To prevent this error we have to query if >>> the corresponding file descriptor is writeable. Notice that at that point we >>> can not access the writable attribute of the corresponding file channel so >>> we have to use fcntl(). >>> >>> src/solaris/classes/java/lang/UNIXProcess.java.aix >>> >>> On AIX the implementation is especially tricky, because the close() system >>> call will block if another thread is at the same time blocked in a file >>> operation (e.g. 'read()') on the same file descriptor. We therefore combine >>> the AIX ProcessPipeInputStream implemenatation with the >>> DeferredCloseInputStream approach used on Solaris (see >>> UNIXProcess.java.solaris). This means that every potentially blocking >>> operation on the file descriptor increments a counter before it is executed >>> and decrements it once it finishes. The 'close()' operation will only be >>> executed if there are no pending operations. Otherwise it is deferred after >>> the last pending operation has finished. >>> >>> src/share/transport/socket/socketTransport.c >>> >>> On AIX we have to call shutdown() on a socket descriptor before closing >>> it, otherwise the close() call may be blocked. This is the same problem as >>> described before. Unfortunately the JDI framework doesn't use the same IO >>> wrappers like other class library components so we can not easily use the >>> NET_ abstractions from aix_close.c here. >>> Without this small change all JDI regression tests will fail on AIX >>> because of the way how the tests act as a "debugger" which launches another >>> VM (the "debugge") which connects itself back to the debugger. In this >>> scenario the "debugge" can not shut down itself because one thread will >>> always be blocked in the close() call on one of the communication sockets. >>> >>> src/solaris/native/java/net/NetworkInterface.c >>> >>> Set the scope identifier for IPv6 addresses on AIX. >>> >>> src/solaris/native/java/net/net_util_md.c >>> >>> It turns out that we do not always have to replace SO_REUSEADDR on AIX by >>> SO_REUSEPORT. Instead we can simply use the same approach like BSD and only >>> use SO_REUSEPORT additionally, if several datagram sockets try to bind to >>> the same port. >>> Also fixed a comment and removed unused local variables. >>> Fixed the obviously inverted assignment newTime = prevTime; which should >>> read prevTime = newTime;. Otherwise prevTime will never change and the >>> timeout will be potential reached too fast. >>> >>> src/solaris/native/sun/management/OperatingSystemImpl.c >>> >>> AIX does not understand /proc/self so we have to query the real process ID >>> to access the proc file system. >>> >>> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c >>> >>> On AIX, connect() may legally return EAFNOSUPPORT if called on a socket >>> with the address family set to AF_UNSPEC. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140115/c93b7945/attachment.html From staffan.larsen at oracle.com Wed Jan 15 11:04:50 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 15 Jan 2014 20:04:50 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: <5F6D2785-23EF-4F43-9E0E-649BEF50F204@oracle.com> On 15 jan 2014, at 18:52, Volker Simonis wrote: > > > On Wed, Jan 15, 2014 at 6:27 PM, Volker Simonis wrote: > > On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis > > wrote: > >> Hi Staffan, > >> > >> thanks for the review. Please find my comments inline: > >> > >> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen > >> wrote: > >>> > >>> Volker, > >>> > >>> I?ve look at the following files: > >>> > >>> src/share/native/sun/management/DiagnosticCommandImpl.c: > >>> nit: ?legel? -> ?legal? (two times) > >>> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if > >>> you allow dcmd_info_array to become NULL, then > >>> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to > >>> check that. > >> > >> > >> Good catch. I actually had problems with malloc returning NULL in > >> 'getDiagnosticCommandArgumentInfoArray()' and then changed all other > >> potentially dangerous locations which used the same pattern. > >> > >> However I think if the 'dcmd_info_array' has zero length it would be > >> perfectly fine to return a zero length array. So what about the following > >> solution: > >> > > Sorry for the noise - it seems I was a little indisposed during the last mails:) > So this is the simple change I'd like to propose for Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo(): > > > @@ -117,19 +119,23 @@ > return NULL; > } > num_commands = (*env)->GetArrayLength(env, commands); > - dcmd_info_array = (dcmdInfo*) malloc(num_commands * > - sizeof(dcmdInfo)); > + dcmdInfoCls = (*env)->FindClass(env, > + "sun/management/DiagnosticCommandInfo"); > + result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); > + if (result == NULL) { > + JNU_ThrowOutOfMemoryError(env, 0); > + } > + if (num_commands == 0) { > + /* Handle the 'zero commands' case specially to avoid calling 'malloc()' */ > + /* with a zero argument because that may legally return a NULL pointer. */ > + return result; > + } > + dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); > if (dcmd_info_array == NULL) { > JNU_ThrowOutOfMemoryError(env, NULL); > } > jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); > - dcmdInfoCls = (*env)->FindClass(env, > - "sun/management/DiagnosticCommandInfo"); > - result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); > - if (result == NULL) { > - free(dcmd_info_array); > - JNU_ThrowOutOfMemoryError(env, 0); > - } > for (i=0; i args = getDiagnosticCommandArgumentInfoArray(env, > (*env)->GetObjectArrayElement(env,commands,i), > > If the 'commands' input array is of zero length just return a zero length array. > OK? Yes, this looks good (still :-) ) /Staffan > > >> dcmdInfoCls = (*env)->FindClass(env, > >> "sun/management/DiagnosticCommandInfo"); > >> num_commands = (*env)->GetArrayLength(env, commands); > > > > Sorry, of course I wanted to say "if (num_commands == 0)" here! > > > >> if (num_commands = 0) { > >> result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); > >> if (result == NULL) { > >> JNU_ThrowOutOfMemoryError(env, 0); > >> } > >> else { > >> return result; > >> } > >> } > >> dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); > >> if (dcmd_info_array == NULL) { > >> JNU_ThrowOutOfMemoryError(env, NULL); > >> } > >> jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); > >> result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); > >> > >> That seems easier and saves me from handling the exception. > >> > >> What do you think? > >> > >>> src/solaris/native/sun/management/OperatingSystemImpl.c > >>> No comments. > >>> > >>> src/share/transport/socket/socketTransport.c > >>> No comments. > >>> > >>> > >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > >>> No comments. > >>> > >>> > >>> Thanks, > >>> /Staffan > >>> > >>> > >>> > >>> On 14 jan 2014, at 09:40, Volker Simonis wrote: > >>> > >>> Hi, > >>> > >>> could you please review the following changes for the ppc-aix-port > >>> stage/stage-9 repositories (the changes are planned for integration into > >>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > >>> > >>> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ > >>> > >>> I've build and smoke tested without any problems on Linux/x86_64 and > >>> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. > >>> > >>> With these changes (and together with the changes from "8028537: PPC64: > >>> Updated jdk/test scripts to understand the AIX os and environment" and > >>> "8031134 : PPC64: implement printing on AIX") our port passes all but the > >>> following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 > >>> baseline from www.java.net/download/jdk8/testresults/testresults.html?): > >>> > >>> java/net/Inet6Address/B6558853.java > >>> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) > >>> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java > >>> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) > >>> java/nio/channels/Selector/RacyDeregister.java > >>> sun/security/krb5/auto/Unreachable.java (only on IPv6) > >>> > >>> Thank you and best regards, > >>> Volker > >>> > >>> > >>> Following a detailed description of the various changes: > >>> > >>> src/share/native/java/util/zip/zip_util.c > >>> src/share/native/sun/management/DiagnosticCommandImpl.c > >>> > >>> According to ISO C it is perfectly legal for malloc to return zero if > >>> called with a zero argument. Fix various places where malloc can potentially > >>> correctly return zero because it was called with a zero argument. > >>> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a > >>> compiler warning on Linux, but on AIX it prevents a VM crash later on > >>> because the return value of malloc() will be casted to int which is > >>> especially bad if that pointer was bigger than 32-bit. > >>> > >>> make/CompileJavaClasses.gmk > >>> > >>> Also use PollingWatchService on AIX. > >>> > >>> make/lib/NioLibraries.gmk > >>> src/aix/native/sun/nio/ch/AixNativeThread.c > >>> > >>> Put the implementation for the native methods of NativeThread into > >>> AixNativeThread.c on AIX. > >>> > >>> src/solaris/native/sun/nio/ch/PollArrayWrapper.c > >>> src/solaris/native/sun/nio/ch/Net.c > >>> src/aix/classes/sun/nio/ch/AixPollPort.java > >>> src/aix/native/sun/nio/ch/AixPollPort.c > >>> src/aix/native/java/net/aix_close.c > >>> > >>> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, > >>> ...) are defined to different values than on other operating systems. The > >>> problem is however, that these constants are hardcoded as public final > >>> static members of various, shared Java classes. We therefore have to map > >>> them from Java to native every time before calling one of the native poll > >>> functions and back to Java after the call on AIX in order to get the right > >>> semantics. > >>> > >>> src/share/classes/java/nio/file/CopyMoveHelper.java > >>> > >>> As discussed on the core-libs mailing list (see > >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) > >>> it is not necessary to call Files.getFileAttributeView() with any > >>> linkOptions because at that place we've already checked that the target file > >>> can not be a symbolic link. This change makes the implementation more robust > >>> on platforms which support symbolic links but do not support the O_NOFOLLOW > >>> flag to the open system call. It also makes the JDK pass the > >>> demo/zipfs/basic.sh test on AIX. > >>> > >>> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java > >>> > >>> Support "compound text" on AIX in the same way like on other Unix > >>> platforms. > >>> > >>> > >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > >>> > >>> Define the correct attach provider for AIX. > >>> > >>> src/solaris/native/java/net/net_util_md.h > >>> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c > >>> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c > >>> > >>> AIX needs a workaround for I/O cancellation (see: > >>> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). > >>> "..The close() subroutine is blocked until all subroutines which use the > >>> file descriptor return to usr space. For example, when a thread is calling > >>> close and another thread is calling select with the same file descriptor, > >>> the close subroutine does not return until the select call returns...". To > >>> fix this problem, we have to use the various NET_ wrappers which are > >>> declared in net_util_md.h and defined in aix_close.c and we also need some > >>> additional wrappers for fcntl(), read() and write() on AIX. > >>> While the current solution isn't really nice because it introduces some > >>> more AIX-specifc sections in shared code, I think it is the best way to go > >>> for JDK 8 because it imposes the smallest possible changes and risks for the > >>> existing platforms. I'm ready to change the code to unconditionally use the > >>> wrappers for all platforms and implement the wrappers empty on platforms > >>> which don't need any wrapping. I think it would also be nice to clean up the > >>> names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix > >>> is probably not appropriate any more so maybe change it to something like > >>> IO_). But again, I'll prefer to keep that as a follow up change for JDK9. > >>> Calling fsync() on a "read-only" file descriptor on AIX will result in an > >>> error (i.e. "EBADF: The FileDescriptor parameter is not a valid file > >>> descriptor open for writing."). To prevent this error we have to query if > >>> the corresponding file descriptor is writeable. Notice that at that point we > >>> can not access the writable attribute of the corresponding file channel so > >>> we have to use fcntl(). > >>> > >>> src/solaris/classes/java/lang/UNIXProcess.java.aix > >>> > >>> On AIX the implementation is especially tricky, because the close() system > >>> call will block if another thread is at the same time blocked in a file > >>> operation (e.g. 'read()') on the same file descriptor. We therefore combine > >>> the AIX ProcessPipeInputStream implemenatation with the > >>> DeferredCloseInputStream approach used on Solaris (see > >>> UNIXProcess.java.solaris). This means that every potentially blocking > >>> operation on the file descriptor increments a counter before it is executed > >>> and decrements it once it finishes. The 'close()' operation will only be > >>> executed if there are no pending operations. Otherwise it is deferred after > >>> the last pending operation has finished. > >>> > >>> src/share/transport/socket/socketTransport.c > >>> > >>> On AIX we have to call shutdown() on a socket descriptor before closing > >>> it, otherwise the close() call may be blocked. This is the same problem as > >>> described before. Unfortunately the JDI framework doesn't use the same IO > >>> wrappers like other class library components so we can not easily use the > >>> NET_ abstractions from aix_close.c here. > >>> Without this small change all JDI regression tests will fail on AIX > >>> because of the way how the tests act as a "debugger" which launches another > >>> VM (the "debugge") which connects itself back to the debugger. In this > >>> scenario the "debugge" can not shut down itself because one thread will > >>> always be blocked in the close() call on one of the communication sockets. > >>> > >>> src/solaris/native/java/net/NetworkInterface.c > >>> > >>> Set the scope identifier for IPv6 addresses on AIX. > >>> > >>> src/solaris/native/java/net/net_util_md.c > >>> > >>> It turns out that we do not always have to replace SO_REUSEADDR on AIX by > >>> SO_REUSEPORT. Instead we can simply use the same approach like BSD and only > >>> use SO_REUSEPORT additionally, if several datagram sockets try to bind to > >>> the same port. > >>> Also fixed a comment and removed unused local variables. > >>> Fixed the obviously inverted assignment newTime = prevTime; which should > >>> read prevTime = newTime;. Otherwise prevTime will never change and the > >>> timeout will be potential reached too fast. > >>> > >>> src/solaris/native/sun/management/OperatingSystemImpl.c > >>> > >>> AIX does not understand /proc/self so we have to query the real process ID > >>> to access the proc file system. > >>> > >>> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c > >>> > >>> On AIX, connect() may legally return EAFNOSUPPORT if called on a socket > >>> with the address family set to AF_UNSPEC. > >>> > >>> > >>> > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140115/c4ae36c9/attachment-0001.html From Alan.Bateman at oracle.com Thu Jan 16 02:05:44 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Jan 2014 10:05:44 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> <52D64ED5.4020409@oracle.com> Message-ID: <52D7AEF8.8090502@oracle.com> On 16/01/2014 09:38, Volker Simonis wrote: > > > Hi Alan, > > I think sun.nio.ch.IOUtil seems even more appropriate to me for these > constants. What do you think? > > Would it be OK for you if I initialize them right in the static > initializer of IOUtil based on "os.name " or do you > prefer to have native methods which return the right constants? I have a small preference for sun.nio.ch.Net because these constants are used with Net.poll. Would you be open to separating this one from the AIX changes? The reason is that it isn't AIX specific, rather just an oversight that hasn't been an issue because it doesn't impact other platforms. Using os.name initially would be okay although we could change that over time. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140116/0bb0612a/attachment.html From volker.simonis at gmail.com Tue Jan 14 06:10:27 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Jan 2014 15:10:27 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D51FAC.8060800@oracle.com> References: <52D51FAC.8060800@oracle.com> Message-ID: On Tue, Jan 14, 2014 at 12:29 PM, David Holmes wrote: > Just a note on this part (I havent looked at the code): > > > On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, >> ...) are defined to different values than on other operating systems. The >> problem is however, that these constants are hardcoded as public final >> static members of various, shared Java classes. >> > > Sounds like this should be handled the same way that the other "system > constants" are handled - you can either store a platform file in the repo > (for cross-compiling) or you generate the class containing the constants at > build time. > > Hi David, thanks for your comments. That sound like a good idea but I'm not sure if it would make sense to duplicate the following files: src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java: src/solaris/classes/sun/nio/ch/Port.java because of this. Do you have a concrete example where Java-classes are being generated with different constants in the class library build? Both solutions would result in different class files on Aix and other Unix variants. What do you think about assigning the concrete values depending on 'os.name' in the static initializers of the corresponding classes? I think that shouldn't introduce too much overhead and I could get rid of all the ugly conversion code. Regards, Volker > David > > > On 14/01/2014 6:40 PM, Volker Simonis wrote: > >> Hi, >> >> could you please review the following changes for the ppc-aix-port >> stage/stage-9 repositories (the changes are planned for integration into >> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> >> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ >> >> I've build and smoke tested without any problems on Linux/x86_64 and >> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. >> >> With these changes (and together with the changes from "8028537: PPC64: >> Updated jdk/test scripts to understand the AIX os and environment" and >> "8031134 : PPC64: implement printing on AIX") our port passes all but >> the following 7 jtreg regression tests on AIX (compared to the >> Linux/x86_64 baseline from >> www.java.net/download/jdk8/testresults/testresults.html >> ?): >> >> >> java/net/Inet6Address/B6558853.java >> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) >> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java >> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) >> java/nio/channels/Selector/RacyDeregister.java >> sun/security/krb5/auto/Unreachable.java (only on IPv6) >> >> Thank you and best regards, >> Volker >> >> >> Following a detailed description of the various changes: >> >> >> src/share/native/java/util/zip/zip_util.c >> src/share/native/sun/management/DiagnosticCommandImpl.c >> >> * According to ISO C it is perfectly legal for malloc to return zero >> >> if called with a zero argument. Fix various places where malloc can >> potentially correctly return zero because it was called with a zero >> argument. >> * Also fixed |DiagnosticCommandImpl.c| to include |stdlib.h|. This >> >> only fixes a compiler warning on Linux, but on AIX it prevents a VM >> crash later on because the return value of |malloc()| will be casted >> to |int| which is especially bad if that pointer was bigger than >> 32-bit. >> >> >> make/CompileJavaClasses.gmk >> >> * Also use |PollingWatchService| on AIX. >> >> >> make/lib/NioLibraries.gmk >> src/aix/native/sun/nio/ch/AixNativeThread.c >> >> * Put the implementation for the native methods of |NativeThread| into >> >> |AixNativeThread.c| on AIX. >> >> >> src/solaris/native/sun/nio/ch/PollArrayWrapper.c >> src/solaris/native/sun/nio/ch/Net.c >> src/aix/classes/sun/nio/ch/AixPollPort.java >> src/aix/native/sun/nio/ch/AixPollPort.c >> src/aix/native/java/net/aix_close.c >> >> * On AIX, the constants used for the polling events (i.e. |POLLIN|, >> |POLLOUT|, ...) are defined to different values than on other >> >> operating systems. The problem is however, that these constants are >> hardcoded as public final static members of various, shared Java >> classes. We therefore have to map them from Java to native every >> time before calling one of the native poll functions and back to >> Java after the call on AIX in order to get the right semantics. >> >> >> src/share/classes/java/nio/file/CopyMoveHelper.java >> >> * As discussed on the core-libs mailing list (see >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013- >> December/024119.html) >> it is not necessary to call |Files.getFileAttributeView()| with any >> |linkOptions| because at that place we've already checked that the >> target file can not be a symbolic link. This change makes the >> implementation more robust on platforms which support symbolic links >> but do not support the |O_NOFOLLOW| flag to the |open| system call. >> It also makes the JDK pass the |demo/zipfs/basic.sh| test on AIX. >> >> >> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java >> >> * Support "compound text" on AIX in the same way like on other Unix >> platforms. >> >> >> src/share/classes/sun/tools/attach/META-INF/services/com. >> sun.tools.attach.spi.AttachProvider >> >> * Define the correct attach provider for AIX. >> >> >> src/solaris/native/java/net/net_util_md.h >> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c >> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c >> >> * AIX needs a workaround for I/O cancellation (see: >> >> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index. >> jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). >> "..The |close()| subroutine is blocked until all subroutines which >> use the file descriptor return to usr space. For example, when a >> thread is calling close and another thread is calling select with >> the same file descriptor, the close subroutine does not return until >> the select call returns...". To fix this problem, we have to use the >> various |NET_| wrappers which are declared in |net_util_md.h| and >> defined in |aix_close.c| and we also need some additional wrappers >> for |fcntl()|, |read()| and |write()| on AIX. >> >> While the current solution isn't really nice because it introduces >> some more AIX-specifc sections in shared code, I think it is the >> best way to go for JDK 8 because it imposes the smallest possible >> changes and risks for the existing platforms. I'm ready to change >> the code to unconditionally use the wrappers for all platforms and >> implement the wrappers empty on platforms which don't need any >> wrapping. I think it would also be nice to clean up the names (e.g. >> |NET_Read()| is currently a wrapper for |recv()| and the |NET_| >> prefix is probably not appropriate any more so maybe change it to >> something like |IO_|). But again, I'll prefer to keep that as a >> >> follow up change for JDK9. >> * Calling |fsync()| on a "read-only" file descriptor on AIX will >> >> result in an error (i.e. "EBADF: The FileDescriptor parameter is not >> a valid file descriptor open for writing."). To prevent this error >> we have to query if the corresponding file descriptor is writeable. >> Notice that at that point we can not access the |writable| attribute >> of the corresponding file channel so we have to use |fcntl()|. >> >> >> src/solaris/classes/java/lang/UNIXProcess.java.aix >> >> * On AIX the implementation is especially tricky, because the >> >> |close()| system call will block if another thread is at the same >> time blocked in a file operation (e.g. 'read()') on the same file >> descriptor. We therefore combine the AIX |ProcessPipeInputStream| >> implemenatation with the |DeferredCloseInputStream| approach used on >> Solaris (see |UNIXProcess.java.solaris|). This means that every >> >> potentially blocking operation on the file descriptor increments a >> counter before it is executed and decrements it once it finishes. >> The 'close()' operation will only be executed if there are no >> pending operations. Otherwise it is deferred after the last pending >> operation has finished. >> >> >> src/share/transport/socket/socketTransport.c >> >> * On AIX we have to call |shutdown()| on a socket descriptor before >> >> closing it, otherwise the |close()| call may be blocked. This is the >> same problem as described before. Unfortunately the JDI framework >> doesn't use the same IO wrappers like other class library components >> so we can not easily use the |NET_| abstractions from |aix_close.c| >> here. >> * Without this small change all JDI regression tests will fail on AIX >> >> because of the way how the tests act as a "debugger" which launches >> another VM (the "debugge") which connects itself back to the >> debugger. In this scenario the "debugge" can not shut down itself >> because one thread will always be blocked in the |close()| call on >> one of the communication sockets. >> >> >> src/solaris/native/java/net/NetworkInterface.c >> >> * Set the scope identifier for IPv6 addresses on AIX. >> >> >> src/solaris/native/java/net/net_util_md.c >> >> * It turns out that we do not always have to replace |SO_REUSEADDR| on >> AIX by |SO_REUSEPORT|. Instead we can simply use the same approach >> >> like BSD and only use |SO_REUSEPORT| additionally, if several >> datagram sockets try to bind to the same port. >> * Also fixed a comment and removed unused local variables. >> * Fixed the obviously inverted assignment |newTime = prevTime;| which >> >> should read |prevTime = newTime;|. Otherwise |prevTime| will never >> change and the timeout will be potential reached too fast. >> >> >> src/solaris/native/sun/management/OperatingSystemImpl.c >> >> * AIX does not understand |/proc/self| so we have to query the real >> >> process ID to access the proc file system. >> >> >> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c >> >> * On AIX, |connect()| may legally return |EAFNOSUPPORT| if called on a >> >> socket with the address family set to |AF_UNSPEC|. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140114/e6f3ed73/attachment-0001.html From volker.simonis at gmail.com Wed Jan 15 03:05:14 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jan 2014 12:05:14 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D64ED5.4020409@oracle.com> References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> <52D64ED5.4020409@oracle.com> Message-ID: On Wed, Jan 15, 2014 at 10:03 AM, Alan Bateman wrote: > On 15/01/2014 06:24, David Holmes wrote: > >> >> I'm not a fan of runtime checks of this kind though if it is only a very >> samll number of values it might be okay. >> >> Another option would be to make those classes into "templates" as done >> with Version.java.template and substitute the right values at build time. >> >> But I'll let Alan and net-dev folk come back with their preferred >> technique for this. >> >> I plan to spend time on Volker's webrev later in the week (just too busy > with other things right now). For the translation issue then it's an > oversight in the original implementation, it just hasn't come up before (to > my knowledge anyway). The simplest solution here maybe to to just move them > to sun.net.ch.Net and have them initialized to their native value. Do you mean sun.nio.ch.Net right? Do you propose to completely remove the definitions of the POLL constants from: src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java src/solaris/classes/sun/nio/ch/Port.java and replace all their usages by Net.POLL* ? > In general then I'm not too concerned about that one, it's the changes to > support async close on AIX that are leaping out at me. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140115/d0df4591/attachment-0001.html From volker.simonis at gmail.com Wed Jan 15 08:34:58 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jan 2014 17:34:58 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: Hi Staffan, thanks for the review. Please find my comments inline: On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen wrote: > Volker, > > I?ve look at the following files: > > src/share/native/sun/management/DiagnosticCommandImpl.c: > nit: ?legel? -> ?legal? (two times) > In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if > you allow dcmd_info_array to become NULL, > then jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you > need to check that. > Good catch. I actually had problems with malloc returning NULL in 'getDiagnosticCommandArgumentInfoArray()' and then changed all other potentially dangerous locations which used the same pattern. However I think if the 'dcmd_info_array' has zero length it would be perfectly fine to return a zero length array. So what about the following solution: dcmdInfoCls = (*env)->FindClass(env, "sun/management/DiagnosticCommandInfo"); num_commands = (*env)->GetArrayLength(env, commands); if (num_commands = 0) { result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); if (result == NULL) { JNU_ThrowOutOfMemoryError(env, 0); } else { return result; } } dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); if (dcmd_info_array == NULL) { JNU_ThrowOutOfMemoryError(env, NULL); } jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); That seems easier and saves me from handling the exception. What do you think? src/solaris/native/sun/management/OperatingSystemImpl.c > No comments. > > src/share/transport/socket/socketTransport.c > No comments. > > > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > No comments. > > > Thanks, > /Staffan > > > > On 14 jan 2014, at 09:40, Volker Simonis wrote: > > Hi, > > could you please review the following changes for the ppc-aix-port > stage/stage-9 repositories (the changes are planned for integration into > ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > > http://cr.openjdk.java.net/~simonis/webrevs/8031581/ > > I've build and smoke tested without any problems on Linux/x86_64 and > PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. > > With these changes (and together with the changes from "8028537: PPC64: > Updated jdk/test scripts to understand the AIX os and environment" and > "8031134 : PPC64: implement printing on AIX") our port passes all but the > following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 > baseline from www.java.net/download/jdk8/testresults/testresults.html?): > > java/net/Inet6Address/B6558853.java > java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) > java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java > java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) > java/nio/channels/Selector/RacyDeregister.java > sun/security/krb5/auto/Unreachable.java (only on IPv6) > > Thank you and best regards, > Volker > > > Following a detailed description of the various changes: > src/share/native/java/util/zip/zip_util.c > src/share/native/sun/management/DiagnosticCommandImpl.c > > - According to ISO C it is perfectly legal for malloc to return zero > if called with a zero argument. Fix various places where malloc can > potentially correctly return zero because it was called with a zero > argument. > - Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only > fixes a compiler warning on Linux, but on AIX it prevents a VM crash later > on because the return value of malloc() will be casted to int which is > especially bad if that pointer was bigger than 32-bit. > > make/CompileJavaClasses.gmk > > - Also use PollingWatchService on AIX. > > make/lib/NioLibraries.gmk > src/aix/native/sun/nio/ch/AixNativeThread.c > > - Put the implementation for the native methods of NativeThread into > AixNativeThread.c on AIX. > > src/solaris/native/sun/nio/ch/PollArrayWrapper.c > src/solaris/native/sun/nio/ch/Net.c > src/aix/classes/sun/nio/ch/AixPollPort.java > src/aix/native/sun/nio/ch/AixPollPort.c > src/aix/native/java/net/aix_close.c > > - On AIX, the constants used for the polling events (i.e. POLLIN, > POLLOUT, ...) are defined to different values than on other operating > systems. The problem is however, that these constants are hardcoded as > public final static members of various, shared Java classes. We therefore > have to map them from Java to native every time before calling one of the > native poll functions and back to Java after the call on AIX in order to > get the right semantics. > > src/share/classes/java/nio/file/CopyMoveHelper.java > > - As discussed on the core-libs mailing list (see > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) > it is not necessary to call Files.getFileAttributeView() with any > linkOptions because at that place we've already checked that the > target file can not be a symbolic link. This change makes the > implementation more robust on platforms which support symbolic links but do > not support the O_NOFOLLOW flag to the open system call. It also makes > the JDK pass the demo/zipfs/basic.sh test on AIX. > > src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java > > - Support "compound text" on AIX in the same way like on other Unix > platforms. > > > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > > - Define the correct attach provider for AIX. > > src/solaris/native/java/net/net_util_md.h > src/solaris/native/sun/nio/ch/FileDispatcherImpl.c > src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c > > - AIX needs a workaround for I/O cancellation (see: > http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). > "..The close() subroutine is blocked until all subroutines which use > the file descriptor return to usr space. For example, when a thread is > calling close and another thread is calling select with the same file > descriptor, the close subroutine does not return until the select call > returns...". To fix this problem, we have to use the various NET_wrappers which are declared in > net_util_md.h and defined in aix_close.c and we also need some > additional wrappers for fcntl(), read() and write() on AIX. > While the current solution isn't really nice because it introduces > some more AIX-specifc sections in shared code, I think it is the best way > to go for JDK 8 because it imposes the smallest possible changes and risks > for the existing platforms. I'm ready to change the code to unconditionally > use the wrappers for all platforms and implement the wrappers empty on > platforms which don't need any wrapping. I think it would also be nice to > clean up the names (e.g. NET_Read() is currently a wrapper for recv()and the > NET_ prefix is probably not appropriate any more so maybe change it to > something like IO_). But again, I'll prefer to keep that as a follow > up change for JDK9. > - Calling fsync() on a "read-only" file descriptor on AIX will result > in an error (i.e. "EBADF: The FileDescriptor parameter is not a valid file > descriptor open for writing."). To prevent this error we have to query if > the corresponding file descriptor is writeable. Notice that at that point > we can not access the writable attribute of the corresponding file > channel so we have to use fcntl(). > > src/solaris/classes/java/lang/UNIXProcess.java.aix > > - On AIX the implementation is especially tricky, because the close()system call will block if another thread is at the same time blocked in a > file operation (e.g. 'read()') on the same file descriptor. We therefore > combine the AIX ProcessPipeInputStream implemenatation with the > DeferredCloseInputStream approach used on Solaris (see > UNIXProcess.java.solaris). This means that every potentially blocking > operation on the file descriptor increments a counter before it is executed > and decrements it once it finishes. The 'close()' operation will only be > executed if there are no pending operations. Otherwise it is deferred after > the last pending operation has finished. > > src/share/transport/socket/socketTransport.c > > - On AIX we have to call shutdown() on a socket descriptor before > closing it, otherwise the close() call may be blocked. This is the > same problem as described before. Unfortunately the JDI framework doesn't > use the same IO wrappers like other class library components so we can not > easily use the NET_ abstractions from aix_close.c here. > - Without this small change all JDI regression tests will fail on AIX > because of the way how the tests act as a "debugger" which launches another > VM (the "debugge") which connects itself back to the debugger. In this > scenario the "debugge" can not shut down itself because one thread will > always be blocked in the close() call on one of the communication > sockets. > > src/solaris/native/java/net/NetworkInterface.c > > - Set the scope identifier for IPv6 addresses on AIX. > > src/solaris/native/java/net/net_util_md.c > > - It turns out that we do not always have to replace SO_REUSEADDR on > AIX by SO_REUSEPORT. Instead we can simply use the same approach like > BSD and only use SO_REUSEPORT additionally, if several datagram > sockets try to bind to the same port. > - Also fixed a comment and removed unused local variables. > - Fixed the obviously inverted assignment newTime = prevTime; which > should read prevTime = newTime;. Otherwise prevTime will never change > and the timeout will be potential reached too fast. > > src/solaris/native/sun/management/OperatingSystemImpl.c > > - AIX does not understand /proc/self so we have to query the real > process ID to access the proc file system. > > src/solaris/native/sun/nio/ch/DatagramChannelImpl.c > > - On AIX, connect() may legally return EAFNOSUPPORT if called on a > socket with the address family set to AF_UNSPEC. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140115/6f1cd9ba/attachment-0001.html From volker.simonis at gmail.com Wed Jan 15 09:27:01 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jan 2014 18:27:01 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis wrote: > Hi Staffan, > > thanks for the review. Please find my comments inline: > > On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen > wrote: >> >> Volker, >> >> I?ve look at the following files: >> >> src/share/native/sun/management/DiagnosticCommandImpl.c: >> nit: ?legel? -> ?legal? (two times) >> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if >> you allow dcmd_info_array to become NULL, then >> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to >> check that. > > > Good catch. I actually had problems with malloc returning NULL in > 'getDiagnosticCommandArgumentInfoArray()' and then changed all other > potentially dangerous locations which used the same pattern. > > However I think if the 'dcmd_info_array' has zero length it would be > perfectly fine to return a zero length array. So what about the following > solution: > > dcmdInfoCls = (*env)->FindClass(env, > "sun/management/DiagnosticCommandInfo"); > num_commands = (*env)->GetArrayLength(env, commands); Sorry, of course I wanted to say "if (num_commands == 0)" here! > if (num_commands = 0) { > result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); > if (result == NULL) { > JNU_ThrowOutOfMemoryError(env, 0); > } > else { > return result; > } > } > dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); > if (dcmd_info_array == NULL) { > JNU_ThrowOutOfMemoryError(env, NULL); > } > jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); > result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); > > That seems easier and saves me from handling the exception. > > What do you think? > >> src/solaris/native/sun/management/OperatingSystemImpl.c >> No comments. >> >> src/share/transport/socket/socketTransport.c >> No comments. >> >> >> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >> No comments. >> >> >> Thanks, >> /Staffan >> >> >> >> On 14 jan 2014, at 09:40, Volker Simonis wrote: >> >> Hi, >> >> could you please review the following changes for the ppc-aix-port >> stage/stage-9 repositories (the changes are planned for integration into >> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> >> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ >> >> I've build and smoke tested without any problems on Linux/x86_64 and >> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. >> >> With these changes (and together with the changes from "8028537: PPC64: >> Updated jdk/test scripts to understand the AIX os and environment" and >> "8031134 : PPC64: implement printing on AIX") our port passes all but the >> following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 >> baseline from www.java.net/download/jdk8/testresults/testresults.html?): >> >> java/net/Inet6Address/B6558853.java >> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) >> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java >> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) >> java/nio/channels/Selector/RacyDeregister.java >> sun/security/krb5/auto/Unreachable.java (only on IPv6) >> >> Thank you and best regards, >> Volker >> >> >> Following a detailed description of the various changes: >> >> src/share/native/java/util/zip/zip_util.c >> src/share/native/sun/management/DiagnosticCommandImpl.c >> >> According to ISO C it is perfectly legal for malloc to return zero if >> called with a zero argument. Fix various places where malloc can potentially >> correctly return zero because it was called with a zero argument. >> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a >> compiler warning on Linux, but on AIX it prevents a VM crash later on >> because the return value of malloc() will be casted to int which is >> especially bad if that pointer was bigger than 32-bit. >> >> make/CompileJavaClasses.gmk >> >> Also use PollingWatchService on AIX. >> >> make/lib/NioLibraries.gmk >> src/aix/native/sun/nio/ch/AixNativeThread.c >> >> Put the implementation for the native methods of NativeThread into >> AixNativeThread.c on AIX. >> >> src/solaris/native/sun/nio/ch/PollArrayWrapper.c >> src/solaris/native/sun/nio/ch/Net.c >> src/aix/classes/sun/nio/ch/AixPollPort.java >> src/aix/native/sun/nio/ch/AixPollPort.c >> src/aix/native/java/net/aix_close.c >> >> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, >> ...) are defined to different values than on other operating systems. The >> problem is however, that these constants are hardcoded as public final >> static members of various, shared Java classes. We therefore have to map >> them from Java to native every time before calling one of the native poll >> functions and back to Java after the call on AIX in order to get the right >> semantics. >> >> src/share/classes/java/nio/file/CopyMoveHelper.java >> >> As discussed on the core-libs mailing list (see >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html) >> it is not necessary to call Files.getFileAttributeView() with any >> linkOptions because at that place we've already checked that the target file >> can not be a symbolic link. This change makes the implementation more robust >> on platforms which support symbolic links but do not support the O_NOFOLLOW >> flag to the open system call. It also makes the JDK pass the >> demo/zipfs/basic.sh test on AIX. >> >> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java >> >> Support "compound text" on AIX in the same way like on other Unix >> platforms. >> >> >> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >> >> Define the correct attach provider for AIX. >> >> src/solaris/native/java/net/net_util_md.h >> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c >> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c >> >> AIX needs a workaround for I/O cancellation (see: >> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm). >> "..The close() subroutine is blocked until all subroutines which use the >> file descriptor return to usr space. For example, when a thread is calling >> close and another thread is calling select with the same file descriptor, >> the close subroutine does not return until the select call returns...". To >> fix this problem, we have to use the various NET_ wrappers which are >> declared in net_util_md.h and defined in aix_close.c and we also need some >> additional wrappers for fcntl(), read() and write() on AIX. >> While the current solution isn't really nice because it introduces some >> more AIX-specifc sections in shared code, I think it is the best way to go >> for JDK 8 because it imposes the smallest possible changes and risks for the >> existing platforms. I'm ready to change the code to unconditionally use the >> wrappers for all platforms and implement the wrappers empty on platforms >> which don't need any wrapping. I think it would also be nice to clean up the >> names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix >> is probably not appropriate any more so maybe change it to something like >> IO_). But again, I'll prefer to keep that as a follow up change for JDK9. >> Calling fsync() on a "read-only" file descriptor on AIX will result in an >> error (i.e. "EBADF: The FileDescriptor parameter is not a valid file >> descriptor open for writing."). To prevent this error we have to query if >> the corresponding file descriptor is writeable. Notice that at that point we >> can not access the writable attribute of the corresponding file channel so >> we have to use fcntl(). >> >> src/solaris/classes/java/lang/UNIXProcess.java.aix >> >> On AIX the implementation is especially tricky, because the close() system >> call will block if another thread is at the same time blocked in a file >> operation (e.g. 'read()') on the same file descriptor. We therefore combine >> the AIX ProcessPipeInputStream implemenatation with the >> DeferredCloseInputStream approach used on Solaris (see >> UNIXProcess.java.solaris). This means that every potentially blocking >> operation on the file descriptor increments a counter before it is executed >> and decrements it once it finishes. The 'close()' operation will only be >> executed if there are no pending operations. Otherwise it is deferred after >> the last pending operation has finished. >> >> src/share/transport/socket/socketTransport.c >> >> On AIX we have to call shutdown() on a socket descriptor before closing >> it, otherwise the close() call may be blocked. This is the same problem as >> described before. Unfortunately the JDI framework doesn't use the same IO >> wrappers like other class library components so we can not easily use the >> NET_ abstractions from aix_close.c here. >> Without this small change all JDI regression tests will fail on AIX >> because of the way how the tests act as a "debugger" which launches another >> VM (the "debugge") which connects itself back to the debugger. In this >> scenario the "debugge" can not shut down itself because one thread will >> always be blocked in the close() call on one of the communication sockets. >> >> src/solaris/native/java/net/NetworkInterface.c >> >> Set the scope identifier for IPv6 addresses on AIX. >> >> src/solaris/native/java/net/net_util_md.c >> >> It turns out that we do not always have to replace SO_REUSEADDR on AIX by >> SO_REUSEPORT. Instead we can simply use the same approach like BSD and only >> use SO_REUSEPORT additionally, if several datagram sockets try to bind to >> the same port. >> Also fixed a comment and removed unused local variables. >> Fixed the obviously inverted assignment newTime = prevTime; which should >> read prevTime = newTime;. Otherwise prevTime will never change and the >> timeout will be potential reached too fast. >> >> src/solaris/native/sun/management/OperatingSystemImpl.c >> >> AIX does not understand /proc/self so we have to query the real process ID >> to access the proc file system. >> >> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c >> >> On AIX, connect() may legally return EAFNOSUPPORT if called on a socket >> with the address family set to AF_UNSPEC. >> >> >> > From volker.simonis at gmail.com Wed Jan 15 09:52:39 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Jan 2014 18:52:39 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <94ABE61E-10BC-407E-92D0-B528165F3460@oracle.com> Message-ID: On Wed, Jan 15, 2014 at 6:27 PM, Volker Simonis wrote: > On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis > wrote: >> Hi Staffan, >> >> thanks for the review. Please find my comments inline: >> >> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen < staffan.larsen at oracle.com> >> wrote: >>> >>> Volker, >>> >>> I?ve look at the following files: >>> >>> src/share/native/sun/management/DiagnosticCommandImpl.c: >>> nit: ?legel? -> ?legal? (two times) >>> In Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo() if >>> you allow dcmd_info_array to become NULL, then >>> jmm_interface->GetDiagnosticCommandInfo() will throw an NPE and you need to >>> check that. >> >> >> Good catch. I actually had problems with malloc returning NULL in >> 'getDiagnosticCommandArgumentInfoArray()' and then changed all other >> potentially dangerous locations which used the same pattern. >> >> However I think if the 'dcmd_info_array' has zero length it would be >> perfectly fine to return a zero length array. So what about the following >> solution: >> Sorry for the noise - it seems I was a little indisposed during the last mails:) So this is the simple change I'd like to propose for Java_sun_management_DiagnosticCommandImpl_getDiagnosticCommandInfo(): @@ -117,19 +119,23 @@ return NULL; } num_commands = (*env)->GetArrayLength(env, commands); - dcmd_info_array = (dcmdInfo*) malloc(num_commands * - sizeof(dcmdInfo)); + dcmdInfoCls = (*env)->FindClass(env, + "sun/management/DiagnosticCommandInfo"); + result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); + if (result == NULL) { + JNU_ThrowOutOfMemoryError(env, 0); + } + if (num_commands == 0) { + /* Handle the 'zero commands' case specially to avoid calling 'malloc()' */ + /* with a zero argument because that may legally return a NULL pointer. */ + return result; + } + dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); if (dcmd_info_array == NULL) { JNU_ThrowOutOfMemoryError(env, NULL); } jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); - dcmdInfoCls = (*env)->FindClass(env, - "sun/management/DiagnosticCommandInfo"); - result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); - if (result == NULL) { - free(dcmd_info_array); - JNU_ThrowOutOfMemoryError(env, 0); - } for (i=0; iGetObjectArrayElement(env,commands,i), If the 'commands' input array is of zero length just return a zero length array. OK? >> dcmdInfoCls = (*env)->FindClass(env, >> "sun/management/DiagnosticCommandInfo"); >> num_commands = (*env)->GetArrayLength(env, commands); > > Sorry, of course I wanted to say "if (num_commands == 0)" here! > >> if (num_commands = 0) { >> result = (*env)->NewObjectArray(env, 0, dcmdInfoCls, NULL); >> if (result == NULL) { >> JNU_ThrowOutOfMemoryError(env, 0); >> } >> else { >> return result; >> } >> } >> dcmd_info_array = (dcmdInfo*) malloc(num_commands * sizeof(dcmdInfo)); >> if (dcmd_info_array == NULL) { >> JNU_ThrowOutOfMemoryError(env, NULL); >> } >> jmm_interface->GetDiagnosticCommandInfo(env, commands, dcmd_info_array); >> result = (*env)->NewObjectArray(env, num_commands, dcmdInfoCls, NULL); >> >> That seems easier and saves me from handling the exception. >> >> What do you think? >> >>> src/solaris/native/sun/management/OperatingSystemImpl.c >>> No comments. >>> >>> src/share/transport/socket/socketTransport.c >>> No comments. >>> >>> >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >>> No comments. >>> >>> >>> Thanks, >>> /Staffan >>> >>> >>> >>> On 14 jan 2014, at 09:40, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following changes for the ppc-aix-port >>> stage/stage-9 repositories (the changes are planned for integration into >>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/8031581/ >>> >>> I've build and smoke tested without any problems on Linux/x86_64 and >>> PPC64, Windows/x86_64, MacOSX, Solaris/SPARC64 and AIX7PPC64. >>> >>> With these changes (and together with the changes from "8028537: PPC64: >>> Updated jdk/test scripts to understand the AIX os and environment" and >>> "8031134 : PPC64: implement printing on AIX") our port passes all but the >>> following 7 jtreg regression tests on AIX (compared to the Linux/x86_64 >>> baseline from www.java.net/download/jdk8/testresults/testresults.html?): >>> >>> java/net/Inet6Address/B6558853.java >>> java/nio/channels/AsynchronousChannelGroup/Basic.java (sporadically) >>> java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java >>> java/nio/channels/AsynchronousChannelGroup/Unbounded.java (sporadically) >>> java/nio/channels/Selector/RacyDeregister.java >>> sun/security/krb5/auto/Unreachable.java (only on IPv6) >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> Following a detailed description of the various changes: >>> >>> src/share/native/java/util/zip/zip_util.c >>> src/share/native/sun/management/DiagnosticCommandImpl.c >>> >>> According to ISO C it is perfectly legal for malloc to return zero if >>> called with a zero argument. Fix various places where malloc can potentially >>> correctly return zero because it was called with a zero argument. >>> Also fixed DiagnosticCommandImpl.c to include stdlib.h. This only fixes a >>> compiler warning on Linux, but on AIX it prevents a VM crash later on >>> because the return value of malloc() will be casted to int which is >>> especially bad if that pointer was bigger than 32-bit. >>> >>> make/CompileJavaClasses.gmk >>> >>> Also use PollingWatchService on AIX. >>> >>> make/lib/NioLibraries.gmk >>> src/aix/native/sun/nio/ch/AixNativeThread.c >>> >>> Put the implementation for the native methods of NativeThread into >>> AixNativeThread.c on AIX. >>> >>> src/solaris/native/sun/nio/ch/PollArrayWrapper.c >>> src/solaris/native/sun/nio/ch/Net.c >>> src/aix/classes/sun/nio/ch/AixPollPort.java >>> src/aix/native/sun/nio/ch/AixPollPort.c >>> src/aix/native/java/net/aix_close.c >>> >>> On AIX, the constants used for the polling events (i.e. POLLIN, POLLOUT, >>> ...) are defined to different values than on other operating systems. The >>> problem is however, that these constants are hardcoded as public final >>> static members of various, shared Java classes. We therefore have to map >>> them from Java to native every time before calling one of the native poll >>> functions and back to Java after the call on AIX in order to get the right >>> semantics. >>> >>> src/share/classes/java/nio/file/CopyMoveHelper.java >>> >>> As discussed on the core-libs mailing list (see >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024119.html ) >>> it is not necessary to call Files.getFileAttributeView() with any >>> linkOptions because at that place we've already checked that the target file >>> can not be a symbolic link. This change makes the implementation more robust >>> on platforms which support symbolic links but do not support the O_NOFOLLOW >>> flag to the open system call. It also makes the JDK pass the >>> demo/zipfs/basic.sh test on AIX. >>> >>> src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java >>> >>> Support "compound text" on AIX in the same way like on other Unix >>> platforms. >>> >>> >>> src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider >>> >>> Define the correct attach provider for AIX. >>> >>> src/solaris/native/java/net/net_util_md.h >>> src/solaris/native/sun/nio/ch/FileDispatcherImpl.c >>> src/solaris/native/sun/nio/ch/ServerSocketChannelImpl.c >>> >>> AIX needs a workaround for I/O cancellation (see: >>> http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/close.htm ). >>> "..The close() subroutine is blocked until all subroutines which use the >>> file descriptor return to usr space. For example, when a thread is calling >>> close and another thread is calling select with the same file descriptor, >>> the close subroutine does not return until the select call returns...". To >>> fix this problem, we have to use the various NET_ wrappers which are >>> declared in net_util_md.h and defined in aix_close.c and we also need some >>> additional wrappers for fcntl(), read() and write() on AIX. >>> While the current solution isn't really nice because it introduces some >>> more AIX-specifc sections in shared code, I think it is the best way to go >>> for JDK 8 because it imposes the smallest possible changes and risks for the >>> existing platforms. I'm ready to change the code to unconditionally use the >>> wrappers for all platforms and implement the wrappers empty on platforms >>> which don't need any wrapping. I think it would also be nice to clean up the >>> names (e.g. NET_Read() is currently a wrapper for recv() and the NET_ prefix >>> is probably not appropriate any more so maybe change it to something like >>> IO_). But again, I'll prefer to keep that as a follow up change for JDK9. >>> Calling fsync() on a "read-only" file descriptor on AIX will result in an >>> error (i.e. "EBADF: The FileDescriptor parameter is not a valid file >>> descriptor open for writing."). To prevent this error we have to query if >>> the corresponding file descriptor is writeable. Notice that at that point we >>> can not access the writable attribute of the corresponding file channel so >>> we have to use fcntl(). >>> >>> src/solaris/classes/java/lang/UNIXProcess.java.aix >>> >>> On AIX the implementation is especially tricky, because the close() system >>> call will block if another thread is at the same time blocked in a file >>> operation (e.g. 'read()') on the same file descriptor. We therefore combine >>> the AIX ProcessPipeInputStream implemenatation with the >>> DeferredCloseInputStream approach used on Solaris (see >>> UNIXProcess.java.solaris). This means that every potentially blocking >>> operation on the file descriptor increments a counter before it is executed >>> and decrements it once it finishes. The 'close()' operation will only be >>> executed if there are no pending operations. Otherwise it is deferred after >>> the last pending operation has finished. >>> >>> src/share/transport/socket/socketTransport.c >>> >>> On AIX we have to call shutdown() on a socket descriptor before closing >>> it, otherwise the close() call may be blocked. This is the same problem as >>> described before. Unfortunately the JDI framework doesn't use the same IO >>> wrappers like other class library components so we can not easily use the >>> NET_ abstractions from aix_close.c here. >>> Without this small change all JDI regression tests will fail on AIX >>> because of the way how the tests act as a "debugger" which launches another >>> VM (the "debugge") which connects itself back to the debugger. In this >>> scenario the "debugge" can not shut down itself because one thread will >>> always be blocked in the close() call on one of the communication sockets. >>> >>> src/solaris/native/java/net/NetworkInterface.c >>> >>> Set the scope identifier for IPv6 addresses on AIX. >>> >>> src/solaris/native/java/net/net_util_md.c >>> >>> It turns out that we do not always have to replace SO_REUSEADDR on AIX by >>> SO_REUSEPORT. Instead we can simply use the same approach like BSD and only >>> use SO_REUSEPORT additionally, if several datagram sockets try to bind to >>> the same port. >>> Also fixed a comment and removed unused local variables. >>> Fixed the obviously inverted assignment newTime = prevTime; which should >>> read prevTime = newTime;. Otherwise prevTime will never change and the >>> timeout will be potential reached too fast. >>> >>> src/solaris/native/sun/management/OperatingSystemImpl.c >>> >>> AIX does not understand /proc/self so we have to query the real process ID >>> to access the proc file system. >>> >>> src/solaris/native/sun/nio/ch/DatagramChannelImpl.c >>> >>> On AIX, connect() may legally return EAFNOSUPPORT if called on a socket >>> with the address family set to AF_UNSPEC. >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140115/6fe475ef/attachment-0001.html From volker.simonis at gmail.com Thu Jan 16 01:38:55 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 16 Jan 2014 10:38:55 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> <52D64ED5.4020409@oracle.com> Message-ID: On Wed, Jan 15, 2014 at 12:05 PM, Volker Simonis wrote: > > > > On Wed, Jan 15, 2014 at 10:03 AM, Alan Bateman wrote: > >> On 15/01/2014 06:24, David Holmes wrote: >> >>> >>> I'm not a fan of runtime checks of this kind though if it is only a very >>> samll number of values it might be okay. >>> >>> Another option would be to make those classes into "templates" as done >>> with Version.java.template and substitute the right values at build time. >>> >>> But I'll let Alan and net-dev folk come back with their preferred >>> technique for this. >>> >>> I plan to spend time on Volker's webrev later in the week (just too >> busy with other things right now). For the translation issue then it's an >> oversight in the original implementation, it just hasn't come up before (to >> my knowledge anyway). The simplest solution here maybe to to just move them >> to sun.net.ch.Net and have them initialized to their native value. > > > Do you mean sun.nio.ch.Net right? > > Do you propose to completely remove the definitions of the POLL constants > from: > > src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java > src/solaris/classes/sun/nio/ch/Port.java > > and replace all their usages by Net.POLL* ? > > Hi Alan, I think sun.nio.ch.IOUtil seems even more appropriate to me for these constants. What do you think? Would it be OK for you if I initialize them right in the static initializer of IOUtil based on "os.name" or do you prefer to have native methods which return the right constants? Regards, Volker > In general then I'm not too concerned about that one, it's the changes to >> support async close on AIX that are leaping out at me. >> >> -Alan >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140116/cacb3907/attachment.html From volker.simonis at gmail.com Thu Jan 16 02:34:03 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 16 Jan 2014 11:34:03 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D7AEF8.8090502@oracle.com> References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> <52D64ED5.4020409@oracle.com> <52D7AEF8.8090502@oracle.com> Message-ID: On Thu, Jan 16, 2014 at 11:05 AM, Alan Bateman wrote: > On 16/01/2014 09:38, Volker Simonis wrote: > > > > Hi Alan, > > I think sun.nio.ch.IOUtil seems even more appropriate to me for these > constants. What do you think? > > Would it be OK for you if I initialize them right in the static initializer > of IOUtil based on "os.name" or do you prefer to have native methods which > return the right constants? > > I have a small preference for sun.nio.ch.Net because these constants are > used with Net.poll. I just thought because poll is more file-descriptor oriented and not network specific. And the constants are also used for example in: src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java: src/solaris/classes/sun/nio/ch/sctp/Sctp* src/solaris/classes/sun/nio/ch/Port.java But actually I have no prefernece here so I can put them just as well to sun.nio.ch.Net > Would you be open to separating this one from the AIX > changes? The reason is that it isn't AIX specific, rather just an oversight > that hasn't been an issue because it doesn't impact other platforms. Sure, no problem. Although I still would like to push this to ppc-aix-port/stage-9 and ppc-aix-port/stage first because that's where we really need it. Anyway, the current plan is to merge ppc-aix-port/stage-9 into jdk9 mainline by the end of January and ppc-aix-port/stage into 8u-dev by the end of March (for 8u20). Would that be ok? > Using > os.name initially would be okay although we could change that over time. I've already written the native methods:) > > -Alan From roger.riggs at oracle.com Thu Jan 16 08:26:55 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 16 Jan 2014 11:26:55 -0500 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions Message-ID: <52D8084F.5060801@oracle.com> Please review: The native macros for checking and returning when exceptions are thrown have been renamed to include the "JNU_" prefix consistent with other functions in jni_util.h. The macros have been renamed and existing uses in the jdk repository for networking, pack200, and have been updated. A jprt run has passed (except for unrelated failures). webrev: http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ Thanks, Roger [1] https://bugs.openjdk.java.net/browse/JDK-8031737 From Alan.Bateman at oracle.com Thu Jan 16 08:41:10 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Jan 2014 16:41:10 +0000 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: <52D8084F.5060801@oracle.com> References: <52D8084F.5060801@oracle.com> Message-ID: <52D80BA6.2060002@oracle.com> On 16/01/2014 16:26, roger riggs wrote: > Please review: > > The native macros for checking and returning when exceptions > are thrown have been renamed to include the "JNU_" prefix > consistent with other functions in jni_util.h. > > The macros have been renamed and existing uses in the jdk repository > for networking, pack200, and have been updated. A jprt run has passed > (except for unrelated failures). > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ Did you mean to rename the CHECK_NULL and CHECK_NULL_RETURN macros? They don't require a JNIEnv so I'm wondering if JNU_* really make sense here. -Alan. From martinrb at google.com Thu Jan 16 08:45:45 2014 From: martinrb at google.com (Martin Buchholz) Date: Thu, 16 Jan 2014 08:45:45 -0800 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: <52D8084F.5060801@oracle.com> References: <52D8084F.5060801@oracle.com> Message-ID: Your backslashes are not aligned; you can fix them using: C-c C-\ runs `c-backslash-region' Documentation: Insert, align, or delete end-of-line backslashes on the lines in the region. On Thu, Jan 16, 2014 at 8:26 AM, roger riggs wrote: > Please review: > > The native macros for checking and returning when exceptions > are thrown have been renamed to include the "JNU_" prefix > consistent with other functions in jni_util.h. > > The macros have been renamed and existing uses in the jdk repository > for networking, pack200, and have been updated. A jprt run has passed > (except for unrelated failures). > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ > > Thanks, Roger > > [1] https://bugs.openjdk.java.net/browse/JDK-8031737 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140116/c32ecd00/attachment.html From roger.riggs at oracle.com Thu Jan 16 08:48:38 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 16 Jan 2014 11:48:38 -0500 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: <52D80BA6.2060002@oracle.com> References: <52D8084F.5060801@oracle.com> <52D80BA6.2060002@oracle.com> Message-ID: <52D80D66.7090105@oracle.com> Hi Alan, The macros are generally useful even without being used on a method that involves jni. An overly aggressive find caught the uses in java/util/jar/pack. But yes, it might be better to limit their scope to functions that involve jni. Roger On 1/16/2014 11:41 AM, Alan Bateman wrote: > On 16/01/2014 16:26, roger riggs wrote: >> Please review: >> >> The native macros for checking and returning when exceptions >> are thrown have been renamed to include the "JNU_" prefix >> consistent with other functions in jni_util.h. >> >> The macros have been renamed and existing uses in the jdk repository >> for networking, pack200, and have been updated. A jprt run has passed >> (except for unrelated failures). >> >> webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ > Did you mean to rename the CHECK_NULL and CHECK_NULL_RETURN macros? > They don't require a JNIEnv so I'm wondering if JNU_* really make > sense here. > > -Alan. From Alan.Bateman at oracle.com Thu Jan 16 08:51:55 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Jan 2014 16:51:55 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D51FAC.8060800@oracle.com> <52D629A0.4080806@oracle.com> <52D64ED5.4020409@oracle.com> <52D7AEF8.8090502@oracle.com> Message-ID: <52D80E2B.5000608@oracle.com> On 16/01/2014 10:34, Volker Simonis wrote: > : > I just thought because poll is more file-descriptor oriented and not > network specific. And the constants are also used for example in: > > src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java: > src/solaris/classes/sun/nio/ch/sctp/Sctp* > src/solaris/classes/sun/nio/ch/Port.java > > But actually I have no prefernece here so I can put them just as well > to sun.nio.ch.Net It's not used for anything except sockets here (there aren't any selectable channels that aren't also network channels). So I think sun.nio.ch.Net is marginly cleaner here. > : > > Sure, no problem. Although I still would like to push this to > ppc-aix-port/stage-9 and ppc-aix-port/stage first because that's where > we really need it. Anyway, the current plan is to merge > ppc-aix-port/stage-9 into jdk9 mainline by the end of January and > ppc-aix-port/stage into 8u-dev by the end of March (for 8u20). Would > that be ok? > I see you've created a bug for this. I guess it's okay if comes via the ppc port although would still be good to get it into jdk9/dev early as it impacts all platforms. -Alan. From kumar.x.srinivasan at oracle.com Thu Jan 16 09:30:38 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 16 Jan 2014 09:30:38 -0800 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: <52D80D66.7090105@oracle.com> References: <52D8084F.5060801@oracle.com> <52D80BA6.2060002@oracle.com> <52D80D66.7090105@oracle.com> Message-ID: <52D8173E.9000700@oracle.com> Hi Roger, Its confusing to use a JNU_ prefixed macro on a method not involvng jni, why not rename these to modulo JNU_ ? I am cc'ing Alex as he has a related bug fix in his queue for pack's jni code. Kumar > Hi Alan, > > The macros are generally useful even without being used on a method that > involves jni. An overly aggressive find caught the uses in > java/util/jar/pack. > > But yes, it might be better to limit their scope to functions that > involve jni. > > Roger > > > On 1/16/2014 11:41 AM, Alan Bateman wrote: >> On 16/01/2014 16:26, roger riggs wrote: >>> Please review: >>> >>> The native macros for checking and returning when exceptions >>> are thrown have been renamed to include the "JNU_" prefix >>> consistent with other functions in jni_util.h. >>> >>> The macros have been renamed and existing uses in the jdk repository >>> for networking, pack200, and have been updated. A jprt run has >>> passed (except for unrelated failures). >>> >>> webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ >> Did you mean to rename the CHECK_NULL and CHECK_NULL_RETURN macros? >> They don't require a JNIEnv so I'm wondering if JNU_* really make >> sense here. >> >> -Alan. > From roger.riggs at oracle.com Thu Jan 16 10:19:03 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 16 Jan 2014 13:19:03 -0500 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: <52D8173E.9000700@oracle.com> References: <52D8084F.5060801@oracle.com> <52D80BA6.2060002@oracle.com> <52D80D66.7090105@oracle.com> <52D8173E.9000700@oracle.com> Message-ID: <52D82297.2090903@oracle.com> Hi Kumar, I will revert the changes to the native code of java.util.jar.pack. Roger On 1/16/2014 12:30 PM, Kumar Srinivasan wrote: > Hi Roger, > > Its confusing to use a JNU_ prefixed macro on a method not involvng jni, > why not rename these to modulo JNU_ ? > > I am cc'ing Alex as he has a related bug fix in his queue for pack's > jni code. > > Kumar > >> Hi Alan, >> >> The macros are generally useful even without being used on a method that >> involves jni. An overly aggressive find caught the uses in >> java/util/jar/pack. >> >> But yes, it might be better to limit their scope to functions that >> involve jni. >> >> Roger >> >> >> On 1/16/2014 11:41 AM, Alan Bateman wrote: >>> On 16/01/2014 16:26, roger riggs wrote: >>>> Please review: >>>> >>>> The native macros for checking and returning when exceptions >>>> are thrown have been renamed to include the "JNU_" prefix >>>> consistent with other functions in jni_util.h. >>>> >>>> The macros have been renamed and existing uses in the jdk repository >>>> for networking, pack200, and have been updated. A jprt run has >>>> passed (except for unrelated failures). >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ >>> Did you mean to rename the CHECK_NULL and CHECK_NULL_RETURN macros? >>> They don't require a JNIEnv so I'm wondering if JNU_* really make >>> sense here. >>> >>> -Alan. >> > From kumar.x.srinivasan at oracle.com Thu Jan 16 10:57:03 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 16 Jan 2014 10:57:03 -0800 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: <52D8173E.9000700@oracle.com> References: <52D8084F.5060801@oracle.com> <52D80BA6.2060002@oracle.com> <52D80D66.7090105@oracle.com> <52D8173E.9000700@oracle.com> Message-ID: <52D82B7F.8030905@oracle.com> Roger, one more thing, shouldn't the parameters be unique ? I think Martin had me do this for all macros in the java launcher for example please see this changeset, I recently pushed. http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6c50c972a101 Kumar On 1/16/2014 9:30 AM, Kumar Srinivasan wrote: > Hi Roger, > > Its confusing to use a JNU_ prefixed macro on a method not involvng jni, > why not rename these to modulo JNU_ ? > > I am cc'ing Alex as he has a related bug fix in his queue for pack's > jni code. > > Kumar > >> Hi Alan, >> >> The macros are generally useful even without being used on a method that >> involves jni. An overly aggressive find caught the uses in >> java/util/jar/pack. >> >> But yes, it might be better to limit their scope to functions that >> involve jni. >> >> Roger >> >> >> On 1/16/2014 11:41 AM, Alan Bateman wrote: >>> On 16/01/2014 16:26, roger riggs wrote: >>>> Please review: >>>> >>>> The native macros for checking and returning when exceptions >>>> are thrown have been renamed to include the "JNU_" prefix >>>> consistent with other functions in jni_util.h. >>>> >>>> The macros have been renamed and existing uses in the jdk repository >>>> for networking, pack200, and have been updated. A jprt run has >>>> passed (except for unrelated failures). >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ >>> Did you mean to rename the CHECK_NULL and CHECK_NULL_RETURN macros? >>> They don't require a JNIEnv so I'm wondering if JNU_* really make >>> sense here. >>> >>> -Alan. >> > From roger.riggs at oracle.com Thu Jan 16 11:51:09 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 16 Jan 2014 14:51:09 -0500 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: <52D82B7F.8030905@oracle.com> References: <52D8084F.5060801@oracle.com> <52D80BA6.2060002@oracle.com> <52D80D66.7090105@oracle.com> <52D8173E.9000700@oracle.com> <52D82B7F.8030905@oracle.com> Message-ID: <52D8382D.3060100@oracle.com> Hi Kumar, The parameter names are purely local to the macro. They do not need to be unique. If the macro was longer (though it is now a lot longer than the original), it might make the code more readable. (Though I'm sure someone has a different convention). Roger On 1/16/2014 1:57 PM, Kumar Srinivasan wrote: > Roger, > > one more thing, shouldn't the parameters be unique ? > I think Martin had me do this for all macros in the java launcher > for example please see this changeset, I recently pushed. > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/6c50c972a101 > > Kumar > > On 1/16/2014 9:30 AM, Kumar Srinivasan wrote: >> Hi Roger, >> >> Its confusing to use a JNU_ prefixed macro on a method not involvng jni, >> why not rename these to modulo JNU_ ? >> >> I am cc'ing Alex as he has a related bug fix in his queue for pack's >> jni code. >> >> Kumar >> >>> Hi Alan, >>> >>> The macros are generally useful even without being used on a method >>> that >>> involves jni. An overly aggressive find caught the uses in >>> java/util/jar/pack. >>> >>> But yes, it might be better to limit their scope to functions that >>> involve jni. >>> >>> Roger >>> >>> >>> On 1/16/2014 11:41 AM, Alan Bateman wrote: >>>> On 16/01/2014 16:26, roger riggs wrote: >>>>> Please review: >>>>> >>>>> The native macros for checking and returning when exceptions >>>>> are thrown have been renamed to include the "JNU_" prefix >>>>> consistent with other functions in jni_util.h. >>>>> >>>>> The macros have been renamed and existing uses in the jdk repository >>>>> for networking, pack200, and have been updated. A jprt run has >>>>> passed (except for unrelated failures). >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ >>>> Did you mean to rename the CHECK_NULL and CHECK_NULL_RETURN macros? >>>> They don't require a JNIEnv so I'm wondering if JNU_* really make >>>> sense here. >>>> >>>> -Alan. >>> >> > From roger.riggs at oracle.com Thu Jan 16 13:49:41 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 16 Jan 2014 16:49:41 -0500 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: References: <52D8084F.5060801@oracle.com> Message-ID: <52D853F5.8060500@oracle.com> The webrev has been updated to revert the java.util.jar/pack CHECK_* macros and to clean up the macro definitions in jni_util.h. I plan to give the review some more time in case there are more comments coming. Roger > On Thu, Jan 16, 2014 at 8:26 AM, roger riggs > wrote: > > Please review: > > The native macros for checking and returning when exceptions > are thrown have been renamed to include the "JNU_" prefix > consistent with other functions in jni_util.h. > > The macros have been renamed and existing uses in the jdk repository > for networking, pack200, and have been updated. A jprt run has > passed (except for unrelated failures). > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ > > Thanks, Roger > > [1] https://bugs.openjdk.java.net/browse/JDK-8031737 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140116/8f2c17f3/attachment.html From tristan.yan at oracle.com Thu Jan 16 21:40:14 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Fri, 17 Jan 2014 13:40:14 +0800 Subject: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException Message-ID: <52D8C23E.6050507@oracle.com> Hi All Please review the simple code fix for JDK-8031666. http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.00/ This test fails in very small chance. Adding socket timeout a little bigger. Thank you Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140117/62f7b2d2/attachment.html From Alan.Bateman at oracle.com Fri Jan 17 02:17:46 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Jan 2014 10:17:46 +0000 Subject: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException In-Reply-To: <52D8C23E.6050507@oracle.com> References: <52D8C23E.6050507@oracle.com> Message-ID: <52D9034A.5060208@oracle.com> On 17/01/2014 05:40, Tristan Yan wrote: > Hi All > > Please review the simple code fix for JDK-8031666. > > http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.00/ > > This test fails in very small chance. Adding socket timeout a little > bigger. Looking at JDK-8031666 then the failure seems to be with the runAfter + receive at end of test2. So I wonder have you the right issue number? In the webrev then you've increased the timeout for tests that expect to timeout (so I assume making the timeout longer just makes the test take longer). As regards the runAfter + receive at the end then maybe the issue is that the runner thread was just slow to start, causing it to take more than 3 seconds (which I think is tolerance of 2s in checkTime). -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140117/29611925/attachment.html From chris.hegarty at oracle.com Fri Jan 17 02:32:20 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 17 Jan 2014 10:32:20 +0000 Subject: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException In-Reply-To: <52D8C23E.6050507@oracle.com> References: <52D8C23E.6050507@oracle.com> Message-ID: <52D906B4.2000406@oracle.com> The bug shows the following stacktrace: ----------System.err:(16/903)---------- java.net.SocketTimeoutException: Receive timed out at java.net.DualStackPlainDatagramSocketImpl.socketReceiveOrPeekData(Native Method) at java.net.DualStackPlainDatagramSocketImpl.peekData(DualStackPlainDatagramSocketImpl.java:109) at java.net.DatagramSocket.receive(DatagramSocket.java:721) at UdpTest.test2(UdpTest.java:159) at UdpTest.main(UdpTest.java:72) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:746) at java.lang.Thread.run(Thread.java:744) ---- So the failure was not related to the initial two receives that are expected to timeout. 4000 millis should be sufficient for these. The failure looks like it is because the third receive, that is expected to NOT timeout, does timeout. The socket timeout value is still set, in the original code, to 4000 millis. It should be more efficient to simply increase the timeout of the socket just before the third received, to say 10000 millis. Make sense? -Chris. On 17/01/14 05:40, Tristan Yan wrote: > Hi All > > Please review the simple code fix for JDK-8031666. > > http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.00/ > > This test fails in very small chance. Adding socket timeout a little bigger. > > Thank you > > Tristan From tristan.yan at oracle.com Fri Jan 17 02:39:58 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Fri, 17 Jan 2014 18:39:58 +0800 Subject: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException In-Reply-To: <52D906B4.2000406@oracle.com> References: <52D8C23E.6050507@oracle.com> <52D906B4.2000406@oracle.com> Message-ID: <52D9087E.1030402@oracle.com> Agree, reset timeout should be better move http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.01/ Thank you Tristan On 01/17/2014 06:32 PM, Chris Hegarty wrote: > The bug shows the following stacktrace: > > ----------System.err:(16/903)---------- > java.net.SocketTimeoutException: Receive timed out > at > java.net.DualStackPlainDatagramSocketImpl.socketReceiveOrPeekData(Native > Method) > at > java.net.DualStackPlainDatagramSocketImpl.peekData(DualStackPlainDatagramSocketImpl.java:109) > at java.net.DatagramSocket.receive(DatagramSocket.java:721) > at UdpTest.test2(UdpTest.java:159) > at UdpTest.main(UdpTest.java:72) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at > com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:746) > at java.lang.Thread.run(Thread.java:744) > ---- > > So the failure was not related to the initial two receives that are > expected to timeout. 4000 millis should be sufficient for these. > > The failure looks like it is because the third receive, that is > expected to NOT timeout, does timeout. The socket timeout value is > still set, in the original code, to 4000 millis. It should be more > efficient to simply increase the timeout of the socket just before the > third received, to say 10000 millis. > > Make sense? > > -Chris. > > > On 17/01/14 05:40, Tristan Yan wrote: >> Hi All >> >> Please review the simple code fix for JDK-8031666. >> >> http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.00/ >> >> This test fails in very small chance. Adding socket timeout a little >> bigger. >> >> Thank you >> >> Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140117/9c7b0e57/attachment.html From chris.hegarty at oracle.com Fri Jan 17 02:48:05 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 17 Jan 2014 10:48:05 +0000 Subject: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException In-Reply-To: <52D9087E.1030402@oracle.com> References: <52D8C23E.6050507@oracle.com> <52D906B4.2000406@oracle.com> <52D9087E.1030402@oracle.com> Message-ID: <52D90A65.1040102@oracle.com> On 17/01/14 10:39, Tristan Yan wrote: > Agree, reset timeout should be better move > http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.01/ Thanks, approved. I can sponsor this change for you. -Chris. > Thank you > Tristan > > On 01/17/2014 06:32 PM, Chris Hegarty wrote: >> The bug shows the following stacktrace: >> >> ----------System.err:(16/903)---------- >> java.net.SocketTimeoutException: Receive timed out >> at >> java.net.DualStackPlainDatagramSocketImpl.socketReceiveOrPeekData(Native >> Method) >> at >> java.net.DualStackPlainDatagramSocketImpl.peekData(DualStackPlainDatagramSocketImpl.java:109) >> at java.net.DatagramSocket.receive(DatagramSocket.java:721) >> at UdpTest.test2(UdpTest.java:159) >> at UdpTest.main(UdpTest.java:72) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:483) >> at >> com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:746) >> at java.lang.Thread.run(Thread.java:744) >> ---- >> >> So the failure was not related to the initial two receives that are >> expected to timeout. 4000 millis should be sufficient for these. >> >> The failure looks like it is because the third receive, that is >> expected to NOT timeout, does timeout. The socket timeout value is >> still set, in the original code, to 4000 millis. It should be more >> efficient to simply increase the timeout of the socket just before the >> third received, to say 10000 millis. >> >> Make sense? >> >> -Chris. >> >> >> On 17/01/14 05:40, Tristan Yan wrote: >>> Hi All >>> >>> Please review the simple code fix for JDK-8031666. >>> >>> http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.00/ >>> >>> This test fails in very small chance. Adding socket timeout a little >>> bigger. >>> >>> Thank you >>> >>> Tristan > From tristan.yan at oracle.com Fri Jan 17 02:41:44 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Fri, 17 Jan 2014 18:41:44 +0800 Subject: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException In-Reply-To: <52D90A65.1040102@oracle.com> References: <52D8C23E.6050507@oracle.com> <52D906B4.2000406@oracle.com> <52D9087E.1030402@oracle.com> <52D90A65.1040102@oracle.com> Message-ID: <52D908E8.4060407@oracle.com> Thank you Tristan On 01/17/2014 06:48 PM, Chris Hegarty wrote: > On 17/01/14 10:39, Tristan Yan wrote: >> Agree, reset timeout should be better move >> http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.01/ > > Thanks, approved. I can sponsor this change for you. > > -Chris. > >> Thank you >> Tristan >> >> On 01/17/2014 06:32 PM, Chris Hegarty wrote: >>> The bug shows the following stacktrace: >>> >>> ----------System.err:(16/903)---------- >>> java.net.SocketTimeoutException: Receive timed out >>> at >>> java.net.DualStackPlainDatagramSocketImpl.socketReceiveOrPeekData(Native >>> >>> Method) >>> at >>> java.net.DualStackPlainDatagramSocketImpl.peekData(DualStackPlainDatagramSocketImpl.java:109) >>> >>> at java.net.DatagramSocket.receive(DatagramSocket.java:721) >>> at UdpTest.test2(UdpTest.java:159) >>> at UdpTest.main(UdpTest.java:72) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >>> at java.lang.reflect.Method.invoke(Method.java:483) >>> at >>> com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:746) >>> >>> at java.lang.Thread.run(Thread.java:744) >>> ---- >>> >>> So the failure was not related to the initial two receives that are >>> expected to timeout. 4000 millis should be sufficient for these. >>> >>> The failure looks like it is because the third receive, that is >>> expected to NOT timeout, does timeout. The socket timeout value is >>> still set, in the original code, to 4000 millis. It should be more >>> efficient to simply increase the timeout of the socket just before the >>> third received, to say 10000 millis. >>> >>> Make sense? >>> >>> -Chris. >>> >>> >>> On 17/01/14 05:40, Tristan Yan wrote: >>>> Hi All >>>> >>>> Please review the simple code fix for JDK-8031666. >>>> >>>> http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.00/ >>>> >>>> This test fails in very small chance. Adding socket timeout a little >>>> bigger. >>>> >>>> Thank you >>>> >>>> Tristan >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140117/e7b34066/attachment.html From chris.hegarty at oracle.com Fri Jan 17 03:20:46 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 17 Jan 2014 11:20:46 +0000 Subject: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException In-Reply-To: <52D90A65.1040102@oracle.com> References: <52D8C23E.6050507@oracle.com> <52D906B4.2000406@oracle.com> <52D9087E.1030402@oracle.com> <52D90A65.1040102@oracle.com> Message-ID: <52D9120E.80606@oracle.com> On 17/01/14 10:48, Chris Hegarty wrote: > On 17/01/14 10:39, Tristan Yan wrote: >> Agree, reset timeout should be better move >> http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.01/ Oh, we should really increase the acceptable expected time in the subsequent checkTime call. From say 2000 -> 4000. If you agree, I will make the change before pushing on your behalf. -Chris. > Thanks, approved. I can sponsor this change for you. > > -Chris. > >> Thank you >> Tristan >> >> On 01/17/2014 06:32 PM, Chris Hegarty wrote: >>> The bug shows the following stacktrace: >>> >>> ----------System.err:(16/903)---------- >>> java.net.SocketTimeoutException: Receive timed out >>> at >>> java.net.DualStackPlainDatagramSocketImpl.socketReceiveOrPeekData(Native >>> Method) >>> at >>> java.net.DualStackPlainDatagramSocketImpl.peekData(DualStackPlainDatagramSocketImpl.java:109) >>> >>> at java.net.DatagramSocket.receive(DatagramSocket.java:721) >>> at UdpTest.test2(UdpTest.java:159) >>> at UdpTest.main(UdpTest.java:72) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >>> at java.lang.reflect.Method.invoke(Method.java:483) >>> at >>> com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:746) >>> >>> at java.lang.Thread.run(Thread.java:744) >>> ---- >>> >>> So the failure was not related to the initial two receives that are >>> expected to timeout. 4000 millis should be sufficient for these. >>> >>> The failure looks like it is because the third receive, that is >>> expected to NOT timeout, does timeout. The socket timeout value is >>> still set, in the original code, to 4000 millis. It should be more >>> efficient to simply increase the timeout of the socket just before the >>> third received, to say 10000 millis. >>> >>> Make sense? >>> >>> -Chris. >>> >>> >>> On 17/01/14 05:40, Tristan Yan wrote: >>>> Hi All >>>> >>>> Please review the simple code fix for JDK-8031666. >>>> >>>> http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.00/ >>>> >>>> This test fails in very small chance. Adding socket timeout a little >>>> bigger. >>>> >>>> Thank you >>>> >>>> Tristan >> From Alan.Bateman at oracle.com Fri Jan 17 03:24:03 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Jan 2014 11:24:03 +0000 Subject: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException In-Reply-To: <52D9087E.1030402@oracle.com> References: <52D8C23E.6050507@oracle.com> <52D906B4.2000406@oracle.com> <52D9087E.1030402@oracle.com> Message-ID: <52D912D3.1000702@oracle.com> On 17/01/2014 10:39, Tristan Yan wrote: > Agree, reset timeout should be better move > http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.01/ > Thank you > Tristan > This looks okay but I just wonder if we also need to adjust the tolerance in checkTime. As I read it then it checks allows for +/- 50%, which in this case is 1000-3000ms. I just wonder if 3 seconds is enough given some of the extreme environment that these tests are expected to run in. Also the test doesn't look at the package contents and so the receive will complete if it receives anything. Maybe not for this fix but I assume the test should check that the expected packet is received. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140117/97e60ad9/attachment.html From tristan.yan at oracle.com Fri Jan 17 03:24:35 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Fri, 17 Jan 2014 19:24:35 +0800 Subject: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException In-Reply-To: <52D9120E.80606@oracle.com> References: <52D8C23E.6050507@oracle.com> <52D906B4.2000406@oracle.com> <52D9087E.1030402@oracle.com> <52D90A65.1040102@oracle.com> <52D9120E.80606@oracle.com> Message-ID: <52D912F3.6020603@oracle.com> Shall we adjust runAfter time a little bigger also if you're doing this. Because if network is fast enough. All thing could be finished less than 3000 ms Thank you Tristan On 01/17/2014 07:20 PM, Chris Hegarty wrote: > Oh, we should really increase the acceptable expected time in the > subsequent checkTime call. From say 2000 -> 4000. > > If you agree, I will make the change before pushing on your behalf. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140117/59f9e296/attachment.html From chris.hegarty at oracle.com Fri Jan 17 03:45:27 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 17 Jan 2014 11:45:27 +0000 Subject: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException In-Reply-To: <52D912F3.6020603@oracle.com> References: <52D8C23E.6050507@oracle.com> <52D906B4.2000406@oracle.com> <52D9087E.1030402@oracle.com> <52D90A65.1040102@oracle.com> <52D9120E.80606@oracle.com> <52D912F3.6020603@oracle.com> Message-ID: <52D917D7.1030106@oracle.com> On 17/01/14 11:24, Tristan Yan wrote: > Shall we adjust runAfter time a little bigger also if you're doing this. > Because if network is fast enough. All thing could be finished less than > 3000 ms No, this is just a wait/delay time before sending the packet. A simple update to the expected time, 2000 -> 4000, should be sufficient. -Chris. > Thank you > Tristan > > On 01/17/2014 07:20 PM, Chris Hegarty wrote: >> Oh, we should really increase the acceptable expected time in the >> subsequent checkTime call. From say 2000 -> 4000. >> >> If you agree, I will make the change before pushing on your behalf. > From Alan.Bateman at oracle.com Fri Jan 17 03:46:13 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Jan 2014 11:46:13 +0000 Subject: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException In-Reply-To: <52D917D7.1030106@oracle.com> References: <52D8C23E.6050507@oracle.com> <52D906B4.2000406@oracle.com> <52D9087E.1030402@oracle.com> <52D90A65.1040102@oracle.com> <52D9120E.80606@oracle.com> <52D912F3.6020603@oracle.com> <52D917D7.1030106@oracle.com> Message-ID: <52D91805.3080407@oracle.com> On 17/01/2014 11:45, Chris Hegarty wrote: > > On 17/01/14 11:24, Tristan Yan wrote: >> Shall we adjust runAfter time a little bigger also if you're doing this. >> Because if network is fast enough. All thing could be finished less than >> 3000 ms > > No, this is just a wait/delay time before sending the packet. A simple > update to the expected time, 2000 -> 4000, should be sufficient. Yes, that would help as it would allow for a delay up to 6 seconds. -Alan From tristan.yan at oracle.com Fri Jan 17 03:55:22 2014 From: tristan.yan at oracle.com (Tristan Yan) Date: Fri, 17 Jan 2014 19:55:22 +0800 Subject: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException In-Reply-To: <52D917D7.1030106@oracle.com> References: <52D8C23E.6050507@oracle.com> <52D906B4.2000406@oracle.com> <52D9087E.1030402@oracle.com> <52D90A65.1040102@oracle.com> <52D9120E.80606@oracle.com> <52D912F3.6020603@oracle.com> <52D917D7.1030106@oracle.com> Message-ID: <52D91A2A.9070406@oracle.com> Sorry, you're right. Change to 4000 means tolerance will be 2000ms to 6000ms. And timeout will be 6000ms. Thank you for sponsor this. Tristan On 01/17/2014 07:45 PM, Chris Hegarty wrote: > > On 17/01/14 11:24, Tristan Yan wrote: >> Shall we adjust runAfter time a little bigger also if you're doing this. >> Because if network is fast enough. All thing could be finished less than >> 3000 ms > > No, this is just a wait/delay time before sending the packet. A simple > update to the expected time, 2000 -> 4000, should be sufficient. > > -Chris. > >> Thank you >> Tristan >> >> On 01/17/2014 07:20 PM, Chris Hegarty wrote: >>> Oh, we should really increase the acceptable expected time in the >>> subsequent checkTime call. From say 2000 -> 4000. >>> >>> If you agree, I will make the change before pushing on your behalf. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140117/ffc4d9d3/attachment.html From Alan.Bateman at oracle.com Mon Jan 20 03:41:48 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Jan 2014 11:41:48 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D50118.3080000@oracle.com> Message-ID: <52DD0B7C.4090605@oracle.com> On 20/01/2014 09:59, Volker Simonis wrote: > : > Hi Alan, > > yes, that's interesting. Sounds like a very similar problem on Mac. > > I would suggest the following: > > I cut out the "Async Close AIX FIX" stuff from this change (i.e. > "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression > tests" and send out a new webrev for the remaining part. I think that > the remaining part was more or less reviewed and we can then push it > faster. > > In the mean time, I'll recheck which tests exactly fail with my > missing "Async Close AIX FIX" stuff and which of these tests will be > fixed by your 7133499 webrev. Maybe we can really get trough with it > or with it and a few enhancements. I'll let you know my results later > today. By the way, my webrev already contained a AixNativeThread.c > implementation in src/aix/native/sun/nio/ch. > > The only remaining problem I see with this approach is that we would > need to downport your 7133499 change to 8u-dev in the 8u20 time frame > to make our AIX port work. Would this be OK for you? > I'm okay with this plan and if you re-generate the webrev without the async close changes then I can look at it quickly so that you can get it into the stage-9 forest. On 7133499 then it would be a good candidate for 8u-dev too, I don't expect any problems but we will need to get it approved on the jdk8u-dev list. -Alan. From Alan.Bateman at oracle.com Mon Jan 20 07:24:01 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Jan 2014 15:24:01 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D50118.3080000@oracle.com> <52DD0B7C.4090605@oracle.com> Message-ID: <52DD3F91.7020202@oracle.com> On 20/01/2014 13:45, Volker Simonis wrote: > : > Hi everybody, > > so here's the second version of this webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/8031581_2/ This looks okay to me. The typo ("legel" -> "legal") still exists in zip_util.c and maybe that can be fixed before you push this (no need to generate a few webrev of course). For the JDWP socket transport then it's interesting that shutdown is being used to cause the reader thread to be preempted. That may be useful when it comes to addressing the bigger async close issue. > > The main changes compared to the first webrew are as follows: > > - the POLL-constants related stuff has been factored out into its own > webrev ("8031997: PPC64: Make the various POLL constants system > dependant" - https://bugs.openjdk.java.net/browse/JDK-8031997). I see this has been pushed to ppc-aix-port/stage-9. Would you have any objection if I brought this into jdk9/dev (minus the AixPollPort change)? We can use a different bug number so as not to cause duplicate bug issues. It should trivially merge when you come to sync'ing up the staging forest. > - the "Async close on AIX" workarounds have been taken out as well > and will be handled separately Thanks for separating this one out as I suspect this that doing this cleanly is going to involve changes for all platforms. -Alan. From Alan.Bateman at oracle.com Mon Jan 20 08:42:39 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Jan 2014 16:42:39 +0000 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D50118.3080000@oracle.com> <52DD0B7C.4090605@oracle.com> <52DD3F91.7020202@oracle.com> Message-ID: <52DD51FF.7060502@oracle.com> On 20/01/2014 16:29, Volker Simonis wrote: > : > > @Alan: on the other hand, the bulk integration from > ppc-aix-port/stage-9 to jdk9/dev is planned for next week anyway, so > maybe you could wait until that happens? > In that case then ignore my request, I assumed it would not be pushed to jdk9/dev until end-Feb. -Alan From lana.steuck at oracle.com Tue Jan 21 11:03:11 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:11 +0000 Subject: hg: jdk8/tl: 5 new changesets Message-ID: <20140121190312.C650E625FA@hg.openjdk.java.net> Changeset: ca4612164195 Author: lana Date: 2014-01-08 11:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ca4612164195 Merge Changeset: b5e1dad69605 Author: jeff Date: 2014-01-13 14:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b5e1dad69605 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: 6ac7d4011e8a Author: lana Date: 2014-01-13 22:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6ac7d4011e8a Merge Changeset: 790bbd46b201 Author: lana Date: 2014-01-15 10:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/790bbd46b201 Merge Changeset: 0623ae55afff Author: katleman Date: 2014-01-17 15:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0623ae55afff Added tag jdk8-b124 for changeset 790bbd46b201 ! .hgtags From lana.steuck at oracle.com Tue Jan 21 11:03:15 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:15 +0000 Subject: hg: jdk8/tl/langtools: 6 new changesets Message-ID: <20140121190344.1A946625FF@hg.openjdk.java.net> Changeset: d5aab8300d3b Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d5aab8300d3b Added tag jdk8-b123 for changeset a345cf28faca ! .hgtags Changeset: 4a5e16002234 Author: lana Date: 2014-01-08 11:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4a5e16002234 Merge Changeset: e90611913bb1 Author: jeff Date: 2014-01-13 14:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e90611913bb1 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: 91e6cd536c34 Author: lana Date: 2014-01-13 22:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/91e6cd536c34 Merge Changeset: 436176151e85 Author: lana Date: 2014-01-15 10:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/436176151e85 Merge Changeset: 9e35f82eec22 Author: katleman Date: 2014-01-17 15:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9e35f82eec22 Added tag jdk8-b124 for changeset 436176151e85 ! .hgtags From lana.steuck at oracle.com Tue Jan 21 11:03:11 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:11 +0000 Subject: hg: jdk8/tl/corba: 5 new changesets Message-ID: <20140121190318.21207625FB@hg.openjdk.java.net> Changeset: afecd2878aee Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/afecd2878aee Added tag jdk8-b123 for changeset 1ecd4619f60c ! .hgtags Changeset: b509e2e0fc41 Author: jeff Date: 2014-01-13 14:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/b509e2e0fc41 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: 33e3d3425095 Author: lana Date: 2014-01-13 22:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/33e3d3425095 Merge Changeset: 7b45151c7a05 Author: lana Date: 2014-01-15 10:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/7b45151c7a05 Merge Changeset: 6b66ffd36885 Author: katleman Date: 2014-01-17 15:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/6b66ffd36885 Added tag jdk8-b124 for changeset 7b45151c7a05 ! .hgtags From lana.steuck at oracle.com Tue Jan 21 11:03:11 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:11 +0000 Subject: hg: jdk8/tl/nashorn: 4 new changesets Message-ID: <20140121190322.3C85A625FC@hg.openjdk.java.net> Changeset: 3356919b1639 Author: jeff Date: 2014-01-13 14:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3356919b1639 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: aefba9e5e35c Author: lana Date: 2014-01-13 22:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/aefba9e5e35c Merge Changeset: 7346abe2ea03 Author: lana Date: 2014-01-15 10:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7346abe2ea03 Merge Changeset: 40192ec6af87 Author: katleman Date: 2014-01-17 15:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/40192ec6af87 Added tag jdk8-b124 for changeset 7346abe2ea03 ! .hgtags From lana.steuck at oracle.com Tue Jan 21 11:03:11 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:11 +0000 Subject: hg: jdk8/tl/jaxp: 5 new changesets Message-ID: <20140121190335.3FF2F625FD@hg.openjdk.java.net> Changeset: 1a28f773c894 Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/1a28f773c894 Added tag jdk8-b123 for changeset 4e35b5b6d2e5 ! .hgtags Changeset: d906d69e24a3 Author: jeff Date: 2014-01-13 14:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d906d69e24a3 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: a7c0452ab987 Author: lana Date: 2014-01-13 22:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a7c0452ab987 Merge Changeset: 83bb924238f8 Author: lana Date: 2014-01-15 10:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/83bb924238f8 Merge Changeset: 5a4e9ef8673d Author: katleman Date: 2014-01-17 15:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/5a4e9ef8673d Added tag jdk8-b124 for changeset 83bb924238f8 ! .hgtags From lana.steuck at oracle.com Tue Jan 21 11:03:17 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:17 +0000 Subject: hg: jdk8/tl/jaxws: 5 new changesets Message-ID: <20140121190335.DFCF8625FE@hg.openjdk.java.net> Changeset: 241e4effed6d Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/241e4effed6d Added tag jdk8-b123 for changeset 91f5c542ccad ! .hgtags Changeset: c71b6b41a2a1 Author: jeff Date: 2014-01-13 14:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c71b6b41a2a1 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: 9ed8a0577511 Author: lana Date: 2014-01-13 22:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/9ed8a0577511 Merge Changeset: ef71ecbcd7bc Author: lana Date: 2014-01-15 10:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/ef71ecbcd7bc Merge Changeset: b14885a461b3 Author: katleman Date: 2014-01-17 15:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b14885a461b3 Added tag jdk8-b124 for changeset ef71ecbcd7bc ! .hgtags From lana.steuck at oracle.com Tue Jan 21 11:03:12 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:03:12 +0000 Subject: hg: jdk8/tl/hotspot: 10 new changesets Message-ID: <20140121190346.1F25862600@hg.openjdk.java.net> Changeset: c89630a122b4 Author: katleman Date: 2014-01-10 08:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c89630a122b4 Added tag jdk8-b123 for changeset 591135a7d6f9 ! .hgtags Changeset: f898fdfc08a5 Author: jeff Date: 2014-01-13 14:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f898fdfc08a5 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: b99955ea4b91 Author: lana Date: 2014-01-13 22:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b99955ea4b91 Merge Changeset: 9d39e8a8ff61 Author: amurillo Date: 2013-12-27 07:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9d39e8a8ff61 8031060: new hotspot build - hs25-b66 Reviewed-by: jcoomes ! make/hotspot_version Changeset: c3f3cfd39184 Author: hseigel Date: 2014-01-10 12:11 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c3f3cfd39184 8031059: invokestatic: ICCE trying to invoke static method when it clashes with an abstract method inherited from an interface Summary: Do not create AME overpass if there is a matching static method Reviewed-by: lfoltan, coleenp, kamg ! src/share/vm/classfile/defaultMethods.cpp Changeset: 9b9816164447 Author: amurillo Date: 2014-01-13 15:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9b9816164447 Merge Changeset: ac902fca803b Author: amurillo Date: 2014-01-13 15:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ac902fca803b Added tag hs25-b66 for changeset 9b9816164447 ! .hgtags Changeset: 2c3130311ffa Author: amurillo Date: 2014-01-14 11:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c3130311ffa Merge Changeset: df333ee12bba Author: lana Date: 2014-01-15 10:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/df333ee12bba Merge Changeset: e2e6ca7e0ea6 Author: katleman Date: 2014-01-17 15:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e2e6ca7e0ea6 Added tag jdk8-b124 for changeset df333ee12bba ! .hgtags From lana.steuck at oracle.com Tue Jan 21 11:04:00 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 21 Jan 2014 19:04:00 +0000 Subject: hg: jdk8/tl/jdk: 8 new changesets Message-ID: <20140121190556.93AC862601@hg.openjdk.java.net> Changeset: 9683419eddef Author: lana Date: 2014-01-08 11:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9683419eddef Merge Changeset: 2551e7290450 Author: jeff Date: 2014-01-13 14:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2551e7290450 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: 01a6b4654550 Author: lana Date: 2014-01-13 22:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01a6b4654550 Merge Changeset: 2a3afe1ec514 Author: rgallard Date: 2014-01-09 16:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a3afe1ec514 8026909: Retire Some Rarely Used GC Combintations Summary: Fix only affects java command, nroff page, OpenJDK Reviewed-by: maxelsso ! src/bsd/doc/man/java.1 ! src/linux/doc/man/java.1 ! src/solaris/doc/sun/man/man1/java.1 Changeset: acc59aae7992 Author: katleman Date: 2014-01-14 11:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/acc59aae7992 Merge Changeset: f1f3596239a4 Author: lana Date: 2014-01-15 10:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1f3596239a4 Merge - src/bsd/doc/man/ja/kinit.1 - src/bsd/doc/man/ja/klist.1 - src/bsd/doc/man/ja/ktab.1 Changeset: ae303640bc1c Author: lana Date: 2014-01-16 10:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae303640bc1c Merge - src/bsd/doc/man/ja/kinit.1 - src/bsd/doc/man/ja/klist.1 - src/bsd/doc/man/ja/ktab.1 Changeset: 3e9b46280c16 Author: katleman Date: 2014-01-17 15:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e9b46280c16 Added tag jdk8-b124 for changeset ae303640bc1c ! .hgtags From sean.mullan at oracle.com Wed Jan 22 16:12:58 2014 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 23 Jan 2014 00:12:58 +0000 Subject: hg: jdk8/tl/jdk: 8031825: OCSP client can't find responder cert if it uses a different subject key id algorithm than responderID Message-ID: <20140123001311.1048B6269C@hg.openjdk.java.net> Changeset: 57c26829deb6 Author: mullan Date: 2014-01-22 19:06 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/57c26829deb6 8031825: OCSP client can't find responder cert if it uses a different subject key id algorithm than responderID Reviewed-by: vinnie, xuelei ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java From paul.sandoz at oracle.com Thu Jan 23 02:08:33 2014 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 23 Jan 2014 10:08:33 +0000 Subject: hg: jdk8/tl/jdk: 8032190: Specifications of stream flatMap methods should require mapped streams to be closed Message-ID: <20140123100901.4C12D626BF@hg.openjdk.java.net> Changeset: 68eb0c55a8c0 Author: psandoz Date: 2014-01-21 10:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68eb0c55a8c0 8032190: Specifications of stream flatMap methods should require mapped streams to be closed Reviewed-by: chegar, alanb ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Stream.java From Ulf.Zibis at CoSoCo.de Thu Jan 16 09:56:59 2014 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 16 Jan 2014 18:56:59 +0100 Subject: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions In-Reply-To: <52D8084F.5060801@oracle.com> References: <52D8084F.5060801@oracle.com> Message-ID: <52D81D6B.6090209@CoSoCo.de> Am 16.01.2014 17:26, schrieb roger riggs: > Please review: > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-jnu-check-rename-8031737/ I more would like a "while (true)" loop, rather than a "do" loop. -Ulf From volker.simonis at gmail.com Fri Jan 17 13:15:08 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Jan 2014 22:15:08 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52D50118.3080000@oracle.com> References: <52D50118.3080000@oracle.com> Message-ID: On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman wrote: > On 14/01/2014 08:40, Volker Simonis wrote: >> >> Hi, >> >> could you please review the following changes for the ppc-aix-port >> stage/stage-9 repositories (the changes are planned for integration into >> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): > > I'd like to review this but I won't have time until later in the week. From > an initial look then there are a few things are not pretty (the changes to > fix the AIX problems with I/O cancellation in particular) and I suspect that > some refactoring is going to be required to handle some of this cleanly. A > minor comment is that bug synopsis doesn't really communicate what these > changes are about. > > -Alan. Just forwarded the following message from another thread here where it belongs: On 17/01/2014 16:57, Alan Bateman wrote: I've finally got to this one. As the event translation issue is now a separate issue then I've ignored that part. I'm not comfortable with the changes to FileDispatcherImpl.c as I don't think we shouldn't be calling into IO_ or NET_* functions here. I think I get the issue that you have on AIX (and assume it's the preClose/dup2 that blocks rather than close) but need a bit of time to suggest alternatives. It may be that it will require an AIX specific SocketDispatcher. Do you happen to know which tests fail due to this part? The other changes look okay. There is a typo in the change to zip_util.c, s/legel/legal/. In DatagramChannelImpl.c then you handle connect failing with EAFNOSUPPORT. I would be tempted to replace the comment to say that it EAFNOSUPPORT can be ignored on AIX. A minor comment but the indentation for rv = errno can be fixed (I see the BSD code has it wrong too). From volker.simonis at gmail.com Mon Jan 20 01:59:13 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 Jan 2014 10:59:13 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: References: <52D50118.3080000@oracle.com> Message-ID: On Fri, Jan 17, 2014 at 10:15 PM, Volker Simonis wrote: > On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman wrote: >> On 14/01/2014 08:40, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following changes for the ppc-aix-port >>> stage/stage-9 repositories (the changes are planned for integration into >>> ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): >> >> I'd like to review this but I won't have time until later in the week. From >> an initial look then there are a few things are not pretty (the changes to >> fix the AIX problems with I/O cancellation in particular) and I suspect that >> some refactoring is going to be required to handle some of this cleanly. A >> minor comment is that bug synopsis doesn't really communicate what these >> changes are about. >> >> -Alan. > > Just forwarded the following message from another thread here where it belongs: > > On 17/01/2014 16:57, Alan Bateman wrote: > > I've finally got to this one. As the event translation issue is now a > separate issue then I've ignored that part. > > I'm not comfortable with the changes to FileDispatcherImpl.c as I > don't think we shouldn't be calling into IO_ or NET_* functions here. > I think I get the issue that you have on AIX (and assume it's the > preClose/dup2 that blocks rather than close) but need a bit of time to > suggest alternatives. It may be that it will require an AIX specific > SocketDispatcher. Do you happen to know which tests fail due to this > part? > > The other changes look okay. There is a typo in the change to > zip_util.c, s/legel/legal/. > > In DatagramChannelImpl.c then you handle connect failing with > EAFNOSUPPORT. I would be tempted to replace the comment to say that it > EAFNOSUPPORT can be ignored on AIX. A minor comment but the > indentation for rv = errno can be fixed (I see the BSD code has it > wrong too). > On 17/01/2014 21:23, Volker Simonis wrote: > > > You're right, one race is with preClose/dup2 but also with other calls > > like read/fcntl/... > > > > There were several tests that failed and once I fixed it they all > > succeeded. But I can recreate some of the failures for you. The > > symptoms are always the same: the VMis locked. If you trigger a stack > > trace you can see that at least on thread is blocked in a I/O > > operation on a file descriptor like fcntl (e.g. for file locking), > > read, etc. while another thread is trying to close that socket. > > > > As it happens, we have some carry over issues from the Mac port, > one of which is that async close of FileChannels will block > indefinitely in dup2 when there is another thread blocked (on > fnctl or reading from a pipe ...). I haven't time time to work on > it but this discussion has reminded me that we need to sort it > out. I've put a preliminary webrev with the changes here: > > http://cr.openjdk.java.net/~alanb/7133499/webrev/ > > The important part is that it's using signal consistently on > Linux/Solaris/OSX so that any blocked threads are interrupted. My > guess is that if NativeThread.c is updated to define a signal on > AIX they this should resolve some of the issues on AIX. > > I would like to see the list of tests failing. If there is an > issue with dup2 with sockets (and OS X doesn't seem to have that > issue) then it will require further work but I would at least > like to start by understanding if this patch will help with the > FileChannel issues. Hi Alan, yes, that's interesting. Sounds like a very similar problem on Mac. I would suggest the following: I cut out the "Async Close AIX FIX" stuff from this change (i.e. "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests" and send out a new webrev for the remaining part. I think that the remaining part was more or less reviewed and we can then push it faster. In the mean time, I'll recheck which tests exactly fail with my missing "Async Close AIX FIX" stuff and which of these tests will be fixed by your 7133499 webrev. Maybe we can really get trough with it or with it and a few enhancements. I'll let you know my results later today. By the way, my webrev already contained a AixNativeThread.c implementation in src/aix/native/sun/nio/ch. The only remaining problem I see with this approach is that we would need to downport your 7133499 change to 8u-dev in the 8u20 time frame to make our AIX port work. Would this be OK for you? Regards, Volker From volker.simonis at gmail.com Mon Jan 20 05:45:12 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 Jan 2014 14:45:12 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52DD0B7C.4090605@oracle.com> References: <52D50118.3080000@oracle.com> <52DD0B7C.4090605@oracle.com> Message-ID: On Mon, Jan 20, 2014 at 12:41 PM, Alan Bateman wrote: > On 20/01/2014 09:59, Volker Simonis wrote: >> >> : >> Hi Alan, >> >> yes, that's interesting. Sounds like a very similar problem on Mac. >> >> I would suggest the following: >> >> I cut out the "Async Close AIX FIX" stuff from this change (i.e. >> "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression >> tests" and send out a new webrev for the remaining part. I think that >> the remaining part was more or less reviewed and we can then push it >> faster. >> >> In the mean time, I'll recheck which tests exactly fail with my >> missing "Async Close AIX FIX" stuff and which of these tests will be >> fixed by your 7133499 webrev. Maybe we can really get trough with it >> or with it and a few enhancements. I'll let you know my results later >> today. By the way, my webrev already contained a AixNativeThread.c >> implementation in src/aix/native/sun/nio/ch. >> >> The only remaining problem I see with this approach is that we would >> need to downport your 7133499 change to 8u-dev in the 8u20 time frame >> to make our AIX port work. Would this be OK for you? >> > I'm okay with this plan and if you re-generate the webrev without the async > close changes then I can look at it quickly so that you can get it into the > stage-9 forest. > > On 7133499 then it would be a good candidate for 8u-dev too, I don't expect > any problems but we will need to get it approved on the jdk8u-dev list. > > -Alan. Hi everybody, so here's the second version of this webrev: http://cr.openjdk.java.net/~simonis/webrevs/8031581_2/ The main changes compared to the first webrew are as follows: - the POLL-constants related stuff has been factored out into its own webrev ("8031997: PPC64: Make the various POLL constants system dependant" - https://bugs.openjdk.java.net/browse/JDK-8031997). - the "Async close on AIX" workarounds have been taken out as well and will be handled separately (probably together with Alans fix for http://cr.openjdk.java.net/~alanb/7133499/webrev/). - in the remaining files I've applied the changes suggested by Staffan, so I think the changes to the following files can be considered as reviewed: src/share/native/sun/management/DiagnosticCommandImpl.c src/solaris/native/sun/management/OperatingSystemImpl.c src/share/transport/socket/socketTransport.c src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider - I've added the following additional files to the change: src/aix/classes/sun/nio/ch/sctp/SctpChannelImpl.java src/aix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java src/aix/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java which are just empty stub implementations of the SCTP classes needed to pass the SCTP jtreg tests. All other changes should be the same like in the first review round. Thanks, Volker From volker.simonis at gmail.com Mon Jan 20 08:29:13 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 Jan 2014 17:29:13 +0100 Subject: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests In-Reply-To: <52DD3F91.7020202@oracle.com> References: <52D50118.3080000@oracle.com> <52DD0B7C.4090605@oracle.com> <52DD3F91.7020202@oracle.com> Message-ID: On Mon, Jan 20, 2014 at 4:24 PM, Alan Bateman wrote: > On 20/01/2014 13:45, Volker Simonis wrote: >> >> : >> Hi everybody, >> >> so here's the second version of this webrev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8031581_2/ > > This looks okay to me. Thanks. > > The typo ("legel" -> "legal") still exists in zip_util.c and maybe that can > be fixed before you push this (no need to generate a few webrev of course). > Sorry, I've just fixed it in my patch queue and will used the fixed version for pushing. @Vladimir: could you please run this change (http://cr.openjdk.java.net/~simonis/webrevs/8031581_2) through JPRT as well. I'll push it (together with the fixed typo in the comment) if everything is OK. > For the JDWP socket transport then it's interesting that shutdown is being > used to cause the reader thread to be preempted. That may be useful when it > comes to addressing the bigger async close issue. > > >> >> The main changes compared to the first webrew are as follows: >> >> - the POLL-constants related stuff has been factored out into its own >> webrev ("8031997: PPC64: Make the various POLL constants system >> dependant" - https://bugs.openjdk.java.net/browse/JDK-8031997). > > I see this has been pushed to ppc-aix-port/stage-9. Would you have any > objection if I brought this into jdk9/dev (minus the AixPollPort change)? We > can use a different bug number so as not to cause duplicate bug issues. It > should trivially merge when you come to sync'ing up the staging forest. > I have no objections of course. I'm just not sure what exact implications this will have. @Vladimir: what do you think - can Alan push "8031997: PPC64: Make the various POLL constants system dependant" minus the Aix-specific stuff to jdk9/dev now, without causing you any harm during integration. @Alan: on the other hand, the bulk integration from ppc-aix-port/stage-9 to jdk9/dev is planned for next week anyway, so maybe you could wait until that happens? Thanks, Volker > >> - the "Async close on AIX" workarounds have been taken out as well >> and will be handled separately > > Thanks for separating this one out as I suspect this that doing this cleanly > is going to involve changes for all platforms. > > -Alan. From weijun.wang at oracle.com Sat Jan 25 05:32:19 2014 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Sat, 25 Jan 2014 13:32:19 +0000 Subject: hg: jdk8/tl/jdk: 8031572: jarsigner -verify exits with 0 when a jar file is not properly signed Message-ID: <20140125133414.AA45C62795@hg.openjdk.java.net> Changeset: 4d891c8db5c1 Author: weijun Date: 2014-01-21 12:08 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d891c8db5c1 8031572: jarsigner -verify exits with 0 when a jar file is not properly signed Reviewed-by: mullan ! src/share/classes/java/util/jar/JarFile.java + test/sun/security/tools/jarsigner/EntriesOrder.java From alan.bateman at oracle.com Sat Jan 25 12:05:49 2014 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 25 Jan 2014 20:05:49 +0000 Subject: hg: jdk8/tl/jdk: 8032456: vm/jni/Miscellaneous/misc001/misc00101m1/misc00101m1.html failing on OS X Message-ID: <20140125200603.4D4F962798@hg.openjdk.java.net> Changeset: b56ff7d30a72 Author: alanb Date: 2014-01-24 11:50 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b56ff7d30a72 8032456: vm/jni/Miscellaneous/misc001/misc00101m1/misc00101m1.html failing on OS X Reviewed-by: sla, chegar, psandoz ! src/solaris/native/common/jni_util_md.c From mark.g.j.christiaens at gmail.com Mon Jan 27 01:28:40 2014 From: mark.g.j.christiaens at gmail.com (Mark Christiaens) Date: Mon, 27 Jan 2014 10:28:40 +0100 Subject: AES GCM slow Message-ID: I wrote a little test client/server setup that transfers 100 MB of data over an SSL socket configured to use TLS 1.2 AES GCM (TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256). On my i7-4770 CPU @ 3.40GHz with OpenJDK 1.8.0-ea-b124 I get a transfer rate of around 5.2 MiB/second. I expected a higher speed. Using TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 I reach 100 MiB/s. Is this to be expected? For reference, here is my code: ///// Client.java package ssl; import javax.net.ssl.*; import java.io.*; import java.util.Arrays; public class Client { public static void main(String[] arstring) { try { SSLSocketFactory sslsocketfactory = (SSLSocketFactory) SSLSocketFactory.getDefault(); SSLSocket sslsocket = (SSLSocket) sslsocketfactory.createSocket("localhost", 9999); Helper.requireAESCipherSuites(sslsocket); sslsocket.setEnabledProtocols(new String[]{"TLSv1.2"}); try (OutputStream outputstream = sslsocket.getOutputStream()) { byte[] buf = new byte[Helper.BUF_SIZE]; Arrays.fill(buf, (byte) 1); for (int i = 0; i < Helper.BUF_COUNT; ++i) { outputstream.write(buf); } System.out.println("Using cipher suite: " + (sslsocket.getSession()).getCipherSuite()); outputstream.flush(); } } catch (IOException exception) { exception.printStackTrace(); } } } ///// Server.java package ssl; import javax.net.ssl.*; import java.io.*; public class Server { public static void main(String[] arstring) { try { SSLServerSocketFactory sslserversocketfactory = (SSLServerSocketFactory) SSLServerSocketFactory.getDefault(); SSLServerSocket sslserversocket = (SSLServerSocket) sslserversocketfactory.createServerSocket(9999); SSLSocket sslsocket = (SSLSocket) sslserversocket.accept(); InputStream inputstream = sslsocket.getInputStream(); byte[] buf = new byte[Helper.BUF_SIZE]; long bytesToRead = BYTES_TO_READ; long startTime = System.currentTimeMillis(); while (bytesToRead > 0) { bytesToRead -= inputstream.read(buf); } long stopTime = System.currentTimeMillis(); long totalTimeMs = stopTime - startTime; double mbRead = BYTES_TO_READ / (1024.0 * 1024); double totalTimeSeconds = totalTimeMs / 1000.0; double mibPerSecond = mbRead / totalTimeSeconds; System.out.println("Using cipher suite: " + (sslsocket.getSession()).getCipherSuite()); System.out.println("Read " + mbRead + "MiB in " + totalTimeSeconds + "s"); System.out.println("Bandwidth: " + mibPerSecond + "MiB/s"); } catch (IOException exception) { exception.printStackTrace(); } } private static final int BYTES_TO_READ = Helper.BUF_COUNT * Helper.BUF_SIZE; } ///// Helper.java package ssl; import java.util.*; import java.util.regex.*; import javax.net.ssl.*; public class Helper { static int BUF_SIZE = 1024 * 1024; static int BUF_COUNT = 100; static SSLSocket requireAESCipherSuites(SSLSocket socket) { String supportedCipherSuites[] = socket.getSupportedCipherSuites(); System.out.println("Supported cipher suite: " + Arrays.toString(supportedCipherSuites)); List selectedCipherSuites = new ArrayList<>(); // String patternString = ".*"; String patternString = "TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256"; // String patternString = "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"; Pattern pattern = Pattern.compile(patternString); for (String cipherSuite : supportedCipherSuites) { Matcher matcher = pattern.matcher(cipherSuite); if (matcher.find()) { selectedCipherSuites.add(cipherSuite); } } System.out.println("Selected cipher suites: " + selectedCipherSuites); socket.setEnabledCipherSuites(selectedCipherSuites.toArray(new String[0])); return socket; } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140127/f6de2b94/attachment.html From chris.hegarty at oracle.com Mon Jan 27 01:34:50 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 27 Jan 2014 09:34:50 +0000 Subject: AES GCM slow In-Reply-To: References: Message-ID: <52E6283A.7000401@oracle.com> Cross posting to security-dev, since the question cipher related. -Chris. On 27/01/14 09:28, Mark Christiaens wrote: > I wrote a little test client/server setup that transfers 100 MB of data > over an SSL socket configured to use TLS 1.2 AES GCM > (TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256). On my i7-4770 CPU @ 3.40GHz > with OpenJDK 1.8.0-ea-b124 I get a transfer rate of around 5.2 > MiB/second. I expected a higher speed. Using > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 I reach 100 MiB/s. Is this to > be expected? > > For reference, here is my code: > > ///// Client.java > > package ssl; > > import javax.net.ssl.*; > import java.io.*; > import java.util.Arrays; > > public class Client { > > public static void main(String[] arstring) { > try { > SSLSocketFactory sslsocketfactory = (SSLSocketFactory) > SSLSocketFactory.getDefault(); > SSLSocket sslsocket = (SSLSocket) > sslsocketfactory.createSocket("localhost", 9999); > Helper.requireAESCipherSuites(sslsocket); > sslsocket.setEnabledProtocols(new String[]{"TLSv1.2"}); > > try (OutputStream outputstream = sslsocket.getOutputStream()) { > byte[] buf = new byte[Helper.BUF_SIZE]; > Arrays.fill(buf, (byte) 1); > for (int i = 0; i < Helper.BUF_COUNT; ++i) { > outputstream.write(buf); > } > > System.out.println("Using cipher suite: " + > (sslsocket.getSession()).getCipherSuite()); > > outputstream.flush(); > } > > } catch (IOException exception) { > exception.printStackTrace(); > } > } > } > > ///// Server.java > > package ssl; > > import javax.net.ssl.*; > import java.io.*; > > public class Server { > > public static void main(String[] arstring) { > try { > SSLServerSocketFactory sslserversocketfactory = > (SSLServerSocketFactory) SSLServerSocketFactory.getDefault(); > SSLServerSocket sslserversocket = (SSLServerSocket) > sslserversocketfactory.createServerSocket(9999); > SSLSocket sslsocket = (SSLSocket) sslserversocket.accept(); > > InputStream inputstream = sslsocket.getInputStream(); > > byte[] buf = new byte[Helper.BUF_SIZE]; > long bytesToRead = BYTES_TO_READ; > > long startTime = System.currentTimeMillis(); > > while (bytesToRead > 0) { > bytesToRead -= inputstream.read(buf); > } > > long stopTime = System.currentTimeMillis(); > long totalTimeMs = stopTime - startTime; > double mbRead = BYTES_TO_READ / (1024.0 * 1024); > double totalTimeSeconds = totalTimeMs / 1000.0; > double mibPerSecond = mbRead / totalTimeSeconds; > > System.out.println("Using cipher suite: " + > (sslsocket.getSession()).getCipherSuite()); > System.out.println("Read " + mbRead + "MiB in " + > totalTimeSeconds + "s"); > System.out.println("Bandwidth: " + mibPerSecond + "MiB/s"); > > } catch (IOException exception) { > exception.printStackTrace(); > } > } > > private static final int BYTES_TO_READ = Helper.BUF_COUNT * > Helper.BUF_SIZE; > } > > ///// Helper.java > > package ssl; > > import java.util.*; > import java.util.regex.*; > import javax.net.ssl.*; > > public class Helper { > > static int BUF_SIZE = 1024 * 1024; > static int BUF_COUNT = 100; > > static SSLSocket requireAESCipherSuites(SSLSocket socket) { > String supportedCipherSuites[] = socket.getSupportedCipherSuites(); > > System.out.println("Supported cipher suite: " + > Arrays.toString(supportedCipherSuites)); > > List selectedCipherSuites = new ArrayList<>(); > > // String patternString = ".*"; > String patternString = "TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256"; > // String patternString = "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"; > > Pattern pattern = Pattern.compile(patternString); > > for (String cipherSuite : supportedCipherSuites) { > Matcher matcher = pattern.matcher(cipherSuite); > if (matcher.find()) { > selectedCipherSuites.add(cipherSuite); > } > } > > System.out.println("Selected cipher suites: " + > selectedCipherSuites); > > socket.setEnabledCipherSuites(selectedCipherSuites.toArray(new > String[0])); > > return socket; > } > } > From xuelei.fan at oracle.com Mon Jan 27 06:19:17 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 27 Jan 2014 22:19:17 +0800 Subject: AES GCM slow In-Reply-To: <52E6283A.7000401@oracle.com> References: <52E6283A.7000401@oracle.com> Message-ID: <52E66AE5.5050303@oracle.com> What's the platform are you using for the testing? Windows, Linux, Solaris or Mac OS? GCM are now only implemented in SunJCE provider. I want to make sure the crypto provider for AES-CBC, which is different for different platforms by default, is not the major cause of the performance impact. Thanks for the performance measure. Regards, Xuelei On 1/27/2014 5:34 PM, Chris Hegarty wrote: > Cross posting to security-dev, since the question cipher related. > > -Chris. > > On 27/01/14 09:28, Mark Christiaens wrote: >> I wrote a little test client/server setup that transfers 100 MB of data >> over an SSL socket configured to use TLS 1.2 AES GCM >> (TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256). On my i7-4770 CPU @ 3.40GHz >> with OpenJDK 1.8.0-ea-b124 I get a transfer rate of around 5.2 >> MiB/second. I expected a higher speed. Using >> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 I reach 100 MiB/s. Is this to >> be expected? >> >> For reference, here is my code: >> >> ///// Client.java >> >> package ssl; >> >> import javax.net.ssl.*; >> import java.io.*; >> import java.util.Arrays; >> >> public class Client { >> >> public static void main(String[] arstring) { >> try { >> SSLSocketFactory sslsocketfactory = (SSLSocketFactory) >> SSLSocketFactory.getDefault(); >> SSLSocket sslsocket = (SSLSocket) >> sslsocketfactory.createSocket("localhost", 9999); >> Helper.requireAESCipherSuites(sslsocket); >> sslsocket.setEnabledProtocols(new String[]{"TLSv1.2"}); >> >> try (OutputStream outputstream = >> sslsocket.getOutputStream()) { >> byte[] buf = new byte[Helper.BUF_SIZE]; >> Arrays.fill(buf, (byte) 1); >> for (int i = 0; i < Helper.BUF_COUNT; ++i) { >> outputstream.write(buf); >> } >> >> System.out.println("Using cipher suite: " + >> (sslsocket.getSession()).getCipherSuite()); >> >> outputstream.flush(); >> } >> >> } catch (IOException exception) { >> exception.printStackTrace(); >> } >> } >> } >> >> ///// Server.java >> >> package ssl; >> >> import javax.net.ssl.*; >> import java.io.*; >> >> public class Server { >> >> public static void main(String[] arstring) { >> try { >> SSLServerSocketFactory sslserversocketfactory = >> (SSLServerSocketFactory) SSLServerSocketFactory.getDefault(); >> SSLServerSocket sslserversocket = (SSLServerSocket) >> sslserversocketfactory.createServerSocket(9999); >> SSLSocket sslsocket = (SSLSocket) sslserversocket.accept(); >> >> InputStream inputstream = sslsocket.getInputStream(); >> >> byte[] buf = new byte[Helper.BUF_SIZE]; >> long bytesToRead = BYTES_TO_READ; >> >> long startTime = System.currentTimeMillis(); >> >> while (bytesToRead > 0) { >> bytesToRead -= inputstream.read(buf); >> } >> >> long stopTime = System.currentTimeMillis(); >> long totalTimeMs = stopTime - startTime; >> double mbRead = BYTES_TO_READ / (1024.0 * 1024); >> double totalTimeSeconds = totalTimeMs / 1000.0; >> double mibPerSecond = mbRead / totalTimeSeconds; >> >> System.out.println("Using cipher suite: " + >> (sslsocket.getSession()).getCipherSuite()); >> System.out.println("Read " + mbRead + "MiB in " + >> totalTimeSeconds + "s"); >> System.out.println("Bandwidth: " + mibPerSecond + "MiB/s"); >> >> } catch (IOException exception) { >> exception.printStackTrace(); >> } >> } >> >> private static final int BYTES_TO_READ = Helper.BUF_COUNT * >> Helper.BUF_SIZE; >> } >> >> ///// Helper.java >> >> package ssl; >> >> import java.util.*; >> import java.util.regex.*; >> import javax.net.ssl.*; >> >> public class Helper { >> >> static int BUF_SIZE = 1024 * 1024; >> static int BUF_COUNT = 100; >> >> static SSLSocket requireAESCipherSuites(SSLSocket socket) { >> String supportedCipherSuites[] = >> socket.getSupportedCipherSuites(); >> >> System.out.println("Supported cipher suite: " + >> Arrays.toString(supportedCipherSuites)); >> >> List selectedCipherSuites = new ArrayList<>(); >> >> // String patternString = ".*"; >> String patternString = "TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256"; >> // String patternString = >> "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"; >> >> Pattern pattern = Pattern.compile(patternString); >> >> for (String cipherSuite : supportedCipherSuites) { >> Matcher matcher = pattern.matcher(cipherSuite); >> if (matcher.find()) { >> selectedCipherSuites.add(cipherSuite); >> } >> } >> >> System.out.println("Selected cipher suites: " + >> selectedCipherSuites); >> >> socket.setEnabledCipherSuites(selectedCipherSuites.toArray(new >> String[0])); >> >> return socket; >> } >> } >> From mark.g.j.christiaens at gmail.com Mon Jan 27 06:23:54 2014 From: mark.g.j.christiaens at gmail.com (Mark Christiaens) Date: Mon, 27 Jan 2014 15:23:54 +0100 Subject: AES GCM slow In-Reply-To: <52E66AE5.5050303@oracle.com> References: <52E6283A.7000401@oracle.com> <52E66AE5.5050303@oracle.com> Message-ID: Silly me, forgot to mention that I'm working on Ubuntu, 64 bit, 13.10. So, AES-CBC seems to be reasonably fast (100 MiB/s) but AES-GCM is slow (5.2 MiB/s). I'm particularly curious about the GCM one because I get the impression that OpenSSL should be able to reach in the GB/s for AES-GCM encryption/authentication. Mark On Mon, Jan 27, 2014 at 3:19 PM, Xuelei Fan wrote: > What's the platform are you using for the testing? Windows, Linux, > Solaris or Mac OS? GCM are now only implemented in SunJCE provider. I > want to make sure the crypto provider for AES-CBC, which is different > for different platforms by default, is not the major cause of the > performance impact. > > Thanks for the performance measure. > > Regards, > Xuelei > > On 1/27/2014 5:34 PM, Chris Hegarty wrote: > > Cross posting to security-dev, since the question cipher related. > > > > -Chris. > > > > On 27/01/14 09:28, Mark Christiaens wrote: > >> I wrote a little test client/server setup that transfers 100 MB of data > >> over an SSL socket configured to use TLS 1.2 AES GCM > >> (TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256). On my i7-4770 CPU @ 3.40GHz > >> with OpenJDK 1.8.0-ea-b124 I get a transfer rate of around 5.2 > >> MiB/second. I expected a higher speed. Using > >> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 I reach 100 MiB/s. Is this to > >> be expected? > >> > >> For reference, here is my code: > >> > >> ///// Client.java > >> > >> package ssl; > >> > >> import javax.net.ssl.*; > >> import java.io.*; > >> import java.util.Arrays; > >> > >> public class Client { > >> > >> public static void main(String[] arstring) { > >> try { > >> SSLSocketFactory sslsocketfactory = (SSLSocketFactory) > >> SSLSocketFactory.getDefault(); > >> SSLSocket sslsocket = (SSLSocket) > >> sslsocketfactory.createSocket("localhost", 9999); > >> Helper.requireAESCipherSuites(sslsocket); > >> sslsocket.setEnabledProtocols(new String[]{"TLSv1.2"}); > >> > >> try (OutputStream outputstream = > >> sslsocket.getOutputStream()) { > >> byte[] buf = new byte[Helper.BUF_SIZE]; > >> Arrays.fill(buf, (byte) 1); > >> for (int i = 0; i < Helper.BUF_COUNT; ++i) { > >> outputstream.write(buf); > >> } > >> > >> System.out.println("Using cipher suite: " + > >> (sslsocket.getSession()).getCipherSuite()); > >> > >> outputstream.flush(); > >> } > >> > >> } catch (IOException exception) { > >> exception.printStackTrace(); > >> } > >> } > >> } > >> > >> ///// Server.java > >> > >> package ssl; > >> > >> import javax.net.ssl.*; > >> import java.io.*; > >> > >> public class Server { > >> > >> public static void main(String[] arstring) { > >> try { > >> SSLServerSocketFactory sslserversocketfactory = > >> (SSLServerSocketFactory) SSLServerSocketFactory.getDefault(); > >> SSLServerSocket sslserversocket = (SSLServerSocket) > >> sslserversocketfactory.createServerSocket(9999); > >> SSLSocket sslsocket = (SSLSocket) sslserversocket.accept(); > >> > >> InputStream inputstream = sslsocket.getInputStream(); > >> > >> byte[] buf = new byte[Helper.BUF_SIZE]; > >> long bytesToRead = BYTES_TO_READ; > >> > >> long startTime = System.currentTimeMillis(); > >> > >> while (bytesToRead > 0) { > >> bytesToRead -= inputstream.read(buf); > >> } > >> > >> long stopTime = System.currentTimeMillis(); > >> long totalTimeMs = stopTime - startTime; > >> double mbRead = BYTES_TO_READ / (1024.0 * 1024); > >> double totalTimeSeconds = totalTimeMs / 1000.0; > >> double mibPerSecond = mbRead / totalTimeSeconds; > >> > >> System.out.println("Using cipher suite: " + > >> (sslsocket.getSession()).getCipherSuite()); > >> System.out.println("Read " + mbRead + "MiB in " + > >> totalTimeSeconds + "s"); > >> System.out.println("Bandwidth: " + mibPerSecond + "MiB/s"); > >> > >> } catch (IOException exception) { > >> exception.printStackTrace(); > >> } > >> } > >> > >> private static final int BYTES_TO_READ = Helper.BUF_COUNT * > >> Helper.BUF_SIZE; > >> } > >> > >> ///// Helper.java > >> > >> package ssl; > >> > >> import java.util.*; > >> import java.util.regex.*; > >> import javax.net.ssl.*; > >> > >> public class Helper { > >> > >> static int BUF_SIZE = 1024 * 1024; > >> static int BUF_COUNT = 100; > >> > >> static SSLSocket requireAESCipherSuites(SSLSocket socket) { > >> String supportedCipherSuites[] = > >> socket.getSupportedCipherSuites(); > >> > >> System.out.println("Supported cipher suite: " + > >> Arrays.toString(supportedCipherSuites)); > >> > >> List selectedCipherSuites = new ArrayList<>(); > >> > >> // String patternString = ".*"; > >> String patternString = > "TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256"; > >> // String patternString = > >> "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"; > >> > >> Pattern pattern = Pattern.compile(patternString); > >> > >> for (String cipherSuite : supportedCipherSuites) { > >> Matcher matcher = pattern.matcher(cipherSuite); > >> if (matcher.find()) { > >> selectedCipherSuites.add(cipherSuite); > >> } > >> } > >> > >> System.out.println("Selected cipher suites: " + > >> selectedCipherSuites); > >> > >> socket.setEnabledCipherSuites(selectedCipherSuites.toArray(new > >> String[0])); > >> > >> return socket; > >> } > >> } > >> > > -- Mark Christiaens Ganzeplas 23 9880 Aalter 09 / 325 07 40 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140127/3fa301cc/attachment-0001.html From mstjohns at comcast.net Mon Jan 27 08:46:45 2014 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 27 Jan 2014 11:46:45 -0500 Subject: AES GCM slow In-Reply-To: References: <52E6283A.7000401@oracle.com> <52E66AE5.5050303@oracle.com> Message-ID: <20140127164647.B073F64D3@mail.openjdk.java.net> At 09:23 AM 1/27/2014, Mark Christiaens wrote: >Silly me, forgot to mention that I'm working on Ubuntu, 64 bit, 13.10. > >So, AES-CBC seems to be reasonably fast (100 MiB/s) but AES-GCM is slow (5.2 MiB/s). ? I'm particularly curious about the GCM one because I get the impression that OpenSSL should be able to reach in the GB/s for AES-GCM encryption/authentication.? > >Mark GCM uses a GF2 multiply as part of the integrity calculation. That operation is pretty expensive. My guess is that if the code was profiled, you'd find a lot of time being spent in com.sun.crypto.provider.GHASH. The more recent intel processors have a set of instructions that substantially improve this performance - http://en.wikipedia.org/wiki/CLMUL_instruction_set - but the code in the standard provider is all pure java and doesn't take advantage of this as far as I can tell. I believe that the more recent versions of OpenSSL *have* been updated to take advantage of the new instructions which explains their performance. The same processors generally also support an AES instruction set so if someone were to build a native version of this it might be useful to also replace/augment the default AES block cipher implementation. Also see http://software.intel.com/en-us/articles/intel-aes-ni-performance-testing-on-linuxjava-stack Mike >On Mon, Jan 27, 2014 at 3:19 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote: >What's the platform are you using for the testing? ? Windows, Linux, >Solaris or Mac OS? ? GCM are now only implemented in SunJCE provider. ? I >want to make sure the crypto provider for AES-CBC, which is different >for different platforms by default, is not the major cause of the >performance impact. > >Thanks for the performance measure. > >Regards, >Xuelei > >On 1/27/2014 5:34 PM, Chris Hegarty wrote: >> Cross posting to security-dev, since the question cipher related. >> >> -Chris. >> >> On 27/01/14 09:28, Mark Christiaens wrote: >>> I wrote ? a little test client/server setup that transfers 100 MB of data >>> over an SSL socket configured to use TLS 1.2 AES GCM >>> (TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256). ? On my i7-4770 CPU @ 3.40GHz >>> with OpenJDK 1.8.0-ea-b124 I get a transfer rate of around 5.2 >>> MiB/second. ? I expected a higher speed. ? Using >>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 I reach 100 MiB/s. ? Is this to >>> be expected? >>> >>> For reference, here is my code: >>> >>> ///// Client.java >>> >>> package ssl; >>> >>> import javax.net.ssl.*; >>> import java.io.*; >>> import java.util.Arrays; >>> >>> public class Client { >>> >>> ? ? ? public static void main(String[] arstring) { >>> ? ? ? ? ? try { >>> ? ? ? ? ? ? ? SSLSocketFactory sslsocketfactory = (SSLSocketFactory) >>> SSLSocketFactory.getDefault(); >>> ? ? ? ? ? ? ? SSLSocket sslsocket = (SSLSocket) >>> sslsocketfactory.createSocket("localhost", 9999); >>> ? ? ? ? ? ? ? Helper.requireAESCipherSuites(sslsocket); >>> ? ? ? ? ? ? ? sslsocket.setEnabledProtocols(new String[]{"TLSv1.2"}); >>> >>> ? ? ? ? ? ? ? try (OutputStream outputstream = >>> sslsocket.getOutputStream()) { >>> ? ? ? ? ? ? ? ? ? byte[] buf = new byte[Helper.BUF_SIZE]; >>> ? ? ? ? ? ? ? ? ? Arrays.fill(buf, (byte) 1); >>> ? ? ? ? ? ? ? ? ? for (int i = 0; i < Helper.BUF_COUNT; ++i) { >>> ? ? ? ? ? ? ? ? ? ? ? outputstream.write(buf); >>> ? ? ? ? ? ? ? ? ? } >>> >>> ? ? ? ? ? ? ? ? ? System.out.println("Using cipher suite: " + >>> (sslsocket.getSession()).getCipherSuite()); >>> >>> ? ? ? ? ? ? ? ? ? outputstream.flush(); >>> ? ? ? ? ? ? ? } >>> >>> ? ? ? ? ? } catch (IOException exception) { >>> ? ? ? ? ? ? ? exception.printStackTrace(); >>> ? ? ? ? ? } >>> ? ? ? } >>> } >>> >>> ///// Server.java >>> >>> package ssl; >>> >>> import javax.net.ssl.*; >>> import java.io.*; >>> >>> public class Server { >>> >>> ? ? ? public static void main(String[] arstring) { >>> ? ? ? ? ? try { >>> ? ? ? ? ? ? ? SSLServerSocketFactory sslserversocketfactory = >>> (SSLServerSocketFactory) SSLServerSocketFactory.getDefault(); >>> ? ? ? ? ? ? ? SSLServerSocket sslserversocket = (SSLServerSocket) >>> sslserversocketfactory.createServerSocket(9999); >>> ? ? ? ? ? ? ? SSLSocket sslsocket = (SSLSocket) sslserversocket.accept(); >>> >>> ? ? ? ? ? ? ? InputStream inputstream = sslsocket.getInputStream(); >>> >>> ? ? ? ? ? ? ? byte[] buf = new byte[Helper.BUF_SIZE]; >>> ? ? ? ? ? ? ? long bytesToRead = BYTES_TO_READ; >>> >>> ? ? ? ? ? ? ? long startTime = System.currentTimeMillis(); >>> >>> ? ? ? ? ? ? ? while (bytesToRead > 0) { >>> ? ? ? ? ? ? ? ? ? bytesToRead -= inputstream.read(buf); >>> ? ? ? ? ? ? ? } >>> >>> ? ? ? ? ? ? ? long stopTime = System.currentTimeMillis(); >>> ? ? ? ? ? ? ? long totalTimeMs = stopTime - startTime; >>> ? ? ? ? ? ? ? double mbRead = BYTES_TO_READ / (1024.0 * 1024); >>> ? ? ? ? ? ? ? double totalTimeSeconds = totalTimeMs / 1000.0; >>> ? ? ? ? ? ? ? double mibPerSecond = mbRead / totalTimeSeconds; >>> >>> ? ? ? ? ? ? ? System.out.println("Using cipher suite: " + >>> (sslsocket.getSession()).getCipherSuite()); >>> ? ? ? ? ? ? ? System.out.println("Read " + mbRead + "MiB in " + >>> totalTimeSeconds + "s"); >>> ? ? ? ? ? ? ? System.out.println("Bandwidth: " + mibPerSecond + "MiB/s"); >>> >>> ? ? ? ? ? } catch (IOException exception) { >>> ? ? ? ? ? ? ? exception.printStackTrace(); >>> ? ? ? ? ? } >>> ? ? ? } >>> >>> ? ? ? private static final int BYTES_TO_READ = Helper.BUF_COUNT * >>> Helper.BUF_SIZE; >>> } >>> >>> ///// Helper.java >>> >>> package ssl; >>> >>> import java.util.*; >>> import java.util.regex.*; >>> import javax.net.ssl.*; >>> >>> public class Helper { >>> >>> ? ? ? static int BUF_SIZE = 1024 * 1024; >>> ? ? ? static int BUF_COUNT = 100; >>> >>> ? ? ? static SSLSocket requireAESCipherSuites(SSLSocket socket) { >>> ? ? ? ? ? String supportedCipherSuites[] = >>> socket.getSupportedCipherSuites(); >>> >>> ? ? ? ? ? System.out.println("Supported cipher suite: " + >>> Arrays.toString(supportedCipherSuites)); >>> >>> ? ? ? ? ? List selectedCipherSuites = new ArrayList<>(); >>> >>> // ? ? ? ? String patternString = ".*"; >>> ? ? ? ? ? String patternString = "TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256"; >>> // ? ? ? ? String patternString = >>> "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"; >>> >>> ? ? ? ? ? Pattern pattern = Pattern.compile(patternString); >>> >>> ? ? ? ? ? for (String cipherSuite : supportedCipherSuites) { >>> ? ? ? ? ? ? ? Matcher matcher = pattern.matcher(cipherSuite); >>> ? ? ? ? ? ? ? if (matcher.find()) { >>> ? ? ? ? ? ? ? ? ? selectedCipherSuites.add(cipherSuite); >>> ? ? ? ? ? ? ? } >>> ? ? ? ? ? } >>> >>> ? ? ? ? ? System.out.println("Selected cipher suites: " + >>> selectedCipherSuites); >>> >>> ? ? ? ? ? socket.setEnabledCipherSuites(selectedCipherSuites.toArray(new >>> String[0])); >>> >>> ? ? ? ? ? return socket; >>> ? ? ? } >>> } >>> > > > > >-- >Mark Christiaens >Ganzeplas 23 >9880 Aalter >09 / 325 07 40 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140127/185f4f02/attachment.html From jeff.dinkins at oracle.com Tue Jan 28 12:40:59 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:40:59 +0000 Subject: hg: jdk8/tl/hotspot: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204101.F2B7262824@hg.openjdk.java.net> Changeset: ce0320cdb075 Author: jeff Date: 2014-01-28 20:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ce0320cdb075 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Tue Jan 28 12:40:07 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:40:07 +0000 Subject: hg: jdk8/tl/corba: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204007.AA92D62823@hg.openjdk.java.net> Changeset: 6d40c0d49c7a Author: jeff Date: 2014-01-28 20:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/6d40c0d49c7a 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Tue Jan 28 12:41:28 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:41:28 +0000 Subject: hg: jdk8/tl/jaxp: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204131.5EC6762825@hg.openjdk.java.net> Changeset: 60c2c003fa11 Author: jeff Date: 2014-01-28 20:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/60c2c003fa11 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Tue Jan 28 12:41:46 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:41:46 +0000 Subject: hg: jdk8/tl/jaxws: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204148.F3F7962826@hg.openjdk.java.net> Changeset: 2b44c111e153 Author: jeff Date: 2014-01-28 20:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/2b44c111e153 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Tue Jan 28 12:42:29 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:42:29 +0000 Subject: hg: jdk8/tl/jdk: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204248.3844C62827@hg.openjdk.java.net> Changeset: 72d0cc723560 Author: jeff Date: 2014-01-28 20:10 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72d0cc723560 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Tue Jan 28 12:44:50 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:44:50 +0000 Subject: hg: jdk8/tl/langtools: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204454.0BE4B62828@hg.openjdk.java.net> Changeset: afa91c54ff00 Author: jeff Date: 2014-01-28 20:10 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/afa91c54ff00 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Tue Jan 28 12:45:07 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:45:07 +0000 Subject: hg: jdk8/tl/nashorn: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128204508.980F662829@hg.openjdk.java.net> Changeset: d3b293a4d554 Author: jeff Date: 2014-01-28 20:10 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d3b293a4d554 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From jeff.dinkins at oracle.com Tue Jan 28 12:39:31 2014 From: jeff.dinkins at oracle.com (jeff.dinkins at oracle.com) Date: Tue, 28 Jan 2014 20:39:31 +0000 Subject: hg: jdk8/tl: 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Message-ID: <20140128203931.DC82E62821@hg.openjdk.java.net> Changeset: 4f590c2cec75 Author: jeff Date: 2014-01-28 20:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4f590c2cec75 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README From chris.hegarty at oracle.com Fri Jan 31 02:52:34 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 31 Jan 2014 10:52:34 +0000 Subject: RFR [9] 7150539: HttpURLConnection.getResponseMessage() doesn't throw IOException on server error (OS X) Message-ID: <52EB8072.6070305@oracle.com> This is a trivial test only change to make it agnostic of system proxy setting on OS X. The test requires that it makes a direct connection to the self contained trivial test HTTP server, it should not be influenced by system proxy settings. diff --git a/test/sun/net/www/http/HttpClient/RetryPost.java b/test/sun/net/www/http/HttpClient/RetryPost.java --- a/test/sun/net/www/http/HttpClient/RetryPost.java +++ b/test/sun/net/www/http/HttpClient/RetryPost.java @@ -55,8 +55,8 @@ void doClient() { try { InetSocketAddress address = httpServer.getAddress(); - URL url = new URL("http://" + address.getHostName() + ":" + address.getPort() + "/test/"); - HttpURLConnection uc = (HttpURLConnection)url.openConnection(); + URL url = new URL("http://localhost:" + address.getPort() + "/test/"); + HttpURLConnection uc = (HttpURLConnection)url.openConnection(Proxy.NO_PROXY); uc.setDoOutput(true); uc.setRequestMethod("POST"); uc.getResponseCode(); -Chris. From michael.x.mcmahon at oracle.com Fri Jan 31 02:54:22 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 31 Jan 2014 10:54:22 +0000 Subject: RFR [9] 7150539: HttpURLConnection.getResponseMessage() doesn't throw IOException on server error (OS X) In-Reply-To: <52EB8072.6070305@oracle.com> References: <52EB8072.6070305@oracle.com> Message-ID: <52EB80DE.6050604@oracle.com> Looks good! Michael. On 31/01/14 10:52, Chris Hegarty wrote: > This is a trivial test only change to make it agnostic of system proxy > setting on OS X. The test requires that it makes a direct connection > to the self contained trivial test HTTP server, it should not be > influenced by system proxy settings. > > diff --git a/test/sun/net/www/http/HttpClient/RetryPost.java > b/test/sun/net/www/http/HttpClient/RetryPost.java > --- a/test/sun/net/www/http/HttpClient/RetryPost.java > +++ b/test/sun/net/www/http/HttpClient/RetryPost.java > @@ -55,8 +55,8 @@ > void doClient() { > try { > InetSocketAddress address = httpServer.getAddress(); > - URL url = new URL("http://" + address.getHostName() + ":" > + address.getPort() + "/test/"); > - HttpURLConnection uc = > (HttpURLConnection)url.openConnection(); > + URL url = new URL("http://localhost:" + address.getPort() > + "/test/"); > + HttpURLConnection uc = > (HttpURLConnection)url.openConnection(Proxy.NO_PROXY); > uc.setDoOutput(true); > uc.setRequestMethod("POST"); > uc.getResponseCode(); > > -Chris. From Alan.Bateman at oracle.com Fri Jan 31 03:02:20 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 31 Jan 2014 11:02:20 +0000 Subject: RFR [9] 7150539: HttpURLConnection.getResponseMessage() doesn't throw IOException on server error (OS X) In-Reply-To: <52EB8072.6070305@oracle.com> References: <52EB8072.6070305@oracle.com> Message-ID: <52EB82BC.7090601@oracle.com> On 31/01/2014 10:52, Chris Hegarty wrote: > This is a trivial test only change to make it agnostic of system proxy > setting on OS X. The test requires that it makes a direct connection > to the self contained trivial test HTTP server, it should not be > influenced by system proxy settings. Looks good to me too. -Alan From paul.sandoz at oracle.com Fri Jan 31 03:24:09 2014 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 31 Jan 2014 11:24:09 +0000 Subject: hg: jdk8/tl/jdk: 4 new changesets Message-ID: <20140131112700.AFEF362911@hg.openjdk.java.net> Changeset: 9f098aed44c0 Author: anazarov Date: 2014-01-31 12:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f098aed44c0 8032025: Update repeating annotations demo Reviewed-by: jfranck + src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Device.java + src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Kettle.xml + src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Module.java + src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/PluginChecker.java + src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Require.java + src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/RequireContainer.java + src/share/sample/annotations/DependencyChecker/Plugins/src/plugins/BoilerPlugin.java + src/share/sample/annotations/DependencyChecker/Plugins/src/plugins/ExtendedBoilerPlugin.java + src/share/sample/annotations/DependencyChecker/Plugins/src/plugins/TimerPlugin.java + src/share/sample/annotations/Validator/src/PositiveIntegerSupplier.java + src/share/sample/annotations/Validator/src/SupplierValidator.java + src/share/sample/annotations/Validator/src/Validate.java + src/share/sample/annotations/Validator/src/Validator.java + src/share/sample/annotations/index.html Changeset: f72a8df6a2ed Author: anazarov Date: 2014-01-31 12:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f72a8df6a2ed 8031650: Update bulk operation demo Reviewed-by: psandoz, mduigou + src/share/sample/lambda/BulkDataOperations/index.html + src/share/sample/lambda/BulkDataOperations/src/CSVProcessor.java + src/share/sample/lambda/BulkDataOperations/src/Grep.java + src/share/sample/lambda/BulkDataOperations/src/PasswordGenerator.java + src/share/sample/lambda/BulkDataOperations/src/WC.java Changeset: 4574011c1689 Author: anazarov Date: 2014-01-31 12:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4574011c1689 8032020: Update try-with-resources demo Reviewed-by: darcy, alanb, smarks + src/share/sample/try-with-resources/index.html + src/share/sample/try-with-resources/src/CustomAutoCloseableSample.java + src/share/sample/try-with-resources/src/Unzip.java + src/share/sample/try-with-resources/src/ZipCat.java Changeset: a4f68fc5f353 Author: psandoz Date: 2014-01-31 12:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a4f68fc5f353 8032056: Create demo to illustrate new practices of the default methods usage Reviewed-by: briangoetz, rfield, psandoz Contributed-by: taras.ledkov at oracle.com + src/share/sample/lambda/DefaultMethods/ArrayIterator.java + src/share/sample/lambda/DefaultMethods/DiamondInheritance.java + src/share/sample/lambda/DefaultMethods/Inheritance.java + src/share/sample/lambda/DefaultMethods/MixIn.java + src/share/sample/lambda/DefaultMethods/Reflection.java + src/share/sample/lambda/DefaultMethods/SimplestUsage.java