Background:

The FileMapInfo::fail_continue() method reports the reason when the CDS archive cannot be mapped. This API predates JDK-8046148 (Unified JVM Logging, aka UL). It has rather ad-hoc behavior, depending on the -Xshare mode.

In -Xshare:auto mode, print the message to the "info" log and continue execution:

The original reason to use the "info" channel is to avoid excessive logging when the CDS archive cannot be mapped for a normal reason. For example, before JDK-8231610, the OS would often refuse to load the archive at the requested location due to Address Space Layout Randmization (ASLR), up to 50% of the time for some Windows configurations.

In -Xshare:on mode, print the message to stderr and exit the JVM immediately:

-Xshare:on is used for HotSpot regression testing only. Many tests have been written to expect (a) the reason is printed in the stdout/stderr of the JVM, and (b) the JVM exits when archive(s) cannot be mapped.



Proposal:

This RFE replaces the FileMapInfo::fail_continue() calls with proper UL calls. The goals are:

- Use UL so that the logging style is consistent with the rest of HotSpot.
- Sometimes the CDS archive cannot be mapped due to a genuine failure (e.g., the archive is corrupted). Log these messages in the warning channel to improve visibility.
- The behavior of -Xshare:on should be comparable with (not necessarily identical to) the previous behavior. It's acceptable to make small adjustments to a small number of the existing CDS tests that run in -Xshare:on mode.

Specifically, it's not necessary to exit the JVM immediately after the message is printed (or else we need to add an exit call after every UL log). Instead, we exit the VM at the end of MetaspaceShared::initialize_runtime_shared_and_meta_spaces(). This behavior change does not affect the existing tests.



Info vs Warning Channel:

Consider the following cases:

[1] The CDS archive is valid, but we cannot use it because the user has chosen an incompatible command-line option (-XX:-UseCompressedClassPointers).

This is an example where the messages should remain in "info". CDS is just an optimization, and is not guaranteed to work under all circumstances. In this case, the failure is expected. Logging it as a warning would be too verbose.

$ java -XX:-UseCompressedClassPointers -Xlog:cds -version

[0.011s][info][cds] trying to map /jdk3/bld/nep-fastdebug/images/jdk/lib/server/classes.jsa
[0.011s][info][cds] Opened archive /jdk3/bld/nep-fastdebug/images/jdk/lib/server/classes.jsa.
[0.011s][info][cds] Archive was created with UseCompressedOops = 1, UseCompressedClassPointers = 1
[0.011s][info][cds] Unable to use shared archive.
The saved state of UseCompressedOops and UseCompressedClassPointers is different from runtime, CDS will be disabled.
[0.011s][info][cds] Initialize static archive failed.
[0.011s][info][cds] Unable to map shared spaces
...

Other similar cases:
- CDS is disabled because early JVMTI ClassFileLoadHook is in use.

[2] A bad CDS archive is used:

In this example, we have a user error -- an invalid archive is file is specified. This should be logged as a warning so the user can take steps to fix the problem

$ rm Foo.jsa
$ touch Foo.jsa
$ java -XX:-UseCompressedClassPointers -Xlog:cds -XX:SharedArchiveFile=Foo.jsa -version
[0.000s][info][cds] Specified shared archive not found (Foo.jsa)
[0.001s][info][cds] Unable to use shared archive: invalid archive

Other similar cases:
- CRC error
- Archive is out of date
- classpath is incompatible with the CDS archive