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

8256368: Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers #1453

Closed
wants to merge 2 commits into from

Conversation

iwanowww
Copy link

@iwanowww iwanowww commented Nov 26, 2020

Method linkage of invokehandle instructions involve an upcall into Java (MethodHandleNatives::linkMethod), but the result is not cached. Unless the upcall behaves idempotently (which is highly desirable, but not guaranteed), repeated invokehandle resolution attempts enter a vicious cycle in tiered mode: switching to a higher tier involves call site re-resolution in generated code, but re-resolution installs a fresh method which puts execution back into interpreter.

(Another prerequisite is no inlining through a invokehandle which doesn't normally happen in practice - relevant methods are marked w/ @ForceInline - except some testing modes, -Xcomp in particular.)

Proposed fix is to inspect ConstantPoolCache first. Previous resolution attempts from interpreter and C1 records their results there and it stabilises the execution.

Testing:

  • failing test
  • tier1-4

Progress

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

Testing

Linux additional Linux x64 Linux x86 Windows x64 macOS x64
Build ✔️ (8/8 passed) ✔️ (2/2 passed) ❌ (2/2 failed) ✔️ (2/2 passed) ❌ (2/2 failed)
Test (tier1) ❌ (1/9 failed) ✔️ (9/9 passed)

Failed test tasks

Issue

  • JDK-8256368: Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers

Reviewers

Download

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

@bridgekeeper
Copy link

bridgekeeper bot commented Nov 26, 2020

👋 Welcome back vlivanov! 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
Copy link

openjdk bot commented Nov 26, 2020

@iwanowww The following label will be automatically applied to this pull request:

  • hotspot-runtime

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-runtime hotspot-runtime-dev@openjdk.org label Nov 26, 2020
@iwanowww iwanowww changed the title Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers. 8256368: Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers Nov 26, 2020
@iwanowww
Copy link
Author

/label add hotspot-compiler

@openjdk openjdk bot added the hotspot-compiler hotspot-compiler-dev@openjdk.org label Nov 26, 2020
@openjdk
Copy link

openjdk bot commented Nov 26, 2020

@iwanowww
The hotspot-compiler label was successfully added.

@iwanowww iwanowww marked this pull request as ready for review November 26, 2020 13:45
@openjdk openjdk bot added the rfr Pull request is ready for review label Nov 26, 2020
@mlbridge
Copy link

mlbridge bot commented Nov 26, 2020

Webrevs

Copy link
Member

@cl4es cl4es left a comment

Choose a reason for hiding this comment

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

Nice!

@openjdk
Copy link

openjdk bot commented Nov 27, 2020

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

8256368: Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers

Reviewed-by: redestad, coleenp

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

  • d51e2ab: 8256986: [PPC64] C2 crashes when accessing nonexisting jvms of CallLeafDirectNode
  • 644271e: 8248566: Make API docs more usable on mobile browsers
  • 53d1444: 8244535: JavaDoc search is overly strict with letter case
  • 78fdb65: 8254893: Fix display of search tag results without holder information
  • 20525d2: 8257149: Improve G1 Service thread task scheduling to guarantee task delay
  • f2f3ba9: 8242652: Throw SkippedException if no JS engine availabe in TestSearchScript
  • ee99686: 8252645: Change time measurements in G1ServiceThread to only account remembered set work
  • a3eec39: 8257181: s390x builds are very noisy with gc-sections messages
  • 9a468d8: 8256757: Incorrect MachCallRuntimeNode::ret_addr_offset() for CallLeafNoFP on x86_32
  • 2215e5a: 8255351: Add detection for Graviton 2 CPUs
  • ... and 26 more: https://git.openjdk.java.net/jdk/compare/26e6cb3eb9a68ded9b0db6bce86afd4523e4c741...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 Nov 27, 2020
Copy link
Contributor

@coleenp coleenp left a comment

Choose a reason for hiding this comment

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

Looks great. I had one question in the code.

bool LinkResolver::resolve_previously_linked_invokehandle(CallInfo& result, const LinkInfo& link_info, const constantPoolHandle& pool, int index, TRAPS) {
int cache_index = ConstantPool::decode_cpcache_index(index, true);
ConstantPoolCacheEntry* cpce = pool->cache()->entry_at(cache_index);
if (!cpce->is_f1_null()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

If f1 is non-null any racing resolution is complete. Can you double check if that's also the case for indy_resolution_failed?

Copy link
Member

Choose a reason for hiding this comment

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

My reading is that a non-null f1 means any resolution races is complete and writes to indy_resolution_failed (part of flags) is done before writing f1, see comments in and logic in ConstantPoolCacheEntry::set_method_handle_common. It thus seem consistent and correct to resolve successfully here, no?

@bridgekeeper
Copy link

bridgekeeper bot commented Dec 25, 2020

@iwanowww 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!

@bridgekeeper
Copy link

bridgekeeper bot commented Jan 22, 2021

@iwanowww This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot-compiler hotspot-compiler-dev@openjdk.org hotspot-runtime hotspot-runtime-dev@openjdk.org ready Pull request is ready to be integrated rfr Pull request is ready for review
3 participants