RFR: 8367795: HeadlessMalfunctionTest may fail due to timeout
Phil Race
prr at openjdk.org
Wed Sep 24 22:00:39 UTC 2025
On Wed, 24 Sep 2025 21:54:44 GMT, Phil Race <prr at openjdk.org> 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
More information about the client-libs-dev
mailing list