[lworld] RFR: 8374954: [lworld] compiler/ciReplay/TestInliningProtectionDomain.java fails with virtual threads

[Tobias Hartmann]

On Fri, 6 Feb 2026 10:20:28 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> # Issue
> 
> `compiler/ciReplay/TestInliningProtectionDomain.java` fails with virtual threads because it expects method `bar()` not to be inlined (1 line in the log) but it gets inlined instead (5 lines in the log for `bar()` and the cascade of methods inside `bar()`).
> 
> # Cause
> 
> `bar()` relies on `java.lang.Thread` not being loaded but the VM seems to be loading it early on with virtual threads enabled. Apparently this happens because JTreg uses a _Virtual ThreadFactory_ to create virtual threads and this references the `Thread` class and make it resolve early. So, when C2 compiles `ProtectionDomainTestNoOtherCompilationPrivate::test()`, `Thread` is already resolved and the `bar()` inline succeeds.
> 
> Mainline isn't affected as it relies on `Integer` instead of `Thread`. This was previously changed in [JDK-8368939](https://bugs.openjdk.org/browse/JDK-8368939) ([PR](https://github.com/openjdk/valhalla/pull/1651)) as `Integer` resolves early in Valhalla due to boxing classes being automatically added when registering a loader.
> 
> # Fix
> 
> To fix this we can rely on another non-virtual-thread-sensitive `java.lang` class to be returned instead of `Thread`, e.g. `Record`.
> 
> # Testing
> Tier 1-3+

That looks good to me. Quite a brittle test though, it seems.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/2060#pullrequestreview-3763615806