[jdk17u-dev] RFR: 8314835: gtest wrappers should be marked as flagless

Thomas Stuefe stuefe at openjdk.org
Tue May 28 08:24:09 UTC 2024


On Tue, 28 May 2024 08:03:26 GMT, SendaoYan <syan at openjdk.org> wrote:

> > Hi, about this and similar "flagless" backports. Why is this backported, and how does it affect test execution? What does flagless do, exactly?
> 
> If the testcase mark as `@requires vm.flagless`, then this testcase will not been selected by jtreg when gived jvm non-default jvm options. That means this testcase not suitable for run with non-default jvm options.
> 
> Take `gtest/AsyncLogGtest.java` as an example: Do jtreg list with default jvm options:
> 
> ```
> > jtreg -l test/hotspot/jtreg/gtest/AsyncLogGtest.java
> Testsuite: /home/yansendao/git/jdk/test/hotspot/jtreg
> gtest/AsyncLogGtest.java
> Tests found: 1
> ```
> 
> Do jtreg list with jvm options -Xcomp, it says not tests found:
> 
> ```
> > jtreg -l -Xcomp test/hotspot/jtreg/gtest/AsyncLogGtest.java
> Testsuite: /home/yansendao/git/jdk/test/hotspot/jtreg
> Tests found: 0
> ```
> 
> The testcases which mark as `@requires vm.flagless` not suitable for run with non-default jvm options, that means these testcases will only run with default jvm options. These testcases will run failed when it's not mark as `@requires vm.flagless` when run with some non-default jvm options. The "flagless" backport make these testcases more robustness.

Interesting, thanks for the clear and concise explanation! BTW, I was not aware that one could give VM options directly to jtreg. Is `jtreg -XX:+abc" the same as `jtreg '-vmoption=-XX:abc'` ?

I also realize that these questions should have been raised at the original PR.

I guess the "flagless" concept assumes that there is always a standard run with no options, and only additional runs specify options. If you want to always specify certain options, e.g. certain paranoia flags, or increase logging, this would unexpectedly omit a bunch of tests.

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

PR Comment: https://git.openjdk.org/jdk17u-dev/pull/2470#issuecomment-2134621304


More information about the jdk-updates-dev mailing list