RFR: 8203923: Add @requires feature to check flag values for the running JVM

[David Holmes]

Hi Stefan,

On 30/05/2018 12:21 AM, Stefan Karlsson wrote:
> Hi all,
> 
> Please review this patch to add @requires vm.opt.final.<vm flag name>, 
> as a way to filter jtreg tests on the final value of flags in the test VM.
> 
> http://cr.openjdk.java.net/~stefank/8203923/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8203923
> 
> This patch is needed to allow tests to be filtered out when ZGC is run.
> 
> ZGC doesn't support UseCompressedOops (and currently doesn't support 
> ClassUnloading). Instead of adding @requires vm.gc != "Z" for tests that 
> rely on ClassUnloading, I think it's nicer to write @requires 
> vm.opt.final.ClassUnloading.
> 
> This will filter out the test if any of the following conditions are met:
> 1) The currently executing VM doesn't support ClassUnloading
> 2) -XX:-ClassUnloading is passed to the test
> 
> The second case can today be handled by @requires vm.opt.ClassUnloading 
> == NULL | vm.opt.ClassUnloading == true, or maybe simpler @requires 
> vm.opt.ClassUnloading != false, but if you need both @requires 
> vm.opt.final.ClassUnloading should be used.

I'm not sure about the use of vm.opt.final as the name here. IIUC vm.opt 
is set by jtreg based on the vmoptions passed to jtreg for running the 
tests. Whereas this is the final flag value as seen in the running VM. 
And given we can only inspect the final value this way, perhaps just 
vm.flag would be better?

> The current solution requires the queried flags to be listed in 
> vmOptFinalFlags. Maybe there's a way to get this to cover all flags 
> automatically?

Yes it is a shame that this has to be manually configured. I think 
ideally this would need to be built into jtreg so that it ran a dcmd(?) 
to get all final flag values and then populated the properties. Though I 
suppose VMProps could also do that ... (The crude way of doing this is 
via PrintFlagsFinal and parsing the output, of course).

Anyway other than my query on the naming, this seems fine for moving ahead.

Thanks,
David

> Thanks,
> StefanK