[lworld] Integrated: 8293994: [lworld] Deoptimization from nmethod entry barrier breaks scalarized calling convention

[Tobias Hartmann]

On Mon, 3 Oct 2022 11:41:25 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The recent sweeper removal ([JDK-8290025](https://bugs.openjdk.org/browse/JDK-8290025)) always enabled nmethod entry barriers. This revealed an issue where deoptimization from the slow path (`-XX:+DeoptimizeNMethodBarriersALot`) breaks the scalarized calling convention because once deoptimization is triggered at nmethod entry via `BarrierSetNMethod::deoptimize`, we already converted the calling convention and can't easily go back. Also with method handle invocation logic, we can not tell in `SharedRuntime::handle_wrong_method` which calling convention the callee nmethod converted to.
> 
> After evaluating several ideas, I found that the cleanest solution is to have an own nmethod entry barrier per entry point right before converting calling conventions.
> 
> While debugging, I discovered similar issues with the class init barriers, that I'll address in a follow-up fix ([JDK-8294013](https://bugs.openjdk.org/browse/JDK-8294013)).
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: ee15e2d9
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ee15e2d905edf29ed7660ca057d6cadb69de3f87
Stats:     335 lines in 22 files changed: 171 ins; 98 del; 66 mod

8293994: [lworld] Deoptimization from nmethod entry barrier breaks scalarized calling convention

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

PR: https://git.openjdk.org/valhalla/pull/773