Re: Request/discussion: BufferedReader reading using async API while providing sync API

On 27/10/2016 22:45, Vitaly Davidovich wrote: On Thursday, October 27, 2016, Brunoais > wrote: You are right. Even in windows it does not set the flags for async reads. It seems like it is windows itself that does the decision to buffer the contents b

Re: JEP 293: Guidelines for JDK Command-Line Tool Options - @-files

OS-specific encoding, but has to be ASCII friendly, modern system with UTF-8 as system encoding should work just fine. Space in quote should work just fine, for example, “c:\\Program Files” should be correct. Can you post messages from JLink? Also if you can verify java is working OK with space

Re: JDK 9 RFR of JDK-8168524: Remove two jdk_nio tests from ProblemList: BashStreams and DeleteInterference.java

On 10/24/16 10:50 PM, Brian Burkhalter wrote: +1 for the DeleteInterference portion. Thank you Brian. Still need a reviewer for BashStreams test. Thanks, Amy Brian On Oct 24, 2016, at 1:08 AM, Amy Lu wrote: Please review the patch to bring back two tests: java/nio/file/WatchService/Del

Re: RFR 9: 8168517 : java/lang/ProcessBuilder/Basic.java failed

Hi Roger, On 28/10/2016 10:46 AM, Roger Riggs wrote: Hi David, On 10/27/16 7:22 PM, David Holmes wrote: On 28/10/2016 6:58 AM, Roger Riggs wrote: Hi David, On 10/27/2016 4:51 PM, David Holmes wrote: Won't that now cause the test to hang until timed-out by the harness? yes, but an in-app

Re: RFR 9: 8168517 : java/lang/ProcessBuilder/Basic.java failed

Hi David, On 10/27/16 7:22 PM, David Holmes wrote: On 28/10/2016 6:58 AM, Roger Riggs wrote: Hi David, On 10/27/2016 4:51 PM, David Holmes wrote: Won't that now cause the test to hang until timed-out by the harness? yes, but an in-app timeout is not much different than the harness timeout

Re: RFR 9: 8168517 : java/lang/ProcessBuilder/Basic.java failed

On 28/10/2016 6:58 AM, Roger Riggs wrote: Hi David, On 10/27/2016 4:51 PM, David Holmes wrote: On 28/10/2016 3:12 AM, Roger Riggs wrote: Hi David, On 10/27/2016 12:57 PM, David Holmes wrote: Hi Roger, On 28/10/2016 1:44 AM, Roger Riggs wrote: Please review a test fix for a timeout on a bus

Re: RFR: 8168010: Deprecate obsolete launcher -d32/-d64 options

On 28/10/2016 7:08 AM, Kumar Srinivasan wrote: Hello, Please review enclosed fix for: https://bugs.openjdk.java.net/browse/JDK-8168010 Based on this discussion, http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-September/004934.html these options are slated for deprecation, only at the d

Re: RFR: 8168640: (fc) Avoiding AtomicBoolean in FileInput/-OutputStream improves startup

On 27/10/2016 3:46 PM, Peter Levart wrote: Hi David, On 10/27/2016 04:57 AM, David Holmes wrote: On 25/10/2016 10:36 PM, Peter Levart wrote: Hi Claes, On 10/25/2016 01:09 PM, Aleksey Shipilev wrote: On 10/25/2016 12:51 PM, Claes Redestad wrote: Avoiding AtomicBoolean improves startup and

Re: Request/discussion: BufferedReader reading using async API while providing sync API

Sorry nio-dev ... On 28/10/2016 7:09 AM, David Holmes wrote: You might try discussing on net-dev rather than core-libs-dev, to get additional historical info related to the io and nio file APIs. David On 28/10/2016 5:08 AM, Brunoais wrote: You are right. Even in windows it does not set the fl

Re: Request/discussion: BufferedReader reading using async API while providing sync API

On Thursday, October 27, 2016, Brunoais wrote: > You are right. Even in windows it does not set the flags for async reads. > It seems like it is windows itself that does the decision to buffer the > contents based on its own heuristics. > You mean nonblocking, not async, right? Two different thin

JEP 293: Guidelines for JDK Command-Line Tool Options - @-files

Hi, I'm facing some troubles with the content of the @-files and the documentation[1] isn't helping me yet. First of all it doesn't mention the encoding, I assume it is the OS specific encoding. I'm facing issues with a long --module-path on Windows. I noticed I can use the "normal" filen

Re: Request/discussion: BufferedReader reading using async API while providing sync API

You might try discussing on net-dev rather than core-libs-dev, to get additional historical info related to the io and nio file APIs. David On 28/10/2016 5:08 AM, Brunoais wrote: You are right. Even in windows it does not set the flags for async reads. It seems like it is windows itself that d

Re: RFR: 8168010: Deprecate obsolete launcher -d32/-d64 options

Hello, Please review enclosed fix for: https://bugs.openjdk.java.net/browse/JDK-8168010 Based on this discussion, http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-September/004934.html these options are slated for deprecation, only at the documentation level, and will continue to opera

