-
Notifications
You must be signed in to change notification settings - Fork 5.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8294437: java/nio/channels/FileChannel tests slow on Windows #10464
Conversation
👋 Welcome back djelinski! A progress list of the required criteria for merging this PR into |
@djelinski The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Creating the files as sparse files make sense, we probably should have changed these tests a long time ago.
raf.write(b); | ||
return b; | ||
try (FileChannel fc = FileChannel.open(src, StandardOpenOption.CREATE_NEW, | ||
StandardOpenOption.SPARSE, StandardOpenOption.WRITE)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LargeMapFile uses import static java.nio.file.StandardOpenOption.* which makes it easier to fit the open options on the same line.
ByteBuffer bb; | ||
try (FileChannel fc = FileChannel.open(p, CREATE_NEW, SPARSE, WRITE)) { | ||
fc.position(BASE); | ||
Random r = new Random(System.nanoTime()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might not matter here but we usually use RandomFactory to allow for reproducibility in the event of test failure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the hint! It shouldn't matter here, but I'll change it.
out.println("Exceptions: OK"); | ||
t1 = System.nanoTime(); | ||
out.printf("Exceptions: done in %d ns (%d ms) %n", | ||
t1 - t0, TimeUnit.NANOSECONDS.toMillis(t1 - t0)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you planning to leave all these timestamps in the output? I can't tell if they are left over from your testing or intentional.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I wanted to leave them here; they don't take up much space, and are very useful when trying to figure out why the tests are slow.
Overall I don’t see any problems aside from the copyright years which I assume you will fix before integrating. It’s good that you removed |
I went with adding I added one more modification to |
I would prefer if the FileChannel tests do not use this. The reason is that these are tests for FileChannel and should not be dependent on test infrastructure that it out of sight. It would be okay for non-FileChannel tests to use of course. |
would it be okay if I moved the method to, say, FileChannelUtils in FileChannel directory? |
WritableByteChannel wbc = Channels.newChannel(os)){ | ||
|
||
long n; | ||
if ((n = srcCh.transferTo(0, LENGTH, wbc)) < LENGTH) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The contract of FileChannel::transferTo
does not guarantee that all bytes are transferred:
An invocation of this method may or may not transfer all of the requested bytes [...]
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
preexisting, and unlikely to change because of Hyrum's law. I can file a ticket to update the docs if you think it makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I think the docs should be left as they are.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack that. If that's okay with you, I'd rather not change this code here; it was always like that, and I haven't found any related failure reports. The tests continue to pass.
sinkChannel.close(); | ||
try (FileChannel sourceChannel = FileChannel.open(source, StandardOpenOption.READ); | ||
FileChannel sinkChannel = FileChannel.open(sink, StandardOpenOption.WRITE)) { | ||
long bytesWritten = sinkChannel.transferFrom(sourceChannel, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment as for FileChannel::transferTo
:
An invocation of this method may or may not transfer all of the requested bytes
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this version looks okay and probably okay drop the loop from testForce. It's probably best to wait until @bplb gets to see the updated version as he has been doing most of the work in this area recently.
@djelinski This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 81 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the update, I don't have any other comments. Will be good to get this change in as these tests are so slow on Windows right now.
throw new RuntimeException("Premature EOF!"); | ||
nread += n; | ||
} | ||
// Setup looback connection and echo server |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"looback" -> "loopback"
Typo fixed. Thanks for the reviews! /integrate |
Going to push as commit a4f2078.
Your commit was automatically rebased without conflicts. |
@djelinski Pushed as commit a4f2078. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Please review this test-only change that improves the execution speed of a few FileChannel tests:
testForce
method; I'm not sure what issues it was supposed to catch, but at far as I can tell, it was only triggering timeouts, see JDK-8289526, JDK-8224480Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/10464/head:pull/10464
$ git checkout pull/10464
Update a local copy of the PR:
$ git checkout pull/10464
$ git pull https://git.openjdk.org/jdk pull/10464/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 10464
View PR using the GUI difftool:
$ git pr show -t 10464
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/10464.diff