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

tkrodriguez · 2021-06-01T15:52:22Z

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

Vladimir Kozlov (@vnkozlov - Reviewer)
Doug Simon (@dougxc - Committer)

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

The text was updated successfully, but these errors were encountered:

bridgekeeper · 2021-06-01T15:53:22Z

👋 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.

tkrodriguez · 2021-06-01T15:54:30Z

src/hotspot/share/jvmci/jvmciRuntime.cpp

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


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.

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.

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?

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...

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, 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 · 2021-06-01T15:55:29Z

@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 · 2021-06-01T15:59:35Z

Webrevs

00: Full (5ae1a5b5)

tkrodriguez · 2021-06-07T19:30:36Z

Could I get some review for this?

dougxc · 2021-06-07T19:31:46Z

LGTM

openjdk · 2021-06-08T02:32:58Z

@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 · 2021-06-08T02:33:01Z

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

tkrodriguez · 2021-06-09T17:33:16Z

/integrate

openjdk · 2021-06-09T17:34:51Z

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

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

5ae1a5b

tkrodriguez reviewed Jun 1, 2021

View changes

openjdk bot added hotspot-compiler rfr labels Jun 1, 2021

vnkozlov approved these changes Jun 8, 2021

View changes

openjdk bot added the ready label Jun 8, 2021

dougxc approved these changes Jun 8, 2021

View changes

openjdk bot closed this Jun 9, 2021

openjdk bot added integrated and removed ready rfr labels Jun 9, 2021

openjdk / jdk Public

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

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

tkrodriguez commented Jun 1, 2021 •

edited by openjdk bot

bridgekeeper bot commented Jun 1, 2021

tkrodriguez Jun 1, 2021

fisk Jun 1, 2021

tkrodriguez Jun 1, 2021

fisk Jun 2, 2021

tkrodriguez Jun 2, 2021

fisk Jun 2, 2021

openjdk bot commented Jun 1, 2021

mlbridge bot commented Jun 1, 2021

tkrodriguez commented Jun 7, 2021

dougxc commented Jun 7, 2021

openjdk bot commented Jun 8, 2021 •

edited

vnkozlov commented Jun 8, 2021

tkrodriguez commented Jun 9, 2021

openjdk bot commented Jun 9, 2021

openjdk / jdk Public

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

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

Conversation

tkrodriguez commented Jun 1, 2021 • edited by openjdk bot

Progress

Issue

Reviewers

Reviewing

bridgekeeper bot commented Jun 1, 2021

tkrodriguez Jun 1, 2021

fisk Jun 1, 2021

tkrodriguez Jun 1, 2021

fisk Jun 2, 2021

tkrodriguez Jun 2, 2021

fisk Jun 2, 2021

openjdk bot commented Jun 1, 2021

mlbridge bot commented Jun 1, 2021

Webrevs

tkrodriguez commented Jun 7, 2021

dougxc commented Jun 7, 2021

openjdk bot commented Jun 8, 2021 • edited

vnkozlov commented Jun 8, 2021

tkrodriguez commented Jun 9, 2021

openjdk bot commented Jun 9, 2021

tkrodriguez commented Jun 1, 2021 •

edited by openjdk bot

openjdk bot commented Jun 8, 2021 •

edited