Re: RFR 9: 8168517 : java/lang/ProcessBuilder/Basic.java failed

Hi David, On 10/27/2016 4:51 PM, David Holmes wrote: On 28/10/2016 3:12 AM, Roger Riggs wrote: Hi David, On 10/27/2016 12:57 PM, David Holmes wrote: Hi Roger, On 28/10/2016 1:44 AM, Roger Riggs wrote: Please review a test fix for a timeout on a busy system in Process.waitFor a destroyed pro

Re: RFR 9: 8168517 : java/lang/ProcessBuilder/Basic.java failed

On 28/10/2016 3:12 AM, Roger Riggs wrote: Hi David, On 10/27/2016 12:57 PM, David Holmes wrote: Hi Roger, On 28/10/2016 1:44 AM, Roger Riggs wrote: Please review a test fix for a timeout on a busy system in Process.waitFor a destroyed process. Won't that now cause the test to hang until tim

Re: Review Request: JDK-8168205: Should not default class path to CWD if -cp is not specified but -m is specified

> On Oct 27, 2016, at 12:24 PM, Paul Sandoz wrote: > > >> On 26 Oct 2016, at 22:59, Mandy Chung wrote: >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8168205/webrev.00/index.html >> >> If -cp is not specified and -m is not specified, the builtin system >> class loader will

Re: RFR: 8168010: Deprecate obsolete launcher -d32/-d64 options

On 27/10/2016 6:03 PM, Alan Bateman wrote: On 27/10/2016 02:20, Kumar Srinivasan wrote: Hello, Please review enclosed fix for: https://bugs.openjdk.java.net/browse/JDK-8168010 Based on this discussion, http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-September/004934.html these options a

Re: Review Request: JDK-8168205: Should not default class path to CWD if -cp is not specified but -m is specified

On 27/10/2016 18:02, Mandy Chung wrote: On Oct 27, 2016, at 2:44 AM, Alan Bateman wrote: The updated comment in ClassLoaders might be a bit clearer if you drop "if defined”. OK, dropped “if defined”. A minor comment on the test is that it could use ProcessTools.executeTestJava to avoid n

Re: RFR 8163553 java.lang.LinkageError from test java/lang/ThreadGroup/Stop.java

Gentle reminder. Paul. > On 18 Oct 2016, at 11:41, Paul Sandoz wrote: > > Hi, > > Please review: > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8163553-vh-mh-link-errors-not-wrapped/webrev/ > > This is the issue that motivated a change in the behaviour of indy wrapping > Errors in Boo

Re: Review Request: JDK-8168205: Should not default class path to CWD if -cp is not specified but -m is specified

> On 26 Oct 2016, at 22:59, Mandy Chung wrote: > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8168205/webrev.00/index.html > > If -cp is not specified and -m is not specified, the builtin system > class loader will default the class path to the current working > directory. If

Re: Request/discussion: BufferedReader reading using async API while providing sync API

You are right. Even in windows it does not set the flags for async reads. It seems like it is windows itself that does the decision to buffer the contents based on its own heuristics. But... Why? Why won't it be? Why is there no API for it? How am I getting 100% HDD use and faster times when I

Re: Request/discussion: BufferedReader reading using async API while providing sync API

Here's my current code for benchmarking. Does this seem correct to you? On 27/10/2016 14:55, Peter Levart wrote: On 10/27/2016 03:48 PM, Peter Levart wrote: On 10/27/2016 02:20 PM, Brunoais wrote: Hey. Any idea how to skip tests? When testing for BufferedInputStream, the directBufferSiz

Re: RFR 9: 8168517 : java/lang/ProcessBuilder/Basic.java failed

Hi David, On 10/27/2016 12:57 PM, David Holmes wrote: Hi Roger, On 28/10/2016 1:44 AM, Roger Riggs wrote: Please review a test fix for a timeout on a busy system in Process.waitFor a destroyed process. Won't that now cause the test to hang until timed-out by the harness? yes, but an in-app

Re: Review Request: JDK-8168205: Should not default class path to CWD if -cp is not specified but -m is specified

> On Oct 27, 2016, at 2:44 AM, Alan Bateman wrote: > > The updated comment in ClassLoaders might be a bit clearer if you drop "if > defined”. > OK, dropped “if defined”. > A minor comment on the test is that it could use ProcessTools.executeTestJava > to avoid needing JAVA_TOOL. ProcessToo

Re: RFR: 8168010: Deprecate obsolete launcher -d32/-d64 options

+1 Mandy > On Oct 26, 2016, at 6:20 PM, Kumar Srinivasan > wrote: > > Hello, > > Please review enclosed fix for: > https://bugs.openjdk.java.net/browse/JDK-8168010 > > Based on this discussion, > http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-September/004934.html > these options are

Re: RFR 9: 8168517 : java/lang/ProcessBuilder/Basic.java failed

Hi Roger, On 28/10/2016 1:44 AM, Roger Riggs wrote: Please review a test fix for a timeout on a busy system in Process.waitFor a destroyed process. Won't that now cause the test to hang until timed-out by the harness? David Webrev: http://cr.openjdk.java.net/~rriggs/webrev-basic-destroy-

