8266890: [lworld] [AArch64] add support for InlineTypePassFieldsAsArgs #420
Conversation
This patch implements InlineTypePassFieldsAsArgs on AArch64 and the associated stack extension/repair mechanism. It mostly follows the x86 implementation closely except for how the stack increment is stored in the callee frame. On x86 the sp_inc stack slot stores the total size of the frame which is the sum of the extension space, return address copy, and the original method frame size (i.e. the total bytes needed to pop the frame). On AArch64 we just store the size of the extension space. I did it this way because it simplifies the stack repair code in MacroAssembler::remove_frame (I've added some notes there to document this). I don't think this should cause any problem because only the MacroAssembler and platform-dependant frame walking code need to be aware of this. This patch includes JDK-8266609 which is a small refactoring in mainline JDK to simplify how the frame size is passed around in the AArch64 C1 backend. There was some X86 specific code in unpack_inline_args() in macroAssembler_common.cpp. I've split this out into an arch-dependant MacroAssembler::extend_stack_for_inline_args(). MacroAssembler::pack_inline_helper() and shuffle_inline_args() now take a new Register val_array argument which is the register holding the buffered oop array for packing. Previously it assumed this was already loaded in RAX (x86) or x20 (AArch64) but IMO passing it in explicitly makes the code easier to understand. There is one new test failure: TestNullableInlineTypes.java. The test seems functionally correct but there is a failure verifying the C2 IR graph (see below). I haven't investigated this but the test enables InlineTypePassFieldsAsArgs which we don't support yet on AArch64 so that might be causing the failure. Exception in thread "main" java.lang.RuntimeException: Graph for 'TestNullableInlineTypes::test26' contains forbidden node: 83 StoreL === 176 177 84 14 [[ 89 ]] @compiler/valhalla/inlinetypes/MyValue3:exact+16 *, name=l, idx=6; Memory: @rawptr:BotPTR, idx=Raw; !orig=82 !jvms: TestNullableInlineTypes::test26 @ bci:13 (line 704): expected false, was true
|
👋 Welcome back ngasson! A progress list of the required criteria for merging this PR into |
|
@nick-arm 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 6 new commits pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the 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 (@TobiHartmann) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
Webrevs
|
There was a problem hiding this comment.
Sorry for the delay, this looks good to me!
I did it this way because it simplifies the stack repair code in MacroAssembler::remove_frame
But that only simplifies the C++ code and not the assembly code that is emitted right? I wonder if we shouldn't aim for optimal assembly because this code will be exercised a lot.
Could you please file bugs for the other issues that you were seeing?
We currently don't have testing on aarch64 enabled for Valhalla in our CI but we will do so as soon as the port is stable.
Yes. I thought about it a bit more and I've modified it slightly so the sp_inc stack slot stores
Sure. Do you have any ideas about this one? https://bugs.openjdk.java.net/browse/JDK-8264340 |
There was a problem hiding this comment.
Looks good to me.
Sure. Do you have any ideas about this one? https://bugs.openjdk.java.net/browse/JDK-8264340
That doesn't ring a bell. Is it reproducible?
Yes, it always fails in that way on AArch64. It seems to be related to scheduling: I just ran it on x86 with |
|
/integrate |
|
/sponsor |
Okay, thanks for the details! |
|
@TobiHartmann @nick-arm Since your change was applied there have been 7 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 0871590. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
This patch implements InlineTypePassFieldsAsArgs on AArch64 and the
associated stack extension/repair mechanism. It mostly follows the x86
implementation closely except for how the stack increment is stored in
the callee frame. On x86 the sp_inc stack slot stores the total size of
the frame which is the sum of the extension space, return address copy,
and the original method frame size (i.e. the total bytes needed to pop
the frame). On AArch64 we just store the size of the extension space. I
did it this way because it simplifies the stack repair code in
MacroAssembler::remove_frame (I've added some notes there to document
this). I don't think this should cause any problem because only the
MacroAssembler and platform-dependant frame walking code need to be
aware of this.
This patch includes JDK-8266609 which is a small refactoring in mainline
JDK to simplify how the frame size is passed around in the AArch64 C1
backend.
There was some X86 specific code in unpack_inline_args() in
macroAssembler_common.cpp. I've split this out into an arch-dependant
MacroAssembler::extend_stack_for_inline_args().
MacroAssembler::pack_inline_helper() and shuffle_inline_args() now take
a new Register val_array argument which is the register holding the
buffered oop array for packing. Previously it assumed this was already
loaded in RAX (x86) or x20 (AArch64) but IMO passing it in explicitly
makes the code easier to understand.
There is one new test failure: TestNullableInlineTypes.java. The test
seems functionally correct but there is a failure verifying the C2 IR
graph (see below). I haven't investigated this but the test enables
InlineTypePassFieldsAsArgs which we don't support yet on AArch64 so that
might be causing the failure.
Tested tier1, runtime/valhalla, and compiler/valhalla on x86 and AArch64. There are some "bad AD file" failures on x86 but don't seem to be related to this patch.
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.java.net/valhalla pull/420/head:pull/420$ git checkout pull/420Update a local copy of the PR:
$ git checkout pull/420$ git pull https://git.openjdk.java.net/valhalla pull/420/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 420View PR using the GUI difftool:
$ git pr show -t 420Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/valhalla/pull/420.diff