RFR: 8327495: Print more warning with -Xshare:auto when CDS fails to use archive [v2]

Calvin Cheung ccheung at openjdk.org
Mon Apr 28 21:55:46 UTC 2025


On Sun, 27 Apr 2025 06:04:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert one of the changes in filemap.cpp
>
> src/hotspot/share/cds/metaspaceShared.cpp line 1135:
> 
>> 1133:   }
>> 1134: }
>> 1135: 
> 
> The AOT workflow doesn't use the `SharedArchiveFile` flag. I think to detect that we are not using the default archive, we should do this:
> 
> 
> bool CDSConfig::is_using_only_default_archive() {
>   return is_using_archive() &&
>          input_static_archive_path() != nullptr &&
>          default_archive_path() != nullptr &&
>          strcmp(input_static_archive_path(), default_archive_path()) == 0 &&
>          input_dynamic_archive_path() == nullptr;
> }
> 
> 
> I think the printing can be simplified like this to avoid duplication:
> 
> 
> // If the user doesn't specify any CDS options, we will try to load the default CDS archive, which
> // may fail due to incompatible VM options. Print at the info level to avoid excessive verbosity.
> // However, if the user has specified a CDS archive (or AOT cache), they would be interested in
> // knowing that the loading fails, so we print at the error level.
> Log(cds) log;
> LogStream ls_error(log.error());
> LogStream ls_info(log.warning());
> LogStream& ls = CDSConfig::is_using_only_default_archive() ? ls_info : ls_error;
> 
> ls.print_cr("An error has occurred while processing the %s.", CDSConfig::type_of_archive_being_loaded());
> if (message != nullptr) {
>    ls_print(cds)("%s", message);
> }

Thanks. I've incorporated your suggestion with some slight adjustment. For the `CDSConfig::is_using_only_default_archive()`, it needs to account for dumping a classlist during JDK build time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24889#discussion_r2064851092


More information about the hotspot-runtime-dev mailing list