<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><font face="monospace">I have some questions regarding an RFE
that I filed about adding some modules<br>
when CDS is enabled [1].<br>
<br>
From <a class="moz-txt-link-freetext" href="https://openjdk.org/jeps/261">https://openjdk.org/jeps/261</a></font></p>
<p><font face="monospace"> It is occasionally necessary to add
modules to the default root set<br>
in order to ensure that specific platform, library, or
service-provider<br>
modules will be present in the resulting module graph. In
any phase the option<br>
<br>
--add-modules <module>(,<module>)*<br>
<br>
where <module> is a module name, adds the indicated
modules to the default<br>
set of root modules. <br>
</font></p>
<p><font face="monospace">I am not sure if this language governs the
current behavior of HotSpot, where<br>
modules are added when certain JVM flags are specified. For
example, when<br>
-XX:+</font><span style="color: rgb(31, 35, 40); font-family: ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: pre-wrap; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;">StartFlightRecording is specified, the </span><font face="monospace">jdk.jfr module is added [2]<br>
</font></p>
<p><font face="monospace"> if (status &&
(FlightRecorderOptions || StartFlightRecording)) {<br>
if (!create_numbered_module_property("jdk.module.addmods",<br>
"jdk.jfr",
_addmods_count++)) {<br>
return false;<br>
}<br>
}<br>
<br>
What are the rules for the JVM to decide whether it can add a
certain module<br>
or not?<br>
<br>
For a compatibility/behavioral perspective, it seems that in the
case of JFR, the<br>
decision by the JVM to add "jdk.jfr" hasn't been a problem.
Otherwise it would<br>
be pretty surprising to see application starting failing once
JFR is used.<br>
<br>
As far as I can guess, the reasons against adding unneeded
modules are:<br>
<br>
- start up performance: time spent to load the information for
the extra modules<br>
- runtime memory footprint<br>
- unnecessary exposure of the APIs (apps could latch onto APIs
exposed by JFR, and<br>
will break when jdk.jfr is changed or removed in the future)<br>
</font></p>
<font face="monospace">What other reasons are there?<br>
</font>
<p><font face="monospace">[1]
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8345969">https://bugs.openjdk.org/browse/JDK-8345969</a><br>
[2]
<a class="moz-txt-link-freetext" href="https://github.com/openjdk/jdk/blob/09c29d1d4274d9c36e1af98f02e6fc5b3f35133f/src/hotspot/share/runtime/arguments.cpp#L1807-L1810">https://github.com/openjdk/jdk/blob/09c29d1d4274d9c36e1af98f02e6fc5b3f35133f/src/hotspot/share/runtime/arguments.cpp#L1807-L1810</a><br>
<br>
<br>
</font></p>
<br>
</body>
</html>