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

[Tobias Hartmann]

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

Nice analysis, Marc! Fix looks good to me, I just added a few suggestions.

src/hotspot/share/code/dependencies.hpp line 120:

> 118:     // was assumed to be callable with the scalar calling convention.
> 119:     // In case of a mismatch, because of future class loading, the
> 120:     // nmethod must be recompiled to use the non-scalar calling convention.

This comment is a bit imprecise. The problem is that **some** argument of this method was assumed to be always passed in scalarized form. Due to a mismatch with two super methods (one assuming scalarized and one assuming non-scalarized), all **callers** of this method (via virtual calls) now need to be recompiled. Right? Maybe refer to the code in `CompiledEntrySignature::compute_calling_conventions` for details.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1677#pullrequestreview-3338417741
PR Review Comment: https://git.openjdk.org/valhalla/pull/1677#discussion_r2431166901