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
8286277: CDS VerifyError when calling clone() on object array #8737
Conversation
👋 Welcome back iklam! A progress list of the required criteria for merging this PR into |
Webrevs
|
invokevirtual Method "java/lang/Object".clone:"()Ljava/lang/Object;"; | ||
return; | ||
} | ||
} |
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.
Missing newline at end of line.
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.
Fixed.
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.
Is the component type of the array already loaded and verified at this point? My only concern would be that the is_assignable
check might load and verify the class as a side-effect, and we have now skipped that. ??
The is_assignable_check() may or may not load the array class depending on what it needs to check assignability. But neither the verifier nor the JVM has any dependency on the array class being loaded. Note that if this were not a protected access or if name_in_supers() returned null then the is_assignable_check() would not get called. Also note that the verifier tries to avoid loading classes. Also, the assignability check may cause the array class to get loaded but would not cause it to get linked or verified. |
Thanks Harold! @hseigel |
@iklam 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 105 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 |
* @build sun.hotspot.WhiteBox | ||
* @build InvokeCloneValid InvokeCloneInvalid VerifyObjArrayCloneTestApp |
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.
Please align line 32 with line 31.
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. Just one nit.
Thanks @calvinccheung and @dholmes-ora for the review, and @hseigel for confirming the fix. |
Going to push as commit 646c8aa.
Your commit was automatically rebased without conflicts. |
Problem:
When verifying an invokevirtual bytecode that calls a protected method in a superclass of the current class, the verifier requires that the object being invoked must be a subtype of the current class. This prevents invocation of protected methods in an unrelated class. For example, the following is disallowed -- the type
InvokeCloneInvalid
cannot invokeclone()
on aString
:However, there's a special case where invoking
Object.clone()
is allowed on all object arrays. Here's an example:Before this PR. the Verifier would first do the assignability check. When a failure is encountered, the Verifier then checks for the special case and ignores the failure accordingly.
In the above case, the assignability check will fail because the object being invoked (an Object array) is not assignable to the current class (InvokeCloneValid)
The problem is that CDS remembers all the assignability checks and tries to replay them at runtime. Therefore, it will re-check the assignability of Object Array to InvokeCloneValid, and throw a VerifyError as a result.
Proposed Fix
In
ClassVerifier::verify_invoke_instructions()
, check the special case first, before doing the assignability check. This way, such invalid-but-ignored assignability checks are no longer performed and thus won't be remembered by CDS.Testing
Tiers 1 - 4, plus 3 new test cases.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/8737/head:pull/8737
$ git checkout pull/8737
Update a local copy of the PR:
$ git checkout pull/8737
$ git pull https://git.openjdk.java.net/jdk pull/8737/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 8737
View PR using the GUI difftool:
$ git pr show -t 8737
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/8737.diff