RFR (M) 8061651 - Interface to the Lookup Index Cache to improve URLClassPath search time (round 2)

Ioi Lam ioi.lam at oracle.com
Fri Oct 24 04:34:57 UTC 2014

Hi Jiangli,

Thanks for the review. Please see comments in-line:

On 10/21/14, 2:04 PM, Jiangli Zhou wrote:
> Hi Ioi,
> Here are some comments from me:
> -src/share/vm/classfile/classLoader.cpp
> In ClassLoader::setup_search_path, if canonicalize is true it's not 
> necessary to allocate the 'path' and copy the 'class_path' to 'path'.
we need to allocate path[] because we need to copy only a part of the 
classpath[] into it. E.g.

     classpath[] = "foo.jar:bar.jar"
     path[] = "foo.jar"  <- need to be zero-terminated
> -src/share/vm/memory/metadataFactory.hpp
> In free_array, is it possible to disable it only when 
> PrintSharedSpaces is enabled, instead of disabling it for all?
I am not sure. For safety, I have filed a bug and will fix that 
separately: https://bugs.openjdk.java.net/browse/JDK-8062016
> -jdk/src/share/native/sun/misc/URLClassPath.c
> Is verifying class name needed in 
> Java_sun_misc_URLClassPath_knownToNotExist0? The class name will be 
> verified when the class loader loads the class.
I coped the code from Java_java_lang_ClassLoader_findBootstrapClass. 
VerifyFixClassname is needed, as it translate "." -> "/". I am not sure 
if VerifyClassname is needed, but I guess it doesn't hurt.

> -jdk/src/share/classes/sun/misc/URLClassPath.java
> Can lookupCacheEnabled flag change during runtime? In getLookupCache() 
> the flag is checked more than once.
Yes, it can change if disableAllLookupCaches() is called in the middle 
of getLookupCache(). I have added more comments in the new webrev. 
Please take a look to see if it makes sense.


- Ioi
> Thanks,
> Jiangli
> On 10/21/2014 10:27 AM, Ioi Lam wrote:
>> Please review this fix:
>> http://cr.openjdk.java.net/~iklam/8061651-lookup-index-open-v1/
>> Bug: Add an interface to the JVM's Class/Resource Lookup Index Cache 
>> for improving sun.misc.URLClassPath search time
>>     https://bugs.openjdk.java.net/browse/JDK-8061651
>> Summary of fix:
>>     Some J2EE environments have lots of JAR files in the
>>     classpath. However, during run-time, most classes are loaded by
>>     custom classloaders which delegate to the system loader. As a
>>     result, each class loaded by a custom classloader will cause many
>>     JAR search failures (in sun.misc.URLClassPath).
>>     To limit the number of searches in URLClassPath, the 8uX HotSpot
>>     VM is going to include a Class/Resource Lookup Index Cache that
>>     records information about the class/resource entries in the JAR
>>     files in the classpath. This can be used to improve
>>     sun.misc.URLClassPath search time.
>>     This is part 1 of the REF -- we are adding appropriate interfaces
>>     in both the JDK code and the HotSpot code to access this cache.
>>     URLClassPath.java is modified to use JNI to call into the HotSpot
>>     JVM_XXX APIs to access the cache.
>>     The implementation of this cache is done in part 2 of this RFE.
>>     Note that this enhancement is for JDK 8uX only. In JDK9 and
>>     beyond, we are considering an alternative implementation where the
>>     cache is maintained in the core libs code, outside of HotSpot.
>> Tests:
>>     JPRT
>>     Adhoc SQE tests
>> Thanks
>> - Ioi

More information about the core-libs-dev mailing list