Skip to content
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

8293122: (fs) Use file cloning in macOS version of Files::copy method #10188

Closed
wants to merge 5 commits into from

Conversation

bplb
Copy link
Member

@bplb bplb commented Sep 7, 2022

Use BSD system call clonefile if possible when using Files::copy on macOS.


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

Issue

  • JDK-8293122: (fs) Use file cloning in macOS version of Files::copy method

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/10188/head:pull/10188
$ git checkout pull/10188

Update a local copy of the PR:
$ git checkout pull/10188
$ git pull https://git.openjdk.org/jdk pull/10188/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 10188

View PR using the GUI difftool:
$ git pr show -t 10188

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/10188.diff

@bridgekeeper
Copy link

bridgekeeper bot commented Sep 7, 2022

👋 Welcome back bpb! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added the rfr Pull request is ready for review label Sep 7, 2022
@openjdk
Copy link

openjdk bot commented Sep 7, 2022

@bplb The following label will be automatically applied to this pull request:

  • nio

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.

@openjdk openjdk bot added the nio nio-dev@openjdk.org label Sep 7, 2022
@mlbridge
Copy link

mlbridge bot commented Sep 7, 2022

Webrevs

// Attempt to clone the source unless cloning is not supported,
// cancellation is not possible, or attributes are not to be copied
if (!cloneFileNotSupported && addressToPollForCancel == 0 &&
flags.copyPosixAttributes) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will need some thought as this means it will only be used when Files.copy is invoked with the COPY_ATTRIBUTES option.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clonefile appears to copy all attributes so if it is acceptable for that to occur if COPY_ATTRIBUTES is not set, then the flags.copyPosixAttributes check could be removed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My opinion is that the improved throughput outweighs any detriment from copying attributes when COPY_ATTRIBUTES is not specified and so the flags.copyPosixAttributes check should be removed.

@openjdk
Copy link

openjdk bot commented Sep 12, 2022

@bplb 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:

8293122: (fs) Use file cloning in macOS version of Files::copy method

Reviewed-by: alanb

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 25 new commits pushed to the master branch:

  • 7f3250d: 8293787: Linux aarch64 build fails after 8292591
  • 2a38791: 8292755: Non-default method in interface leads to a stack overflow in JShell
  • 8351b30: 8293771: runtime/handshake/SystemMembarHandshakeTransitionTest.java fails if MEMBARRIER_CMD_QUERY is unsupported
  • 91f9c0d: 8293774: Improve TraceOptoParse to dump the bytecode name
  • 1169a15: 8291657: Javac assertion when compiling a method call with switch expression as argument
  • 2baf251: 8293654: Improve SharedRuntime handling of continuation helper out-arguments
  • 60f59a4: 8293660: Fix frame::sender_for_compiled_frame frame size assert
  • b3461c1: 8293680: PPC64BE build failure after JDK-8293344
  • 7e02039: 8293647: Avoid unnecessary boxing in jdk.hotspot.agent
  • 9039022: 8287394: AArch64: Remove cbuf parameter from far_call/far_jump/trampoline_call
  • ... and 15 more: https://git.openjdk.org/jdk/compare/524af949370990df6f58a84ad2493eb1dcba2231...master

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 master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Sep 12, 2022
{
// Attempt to clone the source unless cancellation is not possible,
// or attributes are not to be copied
if (addressToPollForCancel == 0 && flags.copyPosixAttributes) {
Copy link
Contributor

@AlanBateman AlanBateman Sep 13, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It wouldn't be wrong to drop the check for copyPosixAttributes here, in which case they would be copied by default (the spec allows for that). The only issue is that someone might become dependent on this and then be surprised when they code behaves differently when run on another platform.

I'm curious if there is a way to test how clone behaves when it fails. What you have is okay although the unlink might only be needed when chown fails.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only issue is that someone might become dependent on this and then be surprised when they code behaves differently when run on another platform.

This is a good reason to leave it as-is.

I'm curious if there is a way to test how clone behaves when it fails. What you have is okay although the unlink might only be needed when chown fails.

All the described error numbers except EIO are things which one would expect the call to verify before actually starting to clone, so for those cases it would be unexpected to find that the destination exists after the failure. Provoking an EIO failure might be difficult.

@bplb
Copy link
Member Author

bplb commented Sep 14, 2022

/integrate

@openjdk
Copy link

openjdk bot commented Sep 14, 2022

Going to push as commit a75ddb8.
Since your change was applied there have been 27 commits pushed to the master branch:

  • 95c7c55: 8293402: hs-err file printer should reattempt stack trace printing if it fails
  • 211fab8: 8291669: [REDO] Fix array range check hoisting for some scaled loop iv
  • 7f3250d: 8293787: Linux aarch64 build fails after 8292591
  • 2a38791: 8292755: Non-default method in interface leads to a stack overflow in JShell
  • 8351b30: 8293771: runtime/handshake/SystemMembarHandshakeTransitionTest.java fails if MEMBARRIER_CMD_QUERY is unsupported
  • 91f9c0d: 8293774: Improve TraceOptoParse to dump the bytecode name
  • 1169a15: 8291657: Javac assertion when compiling a method call with switch expression as argument
  • 2baf251: 8293654: Improve SharedRuntime handling of continuation helper out-arguments
  • 60f59a4: 8293660: Fix frame::sender_for_compiled_frame frame size assert
  • b3461c1: 8293680: PPC64BE build failure after JDK-8293344
  • ... and 17 more: https://git.openjdk.org/jdk/compare/524af949370990df6f58a84ad2493eb1dcba2231...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Sep 14, 2022
@openjdk openjdk bot closed this Sep 14, 2022
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Sep 14, 2022
@openjdk
Copy link

openjdk bot commented Sep 14, 2022

@bplb Pushed as commit a75ddb8.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@bplb bplb deleted the Files-clonefile-8293122 branch September 14, 2022 20:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integrated Pull request has been integrated nio nio-dev@openjdk.org
Development

Successfully merging this pull request may close these issues.

2 participants