[jdk8u-dev] RFR: 8208655: use JTreg skipped status in hotspot tests [v2]

Andrew John Hughes andrew at openjdk.org
Fri Nov 24 15:17:17 UTC 2023


On Fri, 24 Nov 2023 07:44:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Andrew John Hughes has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - 8183503: Update hotspot tests to allow for unique test classes directory
>>  - 8186095: upgrade to jtreg 4.2 b08
>>  - 8129355: [TESTBUG] runtime FragmentMetaspaceSimple.java fails with java.lang.ClassNotFoundException: test.Empty
>
> 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.

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

PR Review Comment: https://git.openjdk.org/jdk8u-dev/pull/387#discussion_r1404455272


More information about the jdk8u-dev mailing list