Please review: VM side of Jigsaw classpath mode support

[David Holmes]

Hi Karen,

On 24/08/2012 6:14 AM, Karen Kinnear wrote:
> The VM side of this webrev is at:
>      http://cr.openjdk.java.net/~acorn/vm.classpath/webrev/

I gave this a quick look over for curiosity. I didn't see anything 
obviously "strange".

One query though. This path format:

"%/lib/modules/jdk.base";

is used to detect a modular runtime but I thought that the actual names 
of the directories used for a module library were configurable when jmod 
is used to create it?

David
-----

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