RFR: 8367795: HeadlessMalfunctionTest may fail due to timeout

[Sergey Bylokhov]

On Wed, 24 Sep 2025 20:54:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> The default timeout factor for tests was changed by [JDK-8260555](https://bugs.openjdk.org/browse/JDK-8260555). Since then, the HeadlessMalfunctionTest may occasionally fail on some systems when run in parallel with other tests. When executed alone, it usually completes in 30–40 seconds, but under CPU spikes it can take up to ~120 seconds, which can occasionally cause it to fail.
>
> test/jdk/java/awt/Headless/HeadlessMalfunctionTest.java line 41:
> 
>> 39:  *              HeadlessMalfunctionAgent
>> 40:  *              HeadlessMalfunctionAgent$1
>> 41:  * @run driver/timeout=240 HeadlessMalfunctionTest
> 
> On my system this runs in about 2.5 seconds.
> Our CI system  -which runs jtreg with concrurrency=4 - on a Linux VM reports a total of 12 seconds (including compilation) and the actual test execution is about 6 seconds.
> 
> That was x64 - a Linux ARM system was a total of 10 seconds.
> 
> So if you need 240 seconds, then I think you need to look into why it is > 10x slower than I see.
> 
> 
> #section:driver
> ----------messages:(8/309)----------
> command: driver HeadlessMalfunctionTest
> reason: User specified action: run driver HeadlessMalfunctionTest 
> started: Wed Sep 24 19:20:07 UTC 2025
> Mode: othervm
> Additional options from @modules: --add-modules java.desktop
> Process id: 2328064
> finished: Wed Sep 24 19:20:13 UTC 2025
> elapsed time (seconds): 6.077

Just tested it on the system:


Build performance summary:
 * Build jobs:     48
 * Memory limit:   95498 MB



command: driver HeadlessMalfunctionTest
reason: User specified action: run driver HeadlessMalfunctionTest 
started: Wed Sep 24 21:08:33 UTC 2025
Mode: othervm
Additional options from @modules: --add-modules java.desktop
Process id: 101951
finished: Wed Sep 24 21:09:54 UTC 2025
elapsed time (seconds): 80.882


It only becomes slow when concurrency is high enough. I don’t need 240; something around 140 should be sufficient. The value 240 was chosen just in case, for slower and highly concurrent ARM systems.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27397#discussion_r2377099890