JDK-8199360 : Rework the support for the 'ignored' module options in CDS
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 10,11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-03-08
  • Updated: 2019-06-20
  • Resolved: 2018-04-10
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
11 b10Fixed
Related Reports
CSR :  
JDK-8199710 - Rework the support for the 'ignored' module options in CDS
Relates :  
JDK-8194812 - Extend class-data sharing to support the module path
Description
void Arguments::check_unsupported_dumping_properties() {
  assert(DumpSharedSpaces, "this function is only used with -Xshare:dump");
  const char* unsupported_properties[] = { "jdk.module.main",
                                           "jdk.module.limitmods",
                                           "jdk.module.path",
                                           "jdk.module.upgrade.path",
                                           "jdk.module.patch.0" };
  const char* unsupported_options[] = { "-m", // cannot use at dump time
                                        "--limit-modules", // ignored at dump time
                                        "--module-path", // ignored at dump time
                                        "--upgrade-module-path", // ignored at dump time
                                        "--patch-module" // ignored at dump time
                                      };
...

Arguments::check_unsupported_dumping_properties() prints 'option is ignored when dumping the shared archive' for --limit-modules, --module-path, --upgrade-module-path, --patch-module if they are specified at CDS dump time.

Starting from JDK 10, PlatformClassLoader and AppClassLoader are used to load the platform and app classes at dump time. The java library code that initializes the module system does take account of those module options if specified in the command line. The loading paths are affected by those options. So they are not truly 'ignored'.

Following is the proposed supporting matrix for those module options in JDK 11:

                                           -Xshare:dump                 -Xshare:{on, auto}
--module-path <mp>	     Allow                                  Allow
--module	                             Allow                                  Allow
--add-modules	                     Allow                                  Allow
--upgrade-module-path	     Disallow - exit if specified	Allow - disable CDS
--patch-module	             Disallow - exit if specified	Allow - disable CDS
--limit-modules	             Disallow - exit if specified	Allow - disable CDS
Comments
In JDK 10, when --upgrade-module-path is specified at CDS dump time, module class is loaded from the upgraded path. Following shows the -Xlog:class+load=debug log output when dumping with --upgrade-module-path set to upgrademods/java_comp.jar (created by Calvin, jar is attached). The module class from the upgraded module path is loaded and archived. bin/java --module-path mymods --limit-modules java.base,java.compiler --upgrade-module-path upgrademods/java_comp.jar -Xlog:class+load=debug -Xshare:dump -XX:+UnlockCommercialFeatures -XX:+UseAppCDS -XX:SharedClassListFile=java_comp.classlist [2.153s][info ][class,load] javax.annotation.processing.FilerException source: file:<...>/upgrademods/java_comp.jar [2.153s][debug][class,load] klass: 0x00000008c0084840 super: 0x00000008c0000f80 loader: [loader data: 0x00007f55c4a7c1b0 for instance a 'jdk/internal/loader/ClassLoaders$PlatformClassLoader'{0x0000000101c6da20}] bytes: 317 checksum: d66a176a
12-03-2018