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.