-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
8254566: Clarify the spec of ClassLoader::getClassLoadingLock for non-parallel capable loader #14720
Conversation
…quired by non-parallel capable loader
👋 Welcome back mchung! A progress list of the required criteria for merging this PR into |
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.
Looks good. One change requested on terminology.
Thanks
* | ||
* @apiNote | ||
* This method allows parallel capable class loaders to implement | ||
* finer-grained locking scheme such that multiple threads may load classes |
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.
s/scheme/schemes/
* This method allows parallel capable class loaders to implement | ||
* finer-grained locking scheme such that multiple threads may load classes | ||
* concurrently without deadlocks. For non-parallel-capable class loaders, | ||
* the {@code ClassLoader} object is held during the class loading operations. |
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.
s/is held/is synchronized on/ - as that is the terminology loadClass uses.
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.
Updated per your suggestion.
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.
Looks good to me.
@mlchung 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 11 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 |
/integrate |
Going to push as commit b9198f9.
Your commit was automatically rebased without conflicts. |
* finer-grained locking schemes such that multiple threads may load classes | ||
* concurrently without deadlocks. For non-parallel-capable class loaders, | ||
* the {@code ClassLoader} object is synchronized on during the class loading | ||
* operations. Class loaders with non-hierarchical delegation should be |
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.
At some point we might want to re-visit the use of "non-hierarchical" (and "hierarchical" in the class description) as deadlocks are also possible with hierarchical delegation when mixing parent-first and child-first delegation. It could be that the the API note provides a strong recommendation the class loader be parallel capable when it is anything other than single parent with parent delegation.
The spec of
ClassLoader::getClassLoadingLock
is unclear that this method is intended for parallel-capable class loader implementations to provide an alternate implementation. For non-parallel-capable class loaders, this method should return thisClassLoader
object. The javadoc uses "the default implementation" which could be interpreted that non-parallel-capable class loaders can also override this implementation, which is not the intent. See https://openjdk.org/groups/core-libs/ClassLoaderProposal.html.Progress
Issues
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/14720/head:pull/14720
$ git checkout pull/14720
Update a local copy of the PR:
$ git checkout pull/14720
$ git pull https://git.openjdk.org/jdk.git pull/14720/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 14720
View PR using the GUI difftool:
$ git pr show -t 14720
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/14720.diff
Webrev
Link to Webrev Comment