Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8209385

CDS runtime classpath checking is too strict when only classes from the system modules are archived

    Details

    • Subcomponent:
    • Resolved In Build:
      b08

      Backports

        Description

        For ease of use, the CDS archive contains only boot classes from the system modules, we ignore the classpath specified in the dump time command-line:

        $ mkdir -p foo
        $ touch foo/bar

        $ rm -f tmp.jsa
        $ echo java/lang/Object > classlist
        $ java -Xshare:dump -XX:SharedClassListFile=classlist -XX:SharedArchiveFile=tmp.jsa -cp foo
        ...
        $ java -Xshare:on -XX:SharedArchiveFile=tmp.jsa -version
        java -Xshare:on -XX:SharedArchiveFile=tmp.jsa -Xlog:class+path=debug -version
        [0.003s][info][class,path] bootstrap loader class path=/jdk/bld/dre/images/jdk/lib/modules
        [0.003s][info][class,path] opened: /jdk/bld/dre/images/jdk/lib/modules
        [0.012s][info][class,path] type=BOOT
        [0.012s][info][class,path] Expecting BOOT path=/jdk/bld/dre/images/jdk/lib/modules
        [0.012s][info][class,path] ok
        [0.027s][info][class,path] checking shared classpath entry: /jdk/bld/dre/images/jdk/lib/modules
        [0.027s][info][class,path] ok
        java version "12-internal" 2019-03-19

        ^----- note that "foo" has been excluded from the dump time classpath.


        However, the above will fail if the CDS archive contains only classes from the system modules, but some of these classes were loaded by the platform or app class loaders (CLDRLocaleDataMetaInfo is loaded by the platform loader):

        $ rm -f tmp.jsa
        $ echo sun/util/resources/cldr/provider/CLDRLocaleDataMetaInfo > classlist
        $ java -Xshare:dump -XX:SharedClassListFile=classlist -XX:SharedArchiveFile=tmp.jsa -cp foo
        narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 3
        Allocated temporary class space: 1073741824 bytes at 0x00000008c0000000
        Allocated shared space: 3221225472 bytes at 0x0000000800000000
        Loading classes to share ...
        Loading classes to share: done.
        Rewriting and linking classes ...
        Rewriting and linking classes: done
        Error: non-empty directory 'foo'
        Hint: enable -Xlog:class+path=info to diagnose the failure
        Error occurred during initialization of VM
        Cannot have non-empty directory in paths

        The bug is present in the JDK 12 early access build 5 (2018/8/2)

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  ccheung Calvin Cheung
                  Reporter:
                  iklam Ioi Lam
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  8 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: