New issue: run time eager module loading
David M. Lloyd
david.lloyd at redhat.com
Fri Mar 11 21:55:56 UTC 2016
On 03/11/2016 11:47 AM, mark.reinhold at oracle.com wrote:
> 2016/3/2 19:22 -0800, david.lloyd at redhat.com:
>> It looks as though the instantiation of a Layer causes a complete load
>> of all the modules in the layer.
> What do you mean by "complete load"? Loading all the classes?
No I mean locating and loading all of the descriptors and building all
the wiring information for every module.
>> Apart from the consequent lack of
>> dynamicism, I think this is very likely to cause problems for large
>> applications, particularly if such an application might have many
>> operation modes, some of which do not require *all* of the bundled
>> modules to be loaded every single time.
>> Can there not instead be an incremental resolution algorithm, akin to
>> how classes are lazily loaded?
> Configuring a set of modules and instantiating that configuration as a
> layer requires no more than reading the modules' descriptors. Nothing
> else from any module definition will be read until it's actually needed.
But it does require that all the module descriptors from a given layer
be available, and that the load time for the first load of a module in a
layer will always be bounded by the size of the layer, rather than just
by the dependency subgraph of the module being loaded. Based on
application server deployments that I know about, I think the far upper
bound for a realistic number of modules in a layer will probably lie in
the thousands to ten thousands range (though there is always the outlier
case where someone has to push it to see how far it goes...), which
might translate into a substantial startup overhead. Another potential
issue is requiring that all modules be present, though this is more
closely related to #MutableConfigurations now I think; I suspect this
issue could be mitigated with an acceptable solution to that issue.
> If you really want to avoid configuring all modules in certain operation
> modes, do layers not provide sufficient flexibility? Load the core of
> your application into the boot layer, figure out which modules you need
> for the requested operation mode, and then create an additional layer to
> load those modules.
That can work in some cases, but only if things are loaded one
additional time (rather than on-demand as configuration changes, for
example) or in such a way that you could just keep adding layers. But
in the event of one large intermeshed layer, this won't work without
#MutableConfigurations and/or #NonHierarchicalLayers and something to
coordinate the load.
More information about the jpms-spec-experts