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

[Tobias Hartmann]

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

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

Commit messages:
 - Missing aarch64 fix
 - Fixed native methods
 - Fixed initialization of orig_pc
 - 8293994: [lworld] Deoptimization from nmethod entry barrier breaks scalarized calling convention

Changes: https://git.openjdk.org/valhalla/pull/773/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=773&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293994
  Stats: 335 lines in 22 files changed: 171 ins; 98 del; 66 mod
  Patch: https://git.openjdk.org/valhalla/pull/773.diff
  Fetch: git fetch https://git.openjdk.org/valhalla pull/773/head:pull/773

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