mandy.chung at oracle.com
Thu Apr 12 21:20:29 PDT 2012
On 4/12/2012 6:52 PM, Jonathan Gibbons wrote:
> Should I be concerned that Catalog.readLocalModuleInfo is being called
> an absurdly high number of times during Configurator.configurePaths?
I would say this's an performance optimization opportunity to be
implemented in the resolver.
> I have a scenario where javac is compiling 3 small modules, and it
> creates a javac-specific impl of Catalog for use by the Configurator.
> The impl of readLocalModuleInfo is being called a total of **416**
> times for these 3 modules.
> What seems anomalous to me is that the method is called
> **read**LocalModuleInfo, implying there might be disk activity
> involved. As such, I presumed, perhaps naively, that it would be
> called once per module id, and the resulting ModuleInfo cached inside
> the Configurator.
> Clearly, I can manage to cache the results and avoid creating a new
> ModuleInfo object on every call. But I wonder if other code that impls
> this method is falling into the same trap and assuming it will be
> called just just per module id per use of the Configurator.
We are aware of some performance issues with the current resolver
prototype - there isn't much optimization, if any, or caching
implemented. There are some low hanging fruits that could be optimized
for example caching the ModuleInfo read. The number of
readLocalModuleInfo calls was increased due to the views and services
With the changes done for aliases  - change from cat.listModuleIds to
cat.listDeclaringModuleIds , it would help a little bit but still more
caching should be done.
> More Configurator oddities ...
> Same environment, small library of 3 small modules, with a parent
> library of the system library.
> Configurator calls the javac impl of Catalog.gatherLocalModuleIds, and
> gets a set of the 3 small modules as a result. But, even though it
> now knows what local modules there are, it is still calling
> readLocalModuleInfo for many/all of the platform modules, i.e.
> beginning jdk.* and sun.*. This seems unnecessary, since it can be
> inferred from the result of gatherLocalModuleIds that these modules
> are not in this particular library.
The reason why jdk* and sun.* are loaded before the resolver is trying
to resolve jdk.base which has several service dependences. This leads
to adding the jdk* and sun* service providers as optional dependences
during the configuration computation. I think
Configurator.configurePaths would not need to resolve the service
dependences as it's done in the install time (i.e.
Configurator.configure) - one difference between compile-time and
More information about the jigsaw-dev