From mikael.vidstedt at oracle.com Tue Mar 1 18:29:55 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 1 Mar 2016 10:29:55 -0800 Subject: RFR (XS): 8149596: Remove java.nio.Bits copy wrapper methods Message-ID: <56D5DFA3.7010300@oracle.com> As part of JDK-8141491[1] the native methods in java.nio.Bits were removed, and the functionality is instead provided by the VM through j.i.m.Unsafe. The Bits wrapper methods are therefore redundant and can be removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8149596 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8149596/webrev.00/webrev/ I've run the java/nio jtreg tests and it all passes (modulo a couple of unrelated failures). Cheers, Mikael [1] https://bugs.openjdk.java.net/browse/JDK-8141491 From brian.burkhalter at oracle.com Tue Mar 1 18:48:07 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 1 Mar 2016 10:48:07 -0800 Subject: RFR (XS): 8149596: Remove java.nio.Bits copy wrapper methods In-Reply-To: <56D5DFA3.7010300@oracle.com> References: <56D5DFA3.7010300@oracle.com> Message-ID: Hi Mikael, Not a Reviewer here, but it looks OK to me aside from the copyright year in the template file. Nice to see code removed! Brian On Mar 1, 2016, at 10:29 AM, Mikael Vidstedt wrote: > As part of JDK-8141491[1] the native methods in java.nio.Bits were removed, and the functionality is instead provided by the VM through j.i.m.Unsafe. The Bits wrapper methods are therefore redundant and can be removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149596 > Webrev:http://cr.openjdk.java.net/~mikael/webrevs/8149596/webrev.00/webrev/ > > I've run the java/nio jtreg tests and it all passes (modulo a couple of unrelated failures). -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Tue Mar 1 19:19:29 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 1 Mar 2016 19:19:29 +0000 Subject: RFR (XS): 8149596: Remove java.nio.Bits copy wrapper methods In-Reply-To: References: <56D5DFA3.7010300@oracle.com> Message-ID: +1. -Chris. On 1 Mar 2016, at 18:48, Brian Burkhalter wrote: > Hi Mikael, > > Not a Reviewer here, but it looks OK to me aside from the copyright year in the template file. > > Nice to see code removed! > > Brian > > On Mar 1, 2016, at 10:29 AM, Mikael Vidstedt wrote: > >> As part of JDK-8141491[1] the native methods in java.nio.Bits were removed, and the functionality is instead provided by the VM through j.i.m.Unsafe. The Bits wrapper methods are therefore redundant and can be removed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8149596 >> Webrev:http://cr.openjdk.java.net/~mikael/webrevs/8149596/webrev.00/webrev/ >> >> I've run the java/nio jtreg tests and it all passes (modulo a couple of unrelated failures). > From paul.sandoz at oracle.com Wed Mar 2 11:37:01 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 2 Mar 2016 12:37:01 +0100 Subject: RFR (XS): 8149596: Remove java.nio.Bits copy wrapper methods In-Reply-To: <56D5DFA3.7010300@oracle.com> References: <56D5DFA3.7010300@oracle.com> Message-ID: <9963229A-EA3C-492F-91B0-1D4995FCD62E@oracle.com> > On 1 Mar 2016, at 19:29, Mikael Vidstedt wrote: > > > As part of JDK-8141491[1] the native methods in java.nio.Bits were removed, and the functionality is instead provided by the VM through j.i.m.Unsafe. The Bits wrapper methods are therefore redundant and can be removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149596 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8149596/webrev.00/webrev/ > +1 Paul. > I've run the java/nio jtreg tests and it all passes (modulo a couple of unrelated failures). > > Cheers, > Mikael > > > [1] https://bugs.openjdk.java.net/browse/JDK-8141491 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dehandecroos at gmail.com Wed Mar 2 17:34:23 2016 From: dehandecroos at gmail.com (Dehan De Croos) Date: Wed, 2 Mar 2016 23:04:23 +0530 Subject: Intriducing NIO functionality to Java 1.4 Message-ID: Hi Team, I have a requirement to introduce a directory listening functionality - [,WatchService API ] to JAVA 1.4. Is this possible? best regards, *Dehan de Croos* -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Wed Mar 2 18:21:24 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 2 Mar 2016 19:21:24 +0100 (CET) Subject: Intriducing NIO functionality to Java 1.4 In-Reply-To: References: Message-ID: <379977851.2166939.1456942884585.JavaMail.zimbra@u-pem.fr> Hi Dehan, you can do polling, i.e. having a thread that periodically checks if something change since java 1, i think that there is a code in apache common-io that does that, if you don't take a recent release, perhaps it will be 1.4 compatible. R?mi PS: I hope you're applying at least a 4x modifier on your price for working in such environment. ----- Mail original ----- > De: "Dehan De Croos" > ?: nio-dev at openjdk.java.net > Envoy?: Mercredi 2 Mars 2016 18:34:23 > Objet: Intriducing NIO functionality to Java 1.4 > Hi Team, > I have a requirement to introduce a directory listening functionality - > [,WatchService API ] to JAVA 1.4. Is this possible? > best regards, > Dehan de Croos -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lloyd at redhat.com Wed Mar 2 22:51:13 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 2 Mar 2016 16:51:13 -0600 Subject: Intriducing NIO functionality to Java 1.4 In-Reply-To: <379977851.2166939.1456942884585.JavaMail.zimbra@u-pem.fr> References: <379977851.2166939.1456942884585.JavaMail.zimbra@u-pem.fr> Message-ID: <56D76E61.6090107@redhat.com> If you have direct control over the code, and C or C++ expertise in-house, JNI is an option as well. On 03/02/2016 12:21 PM, Remi Forax wrote: > Hi Dehan, > you can do polling, i.e. having a thread that periodically checks if > something change since java 1, > i think that there is a code in apache common-io that does that, if you > don't take a recent release, > perhaps it will be 1.4 compatible. > > R?mi > PS: I hope you're applying at least a 4x modifier on your price for > working in such environment. > > > ------------------------------------------------------------------------ > > *De: *"Dehan De Croos" > *?: *nio-dev at openjdk.java.net > *Envoy?: *Mercredi 2 Mars 2016 18:34:23 > *Objet: *Intriducing NIO functionality to Java 1.4 > > Hi Team, > I have a requirement to introduce a directory listening > functionality - [,WatchService API ] to JAVA 1.4. Is this possible? > > best regards, > *Dehan de Croos* > > -- - DML From dehandecroos at gmail.com Thu Mar 3 04:32:10 2016 From: dehandecroos at gmail.com (Dehan De Croos) Date: Thu, 3 Mar 2016 10:02:10 +0530 Subject: Intriducing NIO functionality to Java 1.4 In-Reply-To: <379977851.2166939.1456942884585.JavaMail.zimbra@u-pem.fr> References: <379977851.2166939.1456942884585.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, I know, Remi this is my first job out of college :(. Sad that I am not developing for the cutting edge. The requirement demands that it be compatible to the java 1.4 environment but some environments do have as new as JAVA 8. Polling i quite expensive Isnt it. Wondering how its introduced in the OpenJDK source. any pointers on how I can read the source? best regards, *Dehan de Croos* On 2 March 2016 at 23:51, Remi Forax wrote: > Hi Dehan, > you can do polling, i.e. having a thread that periodically checks if > something change since java 1, > i think that there is a code in apache common-io that does that, if you > don't take a recent release, > perhaps it will be 1.4 compatible. > > R?mi > PS: I hope you're applying at least a 4x modifier on your price for > working in such environment. > > > ------------------------------ > > *De: *"Dehan De Croos" > *?: *nio-dev at openjdk.java.net > *Envoy?: *Mercredi 2 Mars 2016 18:34:23 > *Objet: *Intriducing NIO functionality to Java 1.4 > > > Hi Team, > I have a requirement to introduce a directory listening functionality - > [,WatchService API ] to JAVA 1.4. Is this possible? > > best regards, > *Dehan de Croos* > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mik3hall at gmail.com Thu Mar 3 09:41:41 2016 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 3 Mar 2016 03:41:41 -0600 Subject: Intriducing NIO functionality to Java 1.4 In-Reply-To: References: Message-ID: <4785CB9A-743C-4D4D-8A1D-819E59DE21E6@gmail.com> > On Mar 2, 2016, at 11:34 AM, Dehan De Croos wrote: > > Hi Team, > I have a requirement to introduce a directory listening functionality - [,WatchService API ] to JAVA 1.4. Is this possible? > > best regards, > Dehan de Croos You might check to see if any 3rd party code does what you already want. Polling is discussed and should be doable pure java at 1.4. The nio implementation of a watchservice for OS X is currently still a polling one as far as I know. No one seems to claim that is great, but... I think this... https://stackoverflow.com/questions/494869/file-changed-listener-in-java lists some possibilities. If you go native and get a kqueue watch service working please let the list know. I tried one for OS X that I couldn?t get working right. It seemed to deadlock on the ?many files? nio test case where kqueue would stop pumping events when the java code waited for more. I could get back to it sometime but have no immediate plans to. Michael Hall > -------------- next part -------------- An HTML attachment was scrubbed... URL: From huaming.li at oracle.com Fri Mar 4 10:36:24 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 4 Mar 2016 18:36:24 +0800 Subject: JDK 9 RFR of JDK-8068693: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing Message-ID: <56D96528.3070009@oracle.com> Please review the patch for test java/nio/channels/AsyncCloseAndInterrupt.java It's a test issue. The issue can be reproduced locally within 50 rounds of run. Root cause: even if server's connection backlog seems to be saturated sometime, subsequent connections may still success. Suggested Fix: Pass in parameter backlog as 1 when ServerSocket calls bind to make the socket server's backlog queue as short as possible. In pumpRefuser, try to connect to refuser server as quick as possible. The fix run successfully for 300 rounds of run locally, pass JPRT test. bug: https://bugs.openjdk.java.net/browse/JDK-8068693 webrev: http://cr.openjdk.java.net/~mli/8068693/webrev.00/ Thank you -Hamlin From huaming.li at oracle.com Fri Mar 4 13:05:35 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 4 Mar 2016 21:05:35 +0800 Subject: JDK 9 RFR of JDK-8143610: (dc) java/nio/channels/DatagramChannel/AdaptDatagramSocket.java failed intermittently due to SocketTimeoutException Message-ID: <56D9881F.4050905@oracle.com> Please review the patch for test java/nio/channels/DatagramChannel/AdaptDatagramSocket.java It's a test issue. By launch lots threads to exhaust cpu and network bandwidth, the issue could be reproduced locally with timeout value as 1000 millisecond ( timeout value in test code is 15000 millisecond ). Root cause: Test success depends on a specific timeout value, but in a extremely busy system, it's understandable that socket r/w can not finish in before timeout, so java.net.SocketTimeoutException will be thrown. Solution: Should not assume the socket operation could be finished in a specific time, just set the timeout as max value. bug: https://bugs.openjdk.java.net/browse/JDK-8143610 webrev: http://cr.openjdk.java.net/~mli/8143610/webrev.00/ Thank you -Hamlin From paul.sandoz at oracle.com Fri Mar 4 14:05:55 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 4 Mar 2016 15:05:55 +0100 Subject: [9] RFR: 8151182: HttpHeaders.allValues should return unmodifiable List as per JavaDoc In-Reply-To: <56D98B57.1050400@oracle.com> References: <56D98B57.1050400@oracle.com> Message-ID: Hi Vaibhav, This will not work, as Claes points out. You also might wanna check if there are tests in place asserting unmodfiablity, if there are none you could add some. Michael can point you in the right direction. Follow the trail of HttpHeaders1.makeUnmodifiable(), which is used to transition map values from mutable to unmodifiable: @Override public void makeUnmodifiable() { if (isUnmodifiable) return; Set keys = new HashSet<>(headers.keySet()); for (String key : keys) { List values = headers.remove(key); if (values != null) { headers.put(key, Collections.unmodifiableList(values)); } } isUnmodifiable = true; } In fact duplication of the key set can be avoided if one does this: Iterator> ie = headers.entrySet().iterator(); while (ie.hashNext()) { Map.Entry e = ie.next(); if (e.getValue() != null) { e.setValue(Collections.unmodifiableList(e.getValue())); } else { ie.remove(); } } However, i suspect this could be simplified to: headers.replaceAll((k, v) -> Collections.unmodifiableList(v))) If there are never any explicit null values placed in the map, which should be the case as that is really an anti-pattern. Also this: private List getOrCreate(String name) { List l = headers.get(name); if (l == null) { l = new LinkedList<>(); headers.put(name, l); } return l; } can be replaced with this: return headers.computeIfAbsent(name, k -> new LinkedList<>()); Paul. > On 4 Mar 2016, at 14:19, vaibhav x.choudhary wrote: > > Hi, > > Please review :- > > Review Link :- http://cr.openjdk.java.net/~ntv/vaibhav/JDK8151182/webrev.00/ > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8151182 > > -- > Thank You, > Vaibhav Choudhary > http://blogs.oracle.com/vaibhav > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From michael.x.mcmahon at oracle.com Fri Mar 4 15:14:35 2016 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 4 Mar 2016 15:14:35 +0000 Subject: [9] RFR: 8151182: HttpHeaders.allValues should return unmodifiable List as per JavaDoc In-Reply-To: References: <56D98B57.1050400@oracle.com> Message-ID: <56D9A65B.1040306@oracle.com> Yes, there is a mutability test already. We will have to fix the thread safety problem (and also the fact HttpHeaders1 was left public by mistake). Probably will separate the mutable and immutable types completely. Vaibhav, if you'd like to do it, you can define a package private implementation of HttpHeaders whose constructor takes a HttpHeadersImpl and uses final fields to ensure thread safety, rather than using makeUnmodifiable(). I'll contact you with some other ideas. I'll open a new report on this point and we probably should review on net-dev - Michael. On 04/03/16 14:05, Paul Sandoz wrote: > Hi Vaibhav, > > This will not work, as Claes points out. You also might wanna check if there are tests in place asserting unmodfiablity, if there are none you could add some. Michael can point you in the right direction. > > Follow the trail of HttpHeaders1.makeUnmodifiable(), which is used to transition map values from mutable to unmodifiable: > > @Override > public void makeUnmodifiable() { > if (isUnmodifiable) > return; > > Set keys = new HashSet<>(headers.keySet()); > for (String key : keys) { > List values = headers.remove(key); > if (values != null) { > headers.put(key, Collections.unmodifiableList(values)); > } > } > isUnmodifiable = true; > } > > In fact duplication of the key set can be avoided if one does this: > > Iterator> ie = headers.entrySet().iterator(); > while (ie.hashNext()) { > Map.Entry e = ie.next(); > if (e.getValue() != null) { > e.setValue(Collections.unmodifiableList(e.getValue())); > } > else { > ie.remove(); > } > } > > However, i suspect this could be simplified to: > > headers.replaceAll((k, v) -> Collections.unmodifiableList(v))) > > If there are never any explicit null values placed in the map, which should be the case as that is really an anti-pattern. > > Also this: > > private List getOrCreate(String name) { > List l = headers.get(name); > if (l == null) { > l = new LinkedList<>(); > headers.put(name, l); > } > return l; > } > > can be replaced with this: > > return headers.computeIfAbsent(name, k -> new LinkedList<>()); > > Paul. > >> On 4 Mar 2016, at 14:19, vaibhav x.choudhary wrote: >> >> Hi, >> >> Please review :- >> >> Review Link :- http://cr.openjdk.java.net/~ntv/vaibhav/JDK8151182/webrev.00/ >> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8151182 >> >> -- >> Thank You, >> Vaibhav Choudhary >> http://blogs.oracle.com/vaibhav >> From huaming.li at oracle.com Tue Mar 8 07:39:55 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 8 Mar 2016 15:39:55 +0800 Subject: JDK 9 RFR of JDK-8068693: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing In-Reply-To: <56D96528.3070009@oracle.com> References: <56D96528.3070009@oracle.com> Message-ID: <56DE81CB.5090601@oracle.com> Hi Brian, Would you please help to review the patch? Thank you -Hamlin On 2016/3/4 18:36, Hamlin Li wrote: > Please review the patch for test > java/nio/channels/AsyncCloseAndInterrupt.java > > It's a test issue. The issue can be reproduced locally within 50 > rounds of run. > Root cause: even if server's connection backlog seems to be saturated > sometime, subsequent connections may still success. > Suggested Fix: Pass in parameter backlog as 1 when ServerSocket calls > bind to make the socket server's backlog queue as short as possible. > In pumpRefuser, try to connect to refuser server as quick as possible. > The fix run successfully for 300 rounds of run locally, pass JPRT test. > > bug: https://bugs.openjdk.java.net/browse/JDK-8068693 > webrev: http://cr.openjdk.java.net/~mli/8068693/webrev.00/ > > Thank you > -Hamlin From huaming.li at oracle.com Tue Mar 8 07:40:00 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 8 Mar 2016 15:40:00 +0800 Subject: JDK 9 RFR of JDK-8143610: (dc) java/nio/channels/DatagramChannel/AdaptDatagramSocket.java failed intermittently due to SocketTimeoutException In-Reply-To: <56D9881F.4050905@oracle.com> References: <56D9881F.4050905@oracle.com> Message-ID: <56DE81D0.30006@oracle.com> Hi Brian, Would you please help to review the patch? Thank you -Hamlin On 2016/3/4 21:05, Hamlin Li wrote: > Please review the patch for test > java/nio/channels/DatagramChannel/AdaptDatagramSocket.java > > It's a test issue. By launch lots threads to exhaust cpu and network > bandwidth, the issue could be reproduced locally with timeout value as > 1000 millisecond ( timeout value in test code is 15000 millisecond ). > Root cause: Test success depends on a specific timeout value, but in a > extremely busy system, it's understandable that socket r/w can not > finish in before timeout, so java.net.SocketTimeoutException will be > thrown. > Solution: Should not assume the socket operation could be finished in > a specific time, just set the timeout as max value. > > bug: https://bugs.openjdk.java.net/browse/JDK-8143610 > webrev: http://cr.openjdk.java.net/~mli/8143610/webrev.00/ > > Thank you > -Hamlin From Alan.Bateman at oracle.com Tue Mar 8 10:57:00 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 8 Mar 2016 10:57:00 +0000 Subject: JDK 9 RFR of JDK-8143610: (dc) java/nio/channels/DatagramChannel/AdaptDatagramSocket.java failed intermittently due to SocketTimeoutException In-Reply-To: <56D9881F.4050905@oracle.com> References: <56D9881F.4050905@oracle.com> Message-ID: <56DEAFFC.60402@oracle.com> On 04/03/2016 13:05, Hamlin Li wrote: > Please review the patch for test > java/nio/channels/DatagramChannel/AdaptDatagramSocket.java > > It's a test issue. By launch lots threads to exhaust cpu and network > bandwidth, the issue could be reproduced locally with timeout value as > 1000 millisecond ( timeout value in test code is 15000 millisecond ). > Root cause: Test success depends on a specific timeout value, but in a > extremely busy system, it's understandable that socket r/w can not > finish in before timeout, so java.net.SocketTimeoutException will be > thrown. > Solution: Should not assume the socket operation could be finished in > a specific time, just set the timeout as max value. > > bug: https://bugs.openjdk.java.net/browse/JDK-8143610 > webrev: http://cr.openjdk.java.net/~mli/8143610/webrev.00/ 15s seems very high but the system is swapping or something is looping then you might be right. So I think the change is okay, I can sponsor this for you. -Alan. From brian.burkhalter at oracle.com Wed Mar 9 22:46:43 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 9 Mar 2016 14:46:43 -0800 Subject: JDK 9 RFR of JDK-8068693: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing In-Reply-To: <56D96528.3070009@oracle.com> References: <56D96528.3070009@oracle.com> Message-ID: Hi Hamlin, I am a bit confused about some things here. Firstly the issue is filed as the test failing on the Windows OS only, but some comments indicate that failures have been observed on Linux as well. Secondly, the change in the backlog setting occurs in the initRefuser() method which is invoked only if TestUtil.onWindows() is false, i.e., the test is not being run on Windows. So one would think that the backlog change would have no effect on Windows. Thirdly, if the test is being run with assertions enabled, then it appears that line 517 would throw an AssertionError on Windows and your changes at lines 523, 532, and 544-547 would never be executed. Hopefully I am just misinterpreting something here. Thanks, Brian On Mar 4, 2016, at 2:36 AM, Hamlin Li wrote: > Please review the patch for test java/nio/channels/AsyncCloseAndInterrupt.java > > It's a test issue. The issue can be reproduced locally within 50 rounds of run. > Root cause: even if server's connection backlog seems to be saturated sometime, subsequent connections may still success. > Suggested Fix: Pass in parameter backlog as 1 when ServerSocket calls bind to make the socket server's backlog queue as short as possible. In pumpRefuser, try to connect to refuser server as quick as possible. The fix run successfully for 300 rounds of run locally, pass JPRT test. > > bug: https://bugs.openjdk.java.net/browse/JDK-8068693 > webrev: http://cr.openjdk.java.net/~mli/8068693/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From huaming.li at oracle.com Thu Mar 10 05:55:27 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 10 Mar 2016 13:55:27 +0800 Subject: JDK 9 RFR of JDK-8151582: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing due to "Connection succeeded" In-Reply-To: References: <56D96528.3070009@oracle.com> Message-ID: <56E10C4F.4070404@oracle.com> On 2016/3/10 6:46, Brian Burkhalter wrote: > Hi Hamlin, > > I am a bit confused about some things here. Firstly the issue is filed > as the test failing on the Windows OS only, but some comments indicate > that failures have been observed on Linux as well. Hi Brian, Thanks for point out this. My bad, I should have realized this earlier. In fact there are 2 kinds of issue mixed in original bug JDK-8068693 . 1. one occurred only on windows, there are 5 failures, 1 failed against 6u101b10, 3 of them failed against 1.8.0_40, 1 failed against 1.9.0. The latest failure happened at at 2015-05-13 is against 6u101b10. The issue never happened since then. Pipe.SourceChannel/read/interrupt java.lang.Exception: Pipe.SourceChannel/read/interrupt timed out at TestThread.finishAndThrow(TestThread.java:83) at AsyncCloseAndInterrupt.test(AsyncCloseAndInterrupt.java:602) at AsyncCloseAndInterrupt.test(AsyncCloseAndInterrupt.java:609) at AsyncCloseAndInterrupt.test(AsyncCloseAndInterrupt.java:632) at AsyncCloseAndInterrupt.main(AsyncCloseAndInterrupt.java:732) 2. another occurred only on linux, which are test related to FINISH_CONNECT and happened 6 times from 2015-11-10 to 2016-02-29. SocketChannel/finishConnect/close finishConnect wait for pumping refuser ... java.lang.Exception: SocketChannel/finishConnect/close threw an exception at TestThread.finishAndThrow(TestThread.java:80) at AsyncCloseAndInterrupt.test(AsyncCloseAndInterrupt.java:602) at AsyncCloseAndInterrupt.test(AsyncCloseAndInterrupt.java:622) at AsyncCloseAndInterrupt.main(AsyncCloseAndInterrupt.java:720) ... ... Caused by: java.lang.RuntimeException: Connection succeeded at AsyncCloseAndInterrupt$16.doIO(AsyncCloseAndInterrupt.java:374) at AsyncCloseAndInterrupt$Tester.go(AsyncCloseAndInterrupt.java:485) at TestThread.run(TestThread.java:55) My current fix is just for the second issue as it happens so frequently recently, and I can make sure it's a test issue. To make the bug more clearer, I file a new bug to track the second issue, JDK-8151582 > Secondly, the change in the backlog setting occurs in the > initRefuser() method which is invoked only if TestUtil.onWindows() is > false, i.e., the test is not being run on Windows. So one would think > that the backlog change would have no effect on Windows. Yes, backlog are only used for CONNECT and FINISH_CONNECT tests which use initRefuser() and will not be run on windows. > Thirdly, if the test is being run with assertions enabled, then it > appears that line 517 would throw an AssertionError on Windows and > your changes at lines 523, 532, and 544-547 would never be executed. As said above, FINISH_CONNECT test is only run on non-windows, so the "assert" will not be executed on Windows. My change is only for FINISH_CONNECT test case failure which will not be run on windows. > Hopefully I am just misinterpreting something here. No, you helped to identify the bug description is not clear, thanks a lot.:-) As I filed a new bug, would you please help to review it at new place: http://cr.openjdk.java.net/~mli/8151582/webrev.00/, only updated the bug id in the source code. bug: https://bugs.openjdk.java.net/browse/JDK-8151582 Thank you -Hamlin > > Thanks, > > Brian > > On Mar 4, 2016, at 2:36 AM, Hamlin Li > wrote: > >> Please review the patch for test >> java/nio/channels/AsyncCloseAndInterrupt.java >> >> It's a test issue. The issue can be reproduced locally within 50 >> rounds of run. >> Root cause: even if server's connection backlog seems to be saturated >> sometime, subsequent connections may still success. >> Suggested Fix: Pass in parameter backlog as 1 when ServerSocket calls >> bind to make the socket server's backlog queue as short as possible. >> In pumpRefuser, try to connect to refuser server as quick as >> possible. The fix run successfully for 300 rounds of run locally, >> pass JPRT test. >> >> bug:https://bugs.openjdk.java.net/browse/JDK-8068693 >> webrev:http://cr.openjdk.java.net/~mli/8068693/webrev.00/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Mar 14 22:14:01 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 14 Mar 2016 15:14:01 -0700 Subject: JDK 9 RFR of JDK-8151582: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing due to "Connection succeeded" In-Reply-To: <56E10C4F.4070404@oracle.com> References: <56D96528.3070009@oracle.com> <56E10C4F.4070404@oracle.com> Message-ID: <596FE1B8-7B4A-4F32-BFCC-D2A09B27E11C@oracle.com> Hi Hamlin, On Mar 9, 2016, at 9:55 PM, Hamlin Li wrote: > Thanks for point out this. My bad, I should have realized this earlier. In fact there are 2 kinds of issue mixed in original bug JDK-8068693. > 1. one occurred only on windows, there are 5 failures, 1 failed against 6u101b10, 3 of them failed against 1.8.0_40, 1 failed against 1.9.0. The latest failure happened at at 2015-05-13 is against 6u101b10. The issue never happened since then. > [?] > > My current fix is just for the second issue as it happens so frequently recently, and I can make sure it's a test issue. > To make the bug more clearer, I file a new bug to track the second issue, JDK-8151582 >> Secondly, the change in the backlog setting occurs in the initRefuser() method which is invoked only if TestUtil.onWindows() is false, i.e., the test is not being run on Windows. So one would think that the backlog change would have no effect on Windows. > Yes, backlog are only used for CONNECT and FINISH_CONNECT tests which use initRefuser() and will not be run on windows. >> Thirdly, if the test is being run with assertions enabled, then it appears that line 517 would throw an AssertionError on Windows and your changes at lines 523, 532, and 544-547 would never be executed. > As said above, FINISH_CONNECT test is only run on non-windows, so the "assert" will not be executed on Windows. My change is only for FINISH_CONNECT test case failure which will not be run on windows. Thanks for the clarifications. >> Hopefully I am just misinterpreting something here. > No, you helped to identify the bug description is not clear, thanks a lot.:-) You?re welcome: I am glad it was useful. > As I filed a new bug, would you please help to review it at new place:http://cr.openjdk.java.net/~mli/8151582/webrev.00/, only updated the bug id in the source code. > bug: https://bugs.openjdk.java.net/browse/JDK-8151582 My only question is about AsyncCloseAndInterrupt.java line 92. If I recall correctly from my inspection of the code base last week, the default number of pending connections for ServerSocketChannel.bind(SocketAddress) is 50. Given the comment at line 509 // Create a pump thread dedicated to saturate refuser's connection backlog I am wondering whether we want to go all the way down to a backlog of just one. Have you tried any other values in the range [2,50]? It seems that with a queue length of only one the refuser?s connection backlog would be ?almost always? saturated and I wonder whether that compromises the test somehow? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From huaming.li at oracle.com Mon Mar 14 23:26:57 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 15 Mar 2016 07:26:57 +0800 Subject: JDK 9 RFR of JDK-8151582: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing due to "Connection succeeded" In-Reply-To: <596FE1B8-7B4A-4F32-BFCC-D2A09B27E11C@oracle.com> References: <56D96528.3070009@oracle.com> <56E10C4F.4070404@oracle.com> <596FE1B8-7B4A-4F32-BFCC-D2A09B27E11C@oracle.com> Message-ID: <56E748C1.9070307@oracle.com> On 2016/3/15 6:14, Brian Burkhalter wrote: > Hi Hamlin, > > On Mar 9, 2016, at 9:55 PM, Hamlin Li > wrote: > >> Thanks for point out this. My bad, I should have realized this >> earlier. In fact there are 2 kinds of issue mixed in original >> bugJDK-8068693 . >> 1. one occurred only on windows, there are 5 failures, 1 failed >> against 6u101b10, 3 of them failed against 1.8.0_40, 1 failed against >> 1.9.0. The latest failure happened at at 2015-05-13 is against >> 6u101b10. The issue never happened since then. >> [?] >> >> My current fix is just for the second issue as it happens so >> frequently recently, and I can make sure it's a test issue. >> To make the bug more clearer, I file a new bug to track the second >> issue,JDK-8151582 >>> Secondly, the change in the backlog setting occurs in the >>> initRefuser() method which is invoked only if TestUtil.onWindows() >>> is false, i.e., the test is not being run on Windows. So one would >>> think that the backlog change would have no effect on Windows. >> Yes, backlog are only used for CONNECT and FINISH_CONNECT tests which >> use initRefuser() and will not be run on windows. >>> Thirdly, if the test is being run with assertions enabled, then it >>> appears that line 517 would throw an AssertionError on Windows and >>> your changes at lines 523, 532, and 544-547 would never be executed. >> As said above, FINISH_CONNECT test is only run on non-windows, so the >> "assert" will not be executed on Windows. My change is only for >> FINISH_CONNECT test case failure which will not be run on windows. > > Thanks for the clarifications. > >>> Hopefully I am just misinterpreting something here. >> No, you helped to identify the bug description is not clear, thanks a >> lot.:-) > > You?re welcome: I am glad it was useful. > >> As I filed a new bug, would you please help to review it at new >> place:http://cr.openjdk.java.net/~mli/8151582/webrev.00/, only >> updated the bug id in the source code. >> bug:https://bugs.openjdk.java.net/browse/JDK-8151582 > > My only question is about AsyncCloseAndInterrupt.java line 92. If I > recall correctly from my inspection of the code base last week, the > default number of pending connections for > ServerSocketChannel.bind(SocketAddress) is 50. Given the comment at > line 509 > > // Create a pump thread dedicated to saturate refuser's connection backlog > > I am wondering whether we want to go all the way down to a backlog of > just one. Have you tried any other values in the range [2,50]? It > seems that with a queue length of only one the refuser?s connection > backlog would be ?almost always? saturated and I wonder whether that > compromises the test somehow? Hi Brian, Please let me clarify it: Even with backlog set to 1, there will be more than 1 successful connections on some platforms, for example linux, and it will grow very slowly, the test results on my local verify this. And, even if on some other platforms there is only 1 connection totally in the complete and incomplete queues, it will not do harm to test, because what we want refuser server to do is to reject connections from any clients except the earliest connection[s] from pump thread before refuser server is saturated. I think it's better to set backlog of refuser server as 1, so we can make refuser's complete and incomplete queues saturated as quickly as possible by pump thread, and it will be more possible for pump thread to make sure saturate the queues. Not sure if clarification above is clear enough, please let me know your further concerns. :-) Thank you -Hamlin > > Thanks, > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Mar 14 23:29:43 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 14 Mar 2016 16:29:43 -0700 Subject: JDK 9 RFR of JDK-8151582: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing due to "Connection succeeded" In-Reply-To: <56E748C1.9070307@oracle.com> References: <56D96528.3070009@oracle.com> <56E10C4F.4070404@oracle.com> <596FE1B8-7B4A-4F32-BFCC-D2A09B27E11C@oracle.com> <56E748C1.9070307@oracle.com> Message-ID: <9806CF07-659F-4C5E-8806-003EDAB65B06@oracle.com> Hi Hamlin, On Mar 14, 2016, at 4:26 PM, Hamlin Li wrote: > Please let me clarify it: Even with backlog set to 1, there will be more than 1 successful connections on some platforms, for example linux, and it will grow very slowly, the test results on my local verify this. And, even if on some other platforms there is only 1 connection totally in the complete and incomplete queues, it will not do harm to test, because what we want refuser server to do is to reject connections from any clients except the earliest connection[s] from pump thread before refuser server is saturated. I think it's better to set backlog of refuser server as 1, so we can make refuser's complete and incomplete queues saturated as quickly as possible by pump thread, and it will be more possible for pump thread to make sure saturate the queues. > Not sure if clarification above is clear enough, please let me know your further concerns. :-) OK, now I understand it better. I am OK with the patch but you will still need another +1 from an actual Reviewer. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Mar 16 22:34:00 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 16 Mar 2016 15:34:00 -0700 Subject: JDK 9 RFR of 8152043: (fs) Remove dynamic loopup of Win32 API functions in WindowsNativeDispatcher needed to support Windows XP and Server 2003 Message-ID: <93927E7B-E84E-4BF6-A9B0-41BB95B2F539@oracle.com> Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8152043 Patch: http://cr.openjdk.java.net/~bpb/8152043/webrev.00/ Summary: Remove dynamic loading of certain Win32 API function pointers via the kernel32 module handle which used to be needed to support Windows XP and Windows Server 2003. As the oldest versions of Windows which meet the requirements of JDK 8 onwards directly support the Win32 API functions in question, this dynamic lookup is no longer needed. Running the NIO regression tests did not reveal any problems either building or testing. The issue ID 8152043 is added to the @bug tag in each of the two tests because test/java/nio/file/Files/CheckPermissions.java indirectly exercises the Win32 API functions CreateSymbolicLinkW() and GetFinalPathNameByHandleW(), and test/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java likewise indirectly exercises FindFirstStreamW() and FindNextStreamW(). Thanks, Brian From Alan.Bateman at oracle.com Thu Mar 17 07:02:43 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Mar 2016 07:02:43 +0000 Subject: JDK 9 RFR of 8152043: (fs) Remove dynamic loopup of Win32 API functions in WindowsNativeDispatcher needed to support Windows XP and Server 2003 In-Reply-To: <93927E7B-E84E-4BF6-A9B0-41BB95B2F539@oracle.com> References: <93927E7B-E84E-4BF6-A9B0-41BB95B2F539@oracle.com> Message-ID: <56EA5693.3040800@oracle.com> On 16/03/2016 22:34, Brian Burkhalter wrote: > Please review at your convenience: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8152043 > Patch: http://cr.openjdk.java.net/~bpb/8152043/webrev.00/ > This looks good. As you say, this dates back to when we had to support older versions of Windows. There more than can be done to remove support for older Windows but this is a great start. > > Running the NIO regression tests did not reveal any problems either building or testing. > > The issue ID 8152043 is added to the @bug tag in each of the two tests because test/java/nio/file/Files/CheckPermissions.java indirectly exercises the Win32 API functions CreateSymbolicLinkW() and GetFinalPathNameByHandleW(), and test/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java likewise indirectly exercises FindFirstStreamW() and FindNextStreamW(). > I would skip this part, instead add the noreg-other label to the bug. -Alan From brian.burkhalter at oracle.com Thu Mar 17 14:50:17 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 17 Mar 2016 07:50:17 -0700 Subject: JDK 9 RFR of 8152043: (fs) Remove dynamic loopup of Win32 API functions in WindowsNativeDispatcher needed to support Windows XP and Server 2003 In-Reply-To: <56EA5693.3040800@oracle.com> References: <93927E7B-E84E-4BF6-A9B0-41BB95B2F539@oracle.com> <56EA5693.3040800@oracle.com> Message-ID: <906DD5B1-F3D7-4C3B-856D-833C1505F675@oracle.com> On Mar 17, 2016, at 12:02 AM, Alan Bateman wrote: >> Please review at your convenience: >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8152043 >> Patch: http://cr.openjdk.java.net/~bpb/8152043/webrev.00/ >> > This looks good. As you say, this dates back to when we had to support older versions of Windows. There more than can be done to remove support for older Windows but this is a great start. I should investigate that aspect further. >> Running the NIO regression tests did not reveal any problems either building or testing. >> >> The issue ID 8152043 is added to the @bug tag in each of the two tests because test/java/nio/file/Files/CheckPermissions.java indirectly exercises the Win32 API functions CreateSymbolicLinkW() and GetFinalPathNameByHandleW(), and test/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java likewise indirectly exercises FindFirstStreamW() and FindNextStreamW(). >> > I would skip this part, instead add the noreg-other label to the bug. I was not sure. I rather miss the ?noreg-existing? label. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From huaming.li at oracle.com Fri Mar 18 03:59:39 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 18 Mar 2016 11:59:39 +0800 Subject: JDK 9 RFR of JDK-8151582: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing due to "Connection succeeded" In-Reply-To: <9806CF07-659F-4C5E-8806-003EDAB65B06@oracle.com> References: <56D96528.3070009@oracle.com> <56E10C4F.4070404@oracle.com> <596FE1B8-7B4A-4F32-BFCC-D2A09B27E11C@oracle.com> <56E748C1.9070307@oracle.com> <9806CF07-659F-4C5E-8806-003EDAB65B06@oracle.com> Message-ID: <56EB7D2B.4090808@oracle.com> On 2016/3/15 7:29, Brian Burkhalter wrote: > Hi Hamlin, > > On Mar 14, 2016, at 4:26 PM, Hamlin Li > wrote: > >> Please let me clarify it: Even with backlog set to 1, there will be >> more than 1 successful connections on some platforms, for example >> linux, and it will grow very slowly, the test results on my local >> verify this. And, even if on some other platforms there is only 1 >> connection totally in the complete and incomplete queues, it will not >> do harm to test, because what we want refuser server to do is to >> reject connections from any clients except the earliest connection[s] >> from pump thread before refuser server is saturated. I think it's >> better to set backlog of refuser server as 1, so we can make >> refuser's complete and incomplete queues saturated as quickly as >> possible by pump thread, and it will be more possible for pump thread >> to make sure saturate the queues. >> Not sure if clarification above is clear enough, please let me know >> your further concerns. :-) > > OK, now I understand it better. I am OK with the patch but you will > still need another +1 from an actual Reviewer. Would some reviewer be available to review the patch? bug: https://bugs.openjdk.java.net/browse/JDK-8151582 webrev: http://cr.openjdk.java.net/~mli/8151582/webrev.00 Thank you -Hamlin > > Thanks, > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Fri Mar 18 14:43:48 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 18 Mar 2016 10:43:48 -0400 Subject: JDK 9 RFR of JDK-8151582: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing due to "Connection succeeded" In-Reply-To: <56EB7D2B.4090808@oracle.com> References: <56D96528.3070009@oracle.com> <56E10C4F.4070404@oracle.com> <596FE1B8-7B4A-4F32-BFCC-D2A09B27E11C@oracle.com> <56E748C1.9070307@oracle.com> <9806CF07-659F-4C5E-8806-003EDAB65B06@oracle.com> <56EB7D2B.4090808@oracle.com> Message-ID: <56EC1424.5080209@Oracle.com> Hi, Looks fine. Reviewed Can you fix the typo at line 530: miliseconds -> milliseconds no new webrev required. Roger On 3/17/2016 11:59 PM, Hamlin Li wrote: > > On 2016/3/15 7:29, Brian Burkhalter wrote: >> Hi Hamlin, >> >> On Mar 14, 2016, at 4:26 PM, Hamlin Li wrote: >> >>> Please let me clarify it: Even with backlog set to 1, there will be >>> more than 1 successful connections on some platforms, for example >>> linux, and it will grow very slowly, the test results on my local >>> verify this. And, even if on some other platforms there is only 1 >>> connection totally in the complete and incomplete queues, it will >>> not do harm to test, because what we want refuser server to do is to >>> reject connections from any clients except the earliest >>> connection[s] from pump thread before refuser server is saturated. I >>> think it's better to set backlog of refuser server as 1, so we can >>> make refuser's complete and incomplete queues saturated as quickly >>> as possible by pump thread, and it will be more possible for pump >>> thread to make sure saturate the queues. >>> Not sure if clarification above is clear enough, please let me know >>> your further concerns. :-) >> >> OK, now I understand it better. I am OK with the patch but you will >> still need another +1 from an actual Reviewer. > > Would some reviewer be available to review the patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8151582 > webrev: http://cr.openjdk.java.net/~mli/8151582/webrev.00 > > Thank you > -Hamlin >> >> Thanks, >> >> Brian > From pavel.rappo at oracle.com Fri Mar 18 18:23:56 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 18 Mar 2016 18:23:56 +0000 Subject: Strange behaviour of java.nio.charset.StandardCharsets.UTF8.newDecoder() Message-ID: Hello, As far as I understand one of the major use cases of j.n.c.CharsetDecoder is incremental decoding. That is, a case where a complete data is available in chunks. If the above is true, would the following behaviour be considered an expected one? Namely, byte-wise decoding fails with an error, while bulk (and complete) decoding of the same data completes successfully. Thanks. public static void main(String[] args) { String hex = "48656c6c6f2dc2b540c39fc3b6c3a4c3bcc3a0c3a12d5554462d382121"; Matcher m = Pattern.compile("\\p{XDigit}{2}").matcher(hex); List ints = new ArrayList<>(); while (m.find()) { Integer i = Integer.parseInt(m.group(0), 16); ints.add(i); } if (ints.isEmpty()) { throw new AssertionError(); } // decodeByteWise(ints); decodeWholesale1(ints); decodeWholesale2(ints); } private static void decodeByteWise(List ints) { CoderResult r = null; CharsetDecoder d = StandardCharsets.UTF_8.newDecoder(); CharBuffer out = CharBuffer.allocate(ints.size()); for (Integer i : ints) { r = d.decode(ByteBuffer.wrap(new byte[]{i.byteValue()}), out, false); if (r != CoderResult.UNDERFLOW) { throw new AssertionError(); } } if (r != CoderResult.UNDERFLOW) { throw new AssertionError(); } r = d.decode(ByteBuffer.allocate(0), out, true); if (r != CoderResult.UNDERFLOW) { throw new AssertionError(); } r = d.flush(out); if (r != CoderResult.UNDERFLOW) { throw new AssertionError(); } out.flip(); System.out.println(out); } private static void decodeWholesale1(List ints) { CharsetDecoder d = StandardCharsets.UTF_8.newDecoder(); CharBuffer out = CharBuffer.allocate(ints.size()); ByteBuffer in = ByteBuffer.allocate(ints.size()); for (Integer i : ints) { in.put(i.byteValue()); } in.flip(); CoderResult r = d.decode(in, out, false); if (r != CoderResult.UNDERFLOW) { throw new AssertionError(); } r = d.decode(in, out, true); if (r != CoderResult.UNDERFLOW) { throw new AssertionError(); } r = d.flush(out); if (r != CoderResult.UNDERFLOW) { throw new AssertionError(); } out.flip(); System.out.println(out); } private static void decodeWholesale2(List ints) { CharsetDecoder d = StandardCharsets.UTF_8.newDecoder(); CharBuffer out = CharBuffer.allocate(ints.size()); ByteBuffer in = ByteBuffer.allocate(ints.size()); for (Integer i : ints) { in.put(i.byteValue()); } in.flip(); CoderResult r = d.decode(in, out, true); if (r != CoderResult.UNDERFLOW) { throw new AssertionError(); } r = d.flush(out); if (r != CoderResult.UNDERFLOW) { throw new AssertionError(); } out.flip(); System.out.println(out); } From martinrb at google.com Fri Mar 18 18:31:26 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 18 Mar 2016 11:31:26 -0700 Subject: Strange behaviour of java.nio.charset.StandardCharsets.UTF8.newDecoder() In-Reply-To: References: Message-ID: It looks like you're trying to decode one byte at a time, which cannot work? The minimum unit to decode that will work is 4 bytes, and you have to handle incomplete decoding. On Fri, Mar 18, 2016 at 11:23 AM, Pavel Rappo wrote: > Hello, > > As far as I understand one of the major use cases of j.n.c.CharsetDecoder is > incremental decoding. That is, a case where a complete data is available in > chunks. > If the above is true, would the following behaviour be considered an expected > one? Namely, byte-wise decoding fails with an error, while bulk (and complete) > decoding of the same data completes successfully. > > Thanks. > > public static void main(String[] args) { > String hex = "48656c6c6f2dc2b540c39fc3b6c3a4c3bcc3a0c3a12d5554462d382121"; > Matcher m = Pattern.compile("\\p{XDigit}{2}").matcher(hex); > List ints = new ArrayList<>(); > while (m.find()) { > Integer i = Integer.parseInt(m.group(0), 16); > ints.add(i); > } > if (ints.isEmpty()) { > throw new AssertionError(); > } > > // decodeByteWise(ints); > decodeWholesale1(ints); > decodeWholesale2(ints); > } > > private static void decodeByteWise(List ints) { > CoderResult r = null; > CharsetDecoder d = StandardCharsets.UTF_8.newDecoder(); > CharBuffer out = CharBuffer.allocate(ints.size()); > for (Integer i : ints) { > r = d.decode(ByteBuffer.wrap(new byte[]{i.byteValue()}), out, false); > if (r != CoderResult.UNDERFLOW) { > throw new AssertionError(); > } > } > if (r != CoderResult.UNDERFLOW) { throw new AssertionError(); } > r = d.decode(ByteBuffer.allocate(0), out, true); > if (r != CoderResult.UNDERFLOW) { throw new AssertionError(); } > r = d.flush(out); > if (r != CoderResult.UNDERFLOW) { throw new AssertionError(); } > out.flip(); > System.out.println(out); > } > > private static void decodeWholesale1(List ints) { > CharsetDecoder d = StandardCharsets.UTF_8.newDecoder(); > CharBuffer out = CharBuffer.allocate(ints.size()); > ByteBuffer in = ByteBuffer.allocate(ints.size()); > for (Integer i : ints) { > in.put(i.byteValue()); > } > in.flip(); > CoderResult r = d.decode(in, out, false); > if (r != CoderResult.UNDERFLOW) { throw new AssertionError(); } > r = d.decode(in, out, true); > if (r != CoderResult.UNDERFLOW) { throw new AssertionError(); } > r = d.flush(out); > if (r != CoderResult.UNDERFLOW) { throw new AssertionError(); } > out.flip(); > System.out.println(out); > } > > private static void decodeWholesale2(List ints) { > CharsetDecoder d = StandardCharsets.UTF_8.newDecoder(); > CharBuffer out = CharBuffer.allocate(ints.size()); > ByteBuffer in = ByteBuffer.allocate(ints.size()); > for (Integer i : ints) { > in.put(i.byteValue()); > } > in.flip(); > CoderResult r = d.decode(in, out, true); > if (r != CoderResult.UNDERFLOW) { throw new AssertionError(); } > r = d.flush(out); > if (r != CoderResult.UNDERFLOW) { throw new AssertionError(); } > out.flip(); > System.out.println(out); > } > > > From pavel.rappo at oracle.com Fri Mar 18 18:38:31 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 18 Mar 2016 18:38:31 +0000 Subject: Strange behaviour of java.nio.charset.StandardCharsets.UTF8.newDecoder() In-Reply-To: References: Message-ID: <7E62FF17-CD1F-431A-9F94-B3465A30C93D@oracle.com> Why is that? I don't think I have to supply only "correct" chunks. After all, decoders are free to maintain an internal state needed for this. > On 18 Mar 2016, at 18:31, Martin Buchholz wrote: > > trying to decode one byte at a time, which cannot > work? The minimum unit to decode that will work is 4 bytes From martinrb at google.com Fri Mar 18 18:44:04 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 18 Mar 2016 11:44:04 -0700 Subject: Strange behaviour of java.nio.charset.StandardCharsets.UTF8.newDecoder() In-Reply-To: <7E62FF17-CD1F-431A-9F94-B3465A30C93D@oracle.com> References: <7E62FF17-CD1F-431A-9F94-B3465A30C93D@oracle.com> Message-ID: Coders could have an internal buffer to store incomplete sequences, but the design is that they don't. https://docs.oracle.com/javase/8/docs/api/java/nio/charset/CoderResult.html https://docs.oracle.com/javase/8/docs/api/java/nio/charset/CoderResult.html#UNDERFLOW It's more efficient to not have (yet another) intermediate buffer. On Fri, Mar 18, 2016 at 11:38 AM, Pavel Rappo wrote: > Why is that? I don't think I have to supply only "correct" chunks. After all, > decoders are free to maintain an internal state needed for this. > >> On 18 Mar 2016, at 18:31, Martin Buchholz wrote: >> >> trying to decode one byte at a time, which cannot >> work? The minimum unit to decode that will work is 4 bytes > From xueming.shen at oracle.com Fri Mar 18 18:36:24 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 18 Mar 2016 11:36:24 -0700 Subject: Strange behaviour of java.nio.charset.StandardCharsets.UTF8.newDecoder() In-Reply-To: <7E62FF17-CD1F-431A-9F94-B3465A30C93D@oracle.com> References: <7E62FF17-CD1F-431A-9F94-B3465A30C93D@oracle.com> Message-ID: <56EC4AA8.8090600@oracle.com> The decoder will NOT keep the "incomplete/leftover" byte(s) internally waiting for your new bytes. Those bytes are left in your input ByteBuffer. You need to fill the new bytes you have and feed the decoder again. On 03/18/2016 11:38 AM, Pavel Rappo wrote: > Why is that? I don't think I have to supply only "correct" chunks. After all, > decoders are free to maintain an internal state needed for this. > >> On 18 Mar 2016, at 18:31, Martin Buchholz wrote: >> >> trying to decode one byte at a time, which cannot >> work? The minimum unit to decode that will work is 4 bytes From xueming.shen at oracle.com Fri Mar 18 18:45:33 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 18 Mar 2016 11:45:33 -0700 Subject: Strange behaviour of java.nio.charset.StandardCharsets.UTF8.newDecoder() In-Reply-To: References: <7E62FF17-CD1F-431A-9F94-B3465A30C93D@oracle.com> Message-ID: <56EC4CCD.30405@oracle.com> On 03/18/2016 11:44 AM, Martin Buchholz wrote: > Coders could have an internal buffer to store incomplete sequences, > but the design is that they don't. > https://docs.oracle.com/javase/8/docs/api/java/nio/charset/CoderResult.html > https://docs.oracle.com/javase/8/docs/api/java/nio/charset/CoderResult.html#UNDERFLOW > It's more efficient to not have (yet another) intermediate buffer. > Martin, There are use cases that the input bytes are in several ByteBuffer buffers already (originally they were in byte[], read from the sockets, for example, wrapped into buffers), and the cluster of bytes for a "char" were cut in the middle by the buffer boundaries ... it is really hard to re-range the buffers for the next decoding without a copy/paste. I'm considering the possibility to have a decode(ByteBuffer... bufs) for this kinda of use case. Opinion? Sherman > On Fri, Mar 18, 2016 at 11:38 AM, Pavel Rappo wrote: >> Why is that? I don't think I have to supply only "correct" chunks. After all, >> decoders are free to maintain an internal state needed for this. >> >>> On 18 Mar 2016, at 18:31, Martin Buchholz wrote: >>> >>> trying to decode one byte at a time, which cannot >>> work? The minimum unit to decode that will work is 4 bytes From pavel.rappo at oracle.com Fri Mar 18 19:22:16 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 18 Mar 2016 19:22:16 +0000 Subject: Strange behaviour of java.nio.charset.StandardCharsets.UTF8.newDecoder() In-Reply-To: <56EC4AA8.8090600@oracle.com> References: <7E62FF17-CD1F-431A-9F94-B3465A30C93D@oracle.com> <56EC4AA8.8090600@oracle.com> Message-ID: May I ask then how should I tell apart following two cases: a. There's a malformed sequence in my bytes and no mater how many bytes I add, it will be still malformed b. Current input is not enough to continue, if more bytes added, the input might become well-formed ? > On 18 Mar 2016, at 18:36, Xueming Shen wrote: > > The decoder will NOT keep the "incomplete/leftover" byte(s) internally waiting > for your new bytes. Those bytes are left in your input ByteBuffer. You need to > fill the new bytes you have and feed the decoder again. > > > On 03/18/2016 11:38 AM, Pavel Rappo wrote: >> Why is that? I don't think I have to supply only "correct" chunks. After all, >> decoders are free to maintain an internal state needed for this. >> >>> On 18 Mar 2016, at 18:31, Martin Buchholz wrote: >>> >>> trying to decode one byte at a time, which cannot >>> work? The minimum unit to decode that will work is 4 bytes > From xueming.shen at oracle.com Fri Mar 18 19:22:20 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 18 Mar 2016 12:22:20 -0700 Subject: Strange behaviour of java.nio.charset.StandardCharsets.UTF8.newDecoder() In-Reply-To: References: <7E62FF17-CD1F-431A-9F94-B3465A30C93D@oracle.com> <56EC4AA8.8090600@oracle.com> Message-ID: <56EC556C.2070906@oracle.com> On 03/18/2016 12:22 PM, Pavel Rappo wrote: > May I ask then how should I tell apart following two cases: > > a. There's a malformed sequence in my bytes and no mater how many bytes I add, > it will be still malformed > > b. Current input is not enough to continue, if more bytes added, the input > might become well-formed > > ? The decoder returns a error cr/cr.isError()/isMalformed() for (a), underflow for (b) UNDERFLOW is a singleton. malformed/unmmapped is not. sherman >> On 18 Mar 2016, at 18:36, Xueming Shen wrote: >> >> The decoder will NOT keep the "incomplete/leftover" byte(s) internally waiting >> for your new bytes. Those bytes are left in your input ByteBuffer. You need to >> fill the new bytes you have and feed the decoder again. >> >> >> On 03/18/2016 11:38 AM, Pavel Rappo wrote: >>> Why is that? I don't think I have to supply only "correct" chunks. After all, >>> decoders are free to maintain an internal state needed for this. >>> >>>> On 18 Mar 2016, at 18:31, Martin Buchholz wrote: >>>> >>>> trying to decode one byte at a time, which cannot >>>> work? The minimum unit to decode that will work is 4 bytes From martinrb at google.com Fri Mar 18 20:24:28 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 18 Mar 2016 13:24:28 -0700 Subject: Strange behaviour of java.nio.charset.StandardCharsets.UTF8.newDecoder() In-Reply-To: <56EC4CCD.30405@oracle.com> References: <7E62FF17-CD1F-431A-9F94-B3465A30C93D@oracle.com> <56EC4CCD.30405@oracle.com> Message-ID: Please take a look at Utf8.java in protobuf land http://grepcode.com/file/repo1.maven.org/maven2/com.google.protobuf/protobuf-java/2.5.0/com/google/protobuf/Utf8.java which supports multiple input segments, but is not a Charset. UTF-8 only, but nothing else matters anymore, hopefully! (As always, if you want Google code to be contributed to openjdk, just ask) On Fri, Mar 18, 2016 at 11:45 AM, Xueming Shen wrote: > > On 03/18/2016 11:44 AM, Martin Buchholz wrote: >> >> Coders could have an internal buffer to store incomplete sequences, >> but the design is that they don't. >> >> https://docs.oracle.com/javase/8/docs/api/java/nio/charset/CoderResult.html >> >> https://docs.oracle.com/javase/8/docs/api/java/nio/charset/CoderResult.html#UNDERFLOW >> It's more efficient to not have (yet another) intermediate buffer. >> > > Martin, > > There are use cases that the input bytes are in several ByteBuffer buffers > already (originally they were in byte[], read from the sockets, for example, > wrapped into buffers), and the cluster of bytes for a "char" were cut in the > middle by the buffer boundaries ... it is really hard to re-range the > buffers > for the next decoding without a copy/paste. I'm considering the possibility > to have a decode(ByteBuffer... bufs) for this kinda of use case. Opinion? > > Sherman > > >> On Fri, Mar 18, 2016 at 11:38 AM, Pavel Rappo >> wrote: >>> >>> Why is that? I don't think I have to supply only "correct" chunks. After >>> all, >>> decoders are free to maintain an internal state needed for this. >>> >>>> On 18 Mar 2016, at 18:31, Martin Buchholz wrote: >>>> >>>> trying to decode one byte at a time, which cannot >>>> work? The minimum unit to decode that will work is 4 bytes > > From Alan.Bateman at oracle.com Sun Mar 20 07:45:24 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 20 Mar 2016 07:45:24 +0000 Subject: JDK 9 RFR of JDK-8151582: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing due to "Connection succeeded" In-Reply-To: <56EB7D2B.4090808@oracle.com> References: <56D96528.3070009@oracle.com> <56E10C4F.4070404@oracle.com> <596FE1B8-7B4A-4F32-BFCC-D2A09B27E11C@oracle.com> <56E748C1.9070307@oracle.com> <9806CF07-659F-4C5E-8806-003EDAB65B06@oracle.com> <56EB7D2B.4090808@oracle.com> Message-ID: <56EE5514.4060903@oracle.com> On 18/03/2016 03:59, Hamlin Li wrote: > > > Would some reviewer be available to review the patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8151582 > webrev: http://cr.openjdk.java.net/~mli/8151582/webrev.00 This looks okay although I can't help thinking that we are trying to test a scenario that is impossible to test reliably. A minor point but adding ", Wait successfully" to the trace messages makes for unusual trace messages like: finishConnect wait for pumping refuser ..., Wait successfully If we s/wait/waiting/ and have the suffix be "done" then it would be a bit cleaner. Another minor point is that you can use refuser.bind(wildcardAddress, 1), no need for the socket adapter. I'll these are minor comments then I'll update your patch and get this into jdk9/dev. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From huaming.li at oracle.com Sun Mar 20 10:47:58 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Sun, 20 Mar 2016 18:47:58 +0800 Subject: JDK 9 RFR of JDK-8151582: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing due to "Connection succeeded" In-Reply-To: <56EE5514.4060903@oracle.com> References: <56D96528.3070009@oracle.com> <56E10C4F.4070404@oracle.com> <596FE1B8-7B4A-4F32-BFCC-D2A09B27E11C@oracle.com> <56E748C1.9070307@oracle.com> <9806CF07-659F-4C5E-8806-003EDAB65B06@oracle.com> <56EB7D2B.4090808@oracle.com> <56EE5514.4060903@oracle.com> Message-ID: <56EE7FDE.5030900@oracle.com> Hi Alan, Thanks for reviewing and pushing code. Yes, I tried to find some other way to do it, but unfortunately as you mentioned it's impossible to make sure 100% the test would not fail, what we have done is just to try to improve the possibility, fortunately from local test result, it works better than before. *@**Brian*, Thanks for offering to help push the code, :-) I just found alan did it. Thank you -Hamlin On 2016/3/20 15:45, Alan Bateman wrote: > On 18/03/2016 03:59, Hamlin Li wrote: >> >> >> Would some reviewer be available to review the patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8151582 >> webrev: http://cr.openjdk.java.net/~mli/8151582/webrev.00 > This looks okay although I can't help thinking that we are trying to > test a scenario that is impossible to test reliably. > > A minor point but adding ", Wait successfully" to the trace messages > makes for unusual trace messages like: > > finishConnect wait for pumping refuser ..., Wait successfully > > If we s/wait/waiting/ and have the suffix be "done" then it would be a > bit cleaner. > > Another minor point is that you can use refuser.bind(wildcardAddress, > 1), no need for the socket adapter. > > I'll these are minor comments then I'll update your patch and get this > into jdk9/dev. > > -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From huaming.li at oracle.com Sun Mar 20 11:00:15 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Sun, 20 Mar 2016 19:00:15 +0800 Subject: JDK 9 RFR of JDK-8151582: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing due to "Connection succeeded" In-Reply-To: <56EE5514.4060903@oracle.com> References: <56D96528.3070009@oracle.com> <56E10C4F.4070404@oracle.com> <596FE1B8-7B4A-4F32-BFCC-D2A09B27E11C@oracle.com> <56E748C1.9070307@oracle.com> <9806CF07-659F-4C5E-8806-003EDAB65B06@oracle.com> <56EB7D2B.4090808@oracle.com> <56EE5514.4060903@oracle.com> Message-ID: <56EE82BF.4060606@oracle.com> Hi Alan, Just have 2 questions. 1. Would you mind suggest if it's necessary to back port this fix to earlier versions? If positive, which verions? 2. I isolated this issue from JDK-8068693, as I think these 2 issue are totally different, and I think JDK-8068693 might be due to an environment issue, and it last occurred at at 2015-05-13. Could I suggest to close JDK-8068693? Thank you -Hamlin On 2016/3/20 15:45, Alan Bateman wrote: > On 18/03/2016 03:59, Hamlin Li wrote: >> >> >> Would some reviewer be available to review the patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8151582 >> webrev: http://cr.openjdk.java.net/~mli/8151582/webrev.00 > This looks okay although I can't help thinking that we are trying to > test a scenario that is impossible to test reliably. > > A minor point but adding ", Wait successfully" to the trace messages > makes for unusual trace messages like: > > finishConnect wait for pumping refuser ..., Wait successfully > > If we s/wait/waiting/ and have the suffix be "done" then it would be a > bit cleaner. > > Another minor point is that you can use refuser.bind(wildcardAddress, > 1), no need for the socket adapter. > > I'll these are minor comments then I'll update your patch and get this > into jdk9/dev. > > -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Mar 21 09:00:37 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Mar 2016 09:00:37 +0000 Subject: JDK 9 RFR of JDK-8151582: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing due to "Connection succeeded" In-Reply-To: <56EE82BF.4060606@oracle.com> References: <56D96528.3070009@oracle.com> <56E10C4F.4070404@oracle.com> <596FE1B8-7B4A-4F32-BFCC-D2A09B27E11C@oracle.com> <56E748C1.9070307@oracle.com> <9806CF07-659F-4C5E-8806-003EDAB65B06@oracle.com> <56EB7D2B.4090808@oracle.com> <56EE5514.4060903@oracle.com> <56EE82BF.4060606@oracle.com> Message-ID: <56EFB835.8030309@oracle.com> On 20/03/2016 11:00, Hamlin Li wrote: > Hi Alan, > > Just have 2 questions. > 1. Would you mind suggest if it's necessary to back port this fix to > earlier versions? If positive, which verions? It might be best to wait a bit to see if there are any more sightings in jdk9/dev. If not then you could propose it for jdk8u-dev. > 2. I isolated this issue from JDK-8068693, as I think these 2 issue > are totally different, and I think JDK-8068693 might be due to an > environment issue, and it last occurred at at 2015-05-13. Could I > suggest to close JDK-8068693? It does appear to be another issue, also there is instrumentation in that environment so there may be other things going on. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgaliegue at gmail.com Mon Mar 21 10:38:28 2016 From: fgaliegue at gmail.com (Francis Galiegue) Date: Mon, 21 Mar 2016 11:38:28 +0100 Subject: Zip filesystem provider has an unnecessary limitation... Message-ID: If I try and FileSystems.newFileSystem(somePath, ...) where somePath is some file name NOT ending with .zip or .jar, I get an UnsupportedOperationException. Why? This is a completely arbitrary limitation :( -- Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge JSON Schema in Java: http://json-schema-validator.herokuapp.com Parsers in pure Java: https://github.com/fge/grappa From christoph.langer at sap.com Wed Mar 23 07:13:47 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 23 Mar 2016 07:13:47 +0000 Subject: RFR: 8147468: Allow users to bound the size of buffers cached in the per-thread buffer caches In-Reply-To: References: <569E279E.4010302@oracle.com> <56A23019.2010001@oracle.com> <56A39D29.10509@oracle.com> <56A766A3.9070406@oracle.com> <598AF6CC-55E7-4A50-B3B2-2841D925F3AE@oracle.com> Message-ID: Hi, are there any plans or votes pro/against bringing this fix to jdk8? I?ve got a customer request who would like to see this back in 8, too? Thanks Christoph From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Tony Printezis Sent: Donnerstag, 28. Januar 2016 17:20 To: Brian Burkhalter Cc: nio-dev Subject: Re: RFR: 8147468: Allow users to bound the size of buffers cached in the per-thread buffer caches All set! Thanks everyone for your help with this change!!! Tony On January 28, 2016 at 11:11:02 AM, Brian Burkhalter (brian.burkhalter at oracle.com) wrote: On Jan 28, 2016, at 8:04 AM, Tony Printezis > wrote: I?m all set and jcheck is happy. If the change is this one http://cr.openjdk.java.net/~tonyp/nio-max-buffer-size/webrev.4/ I don?t see a reviewed-by line. See the example here http://openjdk.java.net/guide/producingChangeset.html#create under ?Formatting a Changeset Comment." Do I just do (the change only touches the jdk repo): hg push http://hg.openjdk.java.net/jdk9/dev/jdk Or is there a special way to do pushes? You would need to use ?ssh? in the above URL instead of ?http.? Brian ----- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Wed Mar 23 09:05:46 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 23 Mar 2016 09:05:46 +0000 Subject: RFR: 8147468: Allow users to bound the size of buffers cached in the per-thread buffer caches In-Reply-To: References: <569E279E.4010302@oracle.com> <56A23019.2010001@oracle.com> <56A39D29.10509@oracle.com> <56A766A3.9070406@oracle.com> <598AF6CC-55E7-4A50-B3B2-2841D925F3AE@oracle.com> Message-ID: <56F25C6A.4050008@oracle.com> The changes are pretty much self contained. I wouldn't see a problem with it coming back to jdk8u forest. If you want to work on patching, I can log a CCC request in parallel for the new system property. Regards, Sean. On 23/03/2016 07:13, Langer, Christoph wrote: > > Hi, > > are there any plans or votes pro/against bringing this fix to jdk8? > > I?ve got a customer request who would like to see this back in 8, too? > > Thanks > > Christoph > > *From:*nio-dev [mailto:nio-dev-bounces at openjdk.java.net] *On Behalf Of > *Tony Printezis > *Sent:* Donnerstag, 28. Januar 2016 17:20 > *To:* Brian Burkhalter > *Cc:* nio-dev > *Subject:* Re: RFR: 8147468: Allow users to bound the size of buffers > cached in the per-thread buffer caches > > All set! Thanks everyone for your help with this change!!! > > Tony > > On January 28, 2016 at 11:11:02 AM, Brian Burkhalter > (brian.burkhalter at oracle.com ) wrote: > > On Jan 28, 2016, at 8:04 AM, Tony Printezis > > wrote: > > > > I?m all set and jcheck is happy. > > If the change is this one > > http://cr.openjdk.java.net/~tonyp/nio-max-buffer-size/webrev.4/ > > > I don?t see a reviewed-by line. See the example here > > http://openjdk.java.net/guide/producingChangeset.html#create > > under ?Formatting a Changeset Comment." > > > > Do I just do (the change only touches the jdk repo): > > hg push http://hg.openjdk.java.net/jdk9/dev/jdk > > Or is there a special way to do pushes? > > You would need to use ?ssh? in the above URL instead of ?http.? > > Brian > > ----- > > Tony Printezis | JVM/GC Engineer / VM Team | Twitter > > @TonyPrintezis > > tprintezis at twitter.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Wed Mar 23 11:29:36 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 23 Mar 2016 12:29:36 +0100 Subject: Fwd: RFR 8151163 All Buffer implementations should leverage Unsafe unaligned accessors References: <142D9ABF-C144-42E6-9FA2-48A90A51C3A9@oracle.com> Message-ID: <21C2A208-E6FF-41C9-870C-801425B03288@oracle.com> I forgot include nio-dev? Email thread is here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-March/thread.html#39364 Paul. > Begin forwarded message: > > From: Paul Sandoz > Subject: RFR 8151163 All Buffer implementations should leverage Unsafe unaligned accessors > Date: 8 March 2016 14:06:37 CET > To: core-libs-dev , hotspot-dev developers > > Hi, > > Please pre-emptively review a fix to update the buffer implementations to leverage the Unsafe unaligned accessors: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access/webrev/ > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151163-buffer-unsafe-unaligned-access-hotspot/webrev/ > > The JDK changes depend on those for the following which is in CCC review: > > https://bugs.openjdk.java.net/browse/JDK-8149469 > ByteBuffer API and implementation enhancements for VarHandles > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8149469-byte-buffer-align-and-unifying-enhancements/webrev/ > > > The changes in this webrev take advantage of those for JDK-8149469 and apply the unsafe double addressing scheme so certain byte buffer view implementations can work across heap and direct buffers. This should improve the performance on x86 for: > > 1) direct ByteBuffers using the wider unit size method accessors; and > 2) wider unit size views over heap ByteBuffers. > > As a consequence Bits.java has greatly reduced in size :-) > > > The HotSpot changes update the test that was originally added when the heap ByteBuffer method accessors were updated to utilise unsafe unaligned access. I split the test out so as to reduce the execution time, since I doubled the amount of tests. These tests could be improved for views at various unaligned/unaligned positions in the byte buffer, but i left that for now. > > I plan to push through hs-comp since JDK-8149469 will go through hs-comp. > > Later on today i will kick of a JPRT hotspot test run. > > ? > > This is a small step towards unifying the buffer implementations using the unsafe double addressing scheme: > > https://bugs.openjdk.java.net/browse/JDK-6509032 > > Thanks, > Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From tprintezis at twitter.com Wed Mar 23 15:38:15 2016 From: tprintezis at twitter.com (Tony Printezis) Date: Wed, 23 Mar 2016 11:38:15 -0400 Subject: RFR: 8147468: Allow users to bound the size of buffers cached in the per-thread buffer caches In-Reply-To: <56F25C6A.4050008@oracle.com> References: <569E279E.4010302@oracle.com> <56A23019.2010001@oracle.com> <56A39D29.10509@oracle.com> <56A766A3.9070406@oracle.com> <598AF6CC-55E7-4A50-B3B2-2841D925F3AE@oracle.com> <56F25C6A.4050008@oracle.com> Message-ID: FWIW, we?ve had this change in TwitterJDK 8 for a while (in fact we had deployed it internally before I opened it for code review on this list) and we haven?t had any issues with it. On March 23, 2016 at 5:05:51 AM, Se?n Coffey (sean.coffey at oracle.com) wrote: The changes are pretty much self contained. I wouldn't see a problem with it coming back to jdk8u forest. If you want to work on patching, I can log a CCC request in parallel for the new system property. Regards, Sean. On 23/03/2016 07:13, Langer, Christoph wrote: Hi, ? are there any plans or votes pro/against bringing this fix to jdk8? ? I?ve got a customer request who would like to see this back in 8, too? ? Thanks Christoph ? From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Tony Printezis Sent: Donnerstag, 28. Januar 2016 17:20 To: Brian Burkhalter Cc: nio-dev Subject: Re: RFR: 8147468: Allow users to bound the size of buffers cached in the per-thread buffer caches ? All set! Thanks everyone for your help with this change!!! ? Tony ? On January 28, 2016 at 11:11:02 AM, Brian Burkhalter (brian.burkhalter at oracle.com) wrote: On Jan 28, 2016, at 8:04 AM, Tony Printezis wrote: I?m all set and jcheck is happy. ? If the change is this one ? http://cr.openjdk.java.net/~tonyp/nio-max-buffer-size/webrev.4/ ? I don?t see a reviewed-by line. See the example here ? http://openjdk.java.net/guide/producingChangeset.html#create ? under ?Formatting a Changeset Comment." Do I just do (the change only touches the jdk repo): ? hg push?http://hg.openjdk.java.net/jdk9/dev/jdk ? Or is there a special way to do pushes? ? You would need to use ?ssh? in the above URL instead of ?http.? ? Brian ----- ? Tony Printezis | JVM/GC Engineer / VM Team | Twitter ? @TonyPrintezis tprintezis at twitter.com ? ----- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kzr at jp.fujitsu.com Thu Mar 24 05:04:47 2016 From: kzr at jp.fujitsu.com (Kenji Kazumura) Date: Thu, 24 Mar 2016 14:04:47 +0900 (JST) Subject: RFR - 8142872: Remove support for sun.nio.ch.PollSelectorProvider from 9 In-Reply-To: <5658A681.5080903@oracle.com> References: <5658A2D4.1010500@oracle.com> <5658A681.5080903@oracle.com> Message-ID: <20160324.140447.396900645.kzr@jp.fujitsu.com> Hello, >From the performance point of view, we need still PollSelectorProvider. In our research, the score of SPECjbb2015-MultiJVM with PollSelectorProvider is higher over a few dozen percent than with DevPollSelectorProvider. I have discussed with some Solaris OS engineers about the difference of poll(2) and /dev/poll. They told me that both of them are needed because the use-case is different for each other. So Java programmers also would like to use both for the different situations. Please do not remove PollSelectorProvider from 9 -Kenji Kazumura In message <5658A681.5080903 at oracle.com> RFR - 8142872: Remove support for sun.nio.ch.PollSelectorProvider from 9 Alan.Bateman at oracle.com (Alan Bateman) wrote: > On 27/11/2015 18:37, Rob McKenna wrote: >> Hi folks, >> >> From time to time we get bugs on PollSelectorProvider despite >> recommending people use alternative implementations. The only way it >> can be used is setting the following system property: >> >> -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider >> >> Superior SelectorProvider implementations exist for all Oracle JDK >> platforms and PollSelectorProvider should not be used on those >> platforms if at all possible. That being the case we'd like to pull it >> from the default build: >> >> http://cr.openjdk.java.net/~robm/8076282/ > So in summary, leave the code in jdk repo for those that might want to > use it for porting purposes but exclude it from Linux/Solaris/OSX > builds. That seems reasonable to me as this SelectorProvider is not > interesting/useful on these platforms anymore. > > -Alan. > From Alan.Bateman at oracle.com Thu Mar 24 07:01:09 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Mar 2016 07:01:09 +0000 Subject: RFR - 8142872: Remove support for sun.nio.ch.PollSelectorProvider from 9 In-Reply-To: <20160324.140447.396900645.kzr@jp.fujitsu.com> References: <5658A2D4.1010500@oracle.com> <5658A681.5080903@oracle.com> <20160324.140447.396900645.kzr@jp.fujitsu.com> Message-ID: <56F390B5.4020404@oracle.com> On 24/03/2016 05:04, Kenji Kazumura wrote: > Hello, > > From the performance point of view, we need still PollSelectorProvider. > In our research, the score of SPECjbb2015-MultiJVM with PollSelectorProvider > is higher over a few dozen percent than with DevPollSelectorProvider. > > I have discussed with some Solaris OS engineers about > the difference of poll(2) and /dev/poll. > They told me that both of them are needed because > the use-case is different for each other. > > So Java programmers also would like to use both > for the different situations. > > Please do not remove PollSelectorProvider from 9 > > > -Kenji Kazumura > Do you really mean the ancient poll based Selector or do you mean the event port based Selector? Yes, we have been shipping 3 SelectorProvider implementations on Solaris. -Alan From kzr at jp.fujitsu.com Thu Mar 24 07:46:23 2016 From: kzr at jp.fujitsu.com (Kenji Kazumura) Date: Thu, 24 Mar 2016 16:46:23 +0900 (JST) Subject: RFR - 8142872: Remove support for sun.nio.ch.PollSelectorProvider from 9 In-Reply-To: <56F390B5.4020404@oracle.com> References: <5658A681.5080903@oracle.com> <20160324.140447.396900645.kzr@jp.fujitsu.com> <56F390B5.4020404@oracle.com> Message-ID: <20160324.164623.42929066.kzr@jp.fujitsu.com> Alan, I did not use sun.nio.ch.EventPortSelectorProvider but use sun.nio.ch.PollSelectorImpl. -Kenji Kazumura In message <56F390B5.4020404 at oracle.com> Re: RFR - 8142872: Remove support for sun.nio.ch.PollSelectorProvider from 9 Alan Bateman wrote: > On 24/03/2016 05:04, Kenji Kazumura wrote: >> Hello, >> >> From the performance point of view, we need still >> PollSelectorProvider. >> In our research, the score of SPECjbb2015-MultiJVM with >> PollSelectorProvider >> is higher over a few dozen percent than with DevPollSelectorProvider. >> >> I have discussed with some Solaris OS engineers about >> the difference of poll(2) and /dev/poll. >> They told me that both of them are needed because >> the use-case is different for each other. >> >> So Java programmers also would like to use both >> for the different situations. >> >> Please do not remove PollSelectorProvider from 9 >> >> >> -Kenji Kazumura >> > Do you really mean the ancient poll based Selector or do you mean the > event port based Selector? Yes, we have been shipping 3 > SelectorProvider implementations on Solaris. > > -Alan > From Alan.Bateman at oracle.com Thu Mar 24 11:15:00 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Mar 2016 11:15:00 +0000 Subject: RFR: JDK-8152545: Use preprocessor instead of compiling a program to generate native nio constants In-Reply-To: <56F2C0E2.8020102@oracle.com> References: <56F27A69.4000807@oracle.com> <56F2C0E2.8020102@oracle.com> Message-ID: <56F3CC34.504@oracle.com> On 23/03/2016 16:14, Erik Joelsson wrote: > : > > On 2016-03-23 12:13, Erik Joelsson wrote: >> There are however 3 that, at least on Linux, are defined as an enum >> and not constants, which makes them unavailable to the preprocessor. >> These are: >> >> IPPROTO_TCP = 6 >> IPPROTO_IP = 0 >> IPPROTO_PV6 = 41 >> >> I would say that this is fine. They have the same value on all our >> supported platforms and are actually part of the IP spec. I cannot >> imagine a reason for ever defining them differently. So the solution >> is to simply define these as constants in the java source. >> >> By fixing this, cross compiling new or existing platforms becomes >> much easier. >> >> I have verified this patch by manually comparing the output and by >> running the jdk_nio tests in JPRT. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152545 >> Webrev: http://cr.openjdk.java.net/~erikj/8152545/webrev.jdk.01/ The hard coded values should be okay because they are standard, for example RFC 2292 defines IPPROTO_IPV6 as 41, TCP is protocol number 6. Is the #undef sun really needed? It otherwise looks good to me. We can fix up the very long lines at some point to get it consistent with the other code in this area. -Alan. From Alan.Bateman at oracle.com Thu Mar 24 11:20:15 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Mar 2016 11:20:15 +0000 Subject: RFR - 8142872: Remove support for sun.nio.ch.PollSelectorProvider from 9 In-Reply-To: <20160324.164623.42929066.kzr@jp.fujitsu.com> References: <5658A681.5080903@oracle.com> <20160324.140447.396900645.kzr@jp.fujitsu.com> <56F390B5.4020404@oracle.com> <20160324.164623.42929066.kzr@jp.fujitsu.com> Message-ID: <56F3CD6F.2080701@oracle.com> On 24/03/2016 07:46, Kenji Kazumura wrote: > Alan, > > I did not use sun.nio.ch.EventPortSelectorProvider > but use sun.nio.ch.PollSelectorImpl. > > -Kenji Kazumura > It would be good to get an understanding of what the performance issue is. I recall we had issues with the /dev/poll driver where there was contention on a mutex in the Solaris kernel. This was one of the motives for EventPortSelectorProvider. Given that /dev/poll is legacy now then I think we should be looking to have EventPortSelectorProvider be the default on Solaris now. -Alan From kzr at jp.fujitsu.com Thu Mar 24 11:36:04 2016 From: kzr at jp.fujitsu.com (Kenji Kazumura) Date: Thu, 24 Mar 2016 20:36:04 +0900 (JST) Subject: RFR - 8142872: Remove support for sun.nio.ch.PollSelectorProvider from 9 In-Reply-To: <56F3CD6F.2080701@oracle.com> References: <56F390B5.4020404@oracle.com> <20160324.164623.42929066.kzr@jp.fujitsu.com> <56F3CD6F.2080701@oracle.com> Message-ID: <20160324.203604.397507988.kzr@jp.fujitsu.com> Hi, I will try to use EventPortSelectorProvider and see if the performance is changed. -Kenji Kazumura In message <56F3CD6F.2080701 at oracle.com> Re: RFR - 8142872: Remove support for sun.nio.ch.PollSelectorProvider from 9 Alan Bateman wrote: > On 24/03/2016 07:46, Kenji Kazumura wrote: >> Alan, >> >> I did not use sun.nio.ch.EventPortSelectorProvider >> but use sun.nio.ch.PollSelectorImpl. >> >> -Kenji Kazumura >> > It would be good to get an understanding of what the performance issue > is. I recall we had issues with the /dev/poll driver where there was > contention on a mutex in the Solaris kernel. This was one of the > motives for EventPortSelectorProvider. Given that /dev/poll is legacy > now then I think we should be looking to have > EventPortSelectorProvider be the default on Solaris now. > > -Alan > From erik.joelsson at oracle.com Thu Mar 24 11:57:47 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 24 Mar 2016 12:57:47 +0100 Subject: RFR: JDK-8152545: Use preprocessor instead of compiling a program to generate native nio constants In-Reply-To: <56F3CC34.504@oracle.com> References: <56F27A69.4000807@oracle.com> <56F2C0E2.8020102@oracle.com> <56F3CC34.504@oracle.com> Message-ID: <56F3D63B.2090504@oracle.com> On 2016-03-24 12:15, Alan Bateman wrote: > > On 23/03/2016 16:14, Erik Joelsson wrote: >> : >> >> On 2016-03-23 12:13, Erik Joelsson wrote: >>> There are however 3 that, at least on Linux, are defined as an enum >>> and not constants, which makes them unavailable to the preprocessor. >>> These are: >>> >>> IPPROTO_TCP = 6 >>> IPPROTO_IP = 0 >>> IPPROTO_PV6 = 41 >>> >>> I would say that this is fine. They have the same value on all our >>> supported platforms and are actually part of the IP spec. I cannot >>> imagine a reason for ever defining them differently. So the solution >>> is to simply define these as constants in the java source. >>> >>> By fixing this, cross compiling new or existing platforms becomes >>> much easier. >>> >>> I have verified this patch by manually comparing the output and by >>> running the jdk_nio tests in JPRT. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152545 >>> Webrev: http://cr.openjdk.java.net/~erikj/8152545/webrev.jdk.01/ > > The hard coded values should be okay because they are standard, for > example RFC 2292 defines IPPROTO_IPV6 as 41, TCP is protocol number 6. > > Is the #undef sun really needed? It otherwise looks good to me. We can > fix up the very long lines at some point to get it consistent with the > other code in this area. > When running this on Solaris without "#undef sun", the package line ended up being "package 1 .nio.fs". That's the drawback/scary part of using the preprocessor on something that isn't strictly C source, you might get unexpected matches. If you want me to break up lines, I will do it. /Erik From erik.joelsson at oracle.com Thu Mar 24 12:15:30 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 24 Mar 2016 13:15:30 +0100 Subject: RFR: JDK-8152545: Use preprocessor instead of compiling a program to generate native nio constants In-Reply-To: <56F3D63B.2090504@oracle.com> References: <56F27A69.4000807@oracle.com> <56F2C0E2.8020102@oracle.com> <56F3CC34.504@oracle.com> <56F3D63B.2090504@oracle.com> Message-ID: <56F3DA62.6070202@oracle.com> New webrev with shorter lines in SocketOptionRegistry.java.template. http://cr.openjdk.java.net/~erikj/8152545/webrev.jdk.02/ /Erik On 2016-03-24 12:57, Erik Joelsson wrote: > > > On 2016-03-24 12:15, Alan Bateman wrote: >> >> On 23/03/2016 16:14, Erik Joelsson wrote: >>> : >>> >>> On 2016-03-23 12:13, Erik Joelsson wrote: >>>> There are however 3 that, at least on Linux, are defined as an enum >>>> and not constants, which makes them unavailable to the >>>> preprocessor. These are: >>>> >>>> IPPROTO_TCP = 6 >>>> IPPROTO_IP = 0 >>>> IPPROTO_PV6 = 41 >>>> >>>> I would say that this is fine. They have the same value on all our >>>> supported platforms and are actually part of the IP spec. I cannot >>>> imagine a reason for ever defining them differently. So the >>>> solution is to simply define these as constants in the java source. >>>> >>>> By fixing this, cross compiling new or existing platforms becomes >>>> much easier. >>>> >>>> I have verified this patch by manually comparing the output and by >>>> running the jdk_nio tests in JPRT. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152545 >>>> Webrev: http://cr.openjdk.java.net/~erikj/8152545/webrev.jdk.01/ >> >> The hard coded values should be okay because they are standard, for >> example RFC 2292 defines IPPROTO_IPV6 as 41, TCP is protocol number 6. >> >> Is the #undef sun really needed? It otherwise looks good to me. We >> can fix up the very long lines at some point to get it consistent >> with the other code in this area. >> > When running this on Solaris without "#undef sun", the package line > ended up being "package 1 .nio.fs". That's the drawback/scary part of > using the preprocessor on something that isn't strictly C source, you > might get unexpected matches. > > If you want me to break up lines, I will do it. > > /Erik From Alan.Bateman at oracle.com Thu Mar 24 12:38:12 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Mar 2016 12:38:12 +0000 Subject: RFR: JDK-8152545: Use preprocessor instead of compiling a program to generate native nio constants In-Reply-To: <56F3DA62.6070202@oracle.com> References: <56F27A69.4000807@oracle.com> <56F2C0E2.8020102@oracle.com> <56F3CC34.504@oracle.com> <56F3D63B.2090504@oracle.com> <56F3DA62.6070202@oracle.com> Message-ID: <56F3DFB4.6090203@oracle.com> On 24/03/2016 12:15, Erik Joelsson wrote: > New webrev with shorter lines in SocketOptionRegistry.java.template. > > http://cr.openjdk.java.net/~erikj/8152545/webrev.jdk.02/ > This looks good. -Alan. From kzr at jp.fujitsu.com Wed Mar 30 05:31:44 2016 From: kzr at jp.fujitsu.com (Kenji Kazumura) Date: Wed, 30 Mar 2016 14:31:44 +0900 (JST) Subject: RFR - 8142872: Remove support for sun.nio.ch.PollSelectorProvider from 9 In-Reply-To: <20160324.203604.397507988.kzr@jp.fujitsu.com> References: <20160324.164623.42929066.kzr@jp.fujitsu.com> <56F3CD6F.2080701@oracle.com> <20160324.203604.397507988.kzr@jp.fujitsu.com> Message-ID: <20160330.143144.447982337.kzr@jp.fujitsu.com> The result with EventPortSelectorProvider is almost same as with PollSelectorProvider. This result is good for me. Let me make sure that the provider which will be removed form JDK 9 is only PollSelectorProvider but not EventPortSelectorProvider. Is it right ? -Kenji Kazumura In message <20160324.203604.397507988.kzr at jp.fujitsu.com> Re: RFR - 8142872: Remove support for sun.nio.ch.PollSelectorProvider from 9 Kenji Kazumura wrote: > Hi, > > I will try to use EventPortSelectorProvider and > see if the performance is changed. > > -Kenji Kazumura > > > > In message <56F3CD6F.2080701 at oracle.com> > Re: RFR - 8142872: Remove support for sun.nio.ch.PollSelectorProvider from 9 > Alan Bateman wrote: > >> On 24/03/2016 07:46, Kenji Kazumura wrote: >>> Alan, >>> >>> I did not use sun.nio.ch.EventPortSelectorProvider >>> but use sun.nio.ch.PollSelectorImpl. >>> >>> -Kenji Kazumura >>> >> It would be good to get an understanding of what the performance issue >> is. I recall we had issues with the /dev/poll driver where there was >> contention on a mutex in the Solaris kernel. This was one of the >> motives for EventPortSelectorProvider. Given that /dev/poll is legacy >> now then I think we should be looking to have >> EventPortSelectorProvider be the default on Solaris now. >> >> -Alan >> From Alan.Bateman at oracle.com Wed Mar 30 06:34:01 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Mar 2016 07:34:01 +0100 Subject: RFR - 8142872: Remove support for sun.nio.ch.PollSelectorProvider from 9 In-Reply-To: <20160330.143144.447982337.kzr@jp.fujitsu.com> References: <20160324.164623.42929066.kzr@jp.fujitsu.com> <56F3CD6F.2080701@oracle.com> <20160324.203604.397507988.kzr@jp.fujitsu.com> <20160330.143144.447982337.kzr@jp.fujitsu.com> Message-ID: <56FB7359.1030709@oracle.com> On 30/03/2016 06:31, Kenji Kazumura wrote: > The result with EventPortSelectorProvider is almost same as > with PollSelectorProvider. This result is good for me. > > Let me make sure that the provider which will be removed form JDK 9 is > only PollSelectorProvider but not EventPortSelectorProvider. > Is it right ? > Yes, the proposal is to port the PollSelectorProvider in the Solaris builds of JDK 9. Thanks for the EventPortSelectorProvider, we developed that SelectorProvider implementation on the assumption that we would make it the default on Solaris some day. -Alan From kzr at jp.fujitsu.com Wed Mar 30 13:24:22 2016 From: kzr at jp.fujitsu.com (Kenji Kazumura) Date: Wed, 30 Mar 2016 22:24:22 +0900 (JST) Subject: iepoll might wait too long Message-ID: <20160330.222422.448942430.kzr@jp.fujitsu.com> Hello, When I looked into "EPollArrayWrapper.c" I found the code to be fixed. At line 56, the 4th parameter of epoll_wait is 'timeout', but I think it should be 'remaining' as 'ipoll' of 'PollArrayWrapper.c' does. EPollArrayWrapper.c 44 static int 45 iepoll(int epfd, struct epoll_event *events, int numfds, jlong timeout) 46 { 47 jlong start, now; 48 int remaining = timeout; 49 struct timeval t; 50 int diff; 51 52 gettimeofday(&t, NULL); 53 start = t.tv_sec * 1000 + t.tv_usec / 1000; 54 55 for (;;) { 56 int res = epoll_wait(epfd, events, numfds, timeout); 57 if (res < 0 && errno == EINTR) { 58 if (remaining >= 0) { 59 gettimeofday(&t, NULL); 60 now = t.tv_sec * 1000 + t.tv_usec / 1000; 61 diff = now - start; 62 remaining -= diff; 63 if (diff < 0 || remaining <= 0) { 64 return 0; 65 } 66 start = now; 67 } 68 } else { 69 return res; 70 } 71 } 72 } -Kenji Kazumura From Alan.Bateman at oracle.com Wed Mar 30 19:46:42 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Mar 2016 20:46:42 +0100 Subject: iepoll might wait too long In-Reply-To: <20160330.222422.448942430.kzr@jp.fujitsu.com> References: <20160330.222422.448942430.kzr@jp.fujitsu.com> Message-ID: <56FC2D22.1070105@oracle.com> On 30/03/2016 14:24, Kenji Kazumura wrote: > Hello, > > When I looked into "EPollArrayWrapper.c" I found the code to be fixed. > At line 56, the 4th parameter of epoll_wait is 'timeout', > but I think it should be 'remaining' as 'ipoll' of 'PollArrayWrapper.c' does. > Ugh, you're right. I'll create a bug for this now. -Alan