-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8262901: [macos_aarch64] NativeCallTest expected:<-3.8194101E18> but was:<3.02668882E10> #10238
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
…was:<3.02668882E10>
👋 Welcome back omikhaltcova! A progress list of the required criteria for merging this PR into |
@omikhaltsova The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
ValueKind<?> valueKind = valueKindFactory.getValueKind(kind); | ||
locations[i] = StackSlot.get(valueKind, currentStackOffset, !type.out); | ||
currentStackOffset += Math.max(valueKind.getPlatformKind().getSizeInBytes(), target.wordSize); | ||
} | ||
} |
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.
So I'm curious: why not subclass AArch64HotSpotRegisterConfig
here, or maybe even use an interface, rather than the boolean?
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.
I tried to be closer to the original review #6641 that requires only 2 fixes and tried to do only this in order to continue easily.
Could you clarify please what boolean you talk about? private final boolean macOS;
that was pushed into class AArch64HotSpotRegisterConfig
, right? I'm hesitating a bit because of the highlighted 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.
Yes, that macOS
boolean.
Maybe it's not worth the effort, but it seems to me as though the use of the boolean in several places is something of a code smell, and this patch makes it more so. The control flow is not easy to follow.
I am wondering if refactoring it so that the code between L269 and L291 were broken out into two methods, one for MacOS and one for the others. I might be wrong, but I'd try it.
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.
Thanks for the tip! Absolutely agree, it's worth doing refactoring here. I'll try to follow this way.
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.
@theRealAph could you please take a look! I've made some additional refactoring in order to get rid of those "boolean"s where it's possible. I moved them from AArch64HotSpotVMConfig to TargetDescription. This makes an access to them easier across the code. As a 2nd step it's possible to substitute these "boolean"s with "enum" if it's needed. But imho it's better to keep them as "boolean"s at the moment.
In addition I see a new class RISCV64HotSpotVMConfig (committed after this pr) that also declared the same boolean:
final boolean linuxOs = Services.getSavedProperty("os.name", "").startsWith("Linux");
If this refactoring is made, this "boolean" won't be needed as well because it can be accessed from TargetDescription.
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.
This looks reasonable enough.
The pre-submit tests for linux-x64-hs-minimal and macos-aarch64 were reran manually and succeeded. |
@omikhaltsova This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
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. Thanks.
ValueKind<?> valueKind = valueKindFactory.getValueKind(kind); | ||
locations[i] = StackSlot.get(valueKind, currentStackOffset, !type.out); | ||
currentStackOffset += Math.max(valueKind.getPlatformKind().getSizeInBytes(), target.wordSize); | ||
} | ||
} |
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.
This looks reasonable enough.
@omikhaltsova 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 905 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. As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@theRealAph) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
@omikhaltsova Your changes look good to me. Thanks! |
@theRealAph @teshull thanks for the review! |
/integrate |
@omikhaltsova |
/sponsor |
Going to push as commit 6b456f7.
Your commit was automatically rebased without conflicts. |
@AntonKozlov @omikhaltsova Pushed as commit 6b456f7. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
This PR is opened as a follow-up for [1] and included the "must-done" fixes pointed by @teshull.
This patch for JVMCI includes the following fixes related to the macOS AArch64 calling convention:
Tested with tier1 on macOS AArch64 and Linux AArch64.
[1] #6641
[2] https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms
[3] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160#stack
[4] https://docs.microsoft.com/en-us/cpp/build/stack-usage?view=msvc-170
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/10238/head:pull/10238
$ git checkout pull/10238
Update a local copy of the PR:
$ git checkout pull/10238
$ git pull https://git.openjdk.org/jdk pull/10238/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 10238
View PR using the GUI difftool:
$ git pr show -t 10238
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/10238.diff