From brian.burkhalter at oracle.com Tue Jan 5 00:59:59 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 4 Jan 2016 16:59:59 -0800 Subject: RFR [9] 8146359: test/java/nio/file/attribute/BasicFileAttributeView/UnixSocketFile.java fails when nc is not available Message-ID: <9140D027-EE79-46BC-A1A5-6FD93F08F33A@oracle.com> Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8146359 Patch: http://cr.openjdk.java.net/~bpb/8146359/webrev.00/ The change is to execute ?which nc? to check whether ?nc? is available and if not then skip the test. Thanks, Brian From brian.burkhalter at oracle.com Tue Jan 5 02:09:17 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 4 Jan 2016 18:09:17 -0800 Subject: JDK 9 RFR of 8050499: (ch) NativeSignal.signal fails with error 316 on OS X Message-ID: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8050499 Patch: http://cr.openjdk.java.net/~bpb/8050499/webrev.00/ Summary: On OSX ignore ESRCH returned by pthread_kill(). Thanks, Brian From Alan.Bateman at oracle.com Tue Jan 5 12:34:52 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Jan 2016 12:34:52 +0000 Subject: JDK 9 RFR of 8050499: (ch) NativeSignal.signal fails with error 316 on OS X In-Reply-To: References: Message-ID: <568BB86C.9040106@oracle.com> On 05/01/2016 02:09, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8050499 > Patch: http://cr.openjdk.java.net/~bpb/8050499/webrev.00/ > > Summary: > > On OSX ignore ESRCH returned by pthread_kill(). > As a temporary fix then I think this probably okay but I assume the real issue here is that readerThread/writerThread are being set/cleared without stateLock. Maybe it's time to address this and also look at ServerSocketChannelImpl which I assume has the same issue. We can also look at SocketChannelImpl where this issue has been fixed but where readerThread/writerThread has been left as volatile and this might not be needed now. For the test then it might be good to rename it something like StressNativeSignal or something else that makes it clearer what the test is for. One other question about the test, can it run on all platforms? I assume @requires os.family == "mac" is not needed. -Alan. From Alan.Bateman at oracle.com Tue Jan 5 12:36:14 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Jan 2016 12:36:14 +0000 Subject: RFR [9] 8146359: test/java/nio/file/attribute/BasicFileAttributeView/UnixSocketFile.java fails when nc is not available In-Reply-To: <9140D027-EE79-46BC-A1A5-6FD93F08F33A@oracle.com> References: <9140D027-EE79-46BC-A1A5-6FD93F08F33A@oracle.com> Message-ID: <568BB8BE.4060604@oracle.com> On 05/01/2016 00:59, Brian Burkhalter wrote: > Please review at your convenience: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8146359 > Patch: http://cr.openjdk.java.net/~bpb/8146359/webrev.00/ > > The change is to execute ?which nc? to check whether ?nc? is available and if not then skip the test. > This looks okay. There might be test infrastructure that could help with this too. -Alan From brian.burkhalter at oracle.com Tue Jan 5 18:33:57 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 5 Jan 2016 10:33:57 -0800 Subject: RFR [9] 8146359: test/java/nio/file/attribute/BasicFileAttributeView/UnixSocketFile.java fails when nc is not available In-Reply-To: <568BB8BE.4060604@oracle.com> References: <9140D027-EE79-46BC-A1A5-6FD93F08F33A@oracle.com> <568BB8BE.4060604@oracle.com> Message-ID: On Jan 5, 2016, at 4:36 AM, Alan Bateman wrote: >> The change is to execute ?which nc? to check whether ?nc? is available and if not then skip the test. >> > This looks okay. There might be test infrastructure that could help with this too. I?m not sure what infrastructure that would be. I don?t see anything in the jtreg tag specification which appears useful in this context. So, is this good to go or is further research in order? Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Jan 5 18:40:33 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 5 Jan 2016 10:40:33 -0800 Subject: JDK 9 RFR of 8050499: (ch) NativeSignal.signal fails with error 316 on OS X In-Reply-To: <568BB86C.9040106@oracle.com> References: <568BB86C.9040106@oracle.com> Message-ID: On Jan 5, 2016, at 4:34 AM, Alan Bateman wrote: >> On OSX ignore ESRCH returned by pthread_kill(). >> > As a temporary fix then I think this probably okay but I assume the real issue here is that readerThread/writerThread are being set/cleared without stateLock. Maybe it's time to address this and also look at ServerSocketChannelImpl which I assume has the same issue. We can also look at SocketChannelImpl where this issue has been fixed but where readerThread/writerThread has been left as volatile and this might not be needed now. Yes, I saw the comments in the issue that further work might be necessary in this area. Would it be appropriate to resolve this issue with the current patch and file another, separate issue to follow up the aforementioned root cause(s)? > For the test then it might be good to rename it something like StressNativeSignal or something else that makes it clearer what the test is for. > > One other question about the test, can it run on all platforms? I assume @requires os.family == "mac" is not needed. The above changes are made in this patch: http://cr.openjdk.java.net/~bpb/8050499/webrev.01/ I?ll run it on all platforms also. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jan 5 19:34:57 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Jan 2016 19:34:57 +0000 Subject: JDK 9 RFR of 8050499: (ch) NativeSignal.signal fails with error 316 on OS X In-Reply-To: References: <568BB86C.9040106@oracle.com> Message-ID: <568C1AE1.5000906@oracle.com> On 05/01/2016 18:40, Brian Burkhalter wrote: > > On Jan 5, 2016, at 4:34 AM, Alan Bateman > wrote: > >>> On OSX ignore ESRCH returned by pthread_kill(). >>> >> As a temporary fix then I think this probably okay but I assume the >> real issue here is that readerThread/writerThread are being >> set/cleared without stateLock. Maybe it's time to address this and >> also look at ServerSocketChannelImpl which I assume has the same >> issue. We can also look at SocketChannelImpl where this issue has >> been fixed but where readerThread/writerThread has been left as >> volatile and this might not be needed now. > > Yes, I saw the comments in the issue that further work might be > necessary in this area. Would it be appropriate to resolve this issue > with the current patch and file another, separate issue to follow up > the aforementioned root cause(s)? Yes, that would be okay. > >> For the test then it might be good to rename it something like >> StressNativeSignal or something else that makes it clearer what the >> test is for. >> >> One other question about the test, can it run on all platforms? I >> assume @requires os.family == "mac" is not needed. > > The above changes are made in this patch: > > http://cr.openjdk.java.net/~bpb/8050499/webrev.01/ > > > I?ll run it on all platforms also. > Thanks, it looks good to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jan 5 19:38:07 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 5 Jan 2016 19:38:07 +0000 Subject: RFR [9] 8146359: test/java/nio/file/attribute/BasicFileAttributeView/UnixSocketFile.java fails when nc is not available In-Reply-To: References: <9140D027-EE79-46BC-A1A5-6FD93F08F33A@oracle.com> <568BB8BE.4060604@oracle.com> Message-ID: <568C1B9F.4070801@oracle.com> On 05/01/2016 18:33, Brian Burkhalter wrote: > > On Jan 5, 2016, at 4:36 AM, Alan Bateman > wrote: > >>> The change is to execute ?which nc? to check whether ?nc? is >>> available and if not then skip the test. >>> >> This looks okay. There might be test infrastructure that could help >> with this too. > > I?m not sure what infrastructure that would be. I don?t see anything > in the jtreg tag specification which appears useful in this context. > So, is this good to go or is further research in order? > I meant @library infrastructure, in this case jdk.testlibrary.ProcessTools. No worry about it for now, it's just something to be aware of when creating tests like this. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Jan 7 20:54:35 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 7 Jan 2016 20:54:35 +0000 Subject: sun.nio.ch.Util: Don't cache an unlimited amount of memory In-Reply-To: References: <56824FA1.5050808@oracle.com> <5683EFE3.9080501@oracle.com> Message-ID: <568ED08B.4060400@oracle.com> On 06/01/2016 22:26, Tony Printezis wrote: > Alan and Evan, > > First, apologies I?m a bit late on this thread. > > As Evan mentioned, the fix I implemented was to introduce a parameter > that sets the limit for the size of buffers added to the cache and > never cache a buffer whose size is over this limit. I followed the way > the -XX:MaxDirectMemorySize=? cmd line arg was implemented and added a > -XX:MaxCachedTempBufferSize=? cmd line arg to HotSpot and pass that > value via a property to Java (that?s what?s done for > MaxDirectMemorySize). We could leave it as a property, as Alan > suggested (no changes to HotSpot); I have no strong opinion either > way. I just thought that it was best to be consistent with how > MaxDirectMemorySize is set. > > With MaxCachedTempBufferSize a user can implicitly set the overall > memory used up by cached buffers (it will also depend on how many > buffers per thread are cached, one in our case, and the number of > threads that do operations that need to cache buffers). An alternative > approach I considered was to introduce a parameter that sets a max for > the total memory taken up by all cached buffers. This will be a bit > more user-friendly (the user will know exactly the max overhead of > those buffers). However, it?d also require synchronization between > threads when replacing cached buffers (as we?d have to keep track of > the total size of all cached buffers across all threads) and I wanted > to avoid that. It also has a very bad pathological edge case: a thread > might cache a very large buffer that?s just under the total limit and > prevent all other threads from caching anything. > > Any other alternatives that we could consider here? > > Alan, what would you like me to do next? Should I maybe create a CR > and post the diffs I have so you guys can take a look? > On -XX vs. a system property then one thing to say is that this buffer cache is specific to NIO channels. So that will probably influence the property or VM option name and maybe it would better to not tie HotSpot to specific areas like this. On the value then the simplest is to set the maximum size of a buffer to cache. Scatter/gather I/O is relatively rare so this means that most of the time then only one buffer will be cached per thread. I see your point that a global limit would be more user-friendly but it could always lead to unpredictable performance when the thread count is high and the global limit is reached. In that scenario it would degrade to a malloc + free per I/O operation for threads that are unlucky enough not to have a cached buffer. As regards moving forward then a patch or webrev on cr.openjdk.java.net would be best. I assume you still have access to JIRA and can push webrevs to cr. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Jan 14 23:02:58 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 14 Jan 2016 15:02:58 -0800 Subject: RFR: 8146213, 8133093: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed intermittently with Connection refused and Accept did not time out In-Reply-To: <569716BE.2080103@oracle.com> References: <569716BE.2080103@oracle.com> Message-ID: Hi Hamlin, On Jan 13, 2016, at 7:32 PM, Hamlin Li wrote: > Would you please help to review the fix for below bugs? > https://bugs.openjdk.java.net/browse/JDK-8146213, Test java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed intermittently with Connection refused, > and https://bugs.openjdk.java.net/browse/JDK-8133093, Test java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed with Accept did not time out. > > webrev : http://cr.openjdk.java.net/~mli/8146213/webrev.00/ This looks OK to me aside from the following two points: 1. At line 2, 2013 should be changed to 2016 The general approach for copyright years is discussed in http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-March/016757.html. I could not locate a specification for this in the OpenJDK guidelines which does not of course indicate it is not there. 2. The changeset is missing a comment See the section ?Formatting a Changeset Comment? in http://openjdk.java.net/guide/producingChangeset.html. In a case such as this where there is more than one issue there should be one bugid line per issue. Also as you do not yet have commit rights to JDK 9, the contributed-by line should be included with your e-mail address. I don?t know whether you?ve done it already, but you should run jcheck (http://openjdk.java.net/projects/code-tools/jcheck/) on the patch and correct any problems. These commonly devolve to either trailing whitespace in a file or an invalid reviewer attribution. The whitespace may be corrected using /make/scripts/normalizer.pl. Note that if you are using the mercurial Mq extension, you will need to run ?hg qref? after normalizing any files. Lastly, the labels ?noreg-self? and ?test-only? should I believe be added to both JBS issues. Note that I am not a JDK Reviewer so I cannot formally approve the review request. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Jan 15 07:40:00 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Jan 2016 07:40:00 +0000 Subject: RFR: 8146213, 8133093: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed intermittently with Connection refused and Accept did not time out In-Reply-To: References: <569716BE.2080103@oracle.com> Message-ID: <5698A250.5050207@oracle.com> On 14/01/2016 23:02, Brian Burkhalter wrote: > > 1. At line 2, 2013 should be changed to 2016 > > The general approach for copyright years is discussed in > http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-March/016757.html. > I could not locate a specification for this in the OpenJDK guidelines > which does not of course indicate it is not there. > AFAIK, this isn't a policy in OpenJDK. There is a script in the top-level repo that will do a bulk updates and I think the original intention (going back many years) was that this should be run periodically to do bulk updates. It doesn't seem to run very often and I think this may be why more and more people ask that files be updated manually. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Jan 15 07:44:58 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Jan 2016 07:44:58 +0000 Subject: RFR: 8146213, 8133093: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed intermittently with Connection refused and Accept did not time out In-Reply-To: References: <569716BE.2080103@oracle.com> Message-ID: <5698A37A.9010103@oracle.com> On 14/01/2016 23:02, Brian Burkhalter wrote: > Hi Hamlin, > > On Jan 13, 2016, at 7:32 PM, Hamlin Li > wrote: > >> Would you please help to review the fix for below bugs? >> https://bugs.openjdk.java.net/browse/JDK-8146213, Test >> java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed >> intermittently with Connection refused, >> andhttps://bugs.openjdk.java.net/browse/JDK-8133093, Test >> java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed >> with Accept did not time out. >> >> webrev :http://cr.openjdk.java.net/~mli/8146213/webrev.00/ >> > > This looks OK to me aside from the following two points: > Hamlin - would it be possible to summarize what the issue this? This is a very old test and would be good to have this information to understand what the issue is? Also just to say that it's best to keep the coding style consistent when you can. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From huaming.li at oracle.com Thu Jan 14 03:32:14 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 14 Jan 2016 11:32:14 +0800 Subject: RFR: 8146213, 8133093: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed intermittently with Connection refused and Accept did not time out Message-ID: <569716BE.2080103@oracle.com> Hi Brian and everyone, Would you please help to review the fix for below bugs? https://bugs.openjdk.java.net/browse/JDK-8146213, Test java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed intermittently with Connection refused, and https://bugs.openjdk.java.net/browse/JDK-8133093, Test java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed with Accept did not time out. webrev : http://cr.openjdk.java.net/~mli/8146213/webrev.00/ Thank you -Hamlin From huaming.li at oracle.com Fri Jan 15 05:04:58 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 15 Jan 2016 13:04:58 +0800 Subject: RFR: 8146213, 8133093: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed intermittently with Connection refused and Accept did not time out In-Reply-To: References: <569716BE.2080103@oracle.com> Message-ID: <56987DFA.2080908@oracle.com> Hi everyone, As Brian is not reviewer, would you please help to further review the code change based on Brian's comments. bugs: https://bugs.openjdk.java.net/browse/JDK-8146213, Test java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed intermittently with Connection refused, and https://bugs.openjdk.java.net/browse/JDK-8133093, Test java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed with Accept did not time out. webrev: http://cr.openjdk.java.net/~mli/8146213/webrev.01/ Hi Brian, Thanks for the comments, I have done the jcheck format the commit message locally. -Hamlin On 2016/1/15 7:02, Brian Burkhalter wrote: > Hi Hamlin, > > On Jan 13, 2016, at 7:32 PM, Hamlin Li > wrote: > >> Would you please help to review the fix for below bugs? >> https://bugs.openjdk.java.net/browse/JDK-8146213, Test >> java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed >> intermittently with Connection refused, >> andhttps://bugs.openjdk.java.net/browse/JDK-8133093, Test >> java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed >> with Accept did not time out. >> >> webrev :http://cr.openjdk.java.net/~mli/8146213/webrev.00/ >> > > This looks OK to me aside from the following two points: > > 1. At line 2, 2013 should be changed to 2016 > > The general approach for copyright years is discussed in > http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-March/016757.html. > I could not locate a specification for this in the OpenJDK guidelines > which does not of course indicate it is not there. > > 2. The changeset is missing a comment > > See the section ?Formatting a Changeset Comment? in > http://openjdk.java.net/guide/producingChangeset.html. In a case such > as this where there is more than one issue there should be one bugid > line per issue. Also as you do not yet have commit rights to JDK 9, > the contributed-by line should be included with your e-mail address. > > I don?t know whether you?ve done it already, but you should run jcheck > (http://openjdk.java.net/projects/code-tools/jcheck/) on the patch and > correct any problems. These commonly devolve to either trailing > whitespace in a file or an invalid reviewer attribution. The > whitespace may be corrected using > /make/scripts/normalizer.pl. Note that if you are using > the mercurial Mq extension, you will need to run ?hg qref? after > normalizing any files. > > Lastly, the labels ?noreg-self? and ?test-only? should I believe be > added to both JBS issues. > > Note that I am not a JDK Reviewer so I cannot formally approve the > review request. > > Thanks, > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From huaming.li at oracle.com Fri Jan 15 05:29:04 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 15 Jan 2016 13:29:04 +0800 Subject: RFR: 8141595: java/nio/channels/ServerSocketChannel/NonBlockingAccept.java fails intermittently Message-ID: <569883A0.40102@oracle.com> Hi everyone, Would you please help to review the fix for https://bugs.openjdk.java.net/browse/JDK-8141595, java/nio/channels/ServerSocketChannel/NonBlockingAccept.java fails intermittently. webrev : http://cr.openjdk.java.net/~mli/8141595/webrev.00/ Thank you -Hamlin From huaming.li at oracle.com Fri Jan 15 05:42:52 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 15 Jan 2016 13:42:52 +0800 Subject: RFR: 8143100: java/nio/channels/ServerSocketChannel/Basic.java fails intermittently Message-ID: <569886DC.5080400@oracle.com> Hi everyone, Would you please help to review the fix for bug https://bugs.openjdk.java.net/browse/JDK-8143100, java/nio/channels/ServerSocketChannel/Basic.java fails intermittently. webrev : http://cr.openjdk.java.net/~mli/8143100/webrev.00/ Thank you -Hamlin From huaming.li at oracle.com Fri Jan 15 08:34:22 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 15 Jan 2016 16:34:22 +0800 Subject: RFR: 8146213, 8133093: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed intermittently with Connection refused and Accept did not time out In-Reply-To: <5698A37A.9010103@oracle.com> References: <569716BE.2080103@oracle.com> <5698A37A.9010103@oracle.com> Message-ID: <5698AF0E.7040302@oracle.com> On 2016/1/15 15:44, Alan Bateman wrote: > > > On 14/01/2016 23:02, Brian Burkhalter wrote: >> Hi Hamlin, >> >> On Jan 13, 2016, at 7:32 PM, Hamlin Li wrote: >> >>> Would you please help to review the fix for below bugs? >>> https://bugs.openjdk.java.net/browse/JDK-8146213, Test >>> java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed >>> intermittently with Connection refused, >>> andhttps://bugs.openjdk.java.net/browse/JDK-8133093, Test >>> java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed >>> with Accept did not time out. >>> >>> webrev :http://cr.openjdk.java.net/~mli/8146213/webrev.00/ >> >> This looks OK to me aside from the following two points: >> > Hamlin - would it be possible to summarize what the issue this? This > is a very old test and would be good to have this information to > understand what the issue is? Hi Alan, Thanks for reviewing, please check new webrev : http://cr.openjdk.java.net/~mli/8146213/webrev.02/. both bug JDK-8146213 and JDK-8133093 are test bugs due to race condition. * The bugs occurs only when testing accept timeout in server side, * it's due to race conditions. There is some time window between * server.accept timeout(in server thread), client.interrupt(in server thread), * client wakeup from sleeping(in client thread), client.connect(in client thread). * 1. if time order is server.accept timeout -> client.interrupt * -> client wakeup from sleeping, then test pass successfully. * 2. if time order is server.accept timeout -> client wakes up from sleeping * -> client.connect -> client interrupt, then * exception(java.net.ConnectException: Connection refused: connect) occurs, * it's bug JDK-8146213. * 3. if time order is client wakeup from sleeping -> client.connect * -> server.accept timeout, * then exception(java.lang.Exception: Accept did not time out) occurs, * it's bug JDK-8133093. * To fix the bugs 8146213 8133093, we only need not to start client when testing * server accept timeout. > > Also just to say that it's best to keep the coding style consistent > when you can. fixed. Thank you -Hamlin > > -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Jan 15 09:02:25 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Jan 2016 09:02:25 +0000 Subject: RFR: 8141595: java/nio/channels/ServerSocketChannel/NonBlockingAccept.java fails intermittently In-Reply-To: <569883A0.40102@oracle.com> References: <569883A0.40102@oracle.com> Message-ID: <5698B5A1.1070405@oracle.com> On 15/01/2016 05:29, Hamlin Li wrote: > Hi everyone, > > Would you please help to review the fix for > https://bugs.openjdk.java.net/browse/JDK-8141595, > java/nio/channels/ServerSocketChannel/NonBlockingAccept.java fails > intermittently. > webrev : http://cr.openjdk.java.net/~mli/8141595/webrev.00/ Another old test using Thread.sleep :-) I assume the issue is that the sleep time is not sufficient on busy systems. Your approach is okay but would be good to keep the coding style / line length consistent etc. An alternative is not to drop LOOPS and let it loop until a connection is accepted or the test is timed out by jtreg. -Alan From Alan.Bateman at oracle.com Fri Jan 15 09:11:09 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Jan 2016 09:11:09 +0000 Subject: RFR: 8143100: java/nio/channels/ServerSocketChannel/Basic.java fails intermittently In-Reply-To: <569886DC.5080400@oracle.com> References: <569886DC.5080400@oracle.com> Message-ID: <5698B7AD.3050300@oracle.com> On 15/01/2016 05:42, Hamlin Li wrote: > Hi everyone, > > Would you please help to review the fix for bug > https://bugs.openjdk.java.net/browse/JDK-8143100, > java/nio/channels/ServerSocketChannel/Basic.java fails intermittently. > webrev : http://cr.openjdk.java.net/~mli/8143100/webrev.00/ Changing the finish usages to wait forever looks good. Just on the @bug, I assume this test is missing @bug 4286936 so best to add that as otherwise it will look like the test was created for JDK-8143100. You can then drop the reference to 8143100 from L133. -Alan. From huaming.li at oracle.com Fri Jan 15 09:36:36 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 15 Jan 2016 17:36:36 +0800 Subject: RFR: 8141595: java/nio/channels/ServerSocketChannel/NonBlockingAccept.java fails intermittently In-Reply-To: <5698B5A1.1070405@oracle.com> References: <569883A0.40102@oracle.com> <5698B5A1.1070405@oracle.com> Message-ID: <5698BDA4.2000509@oracle.com> On 2016/1/15 17:02, Alan Bateman wrote: > > On 15/01/2016 05:29, Hamlin Li wrote: >> Hi everyone, >> >> Would you please help to review the fix for >> https://bugs.openjdk.java.net/browse/JDK-8141595, >> java/nio/channels/ServerSocketChannel/NonBlockingAccept.java fails >> intermittently. >> webrev : http://cr.openjdk.java.net/~mli/8141595/webrev.00/ > Another old test using Thread.sleep :-) Hi Alan, Yes, it is. :-) > > I assume the issue is that the sleep time is not sufficient on busy > systems. Your approach is okay but would be good to keep the coding > style / line length consistent etc. An alternative is not to drop > LOOPS and let it loop until a connection is accepted or the test is > timed out by jtreg. Yes, the root cause is sleep time is not sufficient on busy systems. And I follow your suggestion to fix the code style and line length, and let jtreg to timeout the test case. new webrev: http://cr.openjdk.java.net/~mli/8141595/webrev.01/ Thank you -Hamlin > > -Alan From huaming.li at oracle.com Fri Jan 15 09:45:28 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 15 Jan 2016 17:45:28 +0800 Subject: RFR: 8143100: java/nio/channels/ServerSocketChannel/Basic.java fails intermittently In-Reply-To: <5698B7AD.3050300@oracle.com> References: <569886DC.5080400@oracle.com> <5698B7AD.3050300@oracle.com> Message-ID: <5698BFB8.2070001@oracle.com> On 2016/1/15 17:11, Alan Bateman wrote: > > On 15/01/2016 05:42, Hamlin Li wrote: >> Hi everyone, >> >> Would you please help to review the fix for bug >> https://bugs.openjdk.java.net/browse/JDK-8143100, >> java/nio/channels/ServerSocketChannel/Basic.java fails intermittently. >> webrev : http://cr.openjdk.java.net/~mli/8143100/webrev.00/ > Changing the finish usages to wait forever looks good. > > Just on the @bug, I assume this test is missing @bug 4286936 so best > to add that as otherwise it will look like the test was created for > JDK-8143100. You can then drop the reference to 8143100 from L133. Hi Alan, Thanks for reviewing, fixed as you suggested. new webrev: http://cr.openjdk.java.net/~mli/8143100/webrev.01/ Thank you -Hamlin > > -Alan. From huaming.li at oracle.com Fri Jan 15 10:18:11 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 15 Jan 2016 18:18:11 +0800 Subject: RFR: 8037360: java/nio/channels/SocketChannel/Connect.java fails intermittently Message-ID: <5698C763.7090000@oracle.com> Hi everyone, Would you please help to review the fix for bug https://bugs.openjdk.java.net/browse/JDK-8037360, java/nio/channels/SocketChannel/Connect.java fails intermittently. webrev: http://cr.openjdk.java.net/~mli/8037360/webrev.00/ Thank you -Hamlin From huaming.li at oracle.com Fri Jan 15 10:57:34 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 15 Jan 2016 18:57:34 +0800 Subject: RFR: 8145663: java/nio/channels/SocketChannel/CloseDuringWrite.java timed out intermittently Message-ID: <5698D09E.3030406@oracle.com> Hi everyone, Would you please help to review the fix for bug https://bugs.openjdk.java.net/browse/JDK-8145663, java/nio/channels/SocketChannel/CloseDuringWrite.java timed out intermittently. webrev: http://cr.openjdk.java.net/~mli/8145663/webrev.00/ Thank you -Hamlin From Alan.Bateman at oracle.com Fri Jan 15 11:00:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Jan 2016 11:00:45 +0000 Subject: RFR: 8143100: java/nio/channels/ServerSocketChannel/Basic.java fails intermittently In-Reply-To: <5698BFB8.2070001@oracle.com> References: <569886DC.5080400@oracle.com> <5698B7AD.3050300@oracle.com> <5698BFB8.2070001@oracle.com> Message-ID: <5698D15D.2020407@oracle.com> On 15/01/2016 09:45, Hamlin Li wrote: > > > Hi Alan, > Thanks for reviewing, fixed as you suggested. > new webrev: http://cr.openjdk.java.net/~mli/8143100/webrev.01/ This looks okay to me. I've pushed it to jdk9/dev for you. -Alan From Alan.Bateman at oracle.com Fri Jan 15 11:11:31 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Jan 2016 11:11:31 +0000 Subject: RFR: 8141595: java/nio/channels/ServerSocketChannel/NonBlockingAccept.java fails intermittently In-Reply-To: <5698BDA4.2000509@oracle.com> References: <569883A0.40102@oracle.com> <5698B5A1.1070405@oracle.com> <5698BDA4.2000509@oracle.com> Message-ID: <5698D3E3.40408@oracle.com> On 15/01/2016 09:36, Hamlin Li wrote: > : > > Yes, the root cause is sleep time is not sufficient on busy systems. > And I follow your suggestion to fix the code style and line length, > and let jtreg to timeout the test case. > new webrev: http://cr.openjdk.java.net/~mli/8141595/webrev.01/ This looks okay, just a few nits like continue and loop counters aren't needed, the comment doesn't need to 8141595 and we usually put a space in "catch(". These are simple to fix so I can do that and get the test pushed for you. -Alan From Alan.Bateman at oracle.com Fri Jan 15 11:18:20 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Jan 2016 11:18:20 +0000 Subject: RFR: 8037360: java/nio/channels/SocketChannel/Connect.java fails intermittently In-Reply-To: <5698C763.7090000@oracle.com> References: <5698C763.7090000@oracle.com> Message-ID: <5698D57C.9000101@oracle.com> On 15/01/2016 10:18, Hamlin Li wrote: > Hi everyone, > > Would you please help to review the fix for bug > https://bugs.openjdk.java.net/browse/JDK-8037360, > java/nio/channels/SocketChannel/Connect.java fails intermittently. > webrev: http://cr.openjdk.java.net/~mli/8037360/webrev.00/ Can you summarize what the issue is here? The server is binding to an ephermeral port here and it shouldn't be necessary to touch SO_REUSEADDR. -Alan From huaming.li at oracle.com Fri Jan 15 11:38:31 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 15 Jan 2016 19:38:31 +0800 Subject: RFR: 8085792: java/nio/channels/Selector/SelectAfterRead.java timeout intermittently Message-ID: <5698DA37.7030003@oracle.com> Hi everyone, Would you please help to review the fix for bug https://bugs.openjdk.java.net/browse/JDK-8085792, java/nio/channels/Selector/SelectAfterRead.java timeout intermittently. webrev: http://cr.openjdk.java.net/~mli/8085792/webrev.00/ Thank you -Hamlin From huaming.li at oracle.com Fri Jan 15 12:05:20 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 15 Jan 2016 20:05:20 +0800 Subject: RFR: 8037360: java/nio/channels/SocketChannel/Connect.java fails intermittently In-Reply-To: <5698D57C.9000101@oracle.com> References: <5698C763.7090000@oracle.com> <5698D57C.9000101@oracle.com> Message-ID: <5698E080.6020609@oracle.com> On 2016/1/15 19:18, Alan Bateman wrote: > On 15/01/2016 10:18, Hamlin Li wrote: >> Hi everyone, >> >> Would you please help to review the fix for bug >> https://bugs.openjdk.java.net/browse/JDK-8037360, >> java/nio/channels/SocketChannel/Connect.java fails intermittently. >> webrev: http://cr.openjdk.java.net/~mli/8037360/webrev.00/ > Can you summarize what the issue is here? The server is binding to an > ephermeral port here and it shouldn't be necessary to touch SO_REUSEADDR. Hi Alan, One possible root cause I can figure out is a race condition which looks like below : step1, RefusingServer bind to port A, then server is closed step2, some other program reuse the port A, and listen on port A. step3, in test1(...) client connect to port A, and finish writing successfully(which is not expected.) step4, throw new Exception("Refused connection throws no exception"). in step2, we should not allow other program to listen on port A in short time(in when socket is in TIME_WAIT status), so use SO_REUSEADDR to disable socket reuse explicitly, I'm not sure what's the default behavior, just do some defensive fix, hope it could help. Thank you -Hamlin > > -Alan From tprintezis at twitter.com Tue Jan 12 15:19:25 2016 From: tprintezis at twitter.com (Tony Printezis) Date: Tue, 12 Jan 2016 10:19:25 -0500 Subject: sun.nio.ch.Util: Don't cache an unlimited amount of memory In-Reply-To: References: <56824FA1.5050808@oracle.com> <5683EFE3.9080501@oracle.com> <568ED08B.4060400@oracle.com> Message-ID: Alan and all, Here?s the first version of this patch (along with a test): http://cr.openjdk.java.net/~tonyp/nio-max-buffer-size/webrev.1/ A few points: * I called the property java.nio.MaxCachedTempBufferSize. I?m happy to call it something else if you don?t like the name. * I was not sure what the best way to read the property is. I took the same approach used for MaxDirectMemorySize and I read it from the saved properties on sun.misc.VM. Feel free to suggest a more appropriate alternative. * I have compiled and run the test and it works as expected. But I haven?t run it within jtreg, though, given that I need to upgrade my jtreg to a more recent version. I?ll do that when I get a chance. But some tweaking on the metadata on the top comment might be required? Regards, Tony On January 8, 2016 at 5:53:51 PM, Tony Printezis (tprintezis at twitter.com) wrote: Alan, I?m OK with using a property if that?s what?s more appropriate? Yes, I agree that introducing a limit on the size of potentially cached buffers will be the simplest and will have fewer unexpected issues (like what you described). I can?t think of any other reasonable alternatives. I?ll port the change to JDK 9 (our current release, and all our patches, are on JDK 8 right now) and I?ll post the diffs for feedback. BTW, don?t know who?s the mod for the nio-dev list... any chance they can approve my previous message (and maybe this one)? Regards, Tony On January 7, 2016 at 3:54:11 PM, Alan Bateman (alan.bateman at oracle.com) wrote: On 06/01/2016 22:26, Tony Printezis wrote: Alan and Evan, First, apologies I?m a bit late on this thread. As Evan mentioned, the fix I implemented was to introduce a parameter that sets the limit for the size of buffers added to the cache and never cache a buffer whose size is over this limit. I followed the way the -XX:MaxDirectMemorySize=? cmd line arg was implemented and added a -XX:MaxCachedTempBufferSize=? cmd line arg to HotSpot and pass that value via a property to Java (that?s what?s done for MaxDirectMemorySize). We could leave it as a property, as Alan suggested (no changes to HotSpot); I have no strong opinion either way. I just thought that it was best to be consistent with how MaxDirectMemorySize is set. With MaxCachedTempBufferSize a user can implicitly set the overall memory used up by cached buffers (it will also depend on how many buffers per thread are cached, one in our case, and the number of threads that do operations that need to cache buffers). An alternative approach I considered was to introduce a parameter that sets a max for the total memory taken up by all cached buffers. This will be a bit more user-friendly (the user will know exactly the max overhead of those buffers). However, it?d also require synchronization between threads when replacing cached buffers (as we?d have to keep track of the total size of all cached buffers across all threads) and I wanted to avoid that. It also has a very bad pathological edge case: a thread might cache a very large buffer that?s just under the total limit and prevent all other threads from caching anything. Any other alternatives that we could consider here? Alan, what would you like me to do next? Should I maybe create a CR and post the diffs I have so you guys can take a look? On -XX vs. a system property then one thing to say is that this buffer cache is specific to NIO channels. So that will probably influence the property or VM option name and maybe it would better to not tie HotSpot to specific areas like this. On the value then the simplest is to set the maximum size of a buffer to cache. Scatter/gather I/O is relatively rare so this means that most of the time then only one buffer will be cached per thread. I see your point that a global limit would be more user-friendly but it could always lead to unpredictable performance when the thread count is high and the global limit is reached. In that scenario it would degrade to a malloc + free per I/O operation for threads that are unlucky enough not to have a cached buffer. As regards moving forward then a patch or webrev on cr.openjdk.java.net would be best. I assume you still have access to JIRA and can push webrevs to cr. -Alan ----- 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 tprintezis at twitter.com Tue Jan 12 15:45:21 2016 From: tprintezis at twitter.com (Tony Printezis) Date: Tue, 12 Jan 2016 10:45:21 -0500 Subject: sun.nio.ch.Util: Don't cache an unlimited amount of memory In-Reply-To: References: <56824FA1.5050808@oracle.com> <5683EFE3.9080501@oracle.com> <568ED08B.4060400@oracle.com> Message-ID: PS If you?re happy with this change on principle I can go ahead and create a CR for it (unless there already is one?). Should the CR be under core-libs / java.nio? On January 12, 2016 at 10:19:28 AM, Tony Printezis (tprintezis at twitter.com) wrote: Alan and all, Here?s the first version of this patch (along with a test): http://cr.openjdk.java.net/~tonyp/nio-max-buffer-size/webrev.1/ A few points: * I called the property java.nio.MaxCachedTempBufferSize. I?m happy to call it something else if you don?t like the name. * I was not sure what the best way to read the property is. I took the same approach used for MaxDirectMemorySize and I read it from the saved properties on sun.misc.VM. Feel free to suggest a more appropriate alternative. * I have compiled and run the test and it works as expected. But I haven?t run it within jtreg, though, given that I need to upgrade my jtreg to a more recent version. I?ll do that when I get a chance. But some tweaking on the metadata on the top comment might be required? Regards, Tony On January 8, 2016 at 5:53:51 PM, Tony Printezis (tprintezis at twitter.com) wrote: Alan, I?m OK with using a property if that?s what?s more appropriate? Yes, I agree that introducing a limit on the size of potentially cached buffers will be the simplest and will have fewer unexpected issues (like what you described). I can?t think of any other reasonable alternatives. I?ll port the change to JDK 9 (our current release, and all our patches, are on JDK 8 right now) and I?ll post the diffs for feedback. BTW, don?t know who?s the mod for the nio-dev list... any chance they can approve my previous message (and maybe this one)? Regards, Tony On January 7, 2016 at 3:54:11 PM, Alan Bateman (alan.bateman at oracle.com) wrote: On 06/01/2016 22:26, Tony Printezis wrote: Alan and Evan, First, apologies I?m a bit late on this thread. As Evan mentioned, the fix I implemented was to introduce a parameter that sets the limit for the size of buffers added to the cache and never cache a buffer whose size is over this limit. I followed the way the -XX:MaxDirectMemorySize=? cmd line arg was implemented and added a -XX:MaxCachedTempBufferSize=? cmd line arg to HotSpot and pass that value via a property to Java (that?s what?s done for MaxDirectMemorySize). We could leave it as a property, as Alan suggested (no changes to HotSpot); I have no strong opinion either way. I just thought that it was best to be consistent with how MaxDirectMemorySize is set. With MaxCachedTempBufferSize a user can implicitly set the overall memory used up by cached buffers (it will also depend on how many buffers per thread are cached, one in our case, and the number of threads that do operations that need to cache buffers). An alternative approach I considered was to introduce a parameter that sets a max for the total memory taken up by all cached buffers. This will be a bit more user-friendly (the user will know exactly the max overhead of those buffers). However, it?d also require synchronization between threads when replacing cached buffers (as we?d have to keep track of the total size of all cached buffers across all threads) and I wanted to avoid that. It also has a very bad pathological edge case: a thread might cache a very large buffer that?s just under the total limit and prevent all other threads from caching anything. Any other alternatives that we could consider here? Alan, what would you like me to do next? Should I maybe create a CR and post the diffs I have so you guys can take a look? On -XX vs. a system property then one thing to say is that this buffer cache is specific to NIO channels. So that will probably influence the property or VM option name and maybe it would better to not tie HotSpot to specific areas like this. On the value then the simplest is to set the maximum size of a buffer to cache. Scatter/gather I/O is relatively rare so this means that most of the time then only one buffer will be cached per thread. I see your point that a global limit would be more user-friendly but it could always lead to unpredictable performance when the thread count is high and the global limit is reached. In that scenario it would degrade to a malloc + free per I/O operation for threads that are unlucky enough not to have a cached buffer. As regards moving forward then a patch or webrev on cr.openjdk.java.net would be best. I assume you still have access to JIRA and can push webrevs to cr. -Alan ----- 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 ----- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Jan 15 13:09:33 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Jan 2016 13:09:33 +0000 Subject: sun.nio.ch.Util: Don't cache an unlimited amount of memory In-Reply-To: References: <56824FA1.5050808@oracle.com> <5683EFE3.9080501@oracle.com> <568ED08B.4060400@oracle.com> Message-ID: <5698EF8D.3090806@oracle.com> On 12/01/2016 15:19, Tony Printezis wrote: > Alan and all, > > Here?s the first version of this patch (along with a test): > > http://cr.openjdk.java.net/~tonyp/nio-max-buffer-size/webrev.1/ > > > A few points: > > * I called the property java.nio.MaxCachedTempBufferSize. I?m happy to > call it something else if you don?t like the name. > > * I was not sure what the best way to read the property is. I took the > same approach used for MaxDirectMemorySize and I read it from the > saved properties on sun.misc.VM. Feel free to suggest a more > appropriate alternative. > > * I have compiled and run the test and it works as expected. But I > haven?t run it within jtreg, though, given that I need to upgrade my > jtreg to a more recent version. I?ll do that when I get a chance. But > some tweaking on the metadata on the top comment might be required? > > The property is JDK-specific so better to use jdk.* as prefix. A name such as jdk.nio.maxCachedBufferSize works for me. If it's property only then we'll need to get the value from System.getProperty and that will need to be done in a privileged block. It would be good if maxCachedBufferSize could be final. Also as this is a static then the isTempBufferTooLarge methods could be static too. That would be arguably cleaner anyway as the limit is not specific to the thread's buffer cache. It would also mean that getTemporaryDirectBuffer and offeXXXTemporaryDirectBuffer can just check the size without needing the thread's cache. The test will need a bit of clean-up. I assume you will add a copyright header. It would be good to use try-with-resources as a disk full or other issue will leave the file open. There are really long (>200 chars) lines that are really hard to look at without scrolling so it would be good to get those down to sane lengths that would allow for future side-by-side diffs. Otherwise the approach seems okay to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tprintezis at twitter.com Fri Jan 15 16:06:16 2016 From: tprintezis at twitter.com (Tony Printezis) Date: Fri, 15 Jan 2016 11:06:16 -0500 Subject: sun.nio.ch.Util: Don't cache an unlimited amount of memory In-Reply-To: <5698EF8D.3090806@oracle.com> References: <56824FA1.5050808@oracle.com> <5683EFE3.9080501@oracle.com> <568ED08B.4060400@oracle.com> <5698EF8D.3090806@oracle.com> Message-ID: Hi Alan, Thanks for the comments!? On January 15, 2016 at 8:09:22 AM, Alan Bateman (alan.bateman at oracle.com) wrote: On 12/01/2016 15:19, Tony Printezis wrote: Alan and all, Here?s the first version of this patch (along with a test): http://cr.openjdk.java.net/~tonyp/nio-max-buffer-size/webrev.1/ A few points: * I called the property java.nio.MaxCachedTempBufferSize. I?m happy to call it something else if you don?t like the name. * I was not sure what the best way to read the property is. I took the same approach used for MaxDirectMemorySize and I read it from the saved properties on sun.misc.VM. Feel free to suggest a more appropriate alternative. * I have compiled and run the test and it works as expected. But I haven?t run it within jtreg, though, given that I need to upgrade my jtreg to a more recent version. I?ll do that when I get a chance. But some tweaking on the metadata on the top comment might be required? The property is JDK-specific so better to use jdk.* as prefix. A name such as jdk.nio.maxCachedBufferSize works for me.? Sounds good. I?ll change it (and update any field / method names to drop the ?Temp?). If it's property only then we'll need to get the value from System.getProperty and that will need to be done in a privileged block. OK. So I should drop the approach of getting it from the saved properties? It would be good if maxCachedBufferSize could be final.? Done. Also as this is a static then the isTempBufferTooLarge methods could be static too. That would be arguably cleaner anyway as the limit is not specific to the thread's buffer cache. It would also mean that getTemporaryDirectBuffer and offeXXXTemporaryDirectBuffer can just check the size without needing the thread's cache. I?m OK with this change. In fact, this is how it?s implemented in our codebase. However, I thought that maybe in the future it might be helpful to allow different threads to have a different max? But maybe we could do that change if we ever need to? The test will need a bit of clean-up. I assume you will add a copyright header. Yep, I forgot about it. :-) Done. ? It would be good to use try-with-resources as a disk full or other issue will leave the file open.? Done. Should I also delete each temporary file that?s created? There are really long (>200 chars) lines that are really hard to look at without scrolling so it would be good to get those down to sane lengths that would allow for future side-by-side diffs. Fixed the long lines... Should I also move the test to the test/sun/nio/ch dir (it?s in test/java/nio/channels)? Incidentally, I did run the test within jtreg and it worked as expected. I?ll create a JIRA issue for this and post an updated webrev shortly. Tony Otherwise the approach seems okay to me. -Alan ----- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tprintezis at twitter.com Fri Jan 15 16:54:02 2016 From: tprintezis at twitter.com (Tony Printezis) Date: Fri, 15 Jan 2016 11:54:02 -0500 Subject: RFR: 8147468: Allow users to bound the size of buffers cached in the per-thread buffer caches Message-ID: (I?m starting a new thread so that it?s obvious this is a code review request) Second version of this change, addressing Alan?s comments (see previous e-mail exchange): http://cr.openjdk.java.net/~tonyp/nio-max-buffer-size/webrev.2/ ----- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.warburton at gmail.com Sat Jan 16 11:14:43 2016 From: richard.warburton at gmail.com (Richard Warburton) Date: Sat, 16 Jan 2016 13:14:43 +0200 Subject: Callback Based Selectors Message-ID: Hi gents, I've prototyped a callback based addition to the NIO Selector, which I've previously talked through a bit with Alan Bateman. The goal of the callback based selector is to avoid the current pattern of calling select/selectNow on a Nio selector and then having to iterate over a hashmap produced. This pattern being quite object allocation heavy for a critical path and also involving obtaining and releasing multiple locks. I'd like to propose that the following patch, which adds the ability to perform a select on a Selector that takes a callback handler. http://cr.openjdk.java.net/~rwarburton/select-now-4/ I'm happy to iterate on the patch a bit based upon people's feedback and discuss any potential concerns or issues that you may have with the patch. Looking forward to hearing your feedback. regards, Richard Warburton http://insightfullogic.com @RichardWarburto -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Jan 17 08:11:24 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 17 Jan 2016 08:11:24 +0000 Subject: RFR: 8085792: java/nio/channels/Selector/SelectAfterRead.java timeout intermittently In-Reply-To: <5698DA37.7030003@oracle.com> References: <5698DA37.7030003@oracle.com> Message-ID: <569B4CAC.8040202@oracle.com> On 15/01/2016 11:38, Hamlin Li wrote: > Hi everyone, > > Would you please help to review the fix for bug > https://bugs.openjdk.java.net/browse/JDK-8085792, > java/nio/channels/Selector/SelectAfterRead.java timeout intermittently. > webrev: http://cr.openjdk.java.net/~mli/8085792/webrev.00/ I think this issue needs further analysis before deciding if there are any changes needed. I suspect are looking at Solaris specific behavior that arises when we are out of file descriptors or TCP connections. I've cc'ed Michael McMahon as remember that he looked into issues specific to Solaris some time ago where accept appears to hang when resources are exhaused. Michael - do you remember this issue? Are the details written up in any other JIRA? -Alan From Alan.Bateman at oracle.com Sun Jan 17 08:43:37 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 17 Jan 2016 08:43:37 +0000 Subject: RFR: 8146213, 8133093: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failed intermittently with Connection refused and Accept did not time out In-Reply-To: <5698AF0E.7040302@oracle.com> References: <569716BE.2080103@oracle.com> <5698A37A.9010103@oracle.com> <5698AF0E.7040302@oracle.com> Message-ID: <569B5439.2010702@oracle.com> On 15/01/2016 08:34, Hamlin Li wrote: > : > > Hi Alan, > Thanks for reviewing, please check new webrev : > http://cr.openjdk.java.net/~mli/8146213/webrev.02/. I think this is okay. As you point out, a client is not needed when testing that accept times out so no need to start it. I can push this for you today. As per the other issues, we should add include in the 4286936 in the @bug list as it looks like this test dates back to then. Also I assume the @key intermittent should be removed. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Jan 17 10:01:37 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 17 Jan 2016 10:01:37 +0000 Subject: RFR: 8145663: java/nio/channels/SocketChannel/CloseDuringWrite.java timed out intermittently In-Reply-To: <5698D09E.3030406@oracle.com> References: <5698D09E.3030406@oracle.com> Message-ID: <569B6681.6050202@oracle.com> On 15/01/2016 10:57, Hamlin Li wrote: > Hi everyone, > > Would you please help to review the fix for bug > https://bugs.openjdk.java.net/browse/JDK-8145663, > java/nio/channels/SocketChannel/CloseDuringWrite.java timed out > intermittently. > webrev: http://cr.openjdk.java.net/~mli/8145663/webrev.00/ I suspect this is the same issue as JDK-8133093 where we running this test on Solaris when resources are at exhaustion point. I hope Michael will jump in here too to summarize how accept behaves on Solaris when trying to get a loopback connection and the kernel is out of file descriptors or connections. One thing that would be useful is for these "same binary runs" is capture the netstat output so that we can see how many local connections are in timed wait. One other thing is to look at file descriptor usage after each test - I've done this in the past in other to track down tests that are leaking file descriptors as such leaks can accumulate in agent VM test runs and cause issues for tests that run much latter in the test run. -Alan From david.lloyd at redhat.com Mon Jan 18 16:00:42 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 18 Jan 2016 10:00:42 -0600 Subject: Callback Based Selectors In-Reply-To: References: Message-ID: <569D0C2A.9090409@redhat.com> On 01/16/2016 05:14 AM, Richard Warburton wrote: > Hi gents, > > I've prototyped a callback based addition to the NIO Selector, which > I've previously talked through a bit with Alan Bateman. The goal of the > callback based selector is to avoid the current pattern of calling > select/selectNow on a Nio selector and then having to iterate over a > hashmap produced. This pattern being quite object allocation heavy for a > critical path and also involving obtaining and releasing multiple locks. > I'd like to propose that the following patch, which adds the ability to > perform a select on a Selector that takes a callback handler. > > http://cr.openjdk.java.net/~rwarburton/select-now-4/ > > I'm happy to iterate on the patch a bit based upon people's feedback and > discuss any potential concerns or issues that you may have with the > patch. Looking forward to hearing your feedback. Hi Richard. Selector specifies a relatively extensive contract with respect to locking. It is not clear from the documentation of the new method what the behavior is with respect to the various selector locks. Looking at the code, it seems to sidestep locking altogether during the callback process, is that an accurate assessment? Also, any thoughts on compatibility implications in terms of existing Selector subclasses? I don't think such a thing is common, but the class is public and has an accessible constructor. The addition of the new abstract method could theoretically result in unexpected AbstractMethodErrors. -- - DML From Alan.Bateman at oracle.com Mon Jan 18 17:56:40 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 Jan 2016 17:56:40 +0000 Subject: Callback Based Selectors In-Reply-To: <569D0C2A.9090409@redhat.com> References: <569D0C2A.9090409@redhat.com> Message-ID: <569D2758.7040502@oracle.com> On 18/01/2016 16:00, David M. Lloyd wrote: > > Hi Richard. Selector specifies a relatively extensive contract with > respect to locking. It is not clear from the documentation of the new > method what the behavior is with respect to the various selector > locks. Looking at the code, it seems to sidestep locking altogether > during the callback process, is that an accurate assessment? > Right, this is a concern that I brought up with Richard when we originally chatted about this a long time back (I think at JavaOne 2014). I haven't had a chance yet to look at the current proposal but it would minimally need a big warning as it would be too easy to cause deadlocks and other issues when not used correctly. -Alan. From Alan.Bateman at oracle.com Tue Jan 19 12:10:06 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Jan 2016 12:10:06 +0000 Subject: RFR: 8147468: Allow users to bound the size of buffers cached in the per-thread buffer caches In-Reply-To: References: Message-ID: <569E279E.4010302@oracle.com> On 15/01/2016 16:54, Tony Printezis wrote: > (I?m starting a new thread so that it?s obvious this is a code review > request) Second version of this change, addressing Alan?s comments > (see previous e-mail exchange): > > http://cr.openjdk.java.net/~tonyp/nio-max-buffer-size/webrev.2/ > > > I think this mostly looks okay. I assume the property should be jdk.nio.maxCachedBufferSize so that the casing is consistent with other properties. As this will be documented/supported property then I'll need to get a CCC submitted. A few comments on the test: 1. The copyright headers needs to be the pure GPL header, we don't use the Classpath exception on tests. Also the date is duplicated. 2. Using BufferOverflowException when filling the buffer with random bytes is a bit icky, it could use while buffer.hasRemaining() instead. Alternatively random.nextBytes(buffer.array()) should do it in one-line. 3. If you want then you could create the FileChannel directly, the RandomAccessFile + getChannel is not needed. I think that's it. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lloyd at redhat.com Wed Jan 20 16:11:31 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 20 Jan 2016 10:11:31 -0600 Subject: Callback Based Selectors In-Reply-To: <569D2758.7040502@oracle.com> References: <569D0C2A.9090409@redhat.com> <569D2758.7040502@oracle.com> Message-ID: <569FB1B3.6050305@redhat.com> On 01/18/2016 11:56 AM, Alan Bateman wrote: > On 18/01/2016 16:00, David M. Lloyd wrote: >> >> Hi Richard. Selector specifies a relatively extensive contract with >> respect to locking. It is not clear from the documentation of the new >> method what the behavior is with respect to the various selector >> locks. Looking at the code, it seems to sidestep locking altogether >> during the callback process, is that an accurate assessment? >> > Right, this is a concern that I brought up with Richard when we > originally chatted about this a long time back (I think at JavaOne > 2014). I haven't had a chance yet to look at the current proposal but it > would minimally need a big warning as it would be too easy to cause > deadlocks and other issues when not used correctly. I want to clarify that this change looks like a great idea to me: a start to cleaning up the Selector API, which has some serious problems (especially in terms of concurrent access). But these questions do need to be answered. In the long term it seems important to have a Selector API (or Selector-equivalent API) in which interest ops can be concurrently added or modified completely locklessly (though I generally expect that "poking" the selector to wake up will always be necessary when any of this is modified from another thread while the selector is selecting). I think this API change might be a good first step, if it can be determined how the callback-signaled operations relate to the various key sets and their locks. -- - DML From tprintezis at twitter.com Thu Jan 21 16:34:39 2016 From: tprintezis at twitter.com (Tony Printezis) Date: Thu, 21 Jan 2016 14:34:39 -0200 Subject: RFR: 8147468: Allow users to bound the size of buffers cached in the per-thread buffer caches In-Reply-To: <569E279E.4010302@oracle.com> References: <569E279E.4010302@oracle.com> Message-ID: Alan, Thanks for the comments. Please take a look at: http://cr.openjdk.java.net/~tonyp/nio-max-buffer-size/webrev.3/ * changed jdk.nio.MaxCachedBufferSize to jdk.nio.maxCachedBufferSize * changed the copyright to the right (I hope!) version and put the right copyright dates * test now checks hasRemaining() instead of catching BufferOverflowException (I also had to change the buffer put to be done as bytes, instead of ints, given that ints are 4-byte aligned and the calculated buffer size was not) * I now create a FileChannel directly Tony On January 19, 2016 at 10:09:37 AM, Alan Bateman (alan.bateman at oracle.com) wrote: On 15/01/2016 16:54, Tony Printezis wrote: (I?m starting a new thread so that it?s obvious this is a code review request) Second version of this change, addressing Alan?s comments (see previous e-mail exchange): http://cr.openjdk.java.net/~tonyp/nio-max-buffer-size/webrev.2/ I think this mostly looks okay. I assume the property should be jdk.nio.maxCachedBufferSize so that the casing is consistent with other properties. As this will be documented/supported property then I'll need to get a CCC submitted. A few comments on the test: 1. The copyright headers needs to be the pure GPL header, we don't use the Classpath exception on tests. Also the date is duplicated. 2. Using BufferOverflowException when filling the buffer with random bytes is a bit icky, it could use while buffer.hasRemaining() instead. Alternatively random.nextBytes(buffer.array()) should do it in one-line. 3. If you want then you could create the FileChannel directly, the RandomAccessFile + getChannel is not needed. I think that's it. -Alan. ----- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Jan 22 13:35:21 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Jan 2016 13:35:21 +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> Message-ID: <56A23019.2010001@oracle.com> On 21/01/2016 16:34, Tony Printezis wrote: > Alan, > > Thanks for the comments. Please take a look at: > > http://cr.openjdk.java.net/~tonyp/nio-max-buffer-size/webrev.3/ > > > * changed jdk.nio.MaxCachedBufferSize to jdk.nio.maxCachedBufferSize > * changed the copyright to the right (I hope!) version and put the > right copyright dates > * test now checks hasRemaining() instead of catching > BufferOverflowException (I also had to change the buffer put to be > done as bytes, instead of ints, given that ints are 4-byte aligned and > the calculated buffer size was not) > * I now create a FileChannel directly > > Tony > Thanks Tony, this looks good to me. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tprintezis at twitter.com Fri Jan 22 14:27:19 2016 From: tprintezis at twitter.com (Tony Printezis) Date: Fri, 22 Jan 2016 12:27:19 -0200 Subject: RFR: 8147468: Allow users to bound the size of buffers cached in the per-thread buffer caches In-Reply-To: <56A23019.2010001@oracle.com> References: <569E279E.4010302@oracle.com> <56A23019.2010001@oracle.com> Message-ID: Alan, Great! What?s the next step? We need one more review? Tony On January 22, 2016 at 11:35:19 AM, Alan Bateman (alan.bateman at oracle.com) wrote: On 21/01/2016 16:34, Tony Printezis wrote: Alan, Thanks for the comments. Please take a look at: http://cr.openjdk.java.net/~tonyp/nio-max-buffer-size/webrev.3/ * changed jdk.nio.MaxCachedBufferSize to jdk.nio.maxCachedBufferSize * changed the copyright to the right (I hope!) version and put the right copyright dates * test now checks hasRemaining() instead of catching BufferOverflowException (I also had to change the buffer put to be done as bytes, instead of ints, given that ints are 4-byte aligned and the calculated buffer size was not) * I now create a FileChannel directly Tony Thanks Tony, this looks good to me. -Alan. ----- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Jan 22 16:12:18 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 22 Jan 2016 08:12:18 -0800 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> Message-ID: Tony, Alan?s review should suffice. While we?re at it however, I would like to point out a minor stylistic thing which is that a constant such as ?maxCachedBufferSize? is by convention normally named in CAPS such as MAX_CACHED_BUFFER_SIZE and placed at the top of the class as is done here with TEMP_BUF_POOL_SZE. Thanks, Brian On Jan 22, 2016, at 6:27 AM, Tony Printezis wrote: > Alan, > > Great! What?s the next step? We need one more review? > > Tony > > On January 22, 2016 at 11:35:19 AM, Alan Bateman (alan.bateman at oracle.com) wrote: > >> >> >> On 21/01/2016 16:34, Tony Printezis wrote: >>> Alan, >>> >>> Thanks for the comments. Please take a look at: >>> >>> http://cr.openjdk.java.net/~tonyp/nio-max-buffer-size/webrev.3/ >>> >>> * changed jdk.nio.MaxCachedBufferSize to jdk.nio.maxCachedBufferSize >>> * changed the copyright to the right (I hope!) version and put the right copyright dates >>> * test now checks hasRemaining() instead of catching BufferOverflowException (I also had to change the buffer put to be done as bytes, instead of ints, given that ints are 4-byte aligned and the calculated buffer size was not) >>> * I now create a FileChannel directly >>> >>> Tony >>> >> Thanks Tony, this looks good to me. >> >> -Alan. > ----- > > Tony Printezis | JVM/GC Engineer / VM Team | Twitter > > @TonyPrintezis > tprintezis at twitter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.warburton at gmail.com Fri Jan 22 17:19:39 2016 From: richard.warburton at gmail.com (Richard Warburton) Date: Fri, 22 Jan 2016 17:19:39 +0000 Subject: Callback Based Selectors In-Reply-To: <569D0C2A.9090409@redhat.com> References: <569D0C2A.9090409@redhat.com> Message-ID: Hi David, I've prototyped a callback based addition to the NIO Selector, which >> I've previously talked through a bit with Alan Bateman. The goal of the >> callback based selector is to avoid the current pattern of calling >> select/selectNow on a Nio selector and then having to iterate over a >> hashmap produced. This pattern being quite object allocation heavy for a >> critical path and also involving obtaining and releasing multiple locks. >> I'd like to propose that the following patch, which adds the ability to >> perform a select on a Selector that takes a callback handler. >> >> http://cr.openjdk.java.net/~rwarburton/select-now-4/ >> >> I'm happy to iterate on the patch a bit based upon people's feedback and >> discuss any potential concerns or issues that you may have with the >> patch. Looking forward to hearing your feedback. >> > > Hi Richard. Selector specifies a relatively extensive contract with > respect to locking. It is not clear from the documentation of the new > method what the behavior is with respect to the various selector locks. > Looking at the code, it seems to sidestep locking altogether during the > callback process, is that an accurate assessment? > Simple question, complex answer ;) Doing a select() or selectNow() involves 3 sets of locks. One of them is on the hashset for selection keys, one on a unmodifiable view over the keyset of said map and one is a lock that manages the platform specific implementation of the Selector. All 3 of these sets of locks are managed across all the different platform specific backends from the SelectorImpl class. The callback based selector retains the lock for the backend, but ignores the other two sets of locks because its not interested in the selection key set. My expected usecase is that people either call the callback based select or the other select implementations and not both on a single selector. I believe, but would love more code-review from Nio experts to validate my understanding, that the code I've written is threadsafe for multiple threads all calling the callback based selector. Does that make sense? Also, any thoughts on compatibility implications in terms of existing > Selector subclasses? I don't think such a thing is common, but the class > is public and has an accessible constructor. The addition of the new > abstract method could theoretically result in unexpected > AbstractMethodErrors. > Interesting point. It would be simple to add a dumb default implementation on the public class that delegates to the existing select()/selectNow() calls. When writing the patch I hypothesized that the only who maintain subclasses of Selector maintain their own JVMs and probably could be encouraged to port the patches. You're right though that its safer to provide a default implementation on the public class. I'll push an updated patch hopefully over the weekend. regards, Richard Warburton http://insightfullogic.com @RichardWarburto -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.warburton at gmail.com Fri Jan 22 17:22:34 2016 From: richard.warburton at gmail.com (Richard Warburton) Date: Fri, 22 Jan 2016 17:22:34 +0000 Subject: Callback Based Selectors In-Reply-To: <569FB1B3.6050305@redhat.com> References: <569D0C2A.9090409@redhat.com> <569D2758.7040502@oracle.com> <569FB1B3.6050305@redhat.com> Message-ID: Hi David, Hi Richard. Selector specifies a relatively extensive contract with >>> respect to locking. It is not clear from the documentation of the new >>> method what the behavior is with respect to the various selector >>> locks. Looking at the code, it seems to sidestep locking altogether >>> during the callback process, is that an accurate assessment? >>> >>> Right, this is a concern that I brought up with Richard when we >> originally chatted about this a long time back (I think at JavaOne >> 2014). I haven't had a chance yet to look at the current proposal but it >> would minimally need a big warning as it would be too easy to cause >> deadlocks and other issues when not used correctly. >> > > I want to clarify that this change looks like a great idea to me: a start > to cleaning up the Selector API, which has some serious problems > (especially in terms of concurrent access). But these questions do need to > be answered. > Thanks, the feedback is most appreciated. In the long term it seems important to have a Selector API (or > Selector-equivalent API) in which interest ops can be concurrently added or > modified completely locklessly (though I generally expect that "poking" the > selector to wake up will always be necessary when any of this is modified > from another thread while the selector is selecting). I think this API > change might be a good first step, if it can be determined how the > callback-signaled operations relate to the various key sets and their locks. > I agree that lockfree modification would be nice. At the moment the close lock in the selector implementations looks like it exists to protect a single boolean variable ie, could just be a volatile. This is perhaps another step in that direction, but feels like it should be kept as a separate patch. regards, Richard Warburton http://insightfullogic.com @RichardWarburto -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Jan 23 15:32:57 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Jan 2016 15:32:57 +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> Message-ID: <56A39D29.10509@oracle.com> On 22/01/2016 16:12, Brian Burkhalter wrote: > > While we?re at it however, I would like to point out a minor stylistic > thing which is that a constant such as ?maxCachedBufferSize? is by > convention normally named in CAPS such as MAX_CACHED_BUFFER_SIZE and > placed at the top of the class as is done here with TEMP_BUF_POOL_SZE. > Good point, it would be nice to make this consistent before pushing this change. -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tprintezis at twitter.com Sat Jan 23 15:49:28 2016 From: tprintezis at twitter.com (Tony Printezis) Date: Sat, 23 Jan 2016 13:49:28 -0200 Subject: RFR: 8147468: Allow users to bound the size of buffers cached in the per-thread buffer caches In-Reply-To: <56A39D29.10509@oracle.com> References: <569E279E.4010302@oracle.com> <56A23019.2010001@oracle.com> <56A39D29.10509@oracle.com> Message-ID: Alan and Brian, Thanks. I?ll fix this and upload an updated webrev on Monday. Regards, Tony On January 23, 2016 at 1:32:52 PM, Alan Bateman (alan.bateman at oracle.com) wrote: On 22/01/2016 16:12, Brian Burkhalter wrote: While we?re at it however, I would like to point out a minor stylistic thing which is that a constant such as ?maxCachedBufferSize? is by convention normally named in CAPS such as MAX_CACHED_BUFFER_SIZE and placed at the top of the class as is done here with TEMP_BUF_POOL_SZE. Good point, it would be nice to make this consistent before pushing this change. -Alan. ----- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tprintezis at twitter.com Mon Jan 25 18:53:00 2016 From: tprintezis at twitter.com (Tony Printezis) Date: Mon, 25 Jan 2016 13:53:00 -0500 Subject: RFR: 8147468: Allow users to bound the size of buffers cached in the per-thread buffer caches In-Reply-To: <56A39D29.10509@oracle.com> References: <569E279E.4010302@oracle.com> <56A23019.2010001@oracle.com> <56A39D29.10509@oracle.com> <56A39D29.10509@oracle.com> Message-ID: Alan and Brian, webrev with this fix here: http://cr.openjdk.java.net/~tonyp/nio-max-buffer-size/webrev.4/ I also reduced the number of iterations in the test from 20,000 to 10,000 to cut down the time it takes to run the test. Hope that?s OK. Tony On January 23, 2016 at 10:32:52 AM, Alan Bateman (alan.bateman at oracle.com) wrote: On 22/01/2016 16:12, Brian Burkhalter wrote: While we?re at it however, I would like to point out a minor stylistic thing which is that a constant such as ?maxCachedBufferSize? is by convention normally named in CAPS such as MAX_CACHED_BUFFER_SIZE and placed at the top of the class as is done here with TEMP_BUF_POOL_SZE. Good point, it would be nice to make this consistent before pushing this change. -Alan. ----- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.vidstedt at oracle.com Tue Jan 26 04:57:09 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 25 Jan 2016 20:57:09 -0800 Subject: RFR JDK-8141491: Unaligned memory access in Bits.c In-Reply-To: <565628F5.2080801@oracle.com> References: <56560F32.6040300@oracle.com> <565628F5.2080801@oracle.com> Message-ID: <56A6FCA5.7040808@oracle.com> I've finally found some time to return to this and have a new version of the patch which looks more promising: http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.02/webrev/ This uses memcpy to read/write the native data and the preliminary benchmark numbers on linux/x64 shows the expected performance. I'll work on verifying that it doesn't impact other platforms negatively over the next days/weeks. Btw, I also played around with implementing it in pure Java, but there are some issues getting C2 to correctly vectorize the loop given the native data accesses, so the native code seems to be needed for now. Cheers, Mikael On 2015-11-25 13:32, Mikael Vidstedt wrote: > > Have you looked anything at the performance of the generated code? As > you may have seen I was playing around with an alternative > implementation[1] which has the benefit of being pure C++ without > compiler specific hints. That said, when I did some initial > benchmarking of that it did seem like the performance impact was > significant. I didn't have time to look at more in detail why, and > will not have time to return to that until late next week earliest. It > would be interesting to understand what type of performance you see > with your patch. > > Cheers, > Mikael > > > [1] > http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.01/webrev/jdk.patch > > On 2015-11-25 11:42, Coleen Phillimore wrote: >> Sending to core-libs mailing list. >> >> On 11/25/15 2:19 PM, Alexander Smundak wrote: >>> Please take a look at >>> http://cr.openjdk.java.net/~asmundak/8141491/jdk/webrev.00 >>> that fixes the problem. >>> >>> It utilizes the ability of some (GCC and Clang) to declare data >>> alignment explicitly. >>> I have verified it works on x86_64 Linux by running >>> jdk/test/java/nio/Buffer/Basic.java test >>> >>> I need a sponsor. >>> >>> Sasha >> > From Alan.Bateman at oracle.com Tue Jan 26 12:28:02 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Jan 2016 12:28:02 +0000 Subject: RFR JDK-8141491: Unaligned memory access in Bits.c In-Reply-To: <56A6FCA5.7040808@oracle.com> References: <56560F32.6040300@oracle.com> <565628F5.2080801@oracle.com> <56A6FCA5.7040808@oracle.com> Message-ID: <56A76652.5090500@oracle.com> On 26/01/2016 04:57, Mikael Vidstedt wrote: > > I've finally found some time to return to this and have a new version > of the patch which looks more promising: > > http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.02/webrev/ > > This uses memcpy to read/write the native data and the preliminary > benchmark numbers on linux/x64 shows the expected performance. I'll > work on verifying that it doesn't impact other platforms negatively > over the next days/weeks. > > Btw, I also played around with implementing it in pure Java, but there > are some issues getting C2 to correctly vectorize the loop given the > native data accesses, so the native code seems to be needed for now. This looks good and maybe it was a good thing that the compiler upgrade ran into this. We eliminated most of the native methods in this area a few years ago but had to leave the byte swapping methods. It would be good to eliminate those some day. -Alan From Alan.Bateman at oracle.com Tue Jan 26 12:29:23 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Jan 2016 12:29:23 +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> <56A39D29.10509@oracle.com> Message-ID: <56A766A3.9070406@oracle.com> On 25/01/2016 18:53, Tony Printezis wrote: > Alan and Brian, > > webrev with this fix here: > > http://cr.openjdk.java.net/~tonyp/nio-max-buffer-size/webrev.4/ > > > I also reduced the number of iterations in the test from 20,000 to > 10,000 to cut down the time it takes to run the test. Hope that?s OK. > > Yes, this looks fine, I assume you still have committer rights and can push this to jdk9/dev (you don't need a sponsor, right?). -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tprintezis at twitter.com Tue Jan 26 14:21:17 2016 From: tprintezis at twitter.com (Tony Printezis) Date: Tue, 26 Jan 2016 09:21:17 -0500 Subject: RFR: 8147468: Allow users to bound the size of buffers cached in the per-thread buffer caches In-Reply-To: <56A766A3.9070406@oracle.com> References: <569E279E.4010302@oracle.com> <56A23019.2010001@oracle.com> <56A39D29.10509@oracle.com> <56A39D29.10509@oracle.com> <56A766A3.9070406@oracle.com> Message-ID: Alan, I?ve only contributed to HotSpot since I?ve been at Twitter and I always had to have a sponsor for that in order to get it through JPRT. But, yes, I should still be a reviewer. Is the process for pushing to the libraries different? Tony On January 26, 2016 at 7:29:06 AM, Alan Bateman (alan.bateman at oracle.com) wrote: On 25/01/2016 18:53, Tony Printezis wrote: Alan and Brian, webrev with this fix here: http://cr.openjdk.java.net/~tonyp/nio-max-buffer-size/webrev.4/ I also reduced the number of iterations in the test from 20,000 to 10,000 to cut down the time it takes to run the test. Hope that?s OK. Yes, this looks fine, I assume you still have committer rights and can push this to jdk9/dev (you don't need a sponsor, right?). -Alan. ----- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Jan 26 16:13:06 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 26 Jan 2016 08:13:06 -0800 Subject: RFR JDK-8141491: Unaligned memory access in Bits.c In-Reply-To: <56A76652.5090500@oracle.com> References: <56560F32.6040300@oracle.com> <565628F5.2080801@oracle.com> <56A6FCA5.7040808@oracle.com> <56A76652.5090500@oracle.com> Message-ID: <56A79B12.7050803@oracle.com> On 1/26/16 4:28 AM, Alan Bateman wrote: > > On 26/01/2016 04:57, Mikael Vidstedt wrote: >> >> I've finally found some time to return to this and have a new version >> of the patch which looks more promising: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.02/webrev/ >> >> This uses memcpy to read/write the native data and the preliminary >> benchmark numbers on linux/x64 shows the expected performance. I'll >> work on verifying that it doesn't impact other platforms negatively >> over the next days/weeks. >> >> Btw, I also played around with implementing it in pure Java, but >> there are some issues getting C2 to correctly vectorize the loop >> given the native data accesses, so the native code seems to be needed >> for now. > This looks good and maybe it was a good thing that the compiler > upgrade ran into this. We eliminated most of the native methods in > this area a few years ago but had to leave the byte swapping methods. > It would be good to eliminate those some day. I concur that this looks OK. Don't forget to update the latest copyright year to 2016. Thanks, Brian From martinrb at google.com Tue Jan 26 17:58:57 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 26 Jan 2016 09:58:57 -0800 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> Message-ID: You can check your superpowers at the openjdk census. http://openjdk.java.net/census#tonyp says you haven't lost any. Outside of hotspot, there is no requirement for JPRT runs, so you can commit directly! To the jdk9-dev forest. I use mq to manage my patches. On Tue, Jan 26, 2016 at 6:21 AM, Tony Printezis wrote: > Alan, > > I?ve only contributed to HotSpot since I?ve been at Twitter and I always had > to have a sponsor for that in order to get it through JPRT. But, yes, I > should still be a reviewer. Is the process for pushing to the libraries > different? > > Tony > > On January 26, 2016 at 7:29:06 AM, Alan Bateman (alan.bateman at oracle.com) > wrote: > > > > On 25/01/2016 18:53, Tony Printezis wrote: > > Alan and Brian, > > webrev with this fix here: > > http://cr.openjdk.java.net/~tonyp/nio-max-buffer-size/webrev.4/ > > I also reduced the number of iterations in the test from 20,000 to 10,000 to > cut down the time it takes to run the test. Hope that?s OK. > > > Yes, this looks fine, I assume you still have committer rights and can push > this to jdk9/dev (you don't need a sponsor, right?). > > -Alan. > > ----- > > Tony Printezis | JVM/GC Engineer / VM Team | Twitter > > @TonyPrintezis > tprintezis at twitter.com > From john.r.rose at oracle.com Tue Jan 26 18:32:56 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 26 Jan 2016 10:32:56 -0800 Subject: RFR JDK-8141491: Unaligned memory access in Bits.c In-Reply-To: <56A736B7.4020601@redhat.com> References: <56560F32.6040300@oracle.com> <565628F5.2080801@oracle.com> <56A6FCA5.7040808@oracle.com> <56A736B7.4020601@redhat.com> Message-ID: <8D4B5D84-FF89-461E-93B2-7FB2E56F9741@oracle.com> On Jan 26, 2016, at 1:04 AM, Andrew Haley wrote: > > I agree that memcpy is the right thing to use. It's portable and is > inlined well on production-quality C compilers. But it is not strong enough to uphold the Java memory model, because it is allows to copy byte-wise, which can tear shorts, ints, or longs, creating illegal race states. So we try to avoid memcpy when we can. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Jan 26 19:01:23 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 26 Jan 2016 11:01:23 -0800 Subject: JDK 9 RFR of 8148121: (fs) Typo in API , FileOwnerAttributeView.getOwner() and FileOwnerAttributeView.setOwner() Message-ID: <56A7C283.5080501@oracle.com> Please review this simple doc fix: Issue: https://bugs.openjdk.java.net/browse/JDK-8148121 Patch: +++ b/src/java.base/share/classes/java/nio/file/attribute/FileOwnerAttributeView.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2007, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2007, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -59,7 +59,7 @@ /** * Read the file owner. * - *

