On Wed, 24 Sep 2025 21:17:05 GMT, Sergey Bylokhov <[email protected]> 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
