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

Add support for inlining new atomic methods on Power #3018

Merged
merged 9 commits into from
Nov 13, 2018

Conversation

hzongaro
Copy link
Contributor

@hzongaro hzongaro commented Oct 1, 2018

Added support for inlining of the new atomic intrinsics
atomic{AddAndFetch|FetchAndAdd|Swap}{32|64}BitSymbol on Power. This is
largely a copy of similar support in OpenJ9 for inlining methods of
AtomicInteger and AtomicLong on Power.

Issue: #2958

Signed-off-by: Henry Zongaro [email protected]

Added support for inlining of the new atomic methods
atomic{AddAndFetch|FetchAndAdd|Swap}{32|64}BitSymbol on Power.  This is
largely a copy of similar support in OpenJ9 for inlining methods of
AtomicInteger and AtomicLong.

Signed-off-by:  Henry Zongaro <[email protected]>
@hzongaro
Copy link
Contributor Author

hzongaro commented Oct 1, 2018

May I ask @0dvictor @zl-wang @gita-omr to review?

One thing I'll point out is that I put OMR::Power::CodeGenerator::inlineDirectCall in OMRTreeEvaluator.cpp simply because the corresponding J9::Power::CodeGenerator::inlineDirectCall is defined in J9TreeEvaluator.cpp, rather than in J9CodeGenerator.cpp, which feels odd.

There will be a separate PR in OpenJ9 to take advantage of this change.


return doInline;
}

Copy link
Contributor

Choose a reason for hiding this comment

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

High-level issue: this will not work for 32bit JVM. i.e. this is assuming a 64bit JVM.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@zl-wang Julian, thanks for catching this. Just so I'm clear, can this code be inlined on a 32 bit JVM when it's working with 32 bit operands, and inlined on a 64 bit JVM when it's working with either 32 bit and 64 bit operands? Or can it only be inlined on a 64 JVM ever?

Something I just noticed this morning, I was playing with AtomicLong.getAndAdd and AtomicInteger.getAndAdd without my changes for these new intrinsics, and it looks like inline code is never generated for AtomicLong.getAndAdd for 32 bit or 64 bit JVMs, and always generated for AtomicInteger.getAndAdd for both 32 bit and 64 bit JVMs. Is that expected?

Copy link
Contributor

Choose a reason for hiding this comment

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

@hzongaro I didn't expect that. I expected existing JVM can inline CAS of both 32/64 operands in both 32/64 bit JVM. The only assumption is the underlying CPU is 64bit (this has been true since java7.1 when we discontinued support of 32bit hardware). The case for inlining CAS of 64bit operand in 32bit JVM needs special care though ... you can assemble 64bit operand in a register within the CAS range only, depending on the fact that CAS will definitely fail if there was a signal delivered in the between (i.e. meaning the upper 32bit of the register can be trashed anytime).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@zl-wang Julian, I've been working on a revision that handles 64-bit values running in a 32-bit JVM, but it makes the code quite ugly. I’ll pull that out as a separate pull request, and I’ll let you decide whether it’s an important enough case to handle, as well as point out any problems with the way that I tackled the problem.

@fjeremic fjeremic self-assigned this Oct 9, 2018
Copy link
Contributor

@fjeremic fjeremic left a comment

Choose a reason for hiding this comment

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

We'll need to address this PR to conform with #2999 in addition to other reviews.

Added support for inlining of the new atomic methods
atomic{AddAndFetch|FetchAndAdd|Swap}{32|64}BitSymbol on Power.  This is
largely a copy of similar support in OpenJ9 for inlining methods of
AtomicInteger and AtomicLong.

Signed-off-by:  Henry Zongaro <[email protected]>
Pull Request 2999 changed replaced use of supportsAtomicAdd with
supportsNonHelper in order to report whether various atomic operations
can be inlined.  Revised Power codegen to use the same.

Signed-off-by:  Henry Zongaro <[email protected]>
Address various review comments, including:

- Look for opportunity to use add immediate instructions for 64-bit
  constant values that are in range.
- Rename resultReg to oldValueReg to better reflect its use
- Avoid an unnecessary copy of the delta value into a new register every
  time through the l{w|d}arx/st{w|d}arx loop.
- Added assertion to verify the number of register dependencies.

Updated inlineDirectCall to reflect new names of nonhelper methods.

Signed-off-by:  Henry Zongaro <[email protected]
@hzongaro
Copy link
Contributor Author

@zl-wang @fjeremic Julian, Filip - I've made revisions that I think addresses your review comments. May I ask you to re-review when you have some time? The one exception is handling 64-bit values on a 32-bit JVM, which I will submit in a follow up PR.

Removed a bad line break from OMRCodeGenerator.hpp and added a const
declaration for a variable that's never modified.

Signed-off-by:  Henry Zongaro <[email protected]>
@fjeremic
Copy link
Contributor

@hzongaro I think you accidentally checked in some huge file as part of your latest commit.

Removed 'code' file that I had accidentally created.

Signed-off-by:  Henry Zongaro <[email protected]>
Removed calls to stopUsingRegister that were incorrect due to
calls to TR::Node::decReferenceCount that would affect the same register.

Also fixed an incorrect check for whether an 8 byte integer value is in the
range of a 4 byte value that relied on the machine's endianness.

Signed-off-by:  Henry Zongaro <[email protected]>
@hzongaro
Copy link
Contributor Author

hzongaro commented Nov 8, 2018

I believe all review comments have been addressed, so I will remove "WIP" from the title.

@hzongaro hzongaro changed the title WIP: Add support for inlining new atomic methods on Power Add support for inlining new atomic methods on Power Nov 8, 2018
Copy link
Contributor

@fjeremic fjeremic left a comment

Choose a reason for hiding this comment

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

I'll wait until @zl-wang approves before launching builds and merging this.

@fjeremic
Copy link
Contributor

fjeremic commented Nov 8, 2018

@genie-omr build plinux,aix

@fjeremic fjeremic merged commit 4ce1e3d into eclipse-omr:master Nov 13, 2018
@hzongaro hzongaro deleted the atomic-power-alt branch November 27, 2018 16:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants