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

[Leonid Mesnik]

On Fri, 26 Sep 2025 02:59:26 GMT, SendaoYan <syan at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/vm/gc/compact/Compact_InternedStrings_Strings/TestDescription.java line 41:
>> 
>>> 39:  * @run main/othervm
>>> 40:  *      -XX:-UseGCOverheadLimit
>>> 41:  *      -Xmx2G
>> 
>> It is not he good idea to fix heap size for the tests. We run them concurrently and heap size might be smaller then 2GB. 
>> The test should be executed for 30 seconds only and complete in 2 minutes.
>> If you execute test with some specific configuration - it might be needed to add custom timeout factor. 
>> Can you please share the host and run confguration for failures?
>
>> 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.

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

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