org.openjdk.jigsaw.Catalog.readLocalModuleInfo

[Jonathan Gibbons]

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.

-- Jon






On 04/12/2012 06: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 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.
>
> -- Jon