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

[Tom Rodriguez]

On Thu, 22 May 2025 08:04:35 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> 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.
>
> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments

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.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25356#issuecomment-2913383620