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
Claes,
Thanks for pointing that out. Here's the new code
public synchronized void addURL(URL url) {
if (closed)
return;
synchronized (urls) {
if (url == null || path.contains(url))
return;
urls.add(0, url);
path.add(url);
+
+ if (lookupCacheURLs != null) {
+ // The lookup cache is no longer valid, since
getLookupCache()
+ // 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
disabled.
Thanks
- Ioi
