8378519: [lworld] Fold fieldDescriptor / ResolvedFieldEntry checks into the FlatFieldPayload constructor#2186
8378519: [lworld] Fold fieldDescriptor / ResolvedFieldEntry checks into the FlatFieldPayload constructor#2186xmas92 wants to merge 3 commits intoopenjdk:lworldfrom
Conversation
…to the FlatFieldPayload constructor
|
👋 Welcome back aboldtch! A progress list of the required criteria for merging this PR into |
|
@xmas92 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 125 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 |
Webrevs
|
|
Thanks for the review. Re-ran tests with the latests lworld merged. |
|
Going to push as commit f9799f4.
Your commit was automatically rebased without conflicts. |
Right now some of the call sites assets that ResolvedFieldEntry corresponds to the correct fieldDescriptor, and that these fields are in fact flattened. It was suggested that this would be more robust if this was folded into the construction of the FlatFieldPayload construction.
I moved these asserts up the construction hierarchy so that we also verify the unsafe flat field access. Because these can access nested flat values, some extra utility was added to find nested flat fields from an offset.
After this change the
FlatFieldPayloadcheck that thefieldDescriptor*constructor and theResolvedFieldEntry*is a valid non-nested flat field in the containing object.And the
FlatValuePayload::construct_from_partsverifies that there is an field at that offset of of the correct InlineKlass. (Either a direct field or array element, or a nested flat field inside an flat field or array element)Also the unsafe access logging was missing a ResourceMark, and changed it so it does not assert on bad offset, as I moved the assertions into the FlatValuePayload construction.
Testing:
--enable-previewProgress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/valhalla.git pull/2186/head:pull/2186$ git checkout pull/2186Update a local copy of the PR:
$ git checkout pull/2186$ git pull https://git.openjdk.org/valhalla.git pull/2186/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 2186View PR using the GUI difftool:
$ git pr show -t 2186Using diff file
Download this PR as a diff file:
https://git.openjdk.org/valhalla/pull/2186.diff
Using Webrev
Link to Webrev Comment