<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
On 14/12/2024 17:10, David Lloyd wrote:<br>
<blockquote type="cite" cite="mid:CANghgrT0FDq1Nvt-M=BNaaPm_NTE-rfQL_wy8GCR5F+Ajri=mQ@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">:<br>
</div>
</div>
<div class="gmail_quote gmail_quote_container">
<div><br>
</div>
<div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br>
</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
-Alan<br>
</body>
</html>