RFR: 8368668: Several vmTestbase/vm/gc/compact tests timed out on large memory machine [v2]

[SendaoYan]

On Fri, 26 Sep 2025 05:23:22 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>>> We run them concurrently
>> 
>> The file such as test/hotspot/jtreg/vmTestbase/vm/gc/compact/Compact_InternedStrings/TEST.properties which contain config `exclusiveAccess.dirs=.` will make sure these tests run serial, jtreg will ignore the '-conc' parameter when run these tests.
>> 
>>> If you execute test with some specific configuration
>> 
>> My test command is 'jtreg -v:fail,error,time -timeout:10 -nr -w tmp test/hotspot/jtreg/vmTestbase/vm/gc/compact/Compact_InternedStrings_Strings/TestDescription.java', there is no specific configuration. I think the biggest difference maybe my machine has huge physical memory, and many cpu core number.
>> 
>> The test log shows this test will run finish 250 seconds on my machine, seems that the test will detect all the available memory automaticly and the huge memory will consume lots of time to finish. On my machine this test use 448 threads and 30GB max memory to test. So I want to limit the memory usage in test by jvm option `-Xmx2G`.
>> 
>> The partial log snippet from vmTestbase/vm/gc/compact/Compact_InternedStrings_Strings/TestDescription.jtr
>> Max memory: 32178700288
>> Sleep time: 500
>> Iterations: 0
>> Number of threads: 448
>> 
>> [TestDescription.jtr.log](https://github.com/user-attachments/files/22551569/TestDescription.jtr.log)
>> 
>> After add the `-Xmx2G`, the test will detect use 64 threads and 2GB max memory to test. Another solution maybe use test parameter -t 16 to limit the test thread.
>> 
>> 
>> The test environmental info:
>> $ lscpu | head -n 8
>> Architecture:                    x86_64
>> CPU op-mode(s):                  32-bit, 64-bit
>> Address sizes:                   52 bits physical, 57 bits virtual
>> Byte Order:                      Little Endian
>> CPU(s):                          224
>> On-line CPU(s) list:             0-223
>> Vendor ID:                       GenuineIntel
>> Model name:                      Intel(R) Xeon(R) Platinum 8480+
>> $ free -h
>>                total        used        free      shared  buff/cache   available
>> Mem:           755Gi       8.6Gi       720Gi       4.0Mi        26Gi       742Gi
>> Swap:          8.0Gi        18Mi       8.0Gi
>
> Thank you for info.
> 
> The original idea is to scale these tests based on the execution host and not limit them to any particular size. 
> 
> I think that would be better to change the execution for your run assuming that your host is not typical commodity HW. You can set Xmx or RamPercentage for you runs instead of changing tests. Also, the number of CPU and thus the number of threads in stress tests might cause time consuming delays.

The default timeout factor ie set to 4 before JDK-8260555, after JDK-8260555 the default timeout factor is set to 1, and this cause these stress tests run timed out. If we do not change the stress mode for these tests, should we increase the default timeout value from 120s to 480s, this will make these tests run normally for most of the machines.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27488#discussion_r2380987433