8263632: Improve exception handling of APIs in classLoader.cpp #3203
Conversation
|
/label add hotspot-runtime |
|
|
|
@calvinccheung |
Webrevs
|
| @@ -551,7 +551,7 @@ void ClassLoader::setup_module_search_path(const char* path, TRAPS) { | |||
| } | |||
| // File or directory found | |||
| ClassPathEntry* new_entry = NULL; | |||
| new_entry = create_class_path_entry(path, &st, true /* throw_exception */, | |||
| new_entry = create_class_path_entry_or_fail(path, &st, | |||
There was a problem hiding this comment.
Ideally, there's should be no need to check for new_entry == NULL when calling calling create_class_path_entry_or_fail(). This will make the code easier to read.
But currently the create_class_path_entry_or_fail() is still "tri-state":
- success: non-null
- throw vmSymbols::java_io_IOException()
- return NULL
The third case is this:
// Don't complain about bad jar files added via -Xbootclasspath/a:.
if (throw_exception && is_init_completed()) {
THROW_MSG_(vmSymbols::java_lang_ClassNotFoundException(), msg, NULL);
} else {
return NULL; <<<<< here
}
I am wondering if we can get rid of this logic. That way, we can add asserts like:
ClassPathEntry* ClassLoader::create_class_path_entry_or_fail(...) {
ClassPathEntry* entry = create_class_path_entry(, THREAD);
assert(entry != NULL || HAS_PENDING_EXCEPTION, "must throw or return valid entry");
return entry;
}
ClassPathEntry* ClassLoader::create_class_path_entry_or_null(...) {
ClassPathEntry* entry = create_class_path_entry(, current);
assert(!HAS_PENDING_EXCEPTION, "must not throw");
return entry;
}
There was a problem hiding this comment.
You can't use HAS_PENDING_EXCEPTION in create_class_path_entry_or_null without reintroducing THREAD.
There was a problem hiding this comment.
After offline discussion with Ioi, we've decided to get rid of the throw_exception in create_class_path_entry(). This makes the code cleaner. We could also drop the TRAPS parameter of a few other related functions.
There was a problem hiding this comment.
It is not at all clear to me how you now deal with the error cases without exceptions. How is it detected that ClassLoader::setup_module_search_path failed for example?
|
@calvinccheung This change now passes all automated pre-integration checks. 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 35 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.
|
Thanks David. |
| } | ||
|
|
||
| #if INCLUDE_CDS | ||
| void ClassLoader::setup_app_search_path(const char *class_path, TRAPS) { | ||
| void ClassLoader::setup_app_search_path(Thread* current, const char *class_path) { | ||
| Arguments::assert_is_dumping_archive(); | ||
|
|
||
| ResourceMark rm; |
There was a problem hiding this comment.
You can add 'current' as a parameter to ResourceMark since you have it.
There was a problem hiding this comment.
Thanks Coleen.
I've fixed it.
| } | ||
|
|
||
| add_to_module_path_entries(path, new_entry); | ||
| return; |
There was a problem hiding this comment.
Thanks Ioi.
I've fixed it.
|
/integrate |
openjdk
bot
added
integrated
|
@calvinccheung Since your change was applied there have been 38 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit c9d2d02. |
|
Mailing list message from Ioi Lam on hotspot-runtime-dev: On 3/28/21 9:40 PM, David Holmes wrote:
During VM bootstrap, classLoader.cpp tries to open files on related to For --patch-module handling, throw_exception=false was specified. For bootclasspath handling, throw_exception=true was specified before https://github.com/openjdk/jdk/blame/59ed1fa28c80395ddc5e8d8611e2225349aaff1a/src/hotspot/share/classfile/classLoader.cpp#L672 ?? ClassLoader::initialize But this will not throw any exception for invalid JAR files: ?? [1] the file doesn't exist. ?? [2] the file exists but is not a ZIP file The behavior of [2] is due to this: is_init_completed() is false during ?? // Don't complain about bad jar files added via -Xbootclasspath/a:. create_class_path_entry() is called when is_init_completed() is true Thanks |
|
Mailing list message from David Holmes on hotspot-runtime-dev: On 30/03/2021 9:01 am, Ioi Lam wrote:
Thanks for the explanations Ioi! David
|
Please review this change which includes:
ClassLoader::create_class_path_entry_or_fail()andClassLoader::create_class_path_entry_or_fail()functions for better readability. They will call the existingClassLoader::create_class_path_entry().Thread* currentfor the functions which never throw exception.Testing: tiers 1,2 (passed); tiers 3,4 (in progress).
Progress
Issue
Reviewers
Download
To checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3203/head:pull/3203$ git checkout pull/3203To update a local copy of the PR:
$ git checkout pull/3203$ git pull https://git.openjdk.java.net/jdk pull/3203/head