The first implementation of @requires in jtreg doesn't meet all VM needs.
jtreg sets vm.* var context variable (those vars which can be used in @requires expressions) based on given value of the -vmoptions command line option. This approach works in very limited cases.

For example, vm.flavor should be always set. null means default value, but default value for varies from platform to platform, so @require vm.flavor == null will not lead to the expected behavior.

The very similar situation with vm.bits. There is no default value across all platforms.

VM flags is another aspect that requires improvement. A test might be applicable only if a value of some flag is in a certain range. A flag could be set in default value, changed via command line or set by ergonomics. Currently, vm.opt.flag is set only if explicitly specified via -vmoption

The next aspect which is not originally supposed: ability a VM to support a feature. An example, not all VMs support G1. So, it's not possible to express that a test setting G1GC is not applicable, even if vm.gc==null.

Some options have aliases, so saying "-Xcongcs" means the same as "-XX:+UseConcMarcSweepGC". So, appearing of both options should have the same effect on vm.*

Setting one option, might imply (implicitly) setting of another flag. Like -vmoptions="-XX+ResourceManager" implies that G1 is requires.


It is unfair to request jtreg to support all that VM specific things. An ability to form the context (vm.* vars) from outside looks like a good solution. Ideally, it would be great if jtreg delegates setting to a custom code.

Comment about possible suggestion to implement this in driver/testlibrary:
yes, it's possible but hardly applicable:
- increases test execution time
- necessity to write extra code
- reducing readability
- no sharing between repositories (jdk/hotspot)
- no way to distinguish not selected tests from not applicable