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

8253740: [PPC64] Minor interpreter cleanup #385

Closed

Conversation

TheRealMDoerr
Copy link
Contributor

@TheRealMDoerr TheRealMDoerr commented Sep 28, 2020

Template interpreter on PPC64 can be cleaned up after JDK-8253540:
unlock_object has a parameter check_for_exceptions which is now unused.

In addition to that, restore_interpreter_state is redundant after
call_VM(R4_ARG2, CAST_FROM_FN_PTR(address, InterpreterRuntime::member_name_arg_or_null) because it's already included in call_VM.

https://bugs.openjdk.java.net/browse/JDK-8253740


Progress

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

Testing

Linux x64 Windows x64 macOS x64
Build ✔️ (3/3 passed) ✔️ (2/2 passed) ✔️ (2/2 passed)
Test (tier1) ✔️ (9/9 passed) ✔️ (9/9 passed) ✔️ (9/9 passed)

Issue

Reviewers

Download

$ git fetch https://git.openjdk.java.net/jdk pull/385/head:pull/385
$ git checkout pull/385

@bridgekeeper
Copy link

bridgekeeper bot commented Sep 28, 2020

👋 Welcome back mdoerr! 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 Sep 28, 2020
@openjdk
Copy link

openjdk bot commented Sep 28, 2020

@TheRealMDoerr 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 Sep 28, 2020
@mlbridge
Copy link

mlbridge bot commented Sep 28, 2020

Webrevs

@coleenp
Copy link
Contributor

coleenp commented Sep 29, 2020

This looks good but I also noticed that ppc and s390 pass an extra parameter to InterpreterRuntime::monitorenter() also.

@TheRealMDoerr
Copy link
Contributor Author

TheRealMDoerr commented Sep 29, 2020

That's an interesting point: call_VM(monitorenter) uses check_for_exceptions=true on PPC64 and check_for_exceptions=false on s390. check_for_exceptions=true is default, so it's equivalent to omitting the explicit parameter. So PPC64 is implemented like x86 in this matter.

Seems like we have optimized the exception check out for s390. This should be valid because monitorenter uses JRT_ENTRY_NO_ASYNC and doesn't throw any exception. Note that the JIT compiler's version uses assert(!HAS_PENDING_EXCEPTION, "Should have no exception here") in SharedRuntime::monitor_enter_helper.
(monitor_enter_helper uses the CHECK macro which does the check for an exception, but this looks like a bug.)

I think we could assert that in the interpreter's version and use check_for_exceptions=false on all platforms. It's probably not worth optimizing this, but maybe it'd be a good simplification wrt. complexity and readability of the gererated assembly code. At least, it'd be nice to bring the interpreter and the compiler version closer together.
But that's a bit out of scope for this issue.

@mlbridge
Copy link

mlbridge bot commented Sep 29, 2020

Mailing list message from David Holmes on hotspot-dev:

Hi Martin,

On 29/09/2020 7:14 pm, Martin Doerr wrote:

On Tue, 29 Sep 2020 00:02:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

Template interpreter on PPC64 can be cleaned up after JDK-8253540:
unlock_object has a parameter check_for_exceptions which is now unused.

In addition to that, restore_interpreter_state is redundant after
call_VM(R4_ARG2, CAST_FROM_FN_PTR(address, InterpreterRuntime::member_name_arg_or_null) because it's already included
in call_VM.
https://bugs.openjdk.java.net/browse/JDK-8253740

This looks good but I also noticed that ppc and s390 pass an extra parameter to InterpreterRuntime::monitorenter() also.

That's an interesting point: call_VM(monitorenter) uses check_for_exceptions=true on PPC64 and
check_for_exceptions=false on s390. check_for_exceptions=true is default, so it's equivalent to omitting the explicit
parameter. So PPC64 is implemented like x86 in this matter. Seems like we have optimized the exception check out for
s390. This should be valid because monitorenter uses JRT_ENTRY_NO_ASYNC and doesn't throw any exception. Note that the
JIT compiler's version uses assert(!HAS_PENDING_EXCEPTION, "Should have no exception here") in
SharedRuntime::monitor_enter_helper. I think we could assert that in the interpreter's version and use
check_for_exceptions=false on all platforms. It's probably not worth optimizing this, but maybe it'd be a good
simplification wrt. complexity and readability of the gererated assembly code. But that's a bit out of scope for this
issue.

It is not true that monitorenter can't throw exceptions. Contended
monitorenter posts a JVMTI event and the event callback can execute Java
code that triggers an exception. The "no async" just means the callVM
won't actively looking for a pending-async to install, but there could
already be an exception in flight (async or otherwise).

Cheers,
David

@TheRealMDoerr
Copy link
Contributor Author

TheRealMDoerr commented Sep 29, 2020

Hi David,
thanks for reminding me of JVMTI event callbacks. So we need to check s390 code.
And in SharedRuntime::monitor_enter_helper it doesn't make sense to use CHECK macro and then assert(!HAS_PENDING_EXCEPTION, "Should have no exception here").
But this is unrelated to this PPC64 cleanup change.

@mlbridge
Copy link

mlbridge bot commented Sep 30, 2020

Mailing list message from David Holmes on hotspot-dev:

On 29/09/2020 10:52 pm, Martin Doerr wrote:

On Tue, 29 Sep 2020 09:12:37 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

This looks good but I also noticed that ppc and s390 pass an extra parameter to InterpreterRuntime::monitorenter() also.

That's an interesting point: call_VM(monitorenter) uses check_for_exceptions=true on PPC64 and
check_for_exceptions=false on s390. check_for_exceptions=true is default, so it's equivalent to omitting the explicit
parameter. So PPC64 is implemented like x86 in this matter. Seems like we have optimized the exception check out for
s390. This should be valid because monitorenter uses JRT_ENTRY_NO_ASYNC and doesn't throw any exception. Note that the
JIT compiler's version uses assert(!HAS_PENDING_EXCEPTION, "Should have no exception here") in
SharedRuntime::monitor_enter_helper. (monitor_enter_helper uses the CHECK macro which does the check for an exception,
but this looks like a bug.) I think we could assert that in the interpreter's version and use
check_for_exceptions=false on all platforms. It's probably not worth optimizing this, but maybe it'd be a good
simplification wrt. complexity and readability of the gererated assembly code. At least, it'd be nice to bring the
interpreter and the compiler version closer together. But that's a bit out of scope for this issue.

Hi David,
thanks for reminding me of JVMTI event callbacks. So we need to check s390 code.
And in SharedRuntime::monitor_enter_helper it doesn't make sense to use CHECK macro and then
assert(!HAS_PENDING_EXCEPTION, "Should have no exception here"). But this is unrelated to this PPC64 cleanup change.

The assert is somewhat redundant but not wrong, as it it is validating
that the CHECK macro actually worked:

ObjectSynchronizer::enter(h_obj, lock, CHECK);
assert(!HAS_PENDING_EXCEPTION, "Should have no exception here");

expands to:

ObjectSynchronizer::enter(h_obj, lock);
if (HAS_PENDING_EXCEPTION)
return;
assert(!HAS_PENDING_EXCEPTION, "Should have no exception here");

Cheers,
David

@TheRealMDoerr
Copy link
Contributor Author

TheRealMDoerr commented Sep 30, 2020

Hi Coleen,
I've removed the explicit check_exceptions=true parameters on PPC64 so it looks more like x86.
I'll take a look at s390 separately.

Hi David,
the assert(!HAS_PENDING_EXCEPTION, "Should have no exception here") is not wrong, but confusing IMHO.

Thanks for looking at this.

Copy link
Contributor

@RealLucy RealLucy left a comment

The change looks good to me.
Thank you for the cleanup work.

@openjdk
Copy link

openjdk bot commented Oct 9, 2020

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

8253740: [PPC64] Minor interpreter cleanup

Reviewed-by: lucy

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

  • b1448da: 8253900: SA: wrong size computation when JVM was built without AOT
  • 2bc8bc5: 8254265: s390 and linux 32 bit builds broken
  • 4f9a1ff: 8254073: Tokenizer improvements (revised)
  • 9cecc16: 8254244: Some code emitted by TemplateTable::branch is unused when running TieredCompilation
  • a95590d: 8254285: G1: Remove "What is this about" comment in G1CollectedHeap.cpp
  • 0230781: 8254175: Build no-pch configuration in debug mode for submit checks
  • b9873e1: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing
  • a2f6519: 8233685: Test tools/javac/modules/AddLimitMods.java fails
  • 70be8c7: 8253965: Delete the outdated java.awt.PeerFixer class
  • ced46b1: 8254190: [s390] interpreter misses exception check after calling monitorenter
  • ... and 157 more: https://git.openjdk.java.net/jdk/compare/1ae6b533fbba433e64868aa3b6846041e3a91136...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 Oct 9, 2020
@TheRealMDoerr
Copy link
Contributor Author

TheRealMDoerr commented Oct 9, 2020

/integrate

@openjdk openjdk bot closed this Oct 9, 2020
@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 Oct 9, 2020
@openjdk
Copy link

openjdk bot commented Oct 9, 2020

@TheRealMDoerr Since your change was applied there have been 167 commits pushed to the master branch:

  • b1448da: 8253900: SA: wrong size computation when JVM was built without AOT
  • 2bc8bc5: 8254265: s390 and linux 32 bit builds broken
  • 4f9a1ff: 8254073: Tokenizer improvements (revised)
  • 9cecc16: 8254244: Some code emitted by TemplateTable::branch is unused when running TieredCompilation
  • a95590d: 8254285: G1: Remove "What is this about" comment in G1CollectedHeap.cpp
  • 0230781: 8254175: Build no-pch configuration in debug mode for submit checks
  • b9873e1: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing
  • a2f6519: 8233685: Test tools/javac/modules/AddLimitMods.java fails
  • 70be8c7: 8253965: Delete the outdated java.awt.PeerFixer class
  • ced46b1: 8254190: [s390] interpreter misses exception check after calling monitorenter
  • ... and 157 more: https://git.openjdk.java.net/jdk/compare/1ae6b533fbba433e64868aa3b6846041e3a91136...master

Your commit was automatically rebased without conflicts.

Pushed as commit e9c1905.

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

@TheRealMDoerr TheRealMDoerr deleted the 8253740_ppc64_interp_cleanup branch Oct 9, 2020
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
3 participants