Please review: VM side of Jigsaw classpath mode support

[Karen Kinnear]

The VM side of this webrev is at: 
    http://cr.openjdk.java.net/~acorn/vm.classpath/webrev/

Note that this has to go back at the same time as the jdk changes, so if you pick up this patch you need the
patch Mandy sent out below.

thanks,
Karen



On Aug 21, 2012, at 1:09 PM, Mandy Chung wrote:

> 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
>>