<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Yes, this is expected behavior. </p>
<p>A short explanation: the Leyden optimizations depends on -XX:+<font face="Calibri" size="2"><span style="font-size:11pt;">AOTClassLinking,
which requires that all classes loaded during the training run
are visible during the production run.</span></font></p>
<p><font face="Calibri" size="2"><span style="font-size:11pt;">For
example, if --add-module is specified differently during the
two runs, class A could be loading in the training run and
become inlined by AOT-compiled methods. At runtime, if a
different set of --add-modules is used, class A may not be
loadable, and we would have to invalidate the corresponding
optimizations.</span></font></p>
<p><font face="Calibri" size="2"><span style="font-size:11pt;">Doing
such checks correctly is complicated. Today, we have a very
simple check -- (a) the full module graph must be archived
during the training run, and (b) the </span></font><font face="Calibri" size="2"><span style="font-size:11pt;"> full
module graph must be loaded from the AOT cache during the
production run. This way we know the exact set of modules are
used in the two runs so the same set of classes are visible.</span></font></p>
<p><font face="Calibri" size="2"><span style="font-size:11pt;">Currently,
we allow the full module graph to be archived only with a
restricted set of options -- see
ModuleBootstrap::canUseArchivedBootLayer(). We are working to
relax the restrictions (see
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8328313">https://bugs.openjdk.org/browse/JDK-8328313</a> -- Archived module
graph should allow identical --module-path to be specified
during dump time and run time). <br>
</span></font></p>
<p><font face="Calibri" size="2"><span style="font-size:11pt;">Supporting
--add-modules, --add-opens, and --add-exports may require more
work. For --add-opens and --add-exports, I'd to understand why
they are being used. Maybe they are for accessing JDK
internals that otherwise shouldn't really be touched?</span></font></p>
<p><font face="Calibri" size="2"><span style="font-size:11pt;">Thanks</span></font></p>
<p><font face="Calibri" size="2"><span style="font-size:11pt;">- Ioi<br>
</span></font></p>
<p><font face="Calibri" size="2"><span style="font-size:11pt;"><br>
</span></font></p>
<div class="moz-cite-prefix">On 9/9/24 1:16 PM, Boyce, Jeffrey
wrote:<br>
</div>
<blockquote type="cite" cite="mid:MW4PR06MB7865FE42B22B629B6D46F4F4BB992@MW4PR06MB7865.namprd06.prod.outlook.com">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style>.EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; }</style>
<font face="Calibri" size="2"><span style="font-size:11pt;">
<div>Hello,</div>
<div> </div>
<div>I am attempting to evaluate performance improvements
afforded by the Leyden CDS enhancements for an embedded
application running on aarch64. The application makes
extensive use of the --add-modules, --add-opens, and
--add-exports command line arguments.
However, it appears that these arguments are incompatible
with the -XX:CacheDataStore option, as their use results in
errors similar to the following: </div>
<div> </div>
<div>[0.004s][warning][cds] optimized module handling/full
module graph: disabled due to incompatible property:
jdk.module.addopens=java.base/java.nio=org.apache.tomcat.embed.core<br>
Error occurred during initialization of VM<br>
CacheDataStore cannot be created because AOTClassLinking is
enabled but full module graph is disabled</div>
<div> </div>
<div>Is this the expected behavior? If yes, is there a
workaround or a plan to support these options in the future?</div>
<div> </div>
<div> </div>
<div>Thanks, </div>
<div> </div>
<div>Jeff Boyce</div>
<div> </div>
<div> </div>
<div> </div>
</span></font>
</blockquote>
</body>
</html>