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

[Damon Fenacci]

On Fri, 6 Feb 2026 15:03:01 GMT, Tobias Hartmann <thartmann 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.

Thank you for your review @TobiHartmann.
A bit brittle indeed. I hope a bit less now.

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

PR Comment: https://git.openjdk.org/valhalla/pull/2060#issuecomment-3869785214