Netbeans Startup Cache
During full IDE startup, >450 jar files needs to be opened for loading resources (classes, images, resource bundles) from, and the actual reads from those jars are unpredictably interspersed over the startup time. This slows down especially cold start, where operating system caches don't contain the jars and the disk have to seek significantly between requests. A solution to this problem is to keep all the necessary resources in a single file that can be read at once during the startup and the data then used instead of jar files.
For such a solution, few corner cases need to be covered to really prevent opening of module jars:
- Jar manifests - a ClassLoader needs the manifest to be able to define packages. Module system's manifest cache could be reused for this, but there is a potential problem with module jars added using module's ClassPath attribute - they should use manifest from their jars, not the module one.
- Probably the best solution would be to implement retrieving the manifest through its cached resource (META-INF/MANIFEST.MF), but see below.
- Package coverage persistence - JarClassLoader uses current manifest cache for storing virtual Package-Coverage attribute
- so storing of a fake resource would be needed, or another mechanism for storing coverage considered.
- Resource access (ClassLoader.getResource returns URL, so the cache would somehow need to hijack the URL protocol used by the class loader)
- Requests for nonexistent resources - the NetBeans class loader system, while being generally aware of location of resources from given package, would still request a nonexistent resource in few cases. If the cache simply returned miss for such a resource, the jar would still be unnecessarily opened to check also the primary source. So for such resources, there must be an entry and a channel for telling "there's no such resource for sure". The cases are:
- classes from shared packages (org.openide.cookies -> OpenCookie)
- locale/branding variants (org/netbeans/core/startup/Bundle_nb_cs_CZ.properties)
- Format should be appendable, see below.
- Open/Validate the cache as soon as possible, maybe even before loading core/startup
- but needs to validate the timestamps
- Start gathering (unhandled) requests immediately
- Stop gathering requests at defined point in startup sequence, free the cached resources
- May or may not cover the warmup and project opening as well
- Create/append the cache file
- on background later after startup with reasonable yielding
- Creating the full cache file shortly after first/modified start should be cheap as OS caches are still warm and maybe even jars opened
- or during shutdown
- Creating the full cache file after cached start is very slow (as slow as would the cold start be, tens of seconds), avoid this by appending newly requested resources only.