On Wed, 24 Sep 2025 21:54:44 GMT, Phil Race <[email protected]> wrote:
>> 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 ? What's the command you are using to run the tests ? make test .... something .. ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27397#discussion_r2377174293
