On 14/12/2024 17:10, David Lloyd wrote:
:
The reason to lazily load and link modules is basically analogous to
the reason that we lazily load and link classes. In fact there is very
little difference. While requiring all classes to be preloaded may
have some benefits in certain circumstances (take GraalVM for
example), it also significantly restricts flexibility in a few
important ways, and of course has a heavy performance cost, and so is
not generally considered to be a good strategy for application
runtimes or even the Java launcher itself.
For modules, we face the same issue. I can, for example, create a
single application layer with a thousand modules in it. Before the
application can start, every JAR has to be opened and every module has
to be loaded, which entails parsing or dynamically creating
descriptors (generally a combination of these things), each with
dozens of support objects for things like dependencies, exports, and
services, and then their internal graphs have to be resolved and wired
and checked for consistency. So there is a significant performance
cost there.
Startup with a large number of modules on the application module path is
an interesting topic. Reliable configuration means the modules required
by the initial module must be recursively enumerated to create the
module graph, and this does mean the module path must be scanned (once)
to find the modules.
Efforts to date have been focused on shifting the work to link-time with
jlink. When the module system was introduced we included a jlink plugin
to generate the module graph (the Configuration) at link time, then a
fast reconstitute of the Configutation at run-time. In JDK 12 it went a
step further with CDS support for object archiving and enabling CDS by
default. It improved again in JDK 16 with the archiving of the boot
layer. The overall effect of all these efforts is all code to initialize
the module system and the boot layer disappears from startup.
I think it would be interesting to explore shifting the generation of
the Configuration for application / child layers to either build time or
link time. There is a lots of interesting directions to explore. We had
many ideas in this area during JDK 9 but had to focus on the core
system. I suspect this could be a lot more fruitful direction that
wouldn't forsake reliable configuration.
-Alan
