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

8268052: [JVMCI] non-default installed code must be marked as in_use #4283

Closed
wants to merge 1 commit into from

Conversation

@tkrodriguez
Copy link
Contributor

@tkrodriguez tkrodriguez commented Jun 1, 2021


Progress

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

Issue

  • JDK-8268052: [JVMCI] non-default installed code must be marked as in_use

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 4283

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

Using diff file

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

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Jun 1, 2021

👋 Welcome back never! 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.

@@ -1784,6 +1785,8 @@ JVMCI::CodeInstallResult JVMCIRuntime::register_method(JVMCIEnv* JVMCIENV,
MutexLocker ml(CompiledMethod_lock, Mutex::_no_safepoint_check_flag);
if (nm->make_in_use()) {
method->set_code(method, nm);
} else {
result = JVMCI::nmethod_reclaimed;
Copy link
Contributor Author

@tkrodriguez tkrodriguez Jun 1, 2021

Is it really possible for the make_in_use call to fail if the nmethod is nmethodLocker'ed? The copy of this logic in ciEnv.cpp doesn't treat a failure of this call to be a compilation failure but it certainly seems like it should. It would be better if it weren't possible for this call to fail.

Copy link
Contributor

@fisk fisk Jun 1, 2021

The issue is that the nmethod is published to Method code pointers before it is made in_use. That means a concurrent JavaThread may enter it and make the nmethod not_entrant, before it is made in_use. Making it in_use after it became not_entrant would cause a non-monotonic state transition which isn't great and comes with problems.
I agree it feels like there is room for improvement here, but at least that is the reason why make_in_use can fail; to prevent non-monotonic state transitions in this race.

Copy link
Contributor Author

@tkrodriguez tkrodriguez Jun 1, 2021

Ok. I see the intent. In that case it seems like the reordering of the in_use and set_code calls was the important part of JDK-8226705. It can't actually fail here since it hasn't been published until the following line, right? Or is there some other way the nmethod is published? Why couldn't the in_use state be set at the end of the nmethod factory method?

Copy link
Contributor

@fisk fisk Jun 2, 2021

I think it's published in the code cache and we had trouble with code walkers using only the CodeCache_lock to shoot down nmethods, but not the Compile_lock. If the walkers used the Compile_lock too then they wouldn't pick these up until they are fully installed. Plenty of room for improvements...

Copy link
Contributor Author

@tkrodriguez tkrodriguez Jun 2, 2021

Yes, directly scanning the code cache seemed like the only other path. It's unfortunate that the nmethod lifecycle seems to have gotten more complicated instead of less so. So it could really fail in some exceptionally weird circumstances.

Copy link
Contributor

@fisk fisk Jun 2, 2021

Yes, directly scanning the code cache seemed like the only other path. It's unfortunate that the nmethod lifecycle seems to have gotten more complicated instead of less so. So it could really fail in some exceptionally weird circumstances.

Yes indeed. This is what motivated my work on https://openjdk.java.net/jeps/8221828
In my prototype, after removing inline caches, replacing it with an optimized table driven approach to method invocations, I could reduce the nmethod lifecycle down to a boolean: is_in_use(), which is true or false. No zombies, no unloaded, no unloading, no is_alive, no transient installation state, no separate "nmethod locking mechanism". I hope it hits mainline one day, because it reduces so much risk in our code base, by removing a huge amount of state machinery.

@openjdk
Copy link

@openjdk openjdk bot commented Jun 1, 2021

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

  • hotspot-compiler

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.

@mlbridge
Copy link

@mlbridge mlbridge bot commented Jun 1, 2021

Webrevs

@tkrodriguez
Copy link
Contributor Author

@tkrodriguez tkrodriguez commented Jun 7, 2021

Could I get some review for this?

@dougxc
Copy link
Member

@dougxc dougxc commented Jun 7, 2021

LGTM

@openjdk
Copy link

@openjdk openjdk bot commented Jun 8, 2021

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

8268052: [JVMCI] non-default installed code must be marked as in_use

Reviewed-by: kvn, dnsimon

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

  • 00c88f7: 8266918: merge_stack in check_code.c add NULL check
  • 8105478: 8268165: AsyncLogging will crash if rotate() fails
  • fd91b2a: 8265440: IGV: make node selection more visible
  • 81bad59: 8257774: G1: Trigger collect when free region count drops below threshold to prevent evacuation failures
  • 341f676: 8267908: linux: thread_native_entry can scribble on stack frame
  • f40c89e: 8267209: Child threads should defer logging to after child-parent handshake
  • ae986bc: 8266749: AArch64: Backtracing broken on PAC enabled systems
  • 36c4e5f: 8267187: Remove deprecated constructor for Log
  • fc08af5: 8174222: LambdaMetafactory: validate inputs and improve documentation
  • 5e557d8: 8266967: debug.cpp utility find() should print Java Object fields.
  • ... and 128 more: https://git.openjdk.java.net/jdk/compare/f5634fe39db44d5d504e1b2f8aba1bca3e479a89...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.

@vnkozlov
Copy link
Contributor

@vnkozlov vnkozlov commented Jun 8, 2021

@dougxc You need to go to 'File changed' tab and press 'Review changes' and 'Approve' for your review to be counted.

@openjdk openjdk bot added the ready label Jun 8, 2021
dougxc
dougxc approved these changes Jun 8, 2021
@tkrodriguez
Copy link
Contributor Author

@tkrodriguez tkrodriguez commented Jun 9, 2021

/integrate

@openjdk openjdk bot closed this Jun 9, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Jun 9, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Jun 9, 2021

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

  • bb3d226: 8238213: Method resolution should stop on static error
  • 81fdeb5: 8268417: Add test from JDK-8268360
  • caf7f49: 8268122: Add specific gc cause for G1 full collections
  • 43e38a1: 8268377: Windows 32bit build fails after JDK-8268174
  • 5fbb62c: 8268163: Change the order of fallback full GCs in G1
  • 7b1e402: 8266598: Exception values for AnnotationTypeMismatchException are not always informative
  • 13d6180: 8264859: Implement Context-Specific Deserialization Filters
  • dd34a4c: 8268372: ZGC: dynamically select the number of concurrent GC threads used
  • 4388959: 8268056: Update java.net and java.nio to use switch expressions
  • 9cfd560: 8267663: [vector] Add unsigned comparison operators on AArch64
  • ... and 164 more: https://git.openjdk.java.net/jdk/compare/f5634fe39db44d5d504e1b2f8aba1bca3e479a89...master

Your commit was automatically rebased without conflicts.

Pushed as commit db45ff0.

💡 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
4 participants