JDK support for VM to read classes from modules in a module library

[Karen Kinnear]

David,

Thank you - good suggestion, I can add a trace/verbose hook here, under the TraceClassLoading
flag .

If you don't mind, I'm working on a follow-up and will include improved tracing in that next round of
changes.

thanks,
Karen

On May 8, 2012, at 3:22 AM, David Holmes wrote:

> Hi Karen,
> 
> Skimming through ...
> 
> In systemDictionary.cpp:
> 
> 123   if (!HAS_PENDING_EXCEPTION && k != NULL) {
> 124     instanceKlassHandle ik(THREAD, k);
> 125     JavaValue result(T_OBJECT);
> 126     JavaCalls::call_static(&result,
> 127                            ik,
> 128                            vmSymbols::getBaseModuleLoader_name(),
> 129 vmSymbols::void_module_bootloader_signature(),
> 130                            THREAD);
> 131     if (HAS_PENDING_EXCEPTION) {
> 132       UseModuleBootLoader = false;
> 133       CLEAR_PENDING_EXCEPTION;
> 
> Should we have some kind of debug/trace/verbose hook here to see the exception from getBaseModuleLoader() ?
> 
> David
> -----
> 
> On 8/05/2012 10:48 AM, Karen Kinnear wrote:
>> 
>> Webrev for the VM changes:
>>   http://cr.openjdk.java.net/~acorn/vm-module-class-loading/webrev/
>> 
>> VM code includes both class loading changes for base module loader, as well as incremental perfdata timer information
>> to help us track detailed class loading performance.
>> 
>> thanks,
>> Karen
>> 
>> On May 5, 2012, at 2:38 AM, Mandy Chung wrote:
>> 
>>> Karen and I have been working on implementing the support in the VM and library to read classes from a module library in native and proper system initialization for modules.  This will replace the current workaround of using bootclasspath in module mode.  I have put together a set of slides [1] to give an overview of this work (thanks to Alex, Karen, and Alan for their feedback and improvements).
>>> 
>>> This work includes several pieces:
>>> 1) Jigsaw native library interface that the VM will use to search and read classes from the base module
>>> 
>>> This replaces the existing mechanism in the VM that searches and reads classes from rt.jar and the default bootclasspath (that no longer exists in modular JDK) for loading bootstrap classes.
>>> 
>>> Webrev for the jdk change:
>>>   http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-jigsaw-ms/
>>> 
>>> Karen will send out the webrev for the VM change separately.
>>> 
>>> The jigsaw native library interface is defined in jigsaw.h and its implementation is in jigsaw.c.  The temporary hack in org.openjdk.jigsaw.BootLoader to extend the bootclasspath for the base and other modules is now removed.  I have added a few static methods in the Platform class for the system to determine if it's running in module mode, if a given class loader defines system classes, and to get the base module loader (refer below for details).
>>> 
>>> This webrev also includes some minor cleanup in the modularization such as fixing the jdk.desktop requires optional jdk.jaxp that should not be an optional dependency and moving java.text.Bidi class to the base module (Alan has eliminated the bidi to desktop dependency a while ago).
>>> 
>>> 2) system modules to be granted with AllPermissions
>>> 
>>> Today the classes on bootclasspath are granted with AllPermissions.  In a modular JDK, we need to a way to determine if it's a system module and grants with AllPermission.  Alan has implemented the module URL as the code source to modules and grants all permissions to jdk.* modules, as an interim solution.   Sean is looking into different options and a reliable way to identify a system module.
>>> 
>>> Webrev at:
>>>   http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-module-url/
>>> 
>>> 3) The JDK code needs to be audit for the use of class loader and update for modules as listed in the open issues.  We have made changes in a few places in the JDK to fix some of the low hanging fruits that get more of the existing tests to pass when running as modules.
>>> 
>>> a. bootstrap classes skip permission check e.g. ClassLoader.getClassLoader()
>>> 
>>> Today bootstrap classes are loaded by null loader.  In module mode, system modules are loaded by non-null module loader.    A method Platform.isPlatformLoader(ClassLoader) is added to replace the "cl == null" check.  Note that these methods may be more appropriate to live in java.lang or some other class but I add it in Platform class for now.
>>> 
>>> b. Platform.getBaseModuleLoader() - the base module loader is needed when the library
>>> code wants to load a class in base's optional dependency (e.g XML) because Class.getClassLoader() currently returns null (see the open issue listed in [1]).
>>> 
>>> c. replace classloader parameter in the Class.forName call from null to an appropriate loader when loading a class that is not in the base module (e.g. management, scripting, etc).
>>> 
>>> Webrev:
>>>   http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-class-loader-fix/
>>> 
>>> There will be more of this kind of changes required in the jdk and this is just to set a few examples to get going.
>>> 
>>> You can also look at all changes together in this webrev:
>>>   http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-all/
>>> 
>>> Thanks
>>> Mandy
>>> [1] http://openjdk.java.net/projects/jigsaw/doc/module-class-loading.pdf
>>