JDK-8348028 apparently broke the long-standing behavior for the default location of CDS archives. Before, it was looking for CDS archives in the same path there libjvm.so resided. It is now statically combines JVM variant into the search path, which is sometimes _not_ the right path.

This is prominent when you build a custom JDK, for example bearing both fastdebug and release JDKs. There, you would rename the JVM folders like:

cp -r $SRC_RELEASE $DST
cp -r $SRC_FASTDEBUG/lib/server/ $DST/lib/fastdebug/
cp -r $SRC_SLOWDEBUG/lib/server/ $DST/lib/slowdebug/
mv $DST/lib/server $DST/lib/release
ln -s $DST/lib/release $DST/lib/server

...and rewrite the jvm.cfg launcher to pick those up.

cat > $DST/lib/jvm-release.cfg <<EOF
-release KNOWN
-fastdebug KNOWN
-slowdebug KNOWN
-server KNOWN
-client IGNORE
EOF

Note that all these three JVMs are "server", they are different debug levels.

Now, after JDK-8348028, CDS would try to find archives in "server", not "release", not "fastdebug", not anywhere else, and it would fail to do so. Reverting the following hunk restores the original behavior: https://github.com/openjdk/jdk/commit/e98df71d9c5120fbb73a4c2f49863775fe5db781#diff-06d3a6d0bcf035b0b530313dc67b1ef7ef69869bcdee596a28f9efd97c86ace8L89-L100

There is a workaround to specify -XX:SharedArchiveFile at both dump and use times. But it should really work out of the box.

I suspect JDK-8352044 would run into the same kind of problem.