RFR: 8292269: Log more CDS failure messages in the warning channel

[Ioi Lam]

On Tue, 7 Feb 2023 01:10:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I agree that the `fail_continue` is not the ideal name for what this is trying to accomplish: log a message and *possibly* fail. 
>> 
>> That being said, I felt it was appropriate to abstract away the need to manage `LogLevel` as only Info and Warning are used with `fail_continue`. If someone does want to use any of the other channels, like debug, error, etc, they can still use the `fail_continue` variant that excepts a `LogLevel`, but they wouldn't have to worry about it otherwise. I think the binary option of warning vs no warning can help to keep it simple.
>
> In that case I return to "It is better to name a method by what it does do rather than what it doesn't." So `fail_continue` and `fail_continue_warn`?

I think the methods can be renamed to


FileMapInfo::notify_failure(LogLevelType level, const char *msg, ...);
FileMapInfo::notify_failure(const char *msg, ...); // use warning channel


In most cases we use the warning channel, so that should be the default.

The naming of `notify_failure()` follows existing functions such as `VM_GC_Operation::notify_gc_begin()` to indicate that something has happened and some action will happen as a result.

In our case, it's reasonable to expect that some logging may happen as a result of the failure, and the VM may even exit.

By the way, the VM exits only if `-Xshare:on` is specified in the command-line. As specified in https://docs.oracle.com/en/java/javase/17/vm/class-data-sharing.html,  `-Xshare:on` is indented for testing only and should not be used in production.

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

PR: https://git.openjdk.org/jdk/pull/12419