RFR: 8261455: Automatically generate the CDS archive if necessary

[Yumin Qi]

On Tue, 19 Oct 2021 04:38:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review,
>>   When shared archive (dynamic archive) failed to map due to damage of the archive file, dump/run jdk version mismatch or non-existence file etc, the new patch will automatically create a new shared archive if -XX:+AutoCreateSharedArchive specified with the name based on SharedArchiveFile.
>>   This is a revised patch based on the old PR: 5077 and after bug 8273152 integrated.
>> 
>> Tests: tier1,tier2,tier3,tier4
>> 
>> Thanks
>> Yumin
>
> src/hotspot/share/cds/dynamicArchive.cpp line 376:
> 
>> 374:   Arguments::set_dynamic_archive_path(archive_name);
>> 375:   if (!AutoCreateSharedArchive) {
>> 376:     // When dump at exit, prepare_for_dynamic_dumping already called.
> 
> The interaction between AutoCreateSharedArchive, DynamicDumpSharedSpaces and Arguments::GetSharedDynamicArchivePath() seem too complicated (also see the changes in jvm.cpp). One problem is SharedDynamicArchivePath is used both for (a) the dynamic archive to map and (b) the dynamic archive to write.
> 
> Maybe we should separate (a) and (b)? (b) should be set at VM start-up:
> 
> - if -XX:ArchiveClassesAtEx=foo.jsa is set:
>   -  <archive to write>=foo.jsa
> - If -XX:+AutoCreateSharedArchive -XX:SharedArchiveFile=bar.jsa, AND bar.jsa 
>   -  <archive to write>=bar.jsa
> 
> If we do this, the changes in before_exit() shouldn't be necessary anymore.

This is caused by using of dump(const char* filename) which used both by jcmd and here. I think here we can directly call dump(), which skips the file setting and directly use SharedDynamicArchive.

> test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/TestAutoCreateSharedArchive.java line 81:
> 
>> 79: 
>> 80:         // 0. run with non-existing archive should automatically create dynamic archive
>> 81:         print("0. run with non-existing archive should automatically create dynamic archive");
> 
> Is it possible to number the test case using the same numbering system as in the error handling specification in
> 
> https://bugs.openjdk.java.net/browse/JDK-8272331?focusedCommentId=14447808&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14447808
> 
> This way, we can tell why each test case is written. We can also check that all test cases in the specification are covered.

That needs consolidation of the two --- make them exact same. I will make them close to same in next update.

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

PR: https://git.openjdk.java.net/jdk/pull/5997