P4
Currently, -XX:+AOTClassLinking is supported for dynamic CDS archive, but it doesn't produce significant performance benefit (see first comment in this JBS issue) while complicates the AOT cache implementation (see second comment in this JBS issue).
We should update CDSConfig::is_dumping_aot_linked_classes() to return false when creating a dynamic CDS archive. All code related to AOT-linked classes for the dynamic CDS archive should be removed.
My main concerns are (1) code bloat, and (2) the chance of introducing bugs when we add new AOT optimizations without sufficient testing for the dynamic archive. I think I actually have one such bug in fixup_module_field_list() in https://github.com/openjdk/jdk/pull/26375 (preload classes from AOT cache).
Users who wants to get the benefit of -XX:+AOTClassLinking should switch to the new AOT workflow as described in JEP 483 (https://openjdk.org/jeps/483). See third comment in this JBS issue for performance benefit of JEP 483.
============
Background: during early Leyden prototyping, we had a "5 step workflow" where the AOT compiler would compile classes that are in the CDS dynamic archive. As a result, we needed to make sure that the shape of those classes cannot be changed at runtime (or else the AOT-compiled code would be invalid). A convenient solution was to implement AOT class linking for the dynamic archive.
However, now most AOT optimizations are implemented only for the AOT cache (which has the same structure as a static CDS archive).
+ The upcoming AOT compilation JEP (JDK-8335368) does not support the dynamic CDS archive.
+ Most AOT optimizations (prelinked invokedynamic, aot-inited classes) required archive heap objects, which is not supported in the dynamic archive
+ We don't have plans to support archived heap objects in the dynamic archive (due to the "scrambled egg problem").
Note: When -XX:+AOTClassLinking was introduced in JEP 483 (https://openjdk.org/jeps/483), the specification only mention the use of this flag for the AOT cache. There was no mention of supporting it for the dynamic CDS archive.
We should update CDSConfig::is_dumping_aot_linked_classes() to return false when creating a dynamic CDS archive. All code related to AOT-linked classes for the dynamic CDS archive should be removed.
My main concerns are (1) code bloat, and (2) the chance of introducing bugs when we add new AOT optimizations without sufficient testing for the dynamic archive. I think I actually have one such bug in fixup_module_field_list() in https://github.com/openjdk/jdk/pull/26375 (preload classes from AOT cache).
Users who wants to get the benefit of -XX:+AOTClassLinking should switch to the new AOT workflow as described in JEP 483 (https://openjdk.org/jeps/483). See third comment in this JBS issue for performance benefit of JEP 483.
============
Background: during early Leyden prototyping, we had a "5 step workflow" where the AOT compiler would compile classes that are in the CDS dynamic archive. As a result, we needed to make sure that the shape of those classes cannot be changed at runtime (or else the AOT-compiled code would be invalid). A convenient solution was to implement AOT class linking for the dynamic archive.
However, now most AOT optimizations are implemented only for the AOT cache (which has the same structure as a static CDS archive).
+ The upcoming AOT compilation JEP (JDK-8335368) does not support the dynamic CDS archive.
+ Most AOT optimizations (prelinked invokedynamic, aot-inited classes) required archive heap objects, which is not supported in the dynamic archive
+ We don't have plans to support archived heap objects in the dynamic archive (due to the "scrambled egg problem").
Note: When -XX:+AOTClassLinking was introduced in JEP 483 (https://openjdk.org/jeps/483), the specification only mention the use of this flag for the AOT cache. There was no mention of supporting it for the dynamic CDS archive.