It it implementation specific if the file owner can be a {@link + *

It is implementation specific if the file owner can be a {@link * GroupPrincipal group}. * * @return the file owner @@ -78,7 +78,7 @@ /** * Updates the file owner. * - *

It it implementation specific if the file owner can be a {@link + *

It is implementation specific if the file owner can be a {@link Thanks, -- Brian From xueming.shen at oracle.com Tue Jan 26 19:07:18 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 26 Jan 2016 11:07:18 -0800 Subject: JDK 9 RFR of 8148121: (fs) Typo in API , FileOwnerAttributeView.getOwner() and FileOwnerAttributeView.setOwner() In-Reply-To: <56A7C283.5080501@oracle.com> References: <56A7C283.5080501@oracle.com> Message-ID: <56A7C3E6.2090808@oracle.com> looks good. On 01/26/2016 11:01 AM, Brian Burkhalter wrote: > Please review this simple doc fix: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8148121 > Patch: > > +++ b/src/java.base/share/classes/java/nio/file/attribute/FileOwnerAttributeView.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2007, 2011, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2007, 2016, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -59,7 +59,7 @@ > /** > * Read the file owner. > * > - *

It it implementation specific if the file owner can be a {@link > + *

It is implementation specific if the file owner can be a {@link > * GroupPrincipal group}. > * > * @return the file owner > @@ -78,7 +78,7 @@ > /** > * Updates the file owner. > * > - *

It it implementation specific if the file owner can be a {@link > + *

It is implementation specific if the file owner can be a {@link > > Thanks, > From john.r.rose at oracle.com Tue Jan 26 19:04:01 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 26 Jan 2016 11:04:01 -0800 Subject: RFR JDK-8141491: Unaligned memory access in Bits.c In-Reply-To: <56A7BF7B.5020006@redhat.com> References: <56560F32.6040300@oracle.com> <565628F5.2080801@oracle.com> <56A6FCA5.7040808@oracle.com> <56A736B7.4020601@redhat.com> <8D4B5D84-FF89-461E-93B2-7FB2E56F9741@oracle.com> <56A7BF7B.5020006@redhat.com> Message-ID: <17C15340-167F-4B33-A6CF-8510EAC2491C@oracle.com> On Jan 26, 2016, at 10:48 AM, Andrew Haley wrote: > > On 01/26/2016 06:32 PM, John Rose wrote: >> On Jan 26, 2016, at 1:04 AM, Andrew Haley wrote: >>> >>> I agree that memcpy is the right thing to use. It's portable and is >>> inlined well on production-quality C compilers. >> >> But it is not strong enough to uphold the Java memory model, >> because it is allows to copy byte-wise, which can tear shorts, >> ints, or longs, creating illegal race states. >> >> So we try to avoid memcpy when we can. > > Yes, I see. I guess the best we can do is something like the fun and > games in Unsafe.{get, put}LongUnaligned(), which always do the best > they can to align everything. Unsafe.copyMemory bottoms out to Copy::conjoint_memory_atomic. IMO that's a better starting point than memcpy. Perhaps it can be given an additional parameter (or overloading) to specify a swap size. ? John From john.r.rose at oracle.com Tue Jan 26 19:13:32 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 26 Jan 2016 11:13:32 -0800 Subject: RFR JDK-8141491: Unaligned memory access in Bits.c In-Reply-To: <56A7C410.4040301@redhat.com> References: <56560F32.6040300@oracle.com> <565628F5.2080801@oracle.com> <56A6FCA5.7040808@oracle.com> <56A736B7.4020601@redhat.com> <8D4B5D84-FF89-461E-93B2-7FB2E56F9741@oracle.com> <56A7BF7B.5020006@redhat.com> <17C15340-167F-4B33-A6CF-8510EAC2491C@oracle.com> <56A7C410.4040301@redhat.com> Message-ID: <713CDD14-7C04-4B33-AC48-6A5474351C97@oracle.com> On Jan 26, 2016, at 11:08 AM, Andrew Haley wrote: > > On 01/26/2016 07:04 PM, John Rose wrote: >> Unsafe.copyMemory bottoms out to Copy::conjoint_memory_atomic. >> IMO that's a better starting point than memcpy. Perhaps it can be >> given an additional parameter (or overloading) to specify a swap size. > > OK, but conjoint_memory_atomic doesn't guarantee that destination > words won't be torn if their source is misaligned: in fact it > guarantees that they will will be. That's a good point, and argues for a new function with the stronger guarantee. Actually, it would be perfectly reasonable to strengthen the guarantee on the existing function. I don't think anyone will care about the slight performance change, especially since it is probably favorable. Since it's Unsafe, they are not supposed to care, either. ? John From Alan.Bateman at oracle.com Wed Jan 27 13:55:47 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Jan 2016 13:55:47 +0000 Subject: 8148192: (fs) Path.register can fail with Bad file descriptor and other errors Message-ID: <56A8CC63.1000502@oracle.com> We have a bug in one of the base classes for the native WatchService implementations whereby updating a registration will fail with an IOException rather than a ClosedWatchServiceException when invoked at around the time that the WatchService is asynchronously closed. The change is trivial and has two parts: (a) insures that the wakeup is done while holding the requestList lock. I don't know this was missed originally. (b) in the poller thread (the thread that polls the native facility) queues the CloseWatchServiceException and then processes the update when it should never do both. The test in the webrev reproduces the issues on all platforms with native implementations. http://cr.openjdk.java.net/~alanb/8148192/webrev/ -Alan. From mikael.vidstedt at oracle.com Thu Jan 28 01:13:57 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 27 Jan 2016 17:13:57 -0800 Subject: RFR JDK-8141491: Unaligned memory access in Bits.c In-Reply-To: <713CDD14-7C04-4B33-AC48-6A5474351C97@oracle.com> References: <56560F32.6040300@oracle.com> <565628F5.2080801@oracle.com> <56A6FCA5.7040808@oracle.com> <56A736B7.4020601@redhat.com> <8D4B5D84-FF89-461E-93B2-7FB2E56F9741@oracle.com> <56A7BF7B.5020006@redhat.com> <17C15340-167F-4B33-A6CF-8510EAC2491C@oracle.com> <56A7C410.4040301@redhat.com> <713CDD14-7C04-4B33-AC48-6A5474351C97@oracle.com> Message-ID: <56A96B55.7050301@oracle.com> Just an FYI: I'm working on moving all of this to the Hotspot Copy class and bridging to it via jdk.internal.misc.Unsafe, removing Bits.c altogether. The implementation is working, and the preliminary performance numbers beat the pants off of any of the suggested Bits.c implementations (yay!). I'm currently in the progress of getting some unit tests in place for it all to make sure it covers all the corner cases and then I'll run some real benchmarks to see if it actually lives up to the expectations. Cheers, Mikael On 2016-01-26 11:13, John Rose wrote: > On Jan 26, 2016, at 11:08 AM, Andrew Haley wrote: >> On 01/26/2016 07:04 PM, John Rose wrote: >>> Unsafe.copyMemory bottoms out to Copy::conjoint_memory_atomic. >>> IMO that's a better starting point than memcpy. Perhaps it can be >>> given an additional parameter (or overloading) to specify a swap size. >> OK, but conjoint_memory_atomic doesn't guarantee that destination >> words won't be torn if their source is misaligned: in fact it >> guarantees that they will will be. > That's a good point, and argues for a new function with the > stronger guarantee. Actually, it would be perfectly reasonable > to strengthen the guarantee on the existing function. I don't > think anyone will care about the slight performance change, > especially since it is probably favorable. Since it's Unsafe, > they are not supposed to care, either. > > ? John From martinrb at google.com Thu Jan 28 02:29:58 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 27 Jan 2016 18:29:58 -0800 Subject: JDK-8148424 Support ipv6-only environments Message-ID: Are y'all interested in our ipv6-only changes? https://bugs.openjdk.java.net/browse/JDK-8148424 If yes, there will be some work on both sides, mostly for multi-platform testing. From chris.hegarty at oracle.com Thu Jan 28 12:46:57 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 28 Jan 2016 12:46:57 +0000 Subject: 8148192: (fs) Path.register can fail with Bad file descriptor and other errors In-Reply-To: <56A8CC63.1000502@oracle.com> References: <56A8CC63.1000502@oracle.com> Message-ID: <04063A95-EF2D-45F4-9C14-8B6379C0661A@oracle.com> On 27 Jan 2016, at 13:55, Alan Bateman wrote: > > We have a bug in one of the base classes for the native WatchService implementations whereby updating a registration will fail with an IOException rather than a ClosedWatchServiceException when invoked at around the time that the WatchService is asynchronously closed. > > The change is trivial and has two parts: > > (a) insures that the wakeup is done while holding the requestList lock. I don't know this was missed originally. > > (b) in the poller thread (the thread that polls the native facility) queues the CloseWatchServiceException and then processes the update when it should never do both. > > The test in the webrev reproduces the issues on all platforms with native implementations. > > http://cr.openjdk.java.net/~alanb/8148192/webrev/ This looks fine Alan. Trivially, should the test use the test library RandomFactory, or maybe the usage is too trivial? -Chris From Alan.Bateman at oracle.com Thu Jan 28 13:00:22 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Jan 2016 13:00:22 +0000 Subject: 8148192: (fs) Path.register can fail with Bad file descriptor and other errors In-Reply-To: <04063A95-EF2D-45F4-9C14-8B6379C0661A@oracle.com> References: <56A8CC63.1000502@oracle.com> <04063A95-EF2D-45F4-9C14-8B6379C0661A@oracle.com> Message-ID: <56AA10E6.40003@oracle.com> On 28/01/2016 12:46, Chris Hegarty wrote: > : > > Trivially, should the test use the test library RandomFactory, or maybe the usage > is too trivial? > Thanks. I would prefer not to in this case because it makes much harder to run the test on remote systems (the test X only fails on machine Y scenario). -Alan From Alan.Bateman at oracle.com Thu Jan 28 13:41:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Jan 2016 13:41:45 +0000 Subject: JDK-8148424 Support ipv6-only environments In-Reply-To: References: Message-ID: <56AA1A99.7020509@oracle.com> On 28/01/2016 02:29, Martin Buchholz wrote: > Are y'all interested in our ipv6-only changes? > https://bugs.openjdk.java.net/browse/JDK-8148424 > If yes, there will be some work on both sides, mostly for > multi-platform testing. I think so, this is configuration that we attempted to test several times, going back to JDK 1.4. -Alan From tprintezis at twitter.com Thu Jan 28 16:04:36 2016 From: tprintezis at twitter.com (Tony Printezis) Date: Thu, 28 Jan 2016 11:04:36 -0500 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> Message-ID: Martin (and all), Thanks for the clarification. Yes, I also manage my changes with MQs (only sane way to use HG IMHO!!!). I?m all set and jcheck is happy. 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? (again, apologies for all the questions; I?ve only ever pushed changes through JPRT!!!) Tony On January 26, 2016 at 12:58:57 PM, Martin Buchholz (martinrb at google.com) wrote: You can check your superpowers at the openjdk census. http://openjdk.java.net/census#tonyp says you haven't lost any. Outside of hotspot, there is no requirement for JPRT runs, so you can commit directly! To the jdk9-dev forest. I use mq to manage my patches. On Tue, Jan 26, 2016 at 6:21 AM, Tony Printezis wrote: > Alan, > > I?ve only contributed to HotSpot since I?ve been at Twitter and I always had > to have a sponsor for that in order to get it through JPRT. But, yes, I > should still be a reviewer. Is the process for pushing to the libraries > different? > > Tony > > On January 26, 2016 at 7:29:06 AM, Alan Bateman (alan.bateman at oracle.com) > wrote: > > > > On 25/01/2016 18:53, Tony Printezis wrote: > > Alan and Brian, > > webrev with this fix here: > > http://cr.openjdk.java.net/~tonyp/nio-max-buffer-size/webrev.4/ > > I also reduced the number of iterations in the test from 20,000 to 10,000 to > cut down the time it takes to run the test. Hope that?s OK. > > > Yes, this looks fine, I assume you still have committer rights and can push > this to jdk9/dev (you don't need a sponsor, right?). > > -Alan. > > ----- > > 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 brian.burkhalter at oracle.com Thu Jan 28 16:10:51 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 28 Jan 2016 08:10:51 -0800 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> Message-ID: <598AF6CC-55E7-4A50-B3B2-2841D925F3AE@oracle.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tprintezis at twitter.com Thu Jan 28 16:20:09 2016 From: tprintezis at twitter.com (Tony Printezis) Date: Thu, 28 Jan 2016 11:20:09 -0500 Subject: RFR: 8147468: Allow users to bound the size of buffers cached in the per-thread buffer caches In-Reply-To: <598AF6CC-55E7-4A50-B3B2-2841D925F3AE@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> Message-ID: 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 joe.darcy at oracle.com Fri Jan 29 18:53:57 2016 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 29 Jan 2016 10:53:57 -0800 Subject: JDK 9 RFR of JDK-8148627: Problem list TestMaxCachedBufferSize.java Message-ID: <56ABB545.7080600@oracle.com> Hello, Until JDK-8148540 is addressed, the test sun/nio/ch/TestMaxCachedBufferSize.java should be problem listed on the platforms is fails on. Please review the patch below. Thanks, -Joe diff -r eecb3e75b0d8 test/ProblemList.txt --- a/test/ProblemList.txt Thu Jan 28 18:08:53 2016 -0800 +++ b/test/ProblemList.txt Fri Jan 29 10:51:25 2016 -0800 @@ -197,6 +197,9 @@ java/nio/file/WatchService/Basic.java solaris-all java/nio/file/WatchService/LotsOfEvents.java solaris-all +# 8148540 +sun/nio/ch/TestMaxCachedBufferSize.java solaris-i586,windows-i586 + ############################################################################ # jdk_rmi diff -r eecb3e75b0d8 test/sun/nio/ch/TestMaxCachedBufferSize.java --- a/test/sun/nio/ch/TestMaxCachedBufferSize.java Thu Jan 28 18:08:53 2016 -0800 +++ b/test/sun/nio/ch/TestMaxCachedBufferSize.java Fri Jan 29 10:51:25 2016 -0800 @@ -50,6 +50,7 @@ * @run main/othervm -Djdk.nio.maxCachedBufferSize=10000000 TestMaxCachedBufferSize * * @summary Test the implementation of the jdk.nio.maxCachedBufferSize property. + * @key intermittent */ public class TestMaxCachedBufferSize { private static final int DEFAULT_ITERS = 10 * 1000; From Alan.Bateman at oracle.com Fri Jan 29 19:59:12 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 29 Jan 2016 19:59:12 +0000 Subject: JDK 9 RFR of JDK-8148627: Problem list TestMaxCachedBufferSize.java In-Reply-To: <56ABB545.7080600@oracle.com> References: <56ABB545.7080600@oracle.com> Message-ID: <56ABC490.4060609@oracle.com> On 29/01/2016 18:53, joe darcy wrote: > Hello, > > Until JDK-8148540 is addressed, the test > > sun/nio/ch/TestMaxCachedBufferSize.java > > should be problem listed on the platforms is fails on. Please review > the patch below. > I think this test will be tricky to be reliable on 32-bit so the simplest is to just restrict it to 64-bit with: @requires (sun.arch.data.model == "64") -Alan. From joe.darcy at oracle.com Fri Jan 29 20:13:33 2016 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 29 Jan 2016 12:13:33 -0800 Subject: JDK 9 RFR of JDK-8148627: Problem list TestMaxCachedBufferSize.java In-Reply-To: <56ABC490.4060609@oracle.com> References: <56ABB545.7080600@oracle.com> <56ABC490.4060609@oracle.com> Message-ID: <56ABC7ED.60103@oracle.com> Hi Alan, Limiting the test to 64-bit platforms is fine with me; I'll push the change as you've suggested later today. Thanks, -Joe On 1/29/2016 11:59 AM, Alan Bateman wrote: > > > On 29/01/2016 18:53, joe darcy wrote: >> Hello, >> >> Until JDK-8148540 is addressed, the test >> >> sun/nio/ch/TestMaxCachedBufferSize.java >> >> should be problem listed on the platforms is fails on. Please review >> the patch below. >> > I think this test will be tricky to be reliable on 32-bit so the > simplest is to just restrict it to 64-bit with: > > @requires (sun.arch.data.model == "64") > > -Alan. > From tprintezis at twitter.com Fri Jan 29 21:35:39 2016 From: tprintezis at twitter.com (Tony Printezis) Date: Fri, 29 Jan 2016 16:35:39 -0500 Subject: JDK 9 RFR of JDK-8148627: Problem list TestMaxCachedBufferSize.java In-Reply-To: <56ABC7ED.60103@oracle.com> References: <56ABB545.7080600@oracle.com> <56ABC490.4060609@oracle.com> <56ABC7ED.60103@oracle.com> Message-ID: Thanks Joe! On January 29, 2016 at 3:13:37 PM, joe darcy (joe.darcy at oracle.com) wrote: Hi Alan, Limiting the test to 64-bit platforms is fine with me; I'll push the change as you've suggested later today. Thanks, -Joe On 1/29/2016 11:59 AM, Alan Bateman wrote: > > > On 29/01/2016 18:53, joe darcy wrote: >> Hello, >> >> Until JDK-8148540 is addressed, the test >> >> sun/nio/ch/TestMaxCachedBufferSize.java >> >> should be problem listed on the platforms is fails on. Please review >> the patch below. >> > I think this test will be tricky to be reliable on 32-bit so the > simplest is to just restrict it to 64-bit with: > > @requires (sun.arch.data.model == "64") > > -Alan. > ----- Tony Printezis | JVM/GC Engineer / VM Team | Twitter @TonyPrintezis tprintezis at twitter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: