RFR: 8204165: Filter out tests requiring class unloading when ClassUnloading is disabled

[Stefan Karlsson]

Hi Coleen,

On 2018-05-31 14:35, coleen.phillimore at oracle.com wrote:
> 
> If  you look for ClassUnloadCommon, there are a couple others.  It would 
> be good to have these tagged as well, even though the last one tests two 
> things.

I've been very ZGC centric and only tagged problematic tests I've found, 
but of course I can tag more when it makes sense.

> 
> runtime/appcds/customLoader/UnloadUnregisteredLoaderTest.java
> runtime/appcds/customLoader/test-classes/UnloadUnregisteredLoader.java

Added the tag and tested with -XX:+UseG1GC -XX:-ClassUnloading.

> runtime/logging/LoaderConstraintsTest.java

This tests seems to spawn a new test with a ProcessBuilder and therefore 
doesn't propagate the -vmoptions flags. Even if I try to turn off class 
unloading or run ZGC, it will end up running G1 with class unloading. I 
think this tests needs to be changed, before it makes sense to tag it.

If you still want me to add the tag, I can do so.

> runtime/BadObjectClass/TestUnloadClassError.java

This test doesn't fail if I turn off class unloading. Do you still want 
me to add the tag?

> 
> If you look for triggerUnloading there are more: e.g. 
> vmTestbase/metaspace/stressHierarchy.  I assume they pass without class 
> unloading though.

Maybe we can handle those in a future RFE?

Thanks,
StefanK

> 
> Thanks,
> Coleen
> 
> 
> On 5/31/18 8:01 AM, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to annotate jtreg tests that require 
>> ClassUnloading with @requires vm.opt.final.ClassUnloading.
>>
>> http://cr.openjdk.java.net/~stefank/8204165/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8204165
>>
>> This @requires tag will filter out these tests when run with 
>> -XX:-ClassUnloading or when run with GC that doesn't support class 
>> unloading.
>>
>> For the discussion around the introduction of the vm.opt.final tags, 
>> see: 
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-May/032586.html
>>
>> Thanks,
>> StefanK
>