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

[Marc Chevalier]

On Tue, 14 Oct 2025 08:59:48 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> 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...

This pull request has now been integrated.

Changeset: 2da79ac2
Author:    Marc Chevalier <mchevalier at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2da79ac29d9734ecf36f562924b0af1ab68beef9
Stats:     631 lines in 8 files changed: 131 ins; 112 del; 388 mod

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

Reviewed-by: thartmann

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

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