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