Skip to content
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

8266609: AArch64: include FP/LR space in LIR_Assembler::initial_frame_size_in_bytes() #3898

Closed
wants to merge 1 commit into from

Conversation

nick-arm
Copy link
Contributor

@nick-arm nick-arm commented May 6, 2021

LIR_Assembler::initial_frame_size_in_bytes() returns the frame size
without the additional 2*wordSize needed to store FP/LR (i.e. just the
space required for the C1 locals). When we pass this value to
MacroAssembler build_frame and remove_frame we need to remember to add
back the 2*wordSize. This patch changes initial_frame_size_in_bytes()
to return the full frame size including the space for FP/LR. The PPC
and S390 ports already do this, and it also matches the behaviour of
C->output()->frame_size_in_bytes() in C2.

This change may seem a bit trivial in mainline but the Valhalla lworld
branch makes more calls to build_frame/remove_frame in C1 and keeping
track of whether "framesize" is with or without FP/LR quickly becomes
confusing.

Tested tier1 on AArch64. The only use of this function is as input to
C1_MacroAssembler build_frame() and remove_frame() so seems safe.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8266609: AArch64: include FP/LR space in LIR_Assembler::initial_frame_size_in_bytes()

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3898/head:pull/3898
$ git checkout pull/3898

Update a local copy of the PR:
$ git checkout pull/3898
$ git pull https://git.openjdk.java.net/jdk pull/3898/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 3898

View PR using the GUI difftool:
$ git pr show -t 3898

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/3898.diff

…_size_in_bytes()

LIR_Assembler::initial_frame_size_in_bytes() returns the frame size
without the additional 2*wordSize needed to store FP/LR (i.e. just the
space required for the C1 locals).  When we pass this value to
MacroAssembler build_frame and remove_frame we need to remember to add
back the 2*wordSize.  This patch changes initial_frame_size_in_bytes()
to return the full frame size including the space for FP/LR.  The PPC
and S390 ports already do this, and it also matches the behaviour of
C->output()->frame_size_in_bytes() in C2.

This change may seem a bit trivial in mainline but the Valhalla lworld
branch makes more calls to build_frame/remove_frame in C1 and keeping
track of whether "framesize" is with or without FP/LR quickly becomes
confusing.

Tested tier1 on AArch64.  The only use of this function is as input to
C1_MacroAssembler build_frame() and remove_frame() so seems safe.
@bridgekeeper
Copy link

bridgekeeper bot commented May 6, 2021

👋 Welcome back ngasson! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added the rfr Pull request is ready for review label May 6, 2021
@openjdk
Copy link

openjdk bot commented May 6, 2021

@nick-arm The following label will be automatically applied to this pull request:

  • hotspot

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.

@openjdk openjdk bot added the hotspot hotspot-dev@openjdk.org label May 6, 2021
@mlbridge
Copy link

mlbridge bot commented May 6, 2021

Webrevs

Copy link
Contributor

@theRealAph theRealAph left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This calculation is the same as x86. Can you explain why it has to be changed on AArch64, but should not be changed on x86?


// subtract two words to account for return address and link
return (frame_map()->framesize() - (2*VMRegImpl::slots_per_word)) * VMRegImpl::stack_slot_size;
return in_bytes(frame_map()->framesize_in_bytes());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Umm, really? framesize_in_bytes() returns a value that has to be converted to bytes?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

framesize_in_bytes() returns a struct ByteSize that needs to be converted to an int with in_bytes(). The extra _in_bytes seems a bit redundant but it's not my name :-)

@nick-arm
Copy link
Contributor Author

nick-arm commented May 7, 2021

This calculation is the same as x86. Can you explain why it has to be changed on AArch64, but should not be changed on x86?

On AArch64 C1_MacroAssembler::build_frame() delegates to MacroAssembler::build_frame() which expects the total frame size. On x86 we build the frame directly in C1_MacroAssembler by doing roughly __ push(rbp); __ decrement(rsp, frame_size_in_bytes); so it's natural that frame_size_in_bytes shouldn't include the space for the frame pointer and the return address (which was already pushed by the call instruction). If we made this change on x86 we'd need to subtract 2*wordSize from each increment/decrement of rsp which seems like a net loss.

@theRealAph
Copy link
Contributor

This calculation is the same as x86. Can you explain why it has to be changed on AArch64, but should not be changed on x86?

On AArch64 C1_MacroAssembler::build_frame() delegates to MacroAssembler::build_frame() which expects the total frame size. On x86 we build the frame directly in C1_MacroAssembler by doing roughly __ push(rbp); __ decrement(rsp, frame_size_in_bytes); so it's natural that frame_size_in_bytes shouldn't include the space for the frame pointer and the return address (which was already pushed by the call instruction). If we made this change on x86 we'd need to subtract 2*wordSize from each increment/decrement of rsp which seems like a net loss.

OK, makes snse.

@openjdk
Copy link

openjdk bot commented May 7, 2021

@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:

8266609: AArch64: include FP/LR space in LIR_Assembler::initial_frame_size_in_bytes()

Reviewed-by: aph

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 20 new commits pushed to the master branch:

  • ebb68d2: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic
  • 3a474d9: 8265612: revise the help info for jmap histo command
  • c97f56c: 8266172: -Wstringop-overflow happens in vmError.cpp
  • 43ad24f: 8265465: jcmd VM.cds should keep already dumped archive when exception happens
  • 66191ff: 8266193: BasicJMapTest does not include testHistoParallel methods
  • 36e5ad6: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels
  • 0ca86da: 8266002: vmTestbase/nsk/jvmti/ClassPrepare/classprep001 should skip events for unexpected classes
  • 52f1db6: 8262002: java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with "TestCaseScaffoldException: DummyClassWithLVT did not match .class file"
  • 04f7112: 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long"
  • a90b33a: 8266573: Make sure blackholes are tagged for all JVMCI paths
  • ... and 10 more: https://git.openjdk.java.net/jdk/compare/a86ee9b3f370b59caea2ae78169d13498560cd8e...master

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 master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label May 7, 2021
@nick-arm
Copy link
Contributor Author

nick-arm commented May 7, 2021

/integrate

@openjdk openjdk bot closed this May 7, 2021
@openjdk openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels May 7, 2021
@openjdk
Copy link

openjdk bot commented May 7, 2021

@nick-arm Since your change was applied there have been 20 commits pushed to the master branch:

  • ebb68d2: 8049700: Deprecate obsolete classes and methods in javax/swing/plaf/basic
  • 3a474d9: 8265612: revise the help info for jmap histo command
  • c97f56c: 8266172: -Wstringop-overflow happens in vmError.cpp
  • 43ad24f: 8265465: jcmd VM.cds should keep already dumped archive when exception happens
  • 66191ff: 8266193: BasicJMapTest does not include testHistoParallel methods
  • 36e5ad6: 8263236: runtime/os/TestTracePageSizes.java fails on old kernels
  • 0ca86da: 8266002: vmTestbase/nsk/jvmti/ClassPrepare/classprep001 should skip events for unexpected classes
  • 52f1db6: 8262002: java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with "TestCaseScaffoldException: DummyClassWithLVT did not match .class file"
  • 04f7112: 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long"
  • a90b33a: 8266573: Make sure blackholes are tagged for all JVMCI paths
  • ... and 10 more: https://git.openjdk.java.net/jdk/compare/a86ee9b3f370b59caea2ae78169d13498560cd8e...master

Your commit was automatically rebased without conflicts.

Pushed as commit 71b8ad4.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot hotspot-dev@openjdk.org integrated Pull request has been integrated
2 participants