8357424: [JVMCI] Avoid incrementing decompilation count for hosted compiled nmethod

[mur47x111]

Hosted Truffle compilations are installed on the OptimizedCallTarget#profiledPERoot method. Any deoptimization contributes to its decompile count, which can easily exceed the PerMethodRecompilationCutoff threshold, permanently preventing highest tier compilation on this method. This PR exempts hosted compilations from this cutoff by ensuring their decompile count is not incremented for hosted compiled nmethods.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8357424: [JVMCI] Avoid incrementing decompilation count for hosted compiled nmethod (Bug - P4)

Reviewers

• Doug Simon (@dougxc - Reviewer) 🔄 Re-review required (review applies to b72213ae)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/25356/head:pull/25356
$ git checkout pull/25356

Update a local copy of the PR:
$ git checkout pull/25356
$ git pull https://git.openjdk.org/jdk.git pull/25356/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 25356

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/25356.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back yzheng! 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]

@mur47x111 This change is no longer ready for integration - check the PR body for details.

[openjdk]

@mur47x111 The following labels will be automatically applied to this pull request:

• graal
• hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 06: Full - Incremental (f253c0a8)
• 05: Full - Incremental (9d24428e)
• 04: Full - Incremental (57fe5307)
• 03: Full - Incremental (b72213ae)
• 02: Full - Incremental (e66c16d1)
• 01: Full - Incremental (ef4a4c98)
• 00: Full (8fcd7104)

[dougxc]

Looks good.

[tkrodriguez]

I think there are two levels of counters that we might want to disable. We definitely want to stop deopts and recompilations from marking the method not compilable which the current change does. Additionally JVMCIRuntime::register_method will perform this logic if validate_compile_task_dependencies fails and I don't think we want that. I think the new !is_default guard idiom should be in a helper like nmethod::is_jvmci_hosted. Do we use the hosted language elsewhere?

The second level is to stop all counter updates in hosted compiles, for similar reasons. Those updates won't lead to disabling compilation but they will quickly lead to saturating of all the counters which is fairly pointless but probably benign. This would be done by setting update_trap_state to false for hosted nmethods. That also has the effect of keeping inc_recompile_count false. I think that's the right thing to do but I'd want to make sure that we test truffle workloads with those changes before making that change to make sure there isn't some subtle problem with that change.

[mur47x111]

@tkrodriguez by stop all counter updates in hosted compiles you mean the trap-related counters, right?

[tkrodriguez]

Yes. Any update to the MDO for hosted compiles doesn't seem useful I think.

[dougxc]

Someone (like me!) is going to see this code a while from now and try remember why the decompilation count is not being decremented for JVMCI hosted nmethods. I think it's worth adding a comment.

[JohnTortugo]

A comment here will probably be helpful as well.