Bug ID: JDK-8245335 [TESTBUG] DeterministicDump.java fails with release JVM

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 15
15 b25Fixed

This part of the test fails with release build of the JDK. 

http://hg.openjdk.java.net/jdk/jdk/file/ca1687338afe/test/hotspot/jtreg/runtime/cds/DeterministicDump.java#l71

        // (2) This will cause GC to happen after we've allocated 1MB of metaspace objects
        // while processing the built-in SharedClassListFile.
        String withGCArchive = dump(baseArgs, "-XX:MetaspaceSize=1M");
        compare(baseArchive, withGCArchive);

It seems like the GC affects the interned string table in some subtle way. With debug builds, the table seems to be cleaned up before the CDS archive is dumped, so we produce identical CDS images whether GC was executed or not. However, in release build, the clean up might not happen and we end up with more strings in the CDS archive.

=====

Anyway, this test is too aggressive. DeterministicDump.java  was created in JDK-8241071 (Generation of classes.jsa with -Xshare:dump is not deterministic). The goal of JDK-8241071 is for "make images" to produce the same bits. Since the Makefiles will not specify "-XX:MetaspaceSize=1M", testing with it is outside of the scope of JDK-8241071.

Duplicate :	JDK-8245650 - cds/DeterministicDump.java still fails after JDK-8244536
Relates :	JDK-8241071 - Generation of classes.jsa with -Xshare:dump is not deterministic