This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Core's class loaders and other module system stuff should work through an abstraction layer that handles accesses to module JARs. This will permit: 1. Unit tests checking e.g. that certain kind of class loads or resource lookups do not make excessive leaf calls. Just run with a dummy testing manager with a counter that mimics a couple of JARs. 2. Some other module system unit tests could be made simpler, perhaps - no need to create physical JARs for every test. 3. Manifest cache could be abstracted into a cache of "hot" resources from JARs - META-INF/*, **/*layer*.xml, **/Bundle.properties, etc. 4. Could more easily measure impact of JAR mmap'ing on cold start time, hot start time, and RSS, by swapping in a test non-JAR manager. Or, impact of multiple little JARs, by swapping in a manager that loads from a merged megajar. 5. If desirable, could implement more radical optimizations such as loading resources from a cached binary store. 6. Manager can have a method to get a quick package list for a JAR - alternate ProxyClassLoader implementations could exploit this to precompute a domain cache rather than waiting for cache hits. Impl with JAR files may or may not be fast enough - can be measured.
Created branch: cvs rtag jar_manager_30971_base core_nowww_1; cvs rtag -b -r jar_manager_30971_base jar_manager_30971 core_nowww_1
Created attachment 8936 [details] My idea how should packages contract look like.
Because e.g. org.netbeans.modules.debugger package is present in both debuggercore.jar and debuggerjpda.jar, but populated only in debuggercore.jar and we don't want to look for debuggercore classes in the debuggerjpda's classloader, do we?
Right.
Not for 3.5.
BTW: I've tried to implement a ProxyClassLoader that knows full mapping from packages to Set<ProxyClassLoader> (SCL is handled separately) and it seems it works and has potential for speeding up the startup. For now, I just iterate all the jar entries to compute the populated packages (which costs >2000ms) for all NB jars, and the startup is slowed down by about 900ms. If this info is cached (either explicitely noted in manifest, or added only to the manifest cache), we may gain up to ~1200ms
I'm not actively working on this.
Created attachment 11842 [details] My changes to CLs for "shared knowledge"
Just for record. My changes that allows shared,cached knowledge of package coverage. Yarda was interested in seeing it and I've nearly lost the sources, so I hope they're safe here :o) The diff may be a bit outdated and contains noise as I've had hard times even to find it on old HDD...
Was suggested to use ByteBuffer loading of classes as an optimization. This RFE might also provide a more coherent basis for implementing the module system portion of JNLP support.
There is an issue #41028 about using ByteBuffer to speed up class loading
Things have changed, e.g. #753dd88065e7. There is now a cache system. There is also ModuleFactory. Probably enough for now.
Btw. #3 - is also implemented or ready to be - we have Stamps infrastructure that takes care of caches