org.openjdk.jigsaw.Catalog.readLocalModuleInfo

[Mandy Chung]

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 
support.
With the changes done for aliases [1] - 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 
install-time?

Mandy
[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-April/002351.html