Hello, it is supposed to speed up application class loaders which extend URLClassLoader as well. However your point is of course valid, it is one of the reasons why it is good for framework implementers to look into this if they would benefit from any of the methods.
(Especially around code sealing, dynamic imports and lookup misses) But I dont know the actual loader implementations out there, might be that none of them uses any of the system code. Gruss Bernd Am Wed, 22 Oct 2014 07:57:03 -0500 schrieb Thomas Watson <[email protected]>: > Unless you have configured bootdelegation=* I'm not sure how much > this enhancement would help improve performance. OSGi bundle > classloaders already avoid delegating to the boot classpath for most > packages. By default the framework only delegates to the boot > classpath for java.* packages. All other delegations to boot should > involve the system bundle exporting the package (e.g. javax.xml.* on > JavaSE-1.4 and higher) and the bundle importing the package. > > Tom > > > > > > From: Bernd Eckenfels <[email protected]> > To: OSGi Developer Mail List <[email protected]> > Date: 10/21/2014 03:52 PM > Subject: [osgi-dev] openjdk: Interface to the Lookup Index > Cache to improve URLClassPath search time > Sent by: [email protected] > > > > Hello, > > I thought this might be interesting to all OSGi framework > implementors. So here is a mail with a feature request for the JDK. > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-October/029244.html > > > I could have sent a link-only, but since I already spam the list, > find the text attached :) > > Gruss > Bernd > > Date: Tue, 21 Oct 2014 10:27:20 -0700 > From: Ioi Lam > To: [email protected], > [email protected] Subject: RFR (M) 8061651 - Interface > to the Lookup Index Cache to improve URLClassPath search time > > > 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 > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
