RFR: 8255982: Extend BasicJMapTest to test with different GC Heap [v3]

Lin Zang lzang at openjdk.java.net
Wed Nov 11 10:56:57 UTC 2020


On Tue, 10 Nov 2020 17:50:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refine the test configuration.
>
> I believe this would fail when some GCs are not available. For example, in Minimal/Zero only Serial and Parallel are available. ZGC and Shenandoah are not available on all platforms. Plus, specifying another GC with `TEST_VM_OPTS` would probably fail with "multiple GCs selected".
> 
> You need to split the tests like this, and protect each config with `@requires`:
> 
> /*
>  * @test
>  * @summary Unit test for jmap utility
>  * @key intermittent
>  * @requires vm.gc.Parallel
>  * @library /test/lib
>  * @build jdk.test.lib.hprof.*
>  * @build jdk.test.lib.hprof.model.*
>  * @build jdk.test.lib.hprof.parser.*
>  * @build jdk.test.lib.hprof.util.*
>  * @run main/othervm/timeout=240 -XX:+UseParallelGC BasicJMapTest
>  */
> 
> /*
>  * @test
>  * @summary Unit test for jmap utility
>  * @key intermittent
>  * @requires vm.gc.G1
>  * @library /test/lib
>  * @build jdk.test.lib.hprof.*
>  * @build jdk.test.lib.hprof.model.*
>  * @build jdk.test.lib.hprof.parser.*
>  * @build jdk.test.lib.hprof.util.*
>  * @run main/othervm/timeout=240 -XX:+UseG1GC BasicJMapTest
>  */
> ...
> 
> Maybe there is a way to clean up multiple `@build` tags to make the test config less verbose.

Hi @shipilev, 
Thanks for reviewing, I have updated the refine commit. 
One problem is about epsilonGC, this test case keep fail with OOME even with -Xmx set to 4GB. I think it may be better to set up a new issue to investigate whether the OOME is expected, as it may take more efforts that is not quite related with testing jmap. so I didn't include it for this test in this PR.  
What do you think?

Thanks!
Lin

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

PR: https://git.openjdk.java.net/jdk/pull/1094


More information about the serviceability-dev mailing list