RFR 9: 8168517 : java/lang/ProcessBuilder/Basic.java failed

Please review a test fix for a timeout on a busy system in Process.waitFor a destroyed process. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-basic-destroy-8168517/ Thanks, Roger

Re: RFR:JDK-8075205 java/net/URLClassLoader/closetest/CloseTest.java and GetResourceAsStream.java failed with existing dir

Hi, Looks good. Editorial improvements: GetResourceAsStream.java: - line 44-52: Add the new variables after the test description like CloseTest.java or change CloseTest to improve style consistency. - Line 54-57: fix indentation - consistently use /* ... */ or // comment conventions

Re: Request/discussion: BufferedReader reading using async API while providing sync API

On 10/27/2016 03:48 PM, Peter Levart wrote: On 10/27/2016 02:20 PM, Brunoais wrote: Hey. Any idea how to skip tests? When testing for BufferedInputStream, the directBufferSize is not used so testing with different directBufferSize makes no sense. I already tried "return 0" on the benchm

Re: Request/discussion: BufferedReader reading using async API while providing sync API

On 10/27/2016 02:20 PM, Brunoais wrote: Hey. Any idea how to skip tests? When testing for BufferedInputStream, the directBufferSize is not used so testing with different directBufferSize makes no sense. I already tried "return 0" on the benchmarked test but jmh fills the output with " (*i

Re: Request/discussion: BufferedReader reading using async API while providing sync API

I don't know about Windows specifically, but generally file systems across major OS's will implement readahead in their IO scheduler when they detect sequential scans. On Linux, you can also strace your test to confirm which syscalls are emitted (you should be seeing plain read()'s there, with Fil

Re: Request/discussion: BufferedReader reading using async API while providing sync API

Thanks for the heads up. I'll try that later. These tests are still useful then. Meanwhile, I'll end up also checking how FileChannel queries the OS on windows. I'm getting 100% HDD reads... Could it be that the OS reads the file ahead on its own?... Anyway, I'll look into it. Thanks for the h

Re: Request/discussion: BufferedReader reading using async API while providing sync API

On Thu, Oct 27, 2016 at 8:34 AM, Brunoais wrote: > Oh... I see. In that case, it means something is terribly wrong. It can be > my initial tests, though. > > I'm testing on both linux and windows and I'm getting performance gains > from using the FileChannel compared to using FileInputStream... T

Re: Request/discussion: BufferedReader reading using async API while providing sync API

Oh... I see. In that case, it means something is terribly wrong. It can be my initial tests, though. I'm testing on both linux and windows and I'm getting performance gains from using the FileChannel compared to using FileInputStream... The tests also make sense based on my predictions O_O...

Re: Request/discussion: BufferedReader reading using async API while providing sync API

Hey. Any idea how to skip tests? When testing for BufferedInputStream, the directBufferSize is not used so testing with different directBufferSize makes no sense. I already tried "return 0" on the benchmarked test but jmh fills the output with " (*interrupt*)" if I do that. On 26/10/2016

Re: Request/discussion: BufferedReader reading using async API while providing sync API

On Thursday, October 27, 2016, Brunoais wrote: > Did you read the C code? I looked at the Linux code in the JDK. > Have you got any idea how many functions Windows or Linux (nearly all > flavors) have for the read operation towards a file? I do. > > I have already done that homework myself. I

Re: RFR: 8163162: The separation between system loggers and application loggers should take the extension loader in consideration.

On 27/10/16 00:17, Mandy Chung wrote: On Oct 26, 2016, at 6:58 AM, Daniel Fuchs wrote: With the deprivileging of some JDK modules, classes loaded by the Platform class loader should get the same kind of loggers than classes loaded by the Boot class loader (null loader). http://cr.openjdk.jav

Re: Request/discussion: BufferedReader reading using async API while providing sync API

On 27/10/2016 10:28, Bernd Eckenfels wrote: : AsyncFileChannel uses Java threads in the background for the completion handling (and last time I checked they are not signaled by the OS). Performance with that was not very good for sequential processing in my tests. It does use completion ports

Re: Review Request: JDK-8168205: Should not default class path to CWD if -cp is not specified but -m is specified

On 27/10/2016 07:05, Mandy Chung wrote: Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8168205/webrev.00/index.html If -cp is not specified and -m is not specified, the builtin system class loader will default the class path to the current working directory. If -m is specified, no

Re: Request/discussion: BufferedReader reading using async API while providing sync API

Hello, the NIO2 code for files is pretty disappointing as it does not use file completion ports on Windows or AIO on Linux. You use the file channel, in that case it is blocking. It does not implement SelectableChannel. AsyncFileChannel uses Java threads in the background for the completion hand

Re: RFR: 8168010: Deprecate obsolete launcher -d32/-d64 options

On 27/10/2016 02:20, Kumar Srinivasan wrote: Hello, Please review enclosed fix for: https://bugs.openjdk.java.net/browse/JDK-8168010 Based on this discussion, http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-September/004934.html these options are slated for deprecation, only at the doc