[lworld] RFR: 8369185: [lworld] Wrong execution in TestMismatchHandling after regenerating TestMismatchHandling.jcod [v2]

[Marc Chevalier]

> When regenerating `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.jcod`, the preload attribute are back, after being removed in [8325660: [lworld] Update C2 to support new value construction scheme from JEP 401](https://bugs.openjdk.org/browse/JDK-8325660). This change basically disabled the test `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestMismatchHandling.java`. It is not quite clear why the test broke in between, but it doesn't work now! It seems there are two problems.
> 
> The symptom is a wrong execution: we get a null pointer exception, when the pointer is clearly not null. The setup is around a call where the callee takes a value object as parameter (non-receiver), but the method happens to be mismatch, as detailed in [8301007: [lworld] Handle mismatches of the preload attribute in the calling convention](https://bugs.openjdk.org/browse/JDK-8301007). The caller is C2-compiled, the callee is interpreted.
> 
> The caller is correctly compiled to pass a pointer to the callee, but the adapter is expecting a scalar convention, and interpret everything wrong, leading to the wrong execution.
> 
> First problem is that optimized virtual calls are wrongly expected to never use the non-scalar convention:
> https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/runtime/sharedRuntime.cpp#L1374-L1376
> 
> This fixes the original problems, but create a lot more! Well, just flavor of the same thing.
> 
> They all come from piggybacking on the `evol_method` dependency that is used for JVMTI. This have various side effects that makes the code fail assertions a bit everywhere. Overall, dependencies coming from breakpoints are confused with some coming from mismatch calling convention, and some functions are used in both context, but not all. For instance (I might be a blurry on the details), it happens that a function is marked as having a mismatch calling convention, but later, some JVMTI related code will read the dependency as the existence of breakpoints (or something related), and refuse to compile it, making the test fail with `AbortVMOnCompilationFailure`. Distinguishing the cases becomes too complicated: while we can probably tell whether we added the dependency for JVMTI- or convention-related reasons, it is painful to propagate what we are looking for down the chain of calls. The best, and simplest, way is to introduce a new kind of dependency for calling convention mismatch
 . It mostly behaves live the `evol_method` but it's not the sa...

Marc Chevalier has updated the pull request incrementally with two additional commits since the last revision:

 - comment
 - review

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1677/files
  - new: https://git.openjdk.org/valhalla/pull/1677/files/524be8bc..c7c14ec7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1677&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1677&range=00-01

  Stats: 26 lines in 7 files changed: 6 ins; 1 del; 19 mod
  Patch: https://git.openjdk.org/valhalla/pull/1677.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1677/head:pull/1677

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