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.

Bug 17722 - Persistent storage of modules state
Summary: Persistent storage of modules state
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: Petr Nejedly
Depends on: 20168 20190 21675 22322
Blocks: 26580
  Show dependency tree
Reported: 2001-11-15 19:09 UTC by Jaroslav Tulach
Modified: 2008-12-23 08:34 UTC (History)
3 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2001-11-15 19:09:19 UTC
As elaborated at
in order to improve scalability of the system it is necessary to store
information recalculated each time the IDE is started (content of XML
filesystems, lookup, etc.) in a persistent storage. 

This issue should track the progress of such effords.
Comment 1 Jesse Glick 2001-11-15 20:34:30 UTC
Cool, but please don't assign to me until we have agreed what is to be
done and when... I use IZ's priority rank to decide what to do every
Comment 2 Jesse Glick 2001-12-18 00:39:40 UTC
I guess before we go designing some caching system, our first goal is
to understand what precisely we are trying to avoid. Specifically,
which of the following are significant startup time and/or memory
hogs, and which are minor:

- physically opening JAR files and getting the ZIP file list

- defining packages from JARs (probably no more since JarClassLoader
is more efficient, thanks Petr)

- searching for things (e.g. classes) in a ZIP file list after it is

- loading classes needed by modules to customize "entry-point"
functionality (e.g. action enablement logic), incl. any classes they
recursively load due to compile-time references, if those classes are
resolved normally when the module is not actively in use

- loading (but not resolving) classes needed as marker interfaces or

- parsing XML layers

- merging XML layers

- creating InstanceDataObject's without the instances: e.g. parsing
*.settings format and reading the instanceOf attrs

- loading and parsing bundles

If we understand which of these things are actually expensive, we can
know what it is useful to cache. For example without support from new
APIs we might want to:

- cache merged XML layer structure as one big XML layer, or as some
binary format

- cache instanceOf info

- cache info about what resources/classes are present in which JAR

- gather commonly-loaded classes & resources and place them all in one
"primer" JAR for quick access

API extensions or redesigns would be needed for:

- do not load classes at all
Comment 3 Jaroslav Tulach 2002-02-05 15:32:08 UTC
Definitively we can improve the behaviour by persiting the storage of
xml-layers. The issue 20168 shows that at least by 9% at startup.
Comment 4 _ ttran 2002-02-14 09:56:49 UTC
Jesse, please take care of this issue
Comment 5 Jesse Glick 2002-02-22 12:14:19 UTC
Begun, I guess.
Comment 6 Jesse Glick 2002-02-25 12:20:31 UTC
I guess Yarda is next in line with issue #20190.
Comment 7 Marek Grummich 2002-07-22 08:37:15 UTC
Target milestone was changed from '3.4' to TBD.
Comment 8 Marek Grummich 2002-07-22 08:56:17 UTC
Target milestone was changed from '3.4' to TBD.
Comment 9 Jaroslav Tulach 2002-07-29 13:27:16 UTC
Petr, you were thinking about have a "cache" of resources loaded
during startup. Do you think that it belongs under this issue?
Comment 10 Petr Nejedly 2002-07-30 08:43:38 UTC
Partially I think. The title of this issue is a bit confusing to me
as I was going to write "No" here originally.

I was thinking about caching some early needed module resources
(this is *not* module state) to be accessible during the startup
without touching the modlue's jars. It has nice side effect of
the IDE looking smaller because of no mmap()s.
With the better structured JarClassLoader since v1.10
it is possible to have lazy jar openning and even simpler Jar
releasing (if I/somebody implement mod:// url handler instead
of the jar:file:// urls currently used).

There is another issue discussing caching of the manifests
and not parsing zillions of the module-state.xml files which could
fall into this category.

We'd also need to cache the jar's index out of the jar
for the above scenario to work.

Now back to the original topic:
The title should probably read "IDE state", not "module state".
I've fould that with current stable IDE, it takes ~2s to parse the
module states (parse .xml, open .jar, parse manifest), but it takes
~4s to initialize the lookup, where >2.2s is spent only in parsing
tons of .settings files so issue 20190 plays major role here
unless we introduce different (no-init) scheme for looking
up the services (I do not want to push the smart naming again ;-)
Comment 11 Petr Nejedly 2002-07-30 09:04:52 UTC
See issue 21675 - Scalability in number of initialized modules
Comment 12 Jesse Glick 2008-06-11 03:03:08 UTC