[jdk8u-dev] RFR: 8208655: use JTreg skipped status in hotspot tests [v2]
Thomas Stuefe
stuefe at openjdk.org
Fri Nov 24 15:33:18 UTC 2023
On Fri, 24 Nov 2023 15:14:04 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:
>> hotspot/test/gc/metaspace/TestMetaspaceMemoryPool.java line 33:
>>
>>> 31: * @summary Tests that a MemoryPoolMXBeans is created for metaspace and that a
>>> 32: * MemoryManagerMXBean is created.
>>> 33: * @requires vm.bits == 64
>>
>> Why? We have metaspace also on 32-bit, just no class space.
>
> This and the other test you commented on are https://bugs.openjdk.org/browse/JDK-8213410
> The change was backported for the alteration to `runtime/CompressedOops/CompressedClassPointers.java` which would otherwise have its code-based 64-bit check removed by 8208655 and not replaced.
>
> Both of the other tests have this restriction up to trunk as well. I think the history comes from adding `vm.opt.final.UseCompressedOops` in [JDK-8204167](https://bugs.openjdk.org/browse/JDK-8204167) which causes the error shown in 8213410, even though the actual run would work without compressed oops thanks to `-XX:+IgnoreUnrecognizedVMOptions`. `TestMetaspaceMemoryPool` even still includes a `if (Platform.is64bit())` and `if (InputArguments.contains("-XX:+UseCompressedOops"))` in the `main` method which enforce the same restrictions.
>
> I did look at backporting JDK-8204167 as well, but `vm.opt.final.UseCompressedOops` returned `null` for me even on x86_64. Maybe some test infrastructure or HotSpot change we are missing.
>
> I don't see any issue with backporting the whole patch, given the exclusions are also there in 11+. If there is a case for running these on 32-bit, the restriction should probably be dropped in trunk and backported down for consistency.
Okay, that makes sense. Thanks for clarifying.
I looked at test/hotspot/jtreg/gc/metaspace/TestMetaspaceMemoryPool.java more closely. That test could be run for 32-bit as well, but its not worth fixing.
-------------
PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/387#discussion_r1404469585
More information about the jdk8u-dev
mailing list