Generated from commit: e5c44a6

Signed-off-by: genie-openj9 <[email protected]>

jitserver_tuning/index.html

@@ -8301,7 +8301,7 @@ <h3 id="client-session-caches">Client-session caches</h3>
 </code></pre>
 <h3 id="jitserver-aot-cache">JITServer AOT cache</h3>
 <p>The JITServer technology can cache AOT compiled methods at the server.
- The JITServer can, therefore, avoid carrying out an AOT compilation when a compatible AOT method body already exists in the cache, thereby saving CPU resource and improving remote compilation latency. This mechanism works in conjunction with the <a href="https://www.eclipse.org/openj9/docs/aot/">dynamic AOT technology</a> at the client and therefore the client needs to have the <a href="https://www.eclipse.org/openj9/docs/shrc/">shared class cache</a> (SCC) enabled (the SCC is the repository for the AOT code).</p>
+ The JITServer can, therefore, avoid carrying out an AOT compilation when a compatible AOT method body already exists in the cache, thereby saving CPU resource and improving remote compilation latency. This mechanism works in conjunction with the <a href="https://www.eclipse.org/openj9/docs/aot/">dynamic AOT technology</a> at the client and therefore the client needs to have the <a href="https://www.eclipse.org/openj9/docs/shrc/">shared classes cache</a> (SCC) enabled (the SCC is the repository for the AOT code).</p>
 <p>When the JITServer receives an AOT compilation request, it checks its AOT cache for a compatible compiled method body. If one is not found, the server performs the AOT compilation, sends the response to the client JVM, then serializes the compiled method and stores it in its local AOT cache, for future use. If a compatible compiled method is found, the server sends the client the serialized compiled method from its cache, thus avoiding a compilation. The client deserializes the response, stores the result in its local SCC, and loads the compiled method as a regular dynamic AOT code.</p>
 <p>To enable this feature, specify the <a href="../xxjitserveruseaotcache/"><code>-XX:+JITServerUseAOTCache</code></a> command line option, both at the server and at the client JVM.</p>
 <p>A JITServer instance can have several AOT caches, each with its own name. This addresses the situation when client JVMs with significantly different profiles of execution use the same JITServer instance. A client JVM can indicate a specific AOT cache it wants to use by providing its name with the following command-line option <a href="../xxjitserveraotcachename/"><code>-XX:JITServerAOTCacheName=&lt;cache_name&gt;</code></a>. If the client doesn't specify a name for the AOT cache, the server uses a cache named <code>default</code>.</p>
@@ -8311,7 +8311,7 @@ <h3 id="jitserver-aot-cache">JITServer AOT cache</h3>
 <li>The number of extra AOT methods added to the in-memory cache since the last save operation is equal to or more than the value specified by the <code>-Xjit:aotCachePersistenceMinDeltaMethods=&lt;number_of_methods&gt;</code> option (default value - 200 methods), and</li>
 <li>The time passed since the last AOT cache save is equal to or later than the time specified by the <code>-Xjit:aotCachePersistenceMinPeriodMs=&lt;milliseconds&gt;</code> option (default time gap - 10000 milliseconds).</li>
 </ul>
-<p>If the JITServer AOT cache feature and the <a href="../xshareclasses/#readonly"><code>-Xshareclasses:readonly</code></a> option are both enabled at the same time at a JITServer client, the shared class cache startup creates a temporary new (writable) top layer that the JITServer AOT cache can use to store data that it needs to function.</p>
+<p>If the JITServer AOT cache feature and the <a href="../xshareclasses/#readonly"><code>-Xshareclasses:readonly</code></a> option are both enabled at the same time at a JITServer client, the shared classes cache startup creates a temporary new (writable) top layer that the JITServer AOT cache can use to store data that it needs to function.</p>
 <p>Current limitation:</p>
 <ul>
 <li>Caching works only for AOT compilation requests. For this reason, when JITServer AOT caching is enabled, the client JVM will attempt to generate as many AOT requests as possible.</li>

shrc/index.html

@@ -8429,7 +8429,7 @@ <h2 id="enabling-class-data-sharing">Enabling class data sharing</h2>
 <p>For a set of best practices when using class data sharing, see <a href="#creating-a-shared-classes-cache">Creating a shared classes cache</a>.</p>
 <h2 id="class-data-sharing-operations">Class data sharing operations</h2>
 <p>When a VM loads a class and the class loader is enabled for class sharing, the VM looks in the shared classes cache to see if the class is already present. If the class is present and the classpath or URL to load the class is a match, the VM loads the class from the cache. Otherwise, it loads the class from the file system and writes it into the cache.</p>
-<p>The VM detects file system updates by storing timestamp values into the cache and comparing the cached values with actual values. In this way, the VM detects when a class might be invalidated and can mark the class as <em>stale</em>. These operations happen transparently when classes are loaded, so users can modify and update as many classes as they like during the lifetime of a shared class cache, knowing that the correct classes are always loaded. Stale classes are <em>redeemed</em> if the same class is subsequently fetched by the class loader from another VM and checked against the stale class in the cache.</p>
+<p>The VM detects file system updates by storing timestamp values into the cache and comparing the cached values with actual values. In this way, the VM detects when a class might be invalidated and can mark the class as <em>stale</em>. These operations happen transparently when classes are loaded, so users can modify and update as many classes as they like during the lifetime of a shared classes cache, knowing that the correct classes are always loaded. Stale classes are <em>redeemed</em> if the same class is subsequently fetched by the class loader from another VM and checked against the stale class in the cache.</p>
 <p>Occasionally, caches that are created from one version of the VM might not be compatible with caches that are created from a different version. This situation typically occurs when an update is made in OpenJ9 that changes the internal cache data structure. If a VM detects an incompatible cache at start up, it creates a new cache that can coexist, even if it has the same name. The VM detects a conflict by checking an internal shared classes cache generation number.</p>
 <p>Caches are not compatible between VMs that are using different object storage modes. For example, a 64-bit VM that uses compressed references to store 64-bit objects in a 32-bit representation, cannot share a cache with a 64-bit VM that is not using compressed references. For more information about object storage options, see <a href="../allocation/#compressed-references">Compressed references</a>.</p>
 <p>In the OpenJ9 implementation of <code>java.net.URLClassLoader</code>, classes are read from and written to the cache using the public Helper API. Therefore, any class loader that extends <code>java.net.URLClassLoader</code> gets class sharing support for free provided that it continues to use the methods in <code>java.net.URLClassLoader</code> to load classes. Custom class loaders that do not extend <code>java.net.URLClassLoader</code> must be adapted to share class data as described in <a href="#support-for-custom-class-loaders">Support for custom class loaders</a>.</p>