Jigsaw classpath mode support
Mandy Chung
mandy.chung at oracle.com
Tue Aug 21 10:09:42 PDT 2012
Updated webrev at:
http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/classpath-mode.01/
I have modified org.openjdk.jigsaw.ClassPathContext and
sun.misc.Launcher classes to incorporate the comments Alan, Paul and
Karen have. Also updated the ModulesProblemList.txt to include a few
known failures that will be looked into next.
Mandy
On 8/7/2012 10:47 AM, Mandy Chung wrote:
> I have implemented the "classpath mode" support running on
> a module image.
>
> Webrev:
> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/classpath-mode.00/
>
> JDK has been modularized in the jigsaw repo. There no longer
> has a rt.jar, tools.jar, or any jar file. The system classes
> are now installed in a system module library as modules. This
> change will allow the bootstrap class loader, extension class
> loader, and system class loader to search classes and resources
> in the system module library as the default. Some implementation
> details:
>
> 1. VM used to maintain the default bootclasspath list and search
> classes in it. Now it will call jigsaw native interface to find
> classes from the module library unless -Xbootclasspath is set
> to override the default bootclasspath. The -Xbootclasspath/p
> and -Xbootclasspath/a will continue to work as it is today.
>
> Karen will be sending out the webrev for the hotspot change
> separately.
>
> 2. tools.jar
>
> For compatibility, -classpath tools.jar should continue
> to work. There are existing applications using URLClassLoader
> that loads classes from tools.jar (e.g. test harness) that
> also should continue to work.
>
> To be able to determine if the path of the given tools.jar
> to either -classpath option or URL parameter to URLClassLoader
> is the same path as JAVA_HOME/lib/tools.jar in a lightweight,
> the module image for the full JDK will contain an empty tools.jar.
> This also allows applications that check for the existence of
> tools.jar to continue to work.
>
> sun.misc.URLClassPath is the main implementation class to
> support URLClassLoader to search a file from the given URLs.
> Both ExtClassLoader and AppClassLoader are URLClassLoader.
> URLClassPath is extended to find resource file from the
> appropriate system modules if the given URL is
> JAVA_HOME/lib/tools.jar or JAVA_HOME/lib/ext.
>
> 3. How to determine which modules belong to bootclasspath,
> ext directory, and tools.jar (and a few jar files in JDK/lib)
> at runtime
>
> A configuration for the classpath mode support is loaded at
> startup rather than generated to minimize the startup cost.
> The idea is to have one ClassPathContext for bootclasspath,
> one for extension and one for the jdk tools.
>
> In this prototype, I just define a new module "jdk.classpath"
> and install it in the module image. It hardcodes the list
> of modules for each ClassPathContext for now. One alternative
> is to extend jpkg to generate "jdk.classpath" config specifically
> for this classpath mode. We'll explore this later. But I
> think this is good enough for now.
>
> 4. I made simple change in StoredConfiguration to reduce
> the footprint of the configuration stored on disk. There
> were several regression tests setting -Xmx failed due to
> the increase of the startup footprint without this change.
>
> With storing the context names and package names only once,
> it reduces the size of the config with 35-40%. I suspect
> the fast configuration will make similar change.
>
> $ du -k `find . -name 'config'`
> 696 ./jdk.corba/8-ea/config
> 1304 ./jdk.classpath/8-ea/config
> 1232 ./jdk.tools/8-ea/config
> 604 ./jdk.rmi/8-ea/config
> 680 ./jdk.tools.base/8-ea/config
> 604 ./jdk.base/8-ea/config
> 1056 ./jdk.tools.jaxws/8-ea/config
> 676 ./jdk.devtools/8-ea/config
> 608 ./jdk.tools.jre/8-ea/config
>
> $ du -k `find . -name 'config'`
> 444 ./jdk.corba/8-ea/config
> 792 ./jdk.classpath/8-ea/config
> 748 ./jdk.tools/8-ea/config
> 392 ./jdk.rmi/8-ea/config
> 436 ./jdk.tools.base/8-ea/config
> 392 ./jdk.base/8-ea/config
> 636 ./jdk.tools.jaxws/8-ea/config
> 436 ./jdk.devtools/8-ea/config
> 396 ./jdk.tools.jre/8-ea/config
>
>
> 5. I ran the jtreg regression tests and JCK api& lang tests.
> The test results are looking real good. Compared with the
> jigsaw repo as the baseline, there are 2 new JCK test failures
> that I have to investigate (passed: 23,685; failed: 138; error: 28)
>
> There is a startup initialization issue due to the use of
> Files.isSameFile method and the default file system provider
> is replaced with user defined one. I'm currently looking into
> a fix for it.
>
> I'd like to get this webrev out for review early and I also
> expect any issue found will be minor that I will generate a
> separate patch on top of this as a separate review.
>
> Open Issues:
> 1. sun.boot.class.path no longer represents the search path
> for the bootstrap class loader. Any application depending
> on this system property may be impacted.
>
> rmic is one example that uses this property value to find
> system classes. There has been work to convert rmic to
> use the javax.tool APIs that will support a module image.
> Unless rmic becomes module-aware, it continues to use
> the launcher hack setting -Xbootclasspath/p as a workaround.
>
> Mandy
>
More information about the jigsaw-dev
mailing list