On Wed, 24 Sep 2025 20:54:48 GMT, Phil Race <[email protected]> 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

Reply via email to