RFR: 8367795: HeadlessMalfunctionTest may fail due to timeout

[Phil Race]

On Wed, 24 Sep 2025 21:17:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> 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.

" * Build jobs:     48"

That's the build jobs from configure.
I've often wondered about that since it is basically saying "I'm going to use everything".

Is that somehow propagated to jtreg concurrency too ? 
Or are you building + testing in parallel ?

If it takes 80 seconds for this test, I wonder why lots of other tests aren't also having a  timeout problem when you run them ?
Why is this test special ?
Or was the removal of the timeout factor too optimistic ?
Does any other test on your config come close to timeout ?

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

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