JDK-8193213 : Make the UseAppCDS option obsolete
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2017-12-07
  • Updated: 2023-08-24
  • Resolved: 2018-06-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11
11Fixed
Related Reports
CSR :  
JDK-8197963 - Make the UseAppCDS option obsolete
Relates :  
JDK-8182731 - Odd handling of -XX:-UseAppCDS and -XX:SharedArchiveFile
Relates :  
JDK-8202452 - Delete test files missed from commit for 8193213&8182731
Relates :  
JDK-8203031 - segfaults from jvmti_AddToBootstrapClassLoaderSearch
Relates :  
JDK-8185996 - JEP 310: Application Class-Data Sharing
Relates :  
JDK-8303495 - Unused path parameter in ClassLoader::add_to_app_classpath_entries(JavaThread* current, char* path, ...)
Relates :  
JDK-8202282 - [TESTBUG] appcds TestCommon.makeCommandLineForAppCDS() can be removed
Sub Tasks
JDK-8202223 :  
Document UseAppCDS change in JDK 11 - Resolved
Description
The UseAppCDS flag was useful in the old days when AppCDS feature was in the closed and and we wanted a separation of the feature from the basic CDS. Now AppCDS is in the open, UseAppCDS flag is no longer serving its original purpose and complicates code unnecessarily. The behavior of CDS/AppCDS should be determined by the content of the class list at dump time and the content of the archive file at runtime.

The benefits of removing the UseAppCDS flag:
1. Cleaner code 
2. Less confusion in the community about CDS and AppCDS. AppCDS is CDS but with app classes supported in the archive. It adds extra complexity to force the separation of the two.
3. Simpler usage, which will result more adoption.

SharedArchiveFile option
---------------------------------
The -XX:SharedArchiveFile is a product flag when UseAppCDS is enabled, but is a diagnostic flag when UseAppCDS is disabled. As a result of making UseAppCDS obsolete, SharedArchiveFile will become a product flag by default. Specifying +UnlockDiagnosticVMOptions for SharedArchiveFile will no longer be needed in all configurations.

Non-empty directory handling
---------------------------------------
CDS/AppCDS reports error for non-empty directory:
- For base CDS, non-empty directory cannot exist in -Xbootclasspath/a path
- With AppCDS enabled, non-empty directory cannot exist in -Xbootclasspath/a path, class path, and module path

After making UseAppCDS obsolete, the behavior for non-empty directory handling will be based on class type on the classlist:
- If no app classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path
- If app classes are loaded, dump time reports error for non-empty directory exists in -Xbootclasspath/a path, class path, or module path

Above behavior is backward compatible.
Comments
URL: http://hg.openjdk.java.net/jdk/jdk/rev/840e26123940 User: jiangli Date: 2018-04-30 21:00:19 +0000
30-04-2018
The +UnlockCommercialFeatures flag will be removed from appcds tests. The +UnlockDiagnosticVMOptions flag for SharedArchiveFile will be removed from appcds tests. Following are the details for the VM and test changes: - Removed various ‘if (UseAppCDS)’ checks and UseAppCDS asserts. - Removed some of the CDS/AppCDS specifics from general class loading code. - Removed scattered checks for non-empty directory. Dump time non-empty directory check is done at one central place, FileMapInfo::check_nonempty_dir_in_shared_path_table() after loading all classes on the classlist. The behavior is backwards compatible: - If no app/platform classes are loaded, dump time only reports error if non-empty directory exists in -Xbootclasspath/a path - If app/platform classes are loaded, dump time reports error for any non-empty directory exists in -Xbootclasspath/a path, class path, or module path - Removed unnecessary ‘if (!DumpSharedSpaces)’ from SharedClassUtil::initialize(). The code path is only executed when UseSharedSpaces is enabled. - Return immediately in SystemDictionaryShared::find_or_load_shared_class() if the archive header indicates there is no app or platform classes in the shared archive. This reduces overhead in class loading if the shared archive only contains system classes. It also provides backwards compatibility in cases where shared application classes should be disabled. For example, when the default system class loader is replaced by user provided loader, archived application classes are inactive (not loaded from archive) at runtime without affecting the use of archived system classes. - Changed GenerateLinkOptData.gmk to filter out HelloClasslist from the default classlist in JDK image, which is generated using DumpLoadedClassList option. Thanks for David and Ioi's input on this. - Updated various cds/appcds tests to reflect the JVM changes. The use of -XX:+UseAppCDS in tests remains unchanged. - Removed -XX:+UnlockCommercialFeatures for -XX:+UseAppCDS in tests - Removed -XX:+UnlockDiagnosticVMOptions for -XX:SharedArchiveFile in tests - Updated NonBootLoaderClasses.java: ensure app/platform classes on classlist are archived without -XX:+UseAppCDS - Updated DirClasspathTest.java: reflect the change for non-empty directory handling - Updated MismatchedUseAppCDS.java: -XX:-UseAppCDS has no effect
27-04-2018
[~dholmes] Thanks a lot for the suggestion! Filter out the HelloClasslist is a from the default list is a good idea.
20-04-2018
That doesn't sound good. I would not expect the existing behaviour in relation to the JDK's classlist to be changed because of this. AppCDS is still supposed to be opt-in via the classlist, but that's negated if the default classlist always opts-in for you. Update: except it's only two new classes: the system classloader (loaded by the platform loader) and the "app" class HelloClasslist. The former seems like a good addition to the list. The latter can be filtered out at build time.
19-04-2018
As a side effect of making UseAppCDS obsolete, DumpLoadedClassList will include all loaded system and application classes in the output classlist. DumpLoadedClassList is used to create the default classlist in JDK binary. As a result, it will include 'build/tools/classlist/HelloClasslist' in the list. HelloClassList is the app class used at JDK build time for dumping the classlist. The HelloClasslist class will not be included in the generated archive when -Xshare:dump is executed, and a warning will be printed out: Preload Warning: Cannot find build/tools/classlist/HelloClasslist
19-04-2018