jmx-dev RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining [v2]

[Richard Reingruber]

On Fri, 4 Jul 2025 08:14:19 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis.
>> 
>> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled.
>> 
>> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing.
>> 
>> Failed inlining on x86_64 with TieredCompilation disabled:
>> 
>> 
>> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1
>> 
>> [...]
>> 
>> STDOUT:
>> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true
>>                             @ 1   java.util.concurrent.atomic.AtomicBoolean::get (13 bytes)   inline (hot)
>>                             @ 11   java.lang.StringBuffer::<init> (7 bytes)   inline (hot)   late inline succeeded (string method)
>>                               @ 3   java.lang.AbstractStringBuilder::<init> (39 bytes)   inline (hot)
>>                                 @ 1   java.lang.Object::<init> (1 bytes)   inline (hot)
>>                             @ 16   java.lang.System::currentTimeMillis (0 bytes)   (intrinsic)
>>               s             @ 19   java.lang.StringBuffer::append (13 bytes)   failed to inline: already compiled into a big method
>>               s             @ 24   java.lang.StringBuffer::toString (44 bytes)   inline (hot)   late inline succeeded (string method)
>>               s               @ 1   java.lang.StringBuffer::length (5 bytes)   accessor
>>                               @ 24   java.lang.String::<init> (98 bytes)   failed to inline: already compiled into a big method
>>                             @ 30   java.util.concurrent.atomic.AtomicReference::set (6 bytes)   accessor
>> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false
>> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false
>> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false
>> 
>> [...]
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow vm.debug

> About the test and debug mode, we had that kind of conversation in #25958 Windows and Macosx were likely to timeout in debug builds, Linux was OK for me. Not sure if the inlining requests here affect that much, will be interesting to see.

You got timeouts likely because the test searched for eliminated locking in the thread dumps in an endless loop but lock elimination has failed (very early) due to unfavorable inlining.

Inlining depends on timing because jit compilation runs asynchronously in the background. It affects inlining if a call target is already compiled into a big nmethod (see `failed to inline: already compiled into a big method` above). Calls critical for lock elimination will still be inlined because of the `CompileCommand` inlining requests.

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

PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3043813314