-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8259067: bootclasspath append takes out object lock #1935
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
Conversation
👋 Welcome back coleenp! A progress list of the required criteria for merging this PR into |
Webrevs
|
For the record, these tests exercise this code: |
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.
LGTM.
Lois
@coleenp 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 66 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 |
Thanks, Lois! |
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.
Hi Coleen,
LGTM++
Thanks,
Serguei
Thanks Serguei. Ioi convinced me offline to simplify and just use a mutex, so I updated the patch to do that. I tested with jdi and jvmti tests and will rerun tier1-3. |
Coleen, the function |
Thanks Serguei. I was trying to decide whether to move the lock there or add an assert that we are not multi-threaded when the lock isn't held. But it's cleaner to just move the lock there, so I'll do that. |
I reran tier1 and jvmti and jdi tests. |
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.
LGTM
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.
LGTM++
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.
Changes look good to me.
Lois
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.
Hi Coleen,
Just a quick skim, but I think you need acquire/release for the lock-free path.
Thanks,
David
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.
Addition of release/acquire looks good. Note that we now update _first_append_entry with the same release semantics as ClassPathEntry::set_next - as we should in general.
I'm not 100% clear on which part of these API's can only be called whilst the VM is still single-threaded, but ignoring that, the change to use locked updates with lock-free traversal seems functionally correct. The overall necessity of using locking does depend on the potential for concurrent calls to ClassLoader::add_to_boot_append_entries - something I have not investigated at all.
Thanks,
David
Thanks for reviewing this, David. The concurrent calls are from JVMTI where the lock was originally, but as suggested by Serguei, for safety, and to avoid tracing through all the callers, I moved the locking to the function where we write the list. It's not a performance critical operation. |
/integrate |
@coleenp Since your change was applied there have been 69 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 1c33847. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
See CR for details.
I made the classpath append list lock-free. Calling experts in Atomic operations...
Tested with tier1-6.
Thanks,
Coleen
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk pull/1935/head:pull/1935
$ git checkout pull/1935