RFR: JDK-8267371: Concurrent gtests take too long

[Thomas Stuefe]

On Wed, 19 May 2021 08:30:01 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> More than half of the total runtime of the gtests is currently used by just three tests:
> 
> - VirtualSpace.os_reserve_space_concurrent_vm
> - VirtualSpace.os_virtual_space_concurrent_vm
> - os_linux.reserve_memory_special_concurrent_vm
> 
> These tests do concurrent tests with 30 threads, with a timeout of 15 seconds each.
> 
> Since we run the gtests with several configurations (see hotspot/jtreg/gtests) these numbers multiply, which hurts especially when run as part of tier1. I think we can safely reduce the timeouts, still have good test coverage and recover some of the gtest runtime.
> 
> ---
> 
> The patch reduces the timeout to 5 seconds, which reduces the time for one gtest by 30 seconds from 80 seconds down to 50 seconds.

Hi guys,

I am not convinced these tests make a lot of sense. I leave them in for now because they may be of use on AIX where we maintain global data structures and also possibly for stress-testing NMT (I work on JDK-8256844: "Make NMT late-initializable" which will make it possible to enable NMT in gtests, and thereby stress-testing NMT itself). Beyond that, they are just hitting mmap() without really testing VM infrastructure.

I disable `reserve_memory_special_concurrent` for non-large-page-runs. And I reduced the time to run further from 5 to 3 seconds, and the number of threads from 30 to 5.

Like @stefank I also think the gtests are the wrong place for these kind of tests. Jtreg tests are a better place for this, offering finer grained control and better thread facilities. I remember now we had this discussion when these tests were introduced (https://mail.openjdk.java.net/pipermail/hotspot-dev/2021-March/049533.html).

Well, maybe we can do something about this in the future (split them out, remove them, move them back to jtreg...).

Thanks, Thomas

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

PR: https://git.openjdk.java.net/jdk/pull/4110