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 23:37:05 UTC 2014

On 10/24/14, 3:45 AM, Claes Redestad wrote:
> On 10/24/2014 06:34 AM, Ioi Lam wrote:
>>> 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.
>> http://cr.openjdk.java.net/~iklam/8061651-lookup-index-open-v2/ 
> What is the reason to have lookupCacheEnabled disabled globally when 
> for example calling addURL on *any* URLClassLoader? Couldn't the 
> disabling of cache lookups be per URLClassPath rather than global?
> /Claes

Thanks for pointing that out. Here's the new code

     public synchronized void addURL(URL url) {
         if (closed)
         synchronized (urls) {
             if (url == null || path.contains(url))

             urls.add(0, url);
+           if (lookupCacheURLs != null) {
+               // The lookup cache is no longer valid, since 
+               // does not consider the newly added url.
+               disableAllLookupCaches();
+           }

There are dependencies in the caches: Currently the cache is supported 
only for the boot, ext and app loaders. If the boot classpath is 
appended via addURL, then we need to disable the caches for ext and app 
loaders as well.

If the app classpath is appended, then there's no need to disable the 
boot or ext caches. However, the app lookup cache is typically the 
largest, so keeping the other two caches alive don't buy you that much. 
So instead of trying to do it "right", I decided to go for simplicity. 
If any one of the 3 loaders are changed, I disable the cache.

URLClassLoaders that are not these 3 loaders won't cause the cache to be 

- Ioi

More information about the core-libs-dev mailing list