JDK-8199710 : Rework the support for the 'ignored' module options in CDS
  • Type: CSR
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P3
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 11
  • Submitted: 2018-03-15
  • Updated: 2018-03-22
  • Resolved: 2018-03-22
Related Reports
CSR :  
JDK-8199360 - Rework the support for the 'ignored' module options in CDS
Description
Summary
-------

Clarify the handling of the following module options during CDS dump time and run time:

 - --upgrade-module-path
 - --patch-module
 - --limit-modules

Problem
-------

In the JDK 10 documentation, the above 3 options are listed as 'being ignored during dump time.

However, starting from JDK 10, PlatformClassLoader and AppClassLoader are used to load the platform and app classes, respectively, at CDS dump time. When any of these 3 options are specified during CDS dump time, it affects the initialization of the module system. Therefore, these options are not truly 'ignored'.

In JDK 10, we can archive module classes from the runtime image defined to both PlatformClassLoader and AppClassLoader. Module classes from --upgrade-module-path could be unintentionally archived (although such archived classes are never used at run time).

Note:

Not supporting these 3 options during dump time doesn't seem to be an issue:

 - --upgrade-module-path
   In JDK 11, only two system modules are upgradeable (java.compiler, jdk.internal.vm.compiler). It won���t be used too much initially for user���s developed modules. Oracle Lab is using --upgrade-module-path to upgrade the above two modules in order to use Graal as the JIT. This can be added in a subsequent enhancement if CDS and Lab Graal are used often together.

 - --patch-module
   As documented in JEP 261, --patch-module is strongly discouraged for production use.

 - --limit-modules
   --limit-modules is intended for testing purpose to limit the observable modules (as in the image only contains the limited observable modules).  For example, SQE runs tests with --limit-modules java.base to verify if the tests pass with a minimal image.

Solution
--------

At CDS dump time, forbid these 3 options at CDS dump time. At run time, if any of these 3 options are specified, disable CDS.

Specification
-------------

If any of the above 3 module options is specified in the command line with CDS dump enabled (-Xshare:dump), the vm will exit with an error message.
e.g.

    Error occurred during initialization of VM
    Cannot use the following option when dumping the shared archive: --patch-module

If any of the above 3 module options is specified in the command line with CDS enabled (-Xshare:{on, auto}), CDS will be disabled and vm will issue a warning.
e.g.

    Java HotSpot(TM) 64-Bit Server VM warning: CDS is disabled when the --patch-module
    option is specified.
Comments
Moving to Approved.
22-03-2018
I made some clean up to the Description. Also, I deleted the diffs as they don't clearly define the change in behavior. Instead, I moved the error/warning conditions and messages into the Specification section. I also removed the discussion of --module-path as that belongs to a different RFE: JDK-8194812.
16-03-2018
Thanks for the review and cleanup. I'll "finalize" the CSR.
16-03-2018
"During run time with CDS enabled, those module classes will be loaded dynamically from the respective module(s) since currently in JDK10, we don't support the archiving of module classes defined to the PlatformClassLoader and AppClassLoader." Above is not entirely correct and needs clarification. In JDK 10, we can archive module classes from the runtime image defined to both PlatformClassLoader and AppClassLoader. Module classes from --upgrade-module-path and --module-path could be archived but not intended in JDK 10. The archived classes from --upgrade-module-path and --module-path are never used. Other than that. It looks good.
15-03-2018