RFR: 8372241: Add GTestCheckers
Axel Boldt-Christmas
aboldtch at openjdk.org
Thu Nov 20 08:44:44 UTC 2025
Each GTest test case is intended to be able to run on its own (this is the design intent of the frame work).
Hotspot also adds some extra flavours of GTests, those that run with no created VM (`TEST`/`TEST_F`), those that run with a shared created VM (`TEST_VM`/`TEST_VM_F`) and those that run in a private created VM (`TEST_OTHER_VM`/`TEST_VM_ASSERT`/`TEST_VM_ASSERT_MSG`/`TEST_VM_FATAL_ERROR_MSG`/`TEST_VM_CRASH_SIGNAL`).
The way this is implemented is by having the first shared VM test that runs create a VM. But this leads to having all proceeding test also have access to a shared VM, even if they are test that are supposed to be able to run without a created VM.
Combining this with the fact that almost all our automated GTest testing always just run all tests in the same order makes it hard to discover if we have dependencies between tests.
I propose we add three types of GTest invocation tests used to find these incorrect dependencies.
1. A test which runs only our no created VM test, to find if we have any VM dependency.
2. A test which runs only one test at a time, to see if there are any tests which depend on other test having been run.
3. A test which shuffles the order of our tests to see if there are any dependencies on the order of tests.
Added 1. and 3. to tier1 as they are just as cheap or cheaper than the normal `GTestWrapper.java`. 2. is only added to our complement test groups, so `tier4` and `hotspot_misc`. Also added a new test group `:hotspot_validate_gtest` which can be used to more easily run all three of these tests.
3. will have some randomness, so there might be that things start popping up. It is quite easy to add exclude tests from via the filter. But the shuffle dependencies are probably the scariest if we find them, as they might be just a test running bug as the one that is excluded here. But it can also find broken assumptions, or bring things we have missed to light.
These tests and the chain of followup fixes are not of high priority. It has not been able to find anything but bad test assumptions and incorrectly configured tests. So I have no problem letting this PR stay open until after the fork, so these tests can bake in the JDK 27 branch rather than the JDK 26 branch.
-------------
Commit messages:
- Add GTestCheckers
Changes: https://git.openjdk.org/jdk/pull/28409/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28409&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8372241
Stats: 323 lines in 6 files changed: 318 ins; 3 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/28409.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/28409/head:pull/28409
PR: https://git.openjdk.org/jdk/pull/28409
More information about the hotspot-dev
mailing list