Generated from commit: e235ad0b1a0978b055d656aeb8c4122db3b21580

Signed-off-by: genie-openj9 <openj9-bot@eclipse.org>
diff --git a/404.html b/404.html
index 359aeb2..0715448 100644
--- a/404.html
+++ b/404.html
@@ -289,6 +289,18 @@
   
   
     <li class="md-nav__item">
+      <a href="/openj9/docs/version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="/openj9/docs/version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -324,18 +336,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="/openj9/docs/version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -358,6 +358,18 @@
   
   
     <li class="md-nav__item">
+      <a href="/openj9/docs/version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="/openj9/docs/version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/allocation/index.html b/allocation/index.html
index ee944fa..3e1a333 100644
--- a/allocation/index.html
+++ b/allocation/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/aot/index.html b/aot/index.html
index a6d55ac..6395092 100644
--- a/aot/index.html
+++ b/aot/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/api-conditionhandling/index.html b/api-conditionhandling/index.html
index 4f895a0..93c5e6d 100644
--- a/api-conditionhandling/index.html
+++ b/api-conditionhandling/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/api-cuda/index.html b/api-cuda/index.html
index 306b1cf..e48267d 100644
--- a/api-cuda/index.html
+++ b/api-cuda/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/api-daa/index.html b/api-daa/index.html
index ed2a960..e2317e9 100644
--- a/api-daa/index.html
+++ b/api-daa/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/api-dtfj/index.html b/api-dtfj/index.html
index d230d84..db7a75b 100644
--- a/api-dtfj/index.html
+++ b/api-dtfj/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/api-gpu/index.html b/api-gpu/index.html
index 2e67dcc..de95552 100644
--- a/api-gpu/index.html
+++ b/api-gpu/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/api-jdk11/index.html b/api-jdk11/index.html
index 5eaeb8a..2fe8ca3 100644
--- a/api-jdk11/index.html
+++ b/api-jdk11/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/api-jdk17/index.html b/api-jdk17/index.html
index bdcfab3..4dacdbd 100644
--- a/api-jdk17/index.html
+++ b/api-jdk17/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/api-jvm/index.html b/api-jvm/index.html
index d535163..0c02fe4 100644
--- a/api-jvm/index.html
+++ b/api-jvm/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/api-langmgmt/index.html b/api-langmgmt/index.html
index 9069c32..ed2abd0 100644
--- a/api-langmgmt/index.html
+++ b/api-langmgmt/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/api-overview/index.html b/api-overview/index.html
index d471480..8a65463 100644
--- a/api-overview/index.html
+++ b/api-overview/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/api-shrc/index.html b/api-shrc/index.html
index 0823646..c8b4f9a 100644
--- a/api-shrc/index.html
+++ b/api-shrc/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/api/jdk17/allclasses-index.html b/api/jdk17/allclasses-index.html
index 24b62fc..3d25e55 100644
--- a/api/jdk17/allclasses-index.html
+++ b/api/jdk17/allclasses-index.html
@@ -955,7 +955,7 @@
 </div>
 <div class="col-first odd-row-color all-classes-table all-classes-table-tab2"><a href="openj9.cuda/com/ibm/cuda/CudaPermission.html" title="class in com.ibm.cuda">CudaPermission</a></div>
 <div class="col-last odd-row-color all-classes-table all-classes-table-tab2">
-<div class="block">This class defines CUDA permissions as described in the table below.</div>
+<div class="block">This class defines CUDA permissions as described in the following table.</div>
 </div>
 <div class="col-first even-row-color all-classes-table all-classes-table-tab2"><a href="openj9.cuda/com/ibm/cuda/CudaStream.html" title="class in com.ibm.cuda">CudaStream</a></div>
 <div class="col-last even-row-color all-classes-table all-classes-table-tab2">
@@ -1786,7 +1786,7 @@
 </div>
 <div class="col-first even-row-color all-classes-table all-classes-table-tab2"><a href="openj9.gpu/com/ibm/gpu/GPUPermission.html" title="class in com.ibm.gpu">GPUPermission</a></div>
 <div class="col-last even-row-color all-classes-table all-classes-table-tab2">
-<div class="block">This class defines GPU permissions as described in the table below.</div>
+<div class="block">This class defines GPU permissions as described in the following table.</div>
 </div>
 <div class="col-first odd-row-color all-classes-table all-classes-table-tab5"><a href="openj9.gpu/com/ibm/gpu/GPUSortException.html" title="class in com.ibm.gpu">GPUSortException</a></div>
 <div class="col-last odd-row-color all-classes-table all-classes-table-tab5">
@@ -4032,7 +4032,7 @@
 <div class="col-last odd-row-color all-classes-table all-classes-table-tab2">&nbsp;</div>
 <div class="col-first even-row-color all-classes-table all-classes-table-tab2"><a href="openj9.sharedclasses/com/ibm/oti/shared/SharedClassesNamedPermission.html" title="class in com.ibm.oti.shared">SharedClassesNamedPermission</a></div>
 <div class="col-last even-row-color all-classes-table all-classes-table-tab2">
-<div class="block">This class defines shared cache permissions as described in the table below.</div>
+<div class="block">This class defines shared cache permissions as described in the following table.</div>
 </div>
 <div class="col-first odd-row-color all-classes-table all-classes-table-tab1"><a href="openj9.sharedclasses/com/ibm/oti/shared/SharedClassFilter.html" title="interface in com.ibm.oti.shared">SharedClassFilter</a></div>
 <div class="col-last odd-row-color all-classes-table all-classes-table-tab1">
diff --git a/api/jdk17/index-files/index-19.html b/api/jdk17/index-files/index-19.html
index 7a2d124..ca33e2a 100644
--- a/api/jdk17/index-files/index-19.html
+++ b/api/jdk17/index-files/index-19.html
@@ -1410,7 +1410,7 @@
 <dd>&nbsp;</dd>
 <dt><a href="../openj9.sharedclasses/com/ibm/oti/shared/SharedClassesNamedPermission.html" class="type-name-link" title="class in com.ibm.oti.shared">SharedClassesNamedPermission</a> - Class in <a href="../openj9.sharedclasses/com/ibm/oti/shared/package-summary.html">com.ibm.oti.shared</a></dt>
 <dd>
-<div class="block">This class defines shared cache permissions as described in the table below.</div>
+<div class="block">This class defines shared cache permissions as described in the following table.</div>
 </dd>
 <dt><a href="../openj9.sharedclasses/com/ibm/oti/shared/SharedClassesNamedPermission.html#%3Cinit%3E(java.lang.String)" class="member-name-link">SharedClassesNamedPermission(String)</a> - Constructor for class com.ibm.oti.shared.<a href="../openj9.sharedclasses/com/ibm/oti/shared/SharedClassesNamedPermission.html" title="class in com.ibm.oti.shared">SharedClassesNamedPermission</a></dt>
 <dd>
diff --git a/api/jdk17/index-files/index-3.html b/api/jdk17/index-files/index-3.html
index 3308f5c..8c4c4d0 100644
--- a/api/jdk17/index-files/index-3.html
+++ b/api/jdk17/index-files/index-3.html
@@ -2957,7 +2957,7 @@
 </dd>
 <dt><a href="../openj9.cuda/com/ibm/cuda/CudaPermission.html" class="type-name-link" title="class in com.ibm.cuda">CudaPermission</a> - Class in <a href="../openj9.cuda/com/ibm/cuda/package-summary.html">com.ibm.cuda</a></dt>
 <dd>
-<div class="block">This class defines CUDA permissions as described in the table below.</div>
+<div class="block">This class defines CUDA permissions as described in the following table.</div>
 </dd>
 <dt><a href="../openj9.cuda/com/ibm/cuda/CudaPermission.html#%3Cinit%3E(java.lang.String)" class="member-name-link">CudaPermission(String)</a> - Constructor for class com.ibm.cuda.<a href="../openj9.cuda/com/ibm/cuda/CudaPermission.html" title="class in com.ibm.cuda">CudaPermission</a></dt>
 <dd>
diff --git a/api/jdk17/index-files/index-7.html b/api/jdk17/index-files/index-7.html
index 9bc8394..2a3abd5 100644
--- a/api/jdk17/index-files/index-7.html
+++ b/api/jdk17/index-files/index-7.html
@@ -729,7 +729,7 @@
 </dd>
 <dt><a href="../openj9.dtfj/com/ibm/dtfj/image/Image.html#getAddressSpaces()" class="member-name-link">getAddressSpaces()</a> - Method in interface com.ibm.dtfj.image.<a href="../openj9.dtfj/com/ibm/dtfj/image/Image.html" title="interface in com.ibm.dtfj.image">Image</a></dt>
 <dd>
-<div class="block">Get the set of address spaces within the image - typically one but may be more on some 
+<div class="block">Get the set of address spaces within the image - typically one but may be more on some
  systems such as Z/OS.</div>
 </dd>
 <dt><a href="../openj9.dtfj/com/ibm/dtfj/image/j9/Builder.html#getAddressSpaces()" class="member-name-link">getAddressSpaces()</a> - Method in class com.ibm.dtfj.image.j9.<a href="../openj9.dtfj/com/ibm/dtfj/image/j9/Builder.html" title="class in com.ibm.dtfj.image.j9">Builder</a></dt>
@@ -8328,11 +8328,11 @@
 </dd>
 <dt><a href="../jdk.management/com/ibm/lang/management/internal/ExtendedOperatingSystemMXBeanImpl.html#getProcessCpuLoad()" class="member-name-link">getProcessCpuLoad()</a> - Method in class com.ibm.lang.management.internal.<a href="../jdk.management/com/ibm/lang/management/internal/ExtendedOperatingSystemMXBeanImpl.html" title="class in com.ibm.lang.management.internal">ExtendedOperatingSystemMXBeanImpl</a></dt>
 <dd>
-<div class="block">Returns the "recent cpu usage" for the Java Virtual Machine process.</div>
+<div class="block">Returns the recent CPU usage for the Java Virtual Machine process.</div>
 </dd>
 <dt><a href="../jdk.management/com/ibm/lang/management/OperatingSystemMXBean.html#getProcessCpuLoad()" class="member-name-link">getProcessCpuLoad()</a> - Method in interface com.ibm.lang.management.<a href="../jdk.management/com/ibm/lang/management/OperatingSystemMXBean.html" title="interface in com.ibm.lang.management">OperatingSystemMXBean</a></dt>
 <dd>
-<div class="block">Returns the "recent cpu usage" for the Java Virtual Machine process.</div>
+<div class="block">Returns the recent CPU usage for the Java Virtual Machine process.</div>
 </dd>
 <dt><a href="../jdk.management/com/ibm/lang/management/internal/ExtendedOperatingSystemMXBeanImpl.html#getProcessCpuTime()" class="member-name-link">getProcessCpuTime()</a> - Method in class com.ibm.lang.management.internal.<a href="../jdk.management/com/ibm/lang/management/internal/ExtendedOperatingSystemMXBeanImpl.html" title="class in com.ibm.lang.management.internal">ExtendedOperatingSystemMXBeanImpl</a></dt>
 <dd>
@@ -10392,11 +10392,11 @@
 </dd>
 <dt><a href="../jdk.management/com/ibm/lang/management/internal/ExtendedOperatingSystemMXBeanImpl.html#getSystemCpuLoad()" class="member-name-link">getSystemCpuLoad()</a> - Method in class com.ibm.lang.management.internal.<a href="../jdk.management/com/ibm/lang/management/internal/ExtendedOperatingSystemMXBeanImpl.html" title="class in com.ibm.lang.management.internal">ExtendedOperatingSystemMXBeanImpl</a></dt>
 <dd>
-<div class="block">Returns the "recent cpu usage" for the whole system.</div>
+<div class="block">Returns the recent CPU usage for the whole system.</div>
 </dd>
 <dt><a href="../jdk.management/com/ibm/lang/management/OperatingSystemMXBean.html#getSystemCpuLoad()" class="member-name-link">getSystemCpuLoad()</a> - Method in interface com.ibm.lang.management.<a href="../jdk.management/com/ibm/lang/management/OperatingSystemMXBean.html" title="interface in com.ibm.lang.management">OperatingSystemMXBean</a></dt>
 <dd>
-<div class="block">Returns the "recent cpu usage" for the whole system.</div>
+<div class="block">Returns the recent CPU usage for the whole system.</div>
 </dd>
 <dt><a href="../jdk.management/com/ibm/lang/management/JvmCpuMonitorInfo.html#getSystemJvmCpuTime()" class="member-name-link">getSystemJvmCpuTime()</a> - Method in class com.ibm.lang.management.<a href="../jdk.management/com/ibm/lang/management/JvmCpuMonitorInfo.html" title="class in com.ibm.lang.management">JvmCpuMonitorInfo</a></dt>
 <dd>
@@ -11459,7 +11459,7 @@
 </dd>
 <dt><a href="../openj9.gpu/com/ibm/gpu/GPUPermission.html" class="type-name-link" title="class in com.ibm.gpu">GPUPermission</a> - Class in <a href="../openj9.gpu/com/ibm/gpu/package-summary.html">com.ibm.gpu</a></dt>
 <dd>
-<div class="block">This class defines GPU permissions as described in the table below.</div>
+<div class="block">This class defines GPU permissions as described in the following table.</div>
 </dd>
 <dt><a href="../openj9.gpu/com/ibm/gpu/GPUPermission.html#%3Cinit%3E(java.lang.String)" class="member-name-link">GPUPermission(String)</a> - Constructor for class com.ibm.gpu.<a href="../openj9.gpu/com/ibm/gpu/GPUPermission.html" title="class in com.ibm.gpu">GPUPermission</a></dt>
 <dd>
diff --git a/api/jdk17/jdk.management/com/ibm/lang/management/OperatingSystemMXBean.html b/api/jdk17/jdk.management/com/ibm/lang/management/OperatingSystemMXBean.html
index 361bc0f..a9e62e2 100644
--- a/api/jdk17/jdk.management/com/ibm/lang/management/OperatingSystemMXBean.html
+++ b/api/jdk17/jdk.management/com/ibm/lang/management/OperatingSystemMXBean.html
@@ -112,7 +112,7 @@
 <hr>
 <div class="type-signature"><span class="modifiers">public interface </span><span class="element-name type-name-label">OperatingSystemMXBean</span><span class="extends-implements">
 extends <a href="https://docs.oracle.com/en/java/javase/17/docs/api/jdk.management/com/sun/management/OperatingSystemMXBean.html" title="class or interface in com.sun.management" class="external-link" target="_blank">OperatingSystemMXBean</a></span></div>
-<div class="block">OpenJ9 platform management extension interface for the Operating System on which the Java Virtual Machine is running. 
+<div class="block">OpenJ9 platform management extension interface for the Operating System on which the Java Virtual Machine is running.
  <br>
  <table border="1">
  <caption><b>Usage example for the <a href="OperatingSystemMXBean.html" title="interface in com.ibm.lang.management"><code>OperatingSystemMXBean</code></a></b></caption>
@@ -166,7 +166,7 @@
 <div class="col-first even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab3"><code>double</code></div>
 <div class="col-second even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab3"><code><a href="#getProcessCpuLoad()" class="member-name-link">getProcessCpuLoad</a>()</code></div>
 <div class="col-last even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab3">
-<div class="block">Returns the "recent cpu usage" for the Java Virtual Machine process.</div>
+<div class="block">Returns the recent CPU usage for the Java Virtual Machine process.</div>
 </div>
 <div class="col-first odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab3"><code>long</code></div>
 <div class="col-second odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab3"><code><a href="#getProcessCpuTime()" class="member-name-link">getProcessCpuTime</a>()</code></div>
@@ -204,7 +204,7 @@
 <div class="col-first odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab3"><code>double</code></div>
 <div class="col-second odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab3"><code><a href="#getSystemCpuLoad()" class="member-name-link">getSystemCpuLoad</a>()</code></div>
 <div class="col-last odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab3">
-<div class="block">Returns the "recent cpu usage" for the whole system.</div>
+<div class="block">Returns the recent CPU usage for the whole system.</div>
 </div>
 <div class="col-first even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab3 method-summary-table-tab6"><code>long</code></div>
 <div class="col-second even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab3 method-summary-table-tab6"><code><a href="#getTotalPhysicalMemory()" class="member-name-link">getTotalPhysicalMemory</a>()</code></div>
@@ -343,14 +343,14 @@
 <div class="block">Returns total amount of time the process has been scheduled or
  executed so far in both kernel and user modes. Returns -1 if the
  value is unavailable on this platform or in the case of an error.
- 
- Note that as of Java 8 SR5 the returned value is in 1 ns units, unless the system property 
+
+ Note that as of Java 8 SR5 the returned value is in 1 ns units, unless the system property
  com.ibm.lang.management.OperatingSystemMXBean.isCpuTime100ns is set to "true".</div>
 <dl class="notes">
 <dt>Specified by:</dt>
 <dd><code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/jdk.management/com/sun/management/OperatingSystemMXBean.html#getProcessCpuTime()" title="class or interface in com.sun.management" class="external-link" target="_blank">getProcessCpuTime</a></code>&nbsp;in interface&nbsp;<code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/jdk.management/com/sun/management/OperatingSystemMXBean.html" title="class or interface in com.sun.management" class="external-link" target="_blank">OperatingSystemMXBean</a></code></dd>
 <dt>Returns:</dt>
-<dd>process cpu time.</dd>
+<dd>process CPU time.</dd>
 </dl>
 </section>
 </li>
@@ -368,17 +368,17 @@
 <section class="detail" id="getSystemCpuLoad()">
 <h3>getSystemCpuLoad</h3>
 <div class="member-signature"><span class="return-type">double</span>&nbsp;<span class="element-name">getSystemCpuLoad</span>()</div>
-<div class="block">Returns the "recent cpu usage" for the whole system. This value is a double in
+<div class="block">Returns the recent CPU usage for the whole system. This value is a double in
  the [0.0,1.0] interval. A value of 0.0 means all CPUs were idle in the recent
  period of time observed, while a value of 1.0 means that all CPUs were actively
  running 100% of the time during the recent period of time observed. All values
- between 0.0 and 1.0 are possible. The first call to the method always 
+ between 0.0 and 1.0 are possible. The first call to the method always
  returns <a href="CpuLoadCalculationConstants.html" title="interface in com.ibm.lang.management"><code>CpuLoadCalculationConstants</code></a>.ERROR_VALUE
  (-1.0), which marks the starting point. If the Java Virtual Machine's recent CPU
  usage is not available, the method returns a negative error code from
  <a href="CpuLoadCalculationConstants.html" title="interface in com.ibm.lang.management"><code>CpuLoadCalculationConstants</code></a>.
  <p>getSystemCpuLoad might not return the same value that is reported by operating system
- utilities such as Unix "top" or Windows task manager.</p></div>
+ utilities such as Unix <code>top</code> or Windows task manager.</p></div>
 <dl class="notes">
 <dt>Specified by:</dt>
 <dd><code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/jdk.management/com/sun/management/OperatingSystemMXBean.html#getSystemCpuLoad()" title="class or interface in com.sun.management" class="external-link" target="_blank">getSystemCpuLoad</a></code>&nbsp;in interface&nbsp;<code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/jdk.management/com/sun/management/OperatingSystemMXBean.html" title="class or interface in com.sun.management" class="external-link" target="_blank">OperatingSystemMXBean</a></code></dd>
@@ -406,7 +406,7 @@
 <section class="detail" id="getFreePhysicalMemorySize()">
 <h3>getFreePhysicalMemorySize</h3>
 <div class="member-signature"><span class="return-type">long</span>&nbsp;<span class="element-name">getFreePhysicalMemorySize</span>()</div>
-<div class="block">Returns the amount of physical memory that is available on the system in bytes. 
+<div class="block">Returns the amount of physical memory that is available on the system in bytes.
  Returns -1 if the value is unavailable on this platform or in the case of an error.
  <ul>
  <li>This information is not available on the z/OS platform.
@@ -515,14 +515,14 @@
 <section class="detail" id="getProcessCpuLoad()">
 <h3>getProcessCpuLoad</h3>
 <div class="member-signature"><span class="return-type">double</span>&nbsp;<span class="element-name">getProcessCpuLoad</span>()</div>
-<div class="block">Returns the "recent cpu usage" for the Java Virtual Machine process.
+<div class="block">Returns the recent CPU usage for the Java Virtual Machine process.
  This value is a double in the [0.0,1.0] interval. A value of 0.0 means
  that none of the CPUs were running threads from the JVM process during
  the recent period of time observed, while a value of 1.0 means that all
  CPUs were actively running threads from the JVM 100% of the time
  during the recent period of time observed. Threads from the JVM include
  application threads as well as JVM internal threads. All values
- between 0.0 and 1.0 are possible. The first call to the method always 
+ between 0.0 and 1.0 are possible. The first call to the method always
  returns <a href="CpuLoadCalculationConstants.html" title="interface in com.ibm.lang.management"><code>CpuLoadCalculationConstants</code></a>.ERROR_VALUE
  (-1.0), which marks the starting point. If the Java Virtual Machine's recent CPU
  usage is not available, the method returns a negative error code from
@@ -610,7 +610,7 @@
 <dt>Throws:</dt>
 <dd><code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/NullPointerException.html" title="class or interface in java.lang" class="external-link" target="_blank">NullPointerException</a></code> - if a null reference is passed as parameter.</dd>
 <dd><code><a href="ProcessorUsageRetrievalException.html" title="class in com.ibm.lang.management">ProcessorUsageRetrievalException</a></code> - if it failed obtaining Processor usage statistics.</dd>
-<dd><code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/IllegalArgumentException.html" title="class or interface in java.lang" class="external-link" target="_blank">IllegalArgumentException</a></code> - if array provided has insufficient entries and there are more 
+<dd><code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/IllegalArgumentException.html" title="class or interface in java.lang" class="external-link" target="_blank">IllegalArgumentException</a></code> - if array provided has insufficient entries and there are more
                    Processors to report on.
 
  <p>In case of an exception, the handler code might use toString() on the exception code
@@ -695,8 +695,8 @@
 <dt>Returns:</dt>
 <dd>The new <a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/String.html" title="class or interface in java.lang" class="external-link" target="_blank"><code>String</code></a> object or NULL in case of an error.</dd>
 <dt>Throws:</dt>
-<dd><code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/UnsupportedOperationException.html" title="class or interface in java.lang" class="external-link" target="_blank">UnsupportedOperationException</a></code> - if the operation is not implemented on this platform. 
- UnsupportedOperationException will also be thrown if the operation is implemented but it 
+<dd><code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/UnsupportedOperationException.html" title="class or interface in java.lang" class="external-link" target="_blank">UnsupportedOperationException</a></code> - if the operation is not implemented on this platform.
+ UnsupportedOperationException will also be thrown if the operation is implemented but it
  cannot be performed because the system does not satisfy all the requirements, for example,
  an OS service is not installed.</dd>
 <dt>Since:</dt>
diff --git a/api/jdk17/jdk.management/com/ibm/lang/management/internal/ExtendedOperatingSystemMXBeanImpl.html b/api/jdk17/jdk.management/com/ibm/lang/management/internal/ExtendedOperatingSystemMXBeanImpl.html
index 65c48f8..a71d92a 100644
--- a/api/jdk17/jdk.management/com/ibm/lang/management/internal/ExtendedOperatingSystemMXBeanImpl.html
+++ b/api/jdk17/jdk.management/com/ibm/lang/management/internal/ExtendedOperatingSystemMXBeanImpl.html
@@ -190,7 +190,7 @@
 <div class="col-first odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code>final double</code></div>
 <div class="col-second odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="#getProcessCpuLoad()" class="member-name-link">getProcessCpuLoad</a>()</code></div>
 <div class="col-last odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4">
-<div class="block">Returns the "recent cpu usage" for the Java Virtual Machine process.</div>
+<div class="block">Returns the recent CPU usage for the Java Virtual Machine process.</div>
 </div>
 <div class="col-first even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code>final long</code></div>
 <div class="col-second even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="#getProcessCpuTime()" class="member-name-link">getProcessCpuTime</a>()</code></div>
@@ -228,7 +228,7 @@
 <div class="col-first even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code>final double</code></div>
 <div class="col-second even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="#getSystemCpuLoad()" class="member-name-link">getSystemCpuLoad</a>()</code></div>
 <div class="col-last even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4">
-<div class="block">Returns the "recent cpu usage" for the whole system.</div>
+<div class="block">Returns the recent CPU usage for the whole system.</div>
 </div>
 <div class="col-first odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code>long</code></div>
 <div class="col-second odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="#getTotalMemorySize()" class="member-name-link">getTotalMemorySize</a>()</code></div>
@@ -354,7 +354,7 @@
 <section class="detail" id="getFreePhysicalMemorySize()">
 <h3>getFreePhysicalMemorySize</h3>
 <div class="member-signature"><span class="modifiers">public final</span>&nbsp;<span class="return-type">long</span>&nbsp;<span class="element-name">getFreePhysicalMemorySize</span>()</div>
-<div class="block">Returns the amount of physical memory that is available on the system in bytes. 
+<div class="block">Returns the amount of physical memory that is available on the system in bytes.
  Returns -1 if the value is unavailable on this platform or in the case of an error.
  <ul>
  <li>This information is not available on the z/OS platform.
@@ -454,14 +454,14 @@
 <section class="detail" id="getProcessCpuLoad()">
 <h3>getProcessCpuLoad</h3>
 <div class="member-signature"><span class="modifiers">public final</span>&nbsp;<span class="return-type">double</span>&nbsp;<span class="element-name">getProcessCpuLoad</span>()</div>
-<div class="block">Returns the "recent cpu usage" for the Java Virtual Machine process.
+<div class="block">Returns the recent CPU usage for the Java Virtual Machine process.
  This value is a double in the [0.0,1.0] interval. A value of 0.0 means
  that none of the CPUs were running threads from the JVM process during
  the recent period of time observed, while a value of 1.0 means that all
  CPUs were actively running threads from the JVM 100% of the time
  during the recent period of time observed. Threads from the JVM include
  application threads as well as JVM internal threads. All values
- between 0.0 and 1.0 are possible. The first call to the method always 
+ between 0.0 and 1.0 are possible. The first call to the method always
  returns <a href="../CpuLoadCalculationConstants.html" title="interface in com.ibm.lang.management"><code>CpuLoadCalculationConstants</code></a>.ERROR_VALUE
  (-1.0), which marks the starting point. If the Java Virtual Machine's recent CPU
  usage is not available, the method returns a negative error code from
@@ -493,8 +493,8 @@
 <div class="block">Returns total amount of time the process has been scheduled or
  executed so far in both kernel and user modes. Returns -1 if the
  value is unavailable on this platform or in the case of an error.
- 
- Note that as of Java 8 SR5 the returned value is in 1 ns units, unless the system property 
+
+ Note that as of Java 8 SR5 the returned value is in 1 ns units, unless the system property
  com.ibm.lang.management.OperatingSystemMXBean.isCpuTime100ns is set to "true".</div>
 <dl class="notes">
 <dt>Specified by:</dt>
@@ -502,7 +502,7 @@
 <dt>Specified by:</dt>
 <dd><code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/jdk.management/com/sun/management/OperatingSystemMXBean.html#getProcessCpuTime()" title="class or interface in com.sun.management" class="external-link" target="_blank">getProcessCpuTime</a></code>&nbsp;in interface&nbsp;<code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/jdk.management/com/sun/management/OperatingSystemMXBean.html" title="class or interface in com.sun.management" class="external-link" target="_blank">OperatingSystemMXBean</a></code></dd>
 <dt>Returns:</dt>
-<dd>process cpu time.</dd>
+<dd>process CPU time.</dd>
 </dl>
 </section>
 </li>
@@ -613,17 +613,17 @@
 <section class="detail" id="getSystemCpuLoad()">
 <h3>getSystemCpuLoad</h3>
 <div class="member-signature"><span class="modifiers">public final</span>&nbsp;<span class="return-type">double</span>&nbsp;<span class="element-name">getSystemCpuLoad</span>()</div>
-<div class="block">Returns the "recent cpu usage" for the whole system. This value is a double in
+<div class="block">Returns the recent CPU usage for the whole system. This value is a double in
  the [0.0,1.0] interval. A value of 0.0 means all CPUs were idle in the recent
  period of time observed, while a value of 1.0 means that all CPUs were actively
  running 100% of the time during the recent period of time observed. All values
- between 0.0 and 1.0 are possible. The first call to the method always 
+ between 0.0 and 1.0 are possible. The first call to the method always
  returns <a href="../CpuLoadCalculationConstants.html" title="interface in com.ibm.lang.management"><code>CpuLoadCalculationConstants</code></a>.ERROR_VALUE
  (-1.0), which marks the starting point. If the Java Virtual Machine's recent CPU
  usage is not available, the method returns a negative error code from
  <a href="../CpuLoadCalculationConstants.html" title="interface in com.ibm.lang.management"><code>CpuLoadCalculationConstants</code></a>.
  <p>getSystemCpuLoad might not return the same value that is reported by operating system
- utilities such as Unix "top" or Windows task manager.</p></div>
+ utilities such as Unix <code>top</code> or Windows task manager.</p></div>
 <dl class="notes">
 <dt>Specified by:</dt>
 <dd><code><a href="../OperatingSystemMXBean.html#getSystemCpuLoad()">getSystemCpuLoad</a></code>&nbsp;in interface&nbsp;<code><a href="../OperatingSystemMXBean.html" title="interface in com.ibm.lang.management">OperatingSystemMXBean</a></code></dd>
@@ -794,7 +794,7 @@
 <dt>Throws:</dt>
 <dd><code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/NullPointerException.html" title="class or interface in java.lang" class="external-link" target="_blank">NullPointerException</a></code> - if a null reference is passed as parameter.</dd>
 <dd><code><a href="../ProcessorUsageRetrievalException.html" title="class in com.ibm.lang.management">ProcessorUsageRetrievalException</a></code> - if it failed obtaining Processor usage statistics.</dd>
-<dd><code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/IllegalArgumentException.html" title="class or interface in java.lang" class="external-link" target="_blank">IllegalArgumentException</a></code> - if array provided has insufficient entries and there are more 
+<dd><code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/IllegalArgumentException.html" title="class or interface in java.lang" class="external-link" target="_blank">IllegalArgumentException</a></code> - if array provided has insufficient entries and there are more
                    Processors to report on.
 
  <p>In case of an exception, the handler code might use toString() on the exception code
diff --git a/api/jdk17/openj9.cuda/com/ibm/cuda/CudaError.html b/api/jdk17/openj9.cuda/com/ibm/cuda/CudaError.html
index dadd33b..b6c3e9c 100644
--- a/api/jdk17/openj9.cuda/com/ibm/cuda/CudaError.html
+++ b/api/jdk17/openj9.cuda/com/ibm/cuda/CudaError.html
@@ -1211,8 +1211,8 @@
  either because the Driver context was created using an older version
  of the API, because the Runtime API call expects a primary driver
  context and the Driver context is not primary, or because the Driver
- context has been destroyed. Please see \ref CUDART_DRIVER "Interactions
- with the CUDA Driver API" for more information.</div>
+ context has been destroyed. Please see CUDART_DRIVER <q>Interactions
+ with the CUDA Driver API</q> for more information.</div>
 <dl class="notes">
 <dt>See Also:</dt>
 <dd>
diff --git a/api/jdk17/openj9.cuda/com/ibm/cuda/CudaPermission.html b/api/jdk17/openj9.cuda/com/ibm/cuda/CudaPermission.html
index fd25724..c965d65 100644
--- a/api/jdk17/openj9.cuda/com/ibm/cuda/CudaPermission.html
+++ b/api/jdk17/openj9.cuda/com/ibm/cuda/CudaPermission.html
@@ -87,7 +87,7 @@
 <hr>
 <div class="type-signature"><span class="modifiers">public final class </span><span class="element-name type-name-label">CudaPermission</span>
 <span class="extends-implements">extends <a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/BasicPermission.html" title="class or interface in java.security" class="external-link" target="_blank">BasicPermission</a></span></div>
-<div class="block">This class defines CUDA permissions as described in the table below.
+<div class="block">This class defines CUDA permissions as described in the following table.
 
  <table border=1 style="padding:5px">
  <caption>CUDA Permissions</caption>
diff --git a/api/jdk17/openj9.cuda/com/ibm/cuda/package-summary.html b/api/jdk17/openj9.cuda/com/ibm/cuda/package-summary.html
index 766293a..701ec93 100644
--- a/api/jdk17/openj9.cuda/com/ibm/cuda/package-summary.html
+++ b/api/jdk17/openj9.cuda/com/ibm/cuda/package-summary.html
@@ -197,7 +197,7 @@
 </div>
 <div class="col-first even-row-color class-summary class-summary-tab2"><a href="CudaPermission.html" title="class in com.ibm.cuda">CudaPermission</a></div>
 <div class="col-last even-row-color class-summary class-summary-tab2">
-<div class="block">This class defines CUDA permissions as described in the table below.</div>
+<div class="block">This class defines CUDA permissions as described in the following table.</div>
 </div>
 <div class="col-first odd-row-color class-summary class-summary-tab2"><a href="CudaStream.html" title="class in com.ibm.cuda">CudaStream</a></div>
 <div class="col-last odd-row-color class-summary class-summary-tab2">
diff --git a/api/jdk17/openj9.dtfj/com/ibm/dtfj/image/Image.html b/api/jdk17/openj9.dtfj/com/ibm/dtfj/image/Image.html
index 90d2468..5a811cf 100644
--- a/api/jdk17/openj9.dtfj/com/ibm/dtfj/image/Image.html
+++ b/api/jdk17/openj9.dtfj/com/ibm/dtfj/image/Image.html
@@ -102,11 +102,11 @@
 </dl>
 <hr>
 <div class="type-signature"><span class="modifiers">public interface </span><span class="element-name type-name-label">Image</span></div>
-<div class="block"><p>Represents an entire operating system image (for example, a core file).</p> 
- 
- <p>There are methods for accessing information about the architecture 
- of the machine on which the image was running - hardware and 
- operating system. The major feature, however, is the ability to 
+<div class="block"><p>Represents an entire operating system image (for example, a core file).</p>
+
+ <p>There are methods for accessing information about the architecture
+ of the machine on which the image was running - hardware and
+ operating system. The major feature, however, is the ability to
  iterate over the Address Spaces contained within the image.</p></div>
 </section>
 <section class="summary">
@@ -130,7 +130,7 @@
 <div class="col-first odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab3"><code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Iterator.html" title="class or interface in java.util" class="external-link" target="_blank">Iterator</a></code></div>
 <div class="col-second odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab3"><code><a href="#getAddressSpaces()" class="member-name-link">getAddressSpaces</a>()</code></div>
 <div class="col-last odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab3">
-<div class="block">Get the set of address spaces within the image - typically one but may be more on some 
+<div class="block">Get the set of address spaces within the image - typically one but may be more on some
  systems such as Z/OS.</div>
 </div>
 <div class="col-first even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab3"><code>long</code></div>
@@ -218,7 +218,7 @@
 <section class="detail" id="getAddressSpaces()">
 <h3>getAddressSpaces</h3>
 <div class="member-signature"><span class="return-type"><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Iterator.html" title="class or interface in java.util" class="external-link" target="_blank">Iterator</a></span>&nbsp;<span class="element-name">getAddressSpaces</span>()</div>
-<div class="block">Get the set of address spaces within the image - typically one but may be more on some 
+<div class="block">Get the set of address spaces within the image - typically one but may be more on some
  systems such as Z/OS.</div>
 <dl class="notes">
 <dt>Returns:</dt>
@@ -264,7 +264,7 @@
 <dt>Returns:</dt>
 <dd>the precise model of the CPU (note that this can be an empty string but not null).
  <br>
- e.g. getProcessorType() will return "x86" where getProcessorSubType() may return "Pentium IV step 4"
+ e.g. getProcessorType() will return <q>x86</q> where getProcessorSubType() may return <q>Pentium IV step 4</q>
  <p>
  Note that this value is platform and implementation dependent.</dd>
 <dt>Throws:</dt>
@@ -381,8 +381,8 @@
 <div class="block">The set of IP addresses (as InetAddresses) which the system running the image possessed.</div>
 <dl class="notes">
 <dt>Returns:</dt>
-<dd>An Iterator over the IP addresses (as InetAddresses) which the system running 
- the image possessed.  The iterator will be non-null (but can be empty if the host is 
+<dd>An Iterator over the IP addresses (as InetAddresses) which the system running
+ the image possessed.  The iterator will be non-null (but can be empty if the host is
  known to have no IP addresses).</dd>
 <dt>Throws:</dt>
 <dd><code><a href="DataUnavailable.html" title="class in com.ibm.dtfj.image">DataUnavailable</a></code> - If the image did not provide this information (would happen
@@ -404,8 +404,8 @@
 <h3>close</h3>
 <div class="member-signature"><span class="return-type">void</span>&nbsp;<span class="element-name">close</span>()</div>
 <div class="block"><p>Close this image and any associated resources.</p>
- 
- <p>Some kinds of Image require the generation of temporary resources, for example temporary files created 
+
+ <p>Some kinds of Image require the generation of temporary resources, for example temporary files created
  when reading core files and libraries from .zip archives. Ordinarily, these resources are deleted at JVM shutdown,
  but DTFJ applications may want to free them earlier. This method should only be called when the Image is no
  longer needed. After this method has been called, any objects associated with the image will be in an invalid state.</p></div>
diff --git a/api/jdk17/openj9.dtfj/com/ibm/dtfj/image/j9/Image.html b/api/jdk17/openj9.dtfj/com/ibm/dtfj/image/j9/Image.html
index 9819d92..8559b98 100644
--- a/api/jdk17/openj9.dtfj/com/ibm/dtfj/image/j9/Image.html
+++ b/api/jdk17/openj9.dtfj/com/ibm/dtfj/image/j9/Image.html
@@ -166,7 +166,7 @@
 <div class="col-first odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Iterator.html" title="class or interface in java.util" class="external-link" target="_blank">Iterator</a></code></div>
 <div class="col-second odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="#getAddressSpaces()" class="member-name-link">getAddressSpaces</a>()</code></div>
 <div class="col-last odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4">
-<div class="block">Get the set of address spaces within the image - typically one but may be more on some 
+<div class="block">Get the set of address spaces within the image - typically one but may be more on some
  systems such as Z/OS.</div>
 </div>
 <div class="col-first even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code>long</code></div>
@@ -288,7 +288,7 @@
 <h3>getAddressSpaces</h3>
 <div class="member-signature"><span class="modifiers">public</span>&nbsp;<span class="return-type"><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Iterator.html" title="class or interface in java.util" class="external-link" target="_blank">Iterator</a></span>&nbsp;<span class="element-name">getAddressSpaces</span>()</div>
 <div class="block"><span class="descfrm-type-label">Description copied from interface:&nbsp;<code><a href="../Image.html#getAddressSpaces()">Image</a></code></span></div>
-<div class="block">Get the set of address spaces within the image - typically one but may be more on some 
+<div class="block">Get the set of address spaces within the image - typically one but may be more on some
  systems such as Z/OS.</div>
 <dl class="notes">
 <dt>Specified by:</dt>
@@ -342,7 +342,7 @@
 <dt>Returns:</dt>
 <dd>the precise model of the CPU (note that this can be an empty string but not null).
  <br>
- e.g. getProcessorType() will return "x86" where getProcessorSubType() may return "Pentium IV step 4"
+ e.g. getProcessorType() will return <q>x86</q> where getProcessorSubType() may return <q>Pentium IV step 4</q>
  <p>
  Note that this value is platform and implementation dependent.</dd>
 <dt>Throws:</dt>
@@ -482,8 +482,8 @@
 <dt>Specified by:</dt>
 <dd><code><a href="../Image.html#getIPAddresses()">getIPAddresses</a></code>&nbsp;in interface&nbsp;<code><a href="../Image.html" title="interface in com.ibm.dtfj.image">Image</a></code></dd>
 <dt>Returns:</dt>
-<dd>An Iterator over the IP addresses (as InetAddresses) which the system running 
- the image possessed.  The iterator will be non-null (but can be empty if the host is 
+<dd>An Iterator over the IP addresses (as InetAddresses) which the system running
+ the image possessed.  The iterator will be non-null (but can be empty if the host is
  known to have no IP addresses).</dd>
 <dt>Throws:</dt>
 <dd><code><a href="../DataUnavailable.html" title="class in com.ibm.dtfj.image">DataUnavailable</a></code> - If the image did not provide this information (would happen
@@ -526,8 +526,8 @@
 <div class="member-signature"><span class="modifiers">public</span>&nbsp;<span class="return-type">void</span>&nbsp;<span class="element-name">close</span>()</div>
 <div class="block"><span class="descfrm-type-label">Description copied from interface:&nbsp;<code><a href="../Image.html#close()">Image</a></code></span></div>
 <div class="block"><p>Close this image and any associated resources.</p>
- 
- <p>Some kinds of Image require the generation of temporary resources, for example temporary files created 
+
+ <p>Some kinds of Image require the generation of temporary resources, for example temporary files created
  when reading core files and libraries from .zip archives. Ordinarily, these resources are deleted at JVM shutdown,
  but DTFJ applications may want to free them earlier. This method should only be called when the Image is no
  longer needed. After this method has been called, any objects associated with the image will be in an invalid state.</p></div>
diff --git a/api/jdk17/openj9.dtfj/com/ibm/dtfj/image/javacore/JCImage.html b/api/jdk17/openj9.dtfj/com/ibm/dtfj/image/javacore/JCImage.html
index e74b33b..3f1b5cb 100644
--- a/api/jdk17/openj9.dtfj/com/ibm/dtfj/image/javacore/JCImage.html
+++ b/api/jdk17/openj9.dtfj/com/ibm/dtfj/image/javacore/JCImage.html
@@ -162,7 +162,7 @@
 <div class="col-first even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Iterator.html" title="class or interface in java.util" class="external-link" target="_blank">Iterator</a></code></div>
 <div class="col-second even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="#getAddressSpaces()" class="member-name-link">getAddressSpaces</a>()</code></div>
 <div class="col-last even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4">
-<div class="block">Get the set of address spaces within the image - typically one but may be more on some 
+<div class="block">Get the set of address spaces within the image - typically one but may be more on some
  systems such as Z/OS.</div>
 </div>
 <div class="col-first odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code>long</code></div>
@@ -335,7 +335,7 @@
 <h3>getAddressSpaces</h3>
 <div class="member-signature"><span class="modifiers">public</span>&nbsp;<span class="return-type"><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Iterator.html" title="class or interface in java.util" class="external-link" target="_blank">Iterator</a></span>&nbsp;<span class="element-name">getAddressSpaces</span>()</div>
 <div class="block"><span class="descfrm-type-label">Description copied from interface:&nbsp;<code><a href="../Image.html#getAddressSpaces()">Image</a></code></span></div>
-<div class="block">Get the set of address spaces within the image - typically one but may be more on some 
+<div class="block">Get the set of address spaces within the image - typically one but may be more on some
  systems such as Z/OS.</div>
 <dl class="notes">
 <dt>Specified by:</dt>
@@ -402,8 +402,8 @@
 <dt>Specified by:</dt>
 <dd><code><a href="../Image.html#getIPAddresses()">getIPAddresses</a></code>&nbsp;in interface&nbsp;<code><a href="../Image.html" title="interface in com.ibm.dtfj.image">Image</a></code></dd>
 <dt>Returns:</dt>
-<dd>An Iterator over the IP addresses (as InetAddresses) which the system running 
- the image possessed.  The iterator will be non-null (but can be empty if the host is 
+<dd>An Iterator over the IP addresses (as InetAddresses) which the system running
+ the image possessed.  The iterator will be non-null (but can be empty if the host is
  known to have no IP addresses).</dd>
 <dt>Throws:</dt>
 <dd><code><a href="../DataUnavailable.html" title="class in com.ibm.dtfj.image">DataUnavailable</a></code> - If the image did not provide this information (would happen
@@ -469,7 +469,7 @@
 <dt>Returns:</dt>
 <dd>the precise model of the CPU (note that this can be an empty string but not null).
  <br>
- e.g. getProcessorType() will return "x86" where getProcessorSubType() may return "Pentium IV step 4"
+ e.g. getProcessorType() will return <q>x86</q> where getProcessorSubType() may return <q>Pentium IV step 4</q>
  <p>
  Note that this value is platform and implementation dependent.</dd>
 <dt>Throws:</dt>
@@ -653,8 +653,8 @@
 <div class="member-signature"><span class="modifiers">public</span>&nbsp;<span class="return-type">void</span>&nbsp;<span class="element-name">close</span>()</div>
 <div class="block"><span class="descfrm-type-label">Description copied from interface:&nbsp;<code><a href="../Image.html#close()">Image</a></code></span></div>
 <div class="block"><p>Close this image and any associated resources.</p>
- 
- <p>Some kinds of Image require the generation of temporary resources, for example temporary files created 
+
+ <p>Some kinds of Image require the generation of temporary resources, for example temporary files created
  when reading core files and libraries from .zip archives. Ordinarily, these resources are deleted at JVM shutdown,
  but DTFJ applications may want to free them earlier. This method should only be called when the Image is no
  longer needed. After this method has been called, any objects associated with the image will be in an invalid state.</p></div>
diff --git a/api/jdk17/openj9.dtfj/com/ibm/dtfj/java/JavaReference.html b/api/jdk17/openj9.dtfj/com/ibm/dtfj/java/JavaReference.html
index d6910e1..e83509c 100644
--- a/api/jdk17/openj9.dtfj/com/ibm/dtfj/java/JavaReference.html
+++ b/api/jdk17/openj9.dtfj/com/ibm/dtfj/java/JavaReference.html
@@ -857,7 +857,7 @@
 <div class="block">Get the root type, as defined in the JVMTI specification.</div>
 <dl class="notes">
 <dt>Returns:</dt>
-<dd>an integer representing the root type, see HEAP_ROOT_ statics above.</dd>
+<dd>an integer representing the root type, see the HEAP_ROOT_ static fields.</dd>
 <dt>Throws:</dt>
 <dd><code><a href="../image/CorruptDataException.html" title="class in com.ibm.dtfj.image">CorruptDataException</a></code></dd>
 </dl>
@@ -871,7 +871,7 @@
 <div class="block">Get the reference type, as defined in the JVMTI specification.</div>
 <dl class="notes">
 <dt>Returns:</dt>
-<dd>an integer representing the reference type, see REFERENCE_ statics above.</dd>
+<dd>an integer representing the reference type, see the REFERENCE_ static fields.</dd>
 <dt>Throws:</dt>
 <dd><code><a href="../image/CorruptDataException.html" title="class in com.ibm.dtfj.image">CorruptDataException</a></code></dd>
 </dl>
@@ -885,7 +885,7 @@
 <div class="block">Get the reachability of the target object via this specific reference.</div>
 <dl class="notes">
 <dt>Returns:</dt>
-<dd>an integer representing the reachability, see REACHABILITY_ statics above.</dd>
+<dd>an integer representing the reachability, see the REACHABILITY_ static fields.</dd>
 <dt>Throws:</dt>
 <dd><code><a href="../image/CorruptDataException.html" title="class in com.ibm.dtfj.image">CorruptDataException</a></code></dd>
 </dl>
@@ -897,7 +897,7 @@
 <div class="member-signature"><span class="return-type"><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/String.html" title="class or interface in java.lang" class="external-link" target="_blank">String</a></span>&nbsp;<span class="element-name">getDescription</span>()</div>
 <div class="block">Get a string describing the reference type.
  Implementers should not depend on the contents or identity of this string.
- e.g. "JNI Weak global reference", "Instance field 'MyClass.value'", "Constant pool string constant"</div>
+ e.g. <q>JNI Weak global reference</q>, <q>Instance field 'MyClass.value'</q>, <q>Constant pool string constant</q></div>
 <dl class="notes">
 <dt>Returns:</dt>
 <dd>a String describing the reference type</dd>
diff --git a/api/jdk17/openj9.dtfj/com/ibm/dtfj/java/j9/JavaReference.html b/api/jdk17/openj9.dtfj/com/ibm/dtfj/java/j9/JavaReference.html
index be961f7..131555e 100644
--- a/api/jdk17/openj9.dtfj/com/ibm/dtfj/java/j9/JavaReference.html
+++ b/api/jdk17/openj9.dtfj/com/ibm/dtfj/java/j9/JavaReference.html
@@ -268,7 +268,7 @@
 <div class="block"><span class="descfrm-type-label">Description copied from interface:&nbsp;<code><a href="../JavaReference.html#getDescription()">JavaReference</a></code></span></div>
 <div class="block">Get a string describing the reference type.
  Implementers should not depend on the contents or identity of this string.
- e.g. "JNI Weak global reference", "Instance field 'MyClass.value'", "Constant pool string constant"</div>
+ e.g. <q>JNI Weak global reference</q>, <q>Instance field 'MyClass.value'</q>, <q>Constant pool string constant</q></div>
 <dl class="notes">
 <dt>Specified by:</dt>
 <dd><code><a href="../JavaReference.html#getDescription()">getDescription</a></code>&nbsp;in interface&nbsp;<code><a href="../JavaReference.html" title="interface in com.ibm.dtfj.java">JavaReference</a></code></dd>
@@ -288,7 +288,7 @@
 <dt>Specified by:</dt>
 <dd><code><a href="../JavaReference.html#getReachability()">getReachability</a></code>&nbsp;in interface&nbsp;<code><a href="../JavaReference.html" title="interface in com.ibm.dtfj.java">JavaReference</a></code></dd>
 <dt>Returns:</dt>
-<dd>an integer representing the reachability, see REACHABILITY_ statics above.</dd>
+<dd>an integer representing the reachability, see the REACHABILITY_ static fields.</dd>
 <dt>Throws:</dt>
 <dd><code><a href="../../image/CorruptDataException.html" title="class in com.ibm.dtfj.image">CorruptDataException</a></code></dd>
 </dl>
@@ -305,7 +305,7 @@
 <dt>Specified by:</dt>
 <dd><code><a href="../JavaReference.html#getReferenceType()">getReferenceType</a></code>&nbsp;in interface&nbsp;<code><a href="../JavaReference.html" title="interface in com.ibm.dtfj.java">JavaReference</a></code></dd>
 <dt>Returns:</dt>
-<dd>an integer representing the reference type, see REFERENCE_ statics above.</dd>
+<dd>an integer representing the reference type, see the REFERENCE_ static fields.</dd>
 <dt>Throws:</dt>
 <dd><code><a href="../../image/CorruptDataException.html" title="class in com.ibm.dtfj.image">CorruptDataException</a></code></dd>
 </dl>
@@ -322,7 +322,7 @@
 <dt>Specified by:</dt>
 <dd><code><a href="../JavaReference.html#getRootType()">getRootType</a></code>&nbsp;in interface&nbsp;<code><a href="../JavaReference.html" title="interface in com.ibm.dtfj.java">JavaReference</a></code></dd>
 <dt>Returns:</dt>
-<dd>an integer representing the root type, see HEAP_ROOT_ statics above.</dd>
+<dd>an integer representing the root type, see the HEAP_ROOT_ static fields.</dd>
 <dt>Throws:</dt>
 <dd><code><a href="../../image/CorruptDataException.html" title="class in com.ibm.dtfj.image">CorruptDataException</a></code></dd>
 </dl>
diff --git a/api/jdk17/openj9.dtfj/com/ibm/dtfj/phd/PHDImage.html b/api/jdk17/openj9.dtfj/com/ibm/dtfj/phd/PHDImage.html
index dfbffd1..351cfbf 100644
--- a/api/jdk17/openj9.dtfj/com/ibm/dtfj/phd/PHDImage.html
+++ b/api/jdk17/openj9.dtfj/com/ibm/dtfj/phd/PHDImage.html
@@ -135,7 +135,7 @@
 <div class="col-first even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Iterator.html" title="class or interface in java.util" class="external-link" target="_blank">Iterator</a>&lt;<a href="../image/ImageAddressSpace.html" title="interface in com.ibm.dtfj.image">ImageAddressSpace</a>&gt;</code></div>
 <div class="col-second even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="#getAddressSpaces()" class="member-name-link">getAddressSpaces</a>()</code></div>
 <div class="col-last even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4">
-<div class="block">Get the set of address spaces within the image - typically one but may be more on some 
+<div class="block">Get the set of address spaces within the image - typically one but may be more on some
  systems such as Z/OS.</div>
 </div>
 <div class="col-first odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code>long</code></div>
@@ -258,7 +258,7 @@
 <h3>getAddressSpaces</h3>
 <div class="member-signature"><span class="modifiers">public</span>&nbsp;<span class="return-type"><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Iterator.html" title="class or interface in java.util" class="external-link" target="_blank">Iterator</a>&lt;<a href="../image/ImageAddressSpace.html" title="interface in com.ibm.dtfj.image">ImageAddressSpace</a>&gt;</span>&nbsp;<span class="element-name">getAddressSpaces</span>()</div>
 <div class="block"><span class="descfrm-type-label">Description copied from interface:&nbsp;<code><a href="../image/Image.html#getAddressSpaces()">Image</a></code></span></div>
-<div class="block">Get the set of address spaces within the image - typically one but may be more on some 
+<div class="block">Get the set of address spaces within the image - typically one but may be more on some
  systems such as Z/OS.</div>
 <dl class="notes">
 <dt>Specified by:</dt>
@@ -325,8 +325,8 @@
 <dt>Specified by:</dt>
 <dd><code><a href="../image/Image.html#getIPAddresses()">getIPAddresses</a></code>&nbsp;in interface&nbsp;<code><a href="../image/Image.html" title="interface in com.ibm.dtfj.image">Image</a></code></dd>
 <dt>Returns:</dt>
-<dd>An Iterator over the IP addresses (as InetAddresses) which the system running 
- the image possessed.  The iterator will be non-null (but can be empty if the host is 
+<dd>An Iterator over the IP addresses (as InetAddresses) which the system running
+ the image possessed.  The iterator will be non-null (but can be empty if the host is
  known to have no IP addresses).</dd>
 <dt>Throws:</dt>
 <dd><code><a href="../image/DataUnavailable.html" title="class in com.ibm.dtfj.image">DataUnavailable</a></code> - If the image did not provide this information (would happen
@@ -392,7 +392,7 @@
 <dt>Returns:</dt>
 <dd>the precise model of the CPU (note that this can be an empty string but not null).
  <br>
- e.g. getProcessorType() will return "x86" where getProcessorSubType() may return "Pentium IV step 4"
+ e.g. getProcessorType() will return <q>x86</q> where getProcessorSubType() may return <q>Pentium IV step 4</q>
  <p>
  Note that this value is platform and implementation dependent.</dd>
 <dt>Throws:</dt>
@@ -470,8 +470,8 @@
 <div class="member-signature"><span class="modifiers">public</span>&nbsp;<span class="return-type">void</span>&nbsp;<span class="element-name">close</span>()</div>
 <div class="block"><span class="descfrm-type-label">Description copied from interface:&nbsp;<code><a href="../image/Image.html#close()">Image</a></code></span></div>
 <div class="block"><p>Close this image and any associated resources.</p>
- 
- <p>Some kinds of Image require the generation of temporary resources, for example temporary files created 
+
+ <p>Some kinds of Image require the generation of temporary resources, for example temporary files created
  when reading core files and libraries from .zip archives. Ordinarily, these resources are deleted at JVM shutdown,
  but DTFJ applications may want to free them earlier. This method should only be called when the Image is no
  longer needed. After this method has been called, any objects associated with the image will be in an invalid state.</p></div>
diff --git a/api/jdk17/openj9.dtfj/com/ibm/j9ddr/class-use/CorruptDataException.html b/api/jdk17/openj9.dtfj/com/ibm/j9ddr/class-use/CorruptDataException.html
index e72fba7..e60abf4 100644
--- a/api/jdk17/openj9.dtfj/com/ibm/j9ddr/class-use/CorruptDataException.html
+++ b/api/jdk17/openj9.dtfj/com/ibm/j9ddr/class-use/CorruptDataException.html
@@ -1488,7 +1488,7 @@
  <a href="../vm29/j9/gc/GCCardCleaner.html" title="interface in com.ibm.j9ddr.vm29.j9.gc">GCCardCleaner</a>&nbsp;cardCleaner)</code></div>
 <div class="col-last even-row-color">&nbsp;</div>
 <div class="col-first odd-row-color"><code>protected <a href="../vm29/types/UDATA.html" title="class in com.ibm.j9ddr.vm29.types">UDATA</a></code></div>
-<div class="col-second odd-row-color"><span class="type-name-label">GCArrayletObjectModelBase.</span><code><a href="../vm29/j9/gc/GCArrayletObjectModelBase.html#externalArrayletsSize(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)" class="member-name-link">externalArrayletsSize</a><wbr>(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;arrayPtr)</code></div>
+<div class="col-second odd-row-color"><span class="type-name-label">GCArrayletObjectModelBase.</span><code><a href="../vm29/j9/gc/GCArrayletObjectModelBase.html#externalArrayletsSize(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)" class="member-name-link">externalArrayletsSize</a><wbr>(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;array)</code></div>
 <div class="col-last odd-row-color">
 <div class="block">Get the total number of bytes consumed by arraylets external to the
  given indexable object.</div>
@@ -1734,7 +1734,7 @@
 <div class="block">Get the layout for the given indexable object</div>
 </div>
 <div class="col-first odd-row-color"><code><a href="../vm29/pointer/ObjectReferencePointer.html" title="class in com.ibm.j9ddr.vm29.pointer">ObjectReferencePointer</a></code></div>
-<div class="col-second odd-row-color"><span class="type-name-label">GCArrayletObjectModelBase.</span><code><a href="../vm29/j9/gc/GCArrayletObjectModelBase.html#getArrayoidPointer(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)" class="member-name-link">getArrayoidPointer</a><wbr>(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;arrayPtr)</code></div>
+<div class="col-second odd-row-color"><span class="type-name-label">GCArrayletObjectModelBase.</span><code><a href="../vm29/j9/gc/GCArrayletObjectModelBase.html#getArrayoidPointer(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)" class="member-name-link">getArrayoidPointer</a><wbr>(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;array)</code></div>
 <div class="col-last odd-row-color">&nbsp;</div>
 <div class="col-first even-row-color"><code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Iterator.html" title="class or interface in java.util" class="external-link" target="_blank">Iterator</a>&lt;<a href="../vm29/j9/gc/GCHeapRegionDescriptor.html" title="class in com.ibm.j9ddr.vm29.j9.gc">GCHeapRegionDescriptor</a>&gt;</code></div>
 <div class="col-second even-row-color"><span class="type-name-label">GCHeapRegionManager.</span><code><a href="../vm29/j9/gc/GCHeapRegionManager.html#getAuxiliaryRegions()" class="member-name-link">getAuxiliaryRegions</a>()</code></div>
@@ -1767,7 +1767,7 @@
  object alignment and minimum object size</div>
 </div>
 <div class="col-first even-row-color"><code><a href="../vm29/pointer/VoidPointer.html" title="class in com.ibm.j9ddr.vm29.pointer">VoidPointer</a></code></div>
-<div class="col-second even-row-color"><span class="type-name-label">GCArrayletObjectModelBase.</span><code><a href="../vm29/j9/gc/GCArrayletObjectModelBase.html#getDataPointerForContiguous(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)" class="member-name-link">getDataPointerForContiguous</a><wbr>(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;arrayPtr)</code></div>
+<div class="col-second even-row-color"><span class="type-name-label">GCArrayletObjectModelBase.</span><code><a href="../vm29/j9/gc/GCArrayletObjectModelBase.html#getDataPointerForContiguous(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)" class="member-name-link">getDataPointerForContiguous</a><wbr>(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;array)</code></div>
 <div class="col-last even-row-color">&nbsp;</div>
 <div class="col-first odd-row-color"><code><a href="../vm29/types/UDATA.html" title="class in com.ibm.j9ddr.vm29.types">UDATA</a></code></div>
 <div class="col-second odd-row-color"><span class="type-name-label">GCArrayletObjectModelBase.</span><code><a href="../vm29/j9/gc/GCArrayletObjectModelBase.html#getDataSizeInBytes(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)" class="member-name-link">getDataSizeInBytes</a><wbr>(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;array)</code></div>
diff --git a/api/jdk17/openj9.dtfj/com/ibm/j9ddr/view/dtfj/image/J9DDRImage.html b/api/jdk17/openj9.dtfj/com/ibm/j9ddr/view/dtfj/image/J9DDRImage.html
index bdb6511..676e90a 100644
--- a/api/jdk17/openj9.dtfj/com/ibm/j9ddr/view/dtfj/image/J9DDRImage.html
+++ b/api/jdk17/openj9.dtfj/com/ibm/j9ddr/view/dtfj/image/J9DDRImage.html
@@ -149,7 +149,7 @@
 <div class="col-first odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Iterator.html" title="class or interface in java.util" class="external-link" target="_blank">Iterator</a>&lt;<a href="J9DDRImageAddressSpace.html" title="class in com.ibm.j9ddr.view.dtfj.image">J9DDRImageAddressSpace</a>&gt;</code></div>
 <div class="col-second odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="#getAddressSpaces()" class="member-name-link">getAddressSpaces</a>()</code></div>
 <div class="col-last odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4">
-<div class="block">Get the set of address spaces within the image - typically one but may be more on some 
+<div class="block">Get the set of address spaces within the image - typically one but may be more on some
  systems such as Z/OS.</div>
 </div>
 <div class="col-first even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="../../../corereaders/ICore.html" title="interface in com.ibm.j9ddr.corereaders">ICore</a></code></div>
@@ -293,7 +293,7 @@
 <h3>getAddressSpaces</h3>
 <div class="member-signature"><span class="modifiers">public</span>&nbsp;<span class="return-type"><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Iterator.html" title="class or interface in java.util" class="external-link" target="_blank">Iterator</a>&lt;<a href="J9DDRImageAddressSpace.html" title="class in com.ibm.j9ddr.view.dtfj.image">J9DDRImageAddressSpace</a>&gt;</span>&nbsp;<span class="element-name">getAddressSpaces</span>()</div>
 <div class="block"><span class="descfrm-type-label">Description copied from interface:&nbsp;<code><a href="../../../../dtfj/image/Image.html#getAddressSpaces()">Image</a></code></span></div>
-<div class="block">Get the set of address spaces within the image - typically one but may be more on some 
+<div class="block">Get the set of address spaces within the image - typically one but may be more on some
  systems such as Z/OS.</div>
 <dl class="notes">
 <dt>Specified by:</dt>
@@ -362,8 +362,8 @@
 <dt>Specified by:</dt>
 <dd><code><a href="../../../../dtfj/image/Image.html#getIPAddresses()">getIPAddresses</a></code>&nbsp;in interface&nbsp;<code><a href="../../../../dtfj/image/Image.html" title="interface in com.ibm.dtfj.image">Image</a></code></dd>
 <dt>Returns:</dt>
-<dd>An Iterator over the IP addresses (as InetAddresses) which the system running 
- the image possessed.  The iterator will be non-null (but can be empty if the host is 
+<dd>An Iterator over the IP addresses (as InetAddresses) which the system running
+ the image possessed.  The iterator will be non-null (but can be empty if the host is
  known to have no IP addresses).</dd>
 <dt>Throws:</dt>
 <dd><code><a href="../../../../dtfj/image/DataUnavailable.html" title="class in com.ibm.dtfj.image">DataUnavailable</a></code> - If the image did not provide this information (would happen
@@ -429,7 +429,7 @@
 <dt>Returns:</dt>
 <dd>the precise model of the CPU (note that this can be an empty string but not null).
  <br>
- e.g. getProcessorType() will return "x86" where getProcessorSubType() may return "Pentium IV step 4"
+ e.g. getProcessorType() will return <q>x86</q> where getProcessorSubType() may return <q>Pentium IV step 4</q>
  <p>
  Note that this value is platform and implementation dependent.</dd>
 <dt>Throws:</dt>
@@ -507,8 +507,8 @@
 <div class="member-signature"><span class="modifiers">public</span>&nbsp;<span class="return-type">void</span>&nbsp;<span class="element-name">close</span>()</div>
 <div class="block"><span class="descfrm-type-label">Description copied from interface:&nbsp;<code><a href="../../../../dtfj/image/Image.html#close()">Image</a></code></span></div>
 <div class="block"><p>Close this image and any associated resources.</p>
- 
- <p>Some kinds of Image require the generation of temporary resources, for example temporary files created 
+
+ <p>Some kinds of Image require the generation of temporary resources, for example temporary files created
  when reading core files and libraries from .zip archives. Ordinarily, these resources are deleted at JVM shutdown,
  but DTFJ applications may want to free them earlier. This method should only be called when the Image is no
  longer needed. After this method has been called, any objects associated with the image will be in an invalid state.</p></div>
diff --git a/api/jdk17/openj9.dtfj/com/ibm/j9ddr/vm29/j9/gc/GCArrayletObjectModelBase.html b/api/jdk17/openj9.dtfj/com/ibm/j9ddr/vm29/j9/gc/GCArrayletObjectModelBase.html
index 4737f6b..3106635 100644
--- a/api/jdk17/openj9.dtfj/com/ibm/j9ddr/vm29/j9/gc/GCArrayletObjectModelBase.html
+++ b/api/jdk17/openj9.dtfj/com/ibm/j9ddr/vm29/j9/gc/GCArrayletObjectModelBase.html
@@ -168,7 +168,7 @@
 <div class="table-header col-second">Method</div>
 <div class="table-header col-last">Description</div>
 <div class="col-first even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code>protected <a href="../../types/UDATA.html" title="class in com.ibm.j9ddr.vm29.types">UDATA</a></code></div>
-<div class="col-second even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="#externalArrayletsSize(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)" class="member-name-link">externalArrayletsSize</a><wbr>(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;arrayPtr)</code></div>
+<div class="col-second even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="#externalArrayletsSize(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)" class="member-name-link">externalArrayletsSize</a><wbr>(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;array)</code></div>
 <div class="col-last even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4">
 <div class="block">Get the total number of bytes consumed by arraylets external to the
  given indexable object.</div>
@@ -190,12 +190,12 @@
 <div class="block">Get the layout for the given indexable object</div>
 </div>
 <div class="col-first even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="../../pointer/ObjectReferencePointer.html" title="class in com.ibm.j9ddr.vm29.pointer">ObjectReferencePointer</a></code></div>
-<div class="col-second even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="#getArrayoidPointer(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)" class="member-name-link">getArrayoidPointer</a><wbr>(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;arrayPtr)</code></div>
+<div class="col-second even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="#getArrayoidPointer(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)" class="member-name-link">getArrayoidPointer</a><wbr>(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;array)</code></div>
 <div class="col-last even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4">
 <div class="block">Returns the address of first arraylet leaf slot in the spine</div>
 </div>
 <div class="col-first odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="../../pointer/VoidPointer.html" title="class in com.ibm.j9ddr.vm29.pointer">VoidPointer</a></code></div>
-<div class="col-second odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="#getDataPointerForContiguous(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)" class="member-name-link">getDataPointerForContiguous</a><wbr>(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;arrayPtr)</code></div>
+<div class="col-second odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="#getDataPointerForContiguous(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)" class="member-name-link">getDataPointerForContiguous</a><wbr>(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;array)</code></div>
 <div class="col-last odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4">
 <div class="block">Returns the address of first data slot in the array</div>
 </div>
@@ -488,7 +488,7 @@
 <dd><code>objPtr</code> - Pointer to an array object</dd>
 <dt>Returns:</dt>
 <dd>The total size in bytes of objPtr's array spine;
-                        includes header, arraylet ptrs, and (if present) padding &amp; inline data</dd>
+         includes header, arraylet ptrs, and (if present) padding &amp; inline data</dd>
 <dt>Throws:</dt>
 <dd><code><a href="../../../CorruptDataException.html" title="class in com.ibm.j9ddr">CorruptDataException</a></code></dd>
 </dl>
@@ -535,7 +535,7 @@
 <div class="block">Returns the size of data in an indexable object, in bytes, including leaves, excluding the header.</div>
 <dl class="notes">
 <dt>Parameters:</dt>
-<dd><code>arrayPtr</code> - Pointer to the indexable object whose size is required</dd>
+<dd><code>array</code> - Pointer to the indexable object whose size is required</dd>
 <dt>Returns:</dt>
 <dd>Size of object in bytes excluding the header</dd>
 <dt>Throws:</dt>
@@ -546,12 +546,12 @@
 <li>
 <section class="detail" id="getArrayoidPointer(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)">
 <h3>getArrayoidPointer</h3>
-<div class="member-signature"><span class="modifiers">public</span>&nbsp;<span class="return-type"><a href="../../pointer/ObjectReferencePointer.html" title="class in com.ibm.j9ddr.vm29.pointer">ObjectReferencePointer</a></span>&nbsp;<span class="element-name">getArrayoidPointer</span><wbr><span class="parameters">(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;arrayPtr)</span>
+<div class="member-signature"><span class="modifiers">public</span>&nbsp;<span class="return-type"><a href="../../pointer/ObjectReferencePointer.html" title="class in com.ibm.j9ddr.vm29.pointer">ObjectReferencePointer</a></span>&nbsp;<span class="element-name">getArrayoidPointer</span><wbr><span class="parameters">(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;array)</span>
                                           throws <span class="exceptions"><a href="../../../CorruptDataException.html" title="class in com.ibm.j9ddr">CorruptDataException</a></span></div>
 <div class="block">Returns the address of first arraylet leaf slot in the spine</div>
 <dl class="notes">
 <dt>Parameters:</dt>
-<dd><code>arrayPtr</code> - Ptr to an array</dd>
+<dd><code>array</code> - Ptr to an array</dd>
 <dt>Returns:</dt>
 <dd>Arrayoid ptr</dd>
 <dt>Throws:</dt>
@@ -562,12 +562,12 @@
 <li>
 <section class="detail" id="getDataPointerForContiguous(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)">
 <h3>getDataPointerForContiguous</h3>
-<div class="member-signature"><span class="modifiers">public</span>&nbsp;<span class="return-type"><a href="../../pointer/VoidPointer.html" title="class in com.ibm.j9ddr.vm29.pointer">VoidPointer</a></span>&nbsp;<span class="element-name">getDataPointerForContiguous</span><wbr><span class="parameters">(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;arrayPtr)</span>
+<div class="member-signature"><span class="modifiers">public</span>&nbsp;<span class="return-type"><a href="../../pointer/VoidPointer.html" title="class in com.ibm.j9ddr.vm29.pointer">VoidPointer</a></span>&nbsp;<span class="element-name">getDataPointerForContiguous</span><wbr><span class="parameters">(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;array)</span>
                                         throws <span class="exceptions"><a href="../../../CorruptDataException.html" title="class in com.ibm.j9ddr">CorruptDataException</a></span></div>
 <div class="block">Returns the address of first data slot in the array</div>
 <dl class="notes">
 <dt>Parameters:</dt>
-<dd><code>arrayPtr</code> - pointer to an array</dd>
+<dd><code>array</code> - pointer to an array</dd>
 <dt>Returns:</dt>
 <dd>Address of first data slot in the array</dd>
 <dt>Throws:</dt>
@@ -696,13 +696,13 @@
 <li>
 <section class="detail" id="externalArrayletsSize(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)">
 <h3>externalArrayletsSize</h3>
-<div class="member-signature"><span class="modifiers">protected</span>&nbsp;<span class="return-type"><a href="../../types/UDATA.html" title="class in com.ibm.j9ddr.vm29.types">UDATA</a></span>&nbsp;<span class="element-name">externalArrayletsSize</span><wbr><span class="parameters">(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;arrayPtr)</span>
+<div class="member-signature"><span class="modifiers">protected</span>&nbsp;<span class="return-type"><a href="../../types/UDATA.html" title="class in com.ibm.j9ddr.vm29.types">UDATA</a></span>&nbsp;<span class="element-name">externalArrayletsSize</span><wbr><span class="parameters">(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;array)</span>
                                throws <span class="exceptions"><a href="../../../CorruptDataException.html" title="class in com.ibm.j9ddr">CorruptDataException</a></span></div>
 <div class="block">Get the total number of bytes consumed by arraylets external to the
  given indexable object.</div>
 <dl class="notes">
 <dt>Parameters:</dt>
-<dd><code>arrayPtr</code> - Pointer to an array object</dd>
+<dd><code>array</code> - Pointer to an array object</dd>
 <dt>Returns:</dt>
 <dd>the number of bytes consumed external to the spine</dd>
 <dt>Throws:</dt>
diff --git a/api/jdk17/openj9.dtfj/com/ibm/j9ddr/vm29/pointer/class-use/ObjectReferencePointer.html b/api/jdk17/openj9.dtfj/com/ibm/j9ddr/vm29/pointer/class-use/ObjectReferencePointer.html
index e848f02..88484b8 100644
--- a/api/jdk17/openj9.dtfj/com/ibm/j9ddr/vm29/pointer/class-use/ObjectReferencePointer.html
+++ b/api/jdk17/openj9.dtfj/com/ibm/j9ddr/vm29/pointer/class-use/ObjectReferencePointer.html
@@ -77,7 +77,7 @@
 <div class="table-header col-second">Method</div>
 <div class="table-header col-last">Description</div>
 <div class="col-first even-row-color"><code><a href="../ObjectReferencePointer.html" title="class in com.ibm.j9ddr.vm29.pointer">ObjectReferencePointer</a></code></div>
-<div class="col-second even-row-color"><span class="type-name-label">GCArrayletObjectModelBase.</span><code><a href="../../j9/gc/GCArrayletObjectModelBase.html#getArrayoidPointer(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)" class="member-name-link">getArrayoidPointer</a><wbr>(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;arrayPtr)</code></div>
+<div class="col-second even-row-color"><span class="type-name-label">GCArrayletObjectModelBase.</span><code><a href="../../j9/gc/GCArrayletObjectModelBase.html#getArrayoidPointer(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)" class="member-name-link">getArrayoidPointer</a><wbr>(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;array)</code></div>
 <div class="col-last even-row-color">&nbsp;</div>
 </div>
 </section>
diff --git a/api/jdk17/openj9.dtfj/com/ibm/j9ddr/vm29/pointer/class-use/VoidPointer.html b/api/jdk17/openj9.dtfj/com/ibm/j9ddr/vm29/pointer/class-use/VoidPointer.html
index 7147e96..3658215 100644
--- a/api/jdk17/openj9.dtfj/com/ibm/j9ddr/vm29/pointer/class-use/VoidPointer.html
+++ b/api/jdk17/openj9.dtfj/com/ibm/j9ddr/vm29/pointer/class-use/VoidPointer.html
@@ -346,7 +346,7 @@
 <div class="col-second even-row-color"><span class="type-name-label">GCCardTable.</span><code><a href="../../j9/gc/GCCardTable.html#cardAddrToHeapAddr(com.ibm.j9ddr.vm29.pointer.U8Pointer)" class="member-name-link">cardAddrToHeapAddr</a><wbr>(<a href="../U8Pointer.html" title="class in com.ibm.j9ddr.vm29.pointer">U8Pointer</a>&nbsp;cardAddr)</code></div>
 <div class="col-last even-row-color">&nbsp;</div>
 <div class="col-first odd-row-color"><code><a href="../VoidPointer.html" title="class in com.ibm.j9ddr.vm29.pointer">VoidPointer</a></code></div>
-<div class="col-second odd-row-color"><span class="type-name-label">GCArrayletObjectModelBase.</span><code><a href="../../j9/gc/GCArrayletObjectModelBase.html#getDataPointerForContiguous(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)" class="member-name-link">getDataPointerForContiguous</a><wbr>(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;arrayPtr)</code></div>
+<div class="col-second odd-row-color"><span class="type-name-label">GCArrayletObjectModelBase.</span><code><a href="../../j9/gc/GCArrayletObjectModelBase.html#getDataPointerForContiguous(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)" class="member-name-link">getDataPointerForContiguous</a><wbr>(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;array)</code></div>
 <div class="col-last odd-row-color">&nbsp;</div>
 <div class="col-first even-row-color"><code><a href="../VoidPointer.html" title="class in com.ibm.j9ddr.vm29.pointer">VoidPointer</a></code></div>
 <div class="col-second even-row-color"><span class="type-name-label">GCArrayletObjectModelBase.</span><code><a href="../../j9/gc/GCArrayletObjectModelBase.html#getElementAddress(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer,int,int)" class="member-name-link">getElementAddress</a><wbr>(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;array,
diff --git a/api/jdk17/openj9.dtfj/com/ibm/j9ddr/vm29/types/class-use/UDATA.html b/api/jdk17/openj9.dtfj/com/ibm/j9ddr/vm29/types/class-use/UDATA.html
index 8250def..cba4782 100644
--- a/api/jdk17/openj9.dtfj/com/ibm/j9ddr/vm29/types/class-use/UDATA.html
+++ b/api/jdk17/openj9.dtfj/com/ibm/j9ddr/vm29/types/class-use/UDATA.html
@@ -369,7 +369,7 @@
  and 8 byte aligned.</div>
 </div>
 <div class="col-first odd-row-color"><code>protected <a href="../UDATA.html" title="class in com.ibm.j9ddr.vm29.types">UDATA</a></code></div>
-<div class="col-second odd-row-color"><span class="type-name-label">GCArrayletObjectModelBase.</span><code><a href="../../j9/gc/GCArrayletObjectModelBase.html#externalArrayletsSize(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)" class="member-name-link">externalArrayletsSize</a><wbr>(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;arrayPtr)</code></div>
+<div class="col-second odd-row-color"><span class="type-name-label">GCArrayletObjectModelBase.</span><code><a href="../../j9/gc/GCArrayletObjectModelBase.html#externalArrayletsSize(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer)" class="member-name-link">externalArrayletsSize</a><wbr>(com.ibm.j9ddr.vm29.pointer.generated.J9IndexableObjectPointer&nbsp;array)</code></div>
 <div class="col-last odd-row-color">
 <div class="block">Get the total number of bytes consumed by arraylets external to the
  given indexable object.</div>
diff --git a/api/jdk17/openj9.dtfj/com/ibm/j9ddr/vm29/view/dtfj/java/DTFJJavaReference.html b/api/jdk17/openj9.dtfj/com/ibm/j9ddr/vm29/view/dtfj/java/DTFJJavaReference.html
index 3531480..c461f7c 100644
--- a/api/jdk17/openj9.dtfj/com/ibm/j9ddr/vm29/view/dtfj/java/DTFJJavaReference.html
+++ b/api/jdk17/openj9.dtfj/com/ibm/j9ddr/vm29/view/dtfj/java/DTFJJavaReference.html
@@ -237,7 +237,7 @@
 <div class="block"><span class="descfrm-type-label">Description copied from interface:&nbsp;<code><a href="../../../../../dtfj/java/JavaReference.html#getDescription()">JavaReference</a></code></span></div>
 <div class="block">Get a string describing the reference type.
  Implementers should not depend on the contents or identity of this string.
- e.g. "JNI Weak global reference", "Instance field 'MyClass.value'", "Constant pool string constant"</div>
+ e.g. <q>JNI Weak global reference</q>, <q>Instance field 'MyClass.value'</q>, <q>Constant pool string constant</q></div>
 <dl class="notes">
 <dt>Specified by:</dt>
 <dd><code><a href="../../../../../dtfj/java/JavaReference.html#getDescription()">getDescription</a></code>&nbsp;in interface&nbsp;<code><a href="../../../../../dtfj/java/JavaReference.html" title="interface in com.ibm.dtfj.java">JavaReference</a></code></dd>
@@ -257,7 +257,7 @@
 <dt>Specified by:</dt>
 <dd><code><a href="../../../../../dtfj/java/JavaReference.html#getReachability()">getReachability</a></code>&nbsp;in interface&nbsp;<code><a href="../../../../../dtfj/java/JavaReference.html" title="interface in com.ibm.dtfj.java">JavaReference</a></code></dd>
 <dt>Returns:</dt>
-<dd>an integer representing the reachability, see REACHABILITY_ statics above.</dd>
+<dd>an integer representing the reachability, see the REACHABILITY_ static fields.</dd>
 <dt>Throws:</dt>
 <dd><code><a href="../../../../../dtfj/image/CorruptDataException.html" title="class in com.ibm.dtfj.image">CorruptDataException</a></code></dd>
 </dl>
@@ -274,7 +274,7 @@
 <dt>Specified by:</dt>
 <dd><code><a href="../../../../../dtfj/java/JavaReference.html#getReferenceType()">getReferenceType</a></code>&nbsp;in interface&nbsp;<code><a href="../../../../../dtfj/java/JavaReference.html" title="interface in com.ibm.dtfj.java">JavaReference</a></code></dd>
 <dt>Returns:</dt>
-<dd>an integer representing the reference type, see REFERENCE_ statics above.</dd>
+<dd>an integer representing the reference type, see the REFERENCE_ static fields.</dd>
 <dt>Throws:</dt>
 <dd><code><a href="../../../../../dtfj/image/CorruptDataException.html" title="class in com.ibm.dtfj.image">CorruptDataException</a></code></dd>
 </dl>
@@ -291,7 +291,7 @@
 <dt>Specified by:</dt>
 <dd><code><a href="../../../../../dtfj/java/JavaReference.html#getRootType()">getRootType</a></code>&nbsp;in interface&nbsp;<code><a href="../../../../../dtfj/java/JavaReference.html" title="interface in com.ibm.dtfj.java">JavaReference</a></code></dd>
 <dt>Returns:</dt>
-<dd>an integer representing the root type, see HEAP_ROOT_ statics above.</dd>
+<dd>an integer representing the root type, see the HEAP_ROOT_ static fields.</dd>
 <dt>Throws:</dt>
 <dd><code><a href="../../../../../dtfj/image/CorruptDataException.html" title="class in com.ibm.dtfj.image">CorruptDataException</a></code></dd>
 </dl>
diff --git a/api/jdk17/openj9.dtfj/com/ibm/java/diagnostics/utils/DTFJImageBean.html b/api/jdk17/openj9.dtfj/com/ibm/java/diagnostics/utils/DTFJImageBean.html
index 8b40eb3..52be65d 100644
--- a/api/jdk17/openj9.dtfj/com/ibm/java/diagnostics/utils/DTFJImageBean.html
+++ b/api/jdk17/openj9.dtfj/com/ibm/java/diagnostics/utils/DTFJImageBean.html
@@ -142,7 +142,7 @@
 <div class="col-first odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Iterator.html" title="class or interface in java.util" class="external-link" target="_blank">Iterator</a>&lt;?&gt;</code></div>
 <div class="col-second odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code><a href="#getAddressSpaces()" class="member-name-link">getAddressSpaces</a>()</code></div>
 <div class="col-last odd-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4">
-<div class="block">Get the set of address spaces within the image - typically one but may be more on some 
+<div class="block">Get the set of address spaces within the image - typically one but may be more on some
  systems such as Z/OS.</div>
 </div>
 <div class="col-first even-row-color method-summary-table method-summary-table-tab2 method-summary-table-tab4"><code>long</code></div>
@@ -290,8 +290,8 @@
 <dt>Specified by:</dt>
 <dd><code><a href="../../../dtfj/image/Image.html#getIPAddresses()">getIPAddresses</a></code>&nbsp;in interface&nbsp;<code><a href="../../../dtfj/image/Image.html" title="interface in com.ibm.dtfj.image">Image</a></code></dd>
 <dt>Returns:</dt>
-<dd>An Iterator over the IP addresses (as InetAddresses) which the system running 
- the image possessed.  The iterator will be non-null (but can be empty if the host is 
+<dd>An Iterator over the IP addresses (as InetAddresses) which the system running
+ the image possessed.  The iterator will be non-null (but can be empty if the host is
  known to have no IP addresses).</dd>
 <dt>Throws:</dt>
 <dd><code><a href="../../../dtfj/image/DataUnavailable.html" title="class in com.ibm.dtfj.image">DataUnavailable</a></code> - If the image did not provide this information (would happen
@@ -357,7 +357,7 @@
 <dt>Returns:</dt>
 <dd>the precise model of the CPU (note that this can be an empty string but not null).
  <br>
- e.g. getProcessorType() will return "x86" where getProcessorSubType() may return "Pentium IV step 4"
+ e.g. getProcessorType() will return <q>x86</q> where getProcessorSubType() may return <q>Pentium IV step 4</q>
  <p>
  Note that this value is platform and implementation dependent.</dd>
 <dt>Throws:</dt>
@@ -463,8 +463,8 @@
 <div class="member-signature"><span class="modifiers">public</span>&nbsp;<span class="return-type">void</span>&nbsp;<span class="element-name">close</span>()</div>
 <div class="block"><span class="descfrm-type-label">Description copied from interface:&nbsp;<code><a href="../../../dtfj/image/Image.html#close()">Image</a></code></span></div>
 <div class="block"><p>Close this image and any associated resources.</p>
- 
- <p>Some kinds of Image require the generation of temporary resources, for example temporary files created 
+
+ <p>Some kinds of Image require the generation of temporary resources, for example temporary files created
  when reading core files and libraries from .zip archives. Ordinarily, these resources are deleted at JVM shutdown,
  but DTFJ applications may want to free them earlier. This method should only be called when the Image is no
  longer needed. After this method has been called, any objects associated with the image will be in an invalid state.</p></div>
@@ -479,7 +479,7 @@
 <h3>getAddressSpaces</h3>
 <div class="member-signature"><span class="modifiers">public</span>&nbsp;<span class="return-type"><a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Iterator.html" title="class or interface in java.util" class="external-link" target="_blank">Iterator</a>&lt;?&gt;</span>&nbsp;<span class="element-name">getAddressSpaces</span>()</div>
 <div class="block"><span class="descfrm-type-label">Description copied from interface:&nbsp;<code><a href="../../../dtfj/image/Image.html#getAddressSpaces()">Image</a></code></span></div>
-<div class="block">Get the set of address spaces within the image - typically one but may be more on some 
+<div class="block">Get the set of address spaces within the image - typically one but may be more on some
  systems such as Z/OS.</div>
 <dl class="notes">
 <dt>Specified by:</dt>
diff --git a/api/jdk17/openj9.gpu/com/ibm/gpu/GPUPermission.html b/api/jdk17/openj9.gpu/com/ibm/gpu/GPUPermission.html
index dde638a..74fba58 100644
--- a/api/jdk17/openj9.gpu/com/ibm/gpu/GPUPermission.html
+++ b/api/jdk17/openj9.gpu/com/ibm/gpu/GPUPermission.html
@@ -87,7 +87,7 @@
 <hr>
 <div class="type-signature"><span class="modifiers">public final class </span><span class="element-name type-name-label">GPUPermission</span>
 <span class="extends-implements">extends <a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/BasicPermission.html" title="class or interface in java.security" class="external-link" target="_blank">BasicPermission</a></span></div>
-<div class="block">This class defines GPU permissions as described in the table below.
+<div class="block">This class defines GPU permissions as described in the following table.
 
  <table border=1 style="padding:5px">
  <caption>GPU Permissions</caption>
diff --git a/api/jdk17/openj9.gpu/com/ibm/gpu/package-summary.html b/api/jdk17/openj9.gpu/com/ibm/gpu/package-summary.html
index 48332a6..ba462b4 100644
--- a/api/jdk17/openj9.gpu/com/ibm/gpu/package-summary.html
+++ b/api/jdk17/openj9.gpu/com/ibm/gpu/package-summary.html
@@ -108,7 +108,7 @@
 </div>
 <div class="col-first odd-row-color class-summary class-summary-tab2"><a href="GPUPermission.html" title="class in com.ibm.gpu">GPUPermission</a></div>
 <div class="col-last odd-row-color class-summary class-summary-tab2">
-<div class="block">This class defines GPU permissions as described in the table below.</div>
+<div class="block">This class defines GPU permissions as described in the following table.</div>
 </div>
 <div class="col-first even-row-color class-summary class-summary-tab5"><a href="GPUSortException.html" title="class in com.ibm.gpu">GPUSortException</a></div>
 <div class="col-last even-row-color class-summary class-summary-tab5">
diff --git a/api/jdk17/openj9.sharedclasses/com/ibm/oti/shared/SharedClassesNamedPermission.html b/api/jdk17/openj9.sharedclasses/com/ibm/oti/shared/SharedClassesNamedPermission.html
index beff7dc..9a78364 100644
--- a/api/jdk17/openj9.sharedclasses/com/ibm/oti/shared/SharedClassesNamedPermission.html
+++ b/api/jdk17/openj9.sharedclasses/com/ibm/oti/shared/SharedClassesNamedPermission.html
@@ -87,7 +87,7 @@
 <hr>
 <div class="type-signature"><span class="modifiers">public final class </span><span class="element-name type-name-label">SharedClassesNamedPermission</span>
 <span class="extends-implements">extends <a href="https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/BasicPermission.html" title="class or interface in java.security" class="external-link" target="_blank">BasicPermission</a></span></div>
-<div class="block">This class defines shared cache permissions as described in the table below.
+<div class="block">This class defines shared cache permissions as described in the following table.
 
  <table border=1 style="padding=5px">
  <caption>Shared Cache Permissions</caption>
diff --git a/api/jdk17/openj9.sharedclasses/com/ibm/oti/shared/package-summary.html b/api/jdk17/openj9.sharedclasses/com/ibm/oti/shared/package-summary.html
index 876af2a..b4f71b3 100644
--- a/api/jdk17/openj9.sharedclasses/com/ibm/oti/shared/package-summary.html
+++ b/api/jdk17/openj9.sharedclasses/com/ibm/oti/shared/package-summary.html
@@ -125,7 +125,7 @@
 </div>
 <div class="col-first odd-row-color class-summary class-summary-tab2"><a href="SharedClassesNamedPermission.html" title="class in com.ibm.oti.shared">SharedClassesNamedPermission</a></div>
 <div class="col-last odd-row-color class-summary class-summary-tab2">
-<div class="block">This class defines shared cache permissions as described in the table below.</div>
+<div class="block">This class defines shared cache permissions as described in the following table.</div>
 </div>
 <div class="col-first even-row-color class-summary class-summary-tab1"><a href="SharedClassFilter.html" title="interface in com.ibm.oti.shared">SharedClassFilter</a></div>
 <div class="col-last even-row-color class-summary class-summary-tab1">
diff --git a/api/jdk17/openj9.traceformat/com/ibm/jvm/trace/format/api/package-summary.html b/api/jdk17/openj9.traceformat/com/ibm/jvm/trace/format/api/package-summary.html
index 42e62ad..0b12585 100644
--- a/api/jdk17/openj9.traceformat/com/ibm/jvm/trace/format/api/package-summary.html
+++ b/api/jdk17/openj9.traceformat/com/ibm/jvm/trace/format/api/package-summary.html
@@ -75,52 +75,52 @@
  the UtTraceBuffer native type which wrap the UtTraceRecord type. However, in messages from the API they are
  called buffers to keep the naming consistent across the information output of the formatter and the -Xtrace
  options.
- 
+
  A single buffer contains trace data for a single thread with one exception:
-        "0x0 Exception trace pseudo-thread"
+        <q>0x0 Exception trace pseudo-thread</q>
  This "thread" contains data from any threads that have written into the exception buffer interleaved in
  chronological order. There is no mapping from a trace point to its source thread for trace points in the
  exception buffer.
- 
+
  An instance of a JVM corresponds to an instance of a TraceContext object within the API. It is
  possible to have multiple TraceContext instances, each the accessor for trace data from a single JVM.
- 
+
  The primary inputs for the API are metadata from a JVM and trace buffers.
- 
+
  A TraceContext is constructed using metadata from the JVM that's generating the trace records needing
  formatting. This metadata is either present as a file header at the start of a trace file or can
  be acquired via a call to the JVMTI extension com.ibm.GetTraceMetadata.
  Also required is a data file describing the format of trace points for that level of the JVM. At
  least one data file is required to construct a trace context but additional files can be added later
  and they will be searched for a trace point specification in the order they are added.
- 
+
  Trace buffers must be passed to the context corresponding to the JVM that produced them; they are not
  valid in another context and must be added in-order within a single thread.  Detecting that a buffer
  has been added to the wrong context is not always possible so don't depend on an error being produced
  to deduce the correct context. Trace buffers from the same thread must be added in chronological order.
- 
+
  Trace points are organised by thread, and iterators are provided that allow access:
         a. chronologically across all threads (global)
         b. chronologically within a single thread (thread)
-  
+
  The global iterator uses the thread iterators meaning that once a trace point has
  been returned via either type of iterator it will not be returned again via the other type.
  The iterators may return null (without becoming invalid) when there are no more trace points available
  but return data after a new trace buffer has been added. iterator.hasNext() indicates whether a call to
  iterator.next() will return null and says nothing about whether more trace points can be expected for a given
- context or thread. 
- 
+ context or thread.
+
  Trace points are kept sorted across threads when using the global iterator, however this optimisation invariant
  is broken by use of a thread iterator. Consequently there is a performance hit when the global iterator is
  next used, as the threads must be resorted. This can be significant with large numbers of threads.
- 
+
  Example fragment parsing a single buffer via the API:
                 // metadata - byte[] either from the header in a trace file or via jvmti
                 // formatData - File containing the trace point specifications
 
                 TraceContext context = TraceContext.getContext(metadata, formatData, System.out, System.err, System.err, null);
                 TraceThread thread = context.addData(buffer);
- 
+
                 Iterator global = context.getTracepoints();
                 while (global.hasNext()) {
                         try {
diff --git a/attachapi/index.html b/attachapi/index.html
index 42765c4..d7f615a 100644
--- a/attachapi/index.html
+++ b/attachapi/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/builds/index.html b/builds/index.html
index 56d6621..7022b29 100644
--- a/builds/index.html
+++ b/builds/index.html
@@ -350,6 +350,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -385,18 +397,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -419,6 +419,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/cmdline_general/index.html b/cmdline_general/index.html
index 0c7294d..6058e02 100644
--- a/cmdline_general/index.html
+++ b/cmdline_general/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/cmdline_migration/index.html b/cmdline_migration/index.html
index 0c7cc76..0c229b0 100644
--- a/cmdline_migration/index.html
+++ b/cmdline_migration/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/cmdline_specifying/index.html b/cmdline_specifying/index.html
index 4cd156b..0d47b08 100644
--- a/cmdline_specifying/index.html
+++ b/cmdline_specifying/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/configuring/index.html b/configuring/index.html
index e8bc59d..3f920c2 100644
--- a/configuring/index.html
+++ b/configuring/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/d_jvm_commands/index.html b/d_jvm_commands/index.html
index e5c867c..7b886fd 100644
--- a/d_jvm_commands/index.html
+++ b/d_jvm_commands/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dcomibmenableclasscaching/index.html b/dcomibmenableclasscaching/index.html
index 0cfe3f3..b26f9d9 100644
--- a/dcomibmenableclasscaching/index.html
+++ b/dcomibmenableclasscaching/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dcomibmenablelegacydumpsecurity/index.html b/dcomibmenablelegacydumpsecurity/index.html
index 8454f56..18599ae 100644
--- a/dcomibmenablelegacydumpsecurity/index.html
+++ b/dcomibmenablelegacydumpsecurity/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dcomibmenablelegacylogsecurity/index.html b/dcomibmenablelegacylogsecurity/index.html
index 157f96a..446c7be 100644
--- a/dcomibmenablelegacylogsecurity/index.html
+++ b/dcomibmenablelegacylogsecurity/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dcomibmenablelegacytracesecurity/index.html b/dcomibmenablelegacytracesecurity/index.html
index d8335ad..9da37ef 100644
--- a/dcomibmenablelegacytracesecurity/index.html
+++ b/dcomibmenablelegacytracesecurity/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dcomibmgpudisable/index.html b/dcomibmgpudisable/index.html
index 563f374..57577d6 100644
--- a/dcomibmgpudisable/index.html
+++ b/dcomibmgpudisable/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dcomibmgpuenable/index.html b/dcomibmgpuenable/index.html
index 97d807d..2a47d7b 100644
--- a/dcomibmgpuenable/index.html
+++ b/dcomibmgpuenable/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dcomibmgpuverbose/index.html b/dcomibmgpuverbose/index.html
index 2a77af8..4cef264 100644
--- a/dcomibmgpuverbose/index.html
+++ b/dcomibmgpuverbose/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dcomibmlangmanagementosmxbeaniscputime100ns/index.html b/dcomibmlangmanagementosmxbeaniscputime100ns/index.html
index cbc04e1..4848a1d 100644
--- a/dcomibmlangmanagementosmxbeaniscputime100ns/index.html
+++ b/dcomibmlangmanagementosmxbeaniscputime100ns/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dcomibmlangmanagementverbose/index.html b/dcomibmlangmanagementverbose/index.html
index 7317da8..6d153cf 100644
--- a/dcomibmlangmanagementverbose/index.html
+++ b/dcomibmlangmanagementverbose/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dcomibmotisharedsharedclassglobalfilterclass/index.html b/dcomibmotisharedsharedclassglobalfilterclass/index.html
index b5aec5a..6972e14 100644
--- a/dcomibmotisharedsharedclassglobalfilterclass/index.html
+++ b/dcomibmotisharedsharedclassglobalfilterclass/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dcomibmtoolsattachcommand_timeout/index.html b/dcomibmtoolsattachcommand_timeout/index.html
index a671d4f..99653f6 100644
--- a/dcomibmtoolsattachcommand_timeout/index.html
+++ b/dcomibmtoolsattachcommand_timeout/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dcomibmtoolsattachdirectory/index.html b/dcomibmtoolsattachdirectory/index.html
index f62ef18..c91614b 100644
--- a/dcomibmtoolsattachdirectory/index.html
+++ b/dcomibmtoolsattachdirectory/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dcomibmtoolsattachdisplayname/index.html b/dcomibmtoolsattachdisplayname/index.html
index a3c8bce..8a0069f 100644
--- a/dcomibmtoolsattachdisplayname/index.html
+++ b/dcomibmtoolsattachdisplayname/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dcomibmtoolsattachenable/index.html b/dcomibmtoolsattachenable/index.html
index 0397557..ca037c1 100644
--- a/dcomibmtoolsattachenable/index.html
+++ b/dcomibmtoolsattachenable/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dcomibmtoolsattachid/index.html b/dcomibmtoolsattachid/index.html
index f528b9d..fdb2120 100644
--- a/dcomibmtoolsattachid/index.html
+++ b/dcomibmtoolsattachid/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dcomibmtoolsattachlogging/index.html b/dcomibmtoolsattachlogging/index.html
index 264b99f..74029df 100644
--- a/dcomibmtoolsattachlogging/index.html
+++ b/dcomibmtoolsattachlogging/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dcomibmtoolsattachlogname/index.html b/dcomibmtoolsattachlogname/index.html
index 38210a9..22ab53c 100644
--- a/dcomibmtoolsattachlogname/index.html
+++ b/dcomibmtoolsattachlogname/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dcomibmtoolsattachshutdown_timeout/index.html b/dcomibmtoolsattachshutdown_timeout/index.html
index 217e2fd..0176ae5 100644
--- a/dcomibmtoolsattachshutdown_timeout/index.html
+++ b/dcomibmtoolsattachshutdown_timeout/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dcomibmtoolsattachtimeout/index.html b/dcomibmtoolsattachtimeout/index.html
index f38656b..3b6a82f 100644
--- a/dcomibmtoolsattachtimeout/index.html
+++ b/dcomibmtoolsattachtimeout/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dfileencoding/index.html b/dfileencoding/index.html
index b7e738d..cd39688 100644
--- a/dfileencoding/index.html
+++ b/dfileencoding/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/diag_overview/index.html b/diag_overview/index.html
index c3614fe..e02adff 100644
--- a/diag_overview/index.html
+++ b/diag_overview/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/djavacompiler/index.html b/djavacompiler/index.html
index 87a0460..d8c5e79 100644
--- a/djavacompiler/index.html
+++ b/djavacompiler/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/djavalangstringbuffergrowaggressively/index.html b/djavalangstringbuffergrowaggressively/index.html
index ba8d9b3..3fcec03 100644
--- a/djavalangstringbuffergrowaggressively/index.html
+++ b/djavalangstringbuffergrowaggressively/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/djavalangstringsubstringnocopy/index.html b/djavalangstringsubstringnocopy/index.html
index e4941f9..ce1aad5 100644
--- a/djavalangstringsubstringnocopy/index.html
+++ b/djavalangstringsubstringnocopy/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/djdknativecbc/index.html b/djdknativecbc/index.html
index d214c6d..6d4a7d7 100644
--- a/djdknativecbc/index.html
+++ b/djdknativecbc/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/djdknativechacha20/index.html b/djdknativechacha20/index.html
index 4b3099b..a5612dd 100644
--- a/djdknativechacha20/index.html
+++ b/djdknativechacha20/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/djdknativecrypto/index.html b/djdknativecrypto/index.html
index d41bdb9..8a25803 100644
--- a/djdknativecrypto/index.html
+++ b/djdknativecrypto/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/djdknativedigest/index.html b/djdknativedigest/index.html
index 0cbe20b..2c2230c 100644
--- a/djdknativedigest/index.html
+++ b/djdknativedigest/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/djdknativegcm/index.html b/djdknativegcm/index.html
index 18679df..154d702 100644
--- a/djdknativegcm/index.html
+++ b/djdknativegcm/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/djdknativersa/index.html b/djdknativersa/index.html
index 23d5d7f..94d1c9c 100644
--- a/djdknativersa/index.html
+++ b/djdknativersa/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dump_heapdump/index.html b/dump_heapdump/index.html
index d950e4b..443f85e 100644
--- a/dump_heapdump/index.html
+++ b/dump_heapdump/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dump_javadump/index.html b/dump_javadump/index.html
index c4be02e..500a4b3 100644
--- a/dump_javadump/index.html
+++ b/dump_javadump/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/dump_systemdump/index.html b/dump_systemdump/index.html
index 12102ac..6942cda 100644
--- a/dump_systemdump/index.html
+++ b/dump_systemdump/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/env_var/index.html b/env_var/index.html
index 45545ae..241914d 100644
--- a/env_var/index.html
+++ b/env_var/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/gc/index.html b/gc/index.html
index 9df66b7..f21cda1 100644
--- a/gc/index.html
+++ b/gc/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/gc_overview/index.html b/gc_overview/index.html
index f74b1eb..20e9e18 100644
--- a/gc_overview/index.html
+++ b/gc_overview/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/index.html b/index.html
index a2bf1e4..f108451 100644
--- a/index.html
+++ b/index.html
@@ -350,6 +350,18 @@
   
   
     <li class="md-nav__item">
+      <a href="version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -385,18 +397,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -419,6 +419,18 @@
   
   
     <li class="md-nav__item">
+      <a href="version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/interface_dtfj/index.html b/interface_dtfj/index.html
index d7f8c9b..81fffae 100644
--- a/interface_dtfj/index.html
+++ b/interface_dtfj/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/interface_jvmti/index.html b/interface_jvmti/index.html
index 8ef41df..4d30690 100644
--- a/interface_jvmti/index.html
+++ b/interface_jvmti/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/interface_lang_management/index.html b/interface_lang_management/index.html
index 3ca049e..0e0aa0e 100644
--- a/interface_lang_management/index.html
+++ b/interface_lang_management/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/introduction/index.html b/introduction/index.html
index 7a39581..e34a338 100644
--- a/introduction/index.html
+++ b/introduction/index.html
@@ -433,6 +433,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -468,18 +480,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -502,6 +502,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/jit/index.html b/jit/index.html
index 375cb6f..22f3a94 100644
--- a/jit/index.html
+++ b/jit/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/jitserver/index.html b/jitserver/index.html
index 509b7f7..4b3e689 100644
--- a/jitserver/index.html
+++ b/jitserver/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/jitserver_tuning/index.html b/jitserver_tuning/index.html
index 740a3e9..5f95f0d 100644
--- a/jitserver_tuning/index.html
+++ b/jitserver_tuning/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/legal/index.html b/legal/index.html
index 12a937c..a839852 100644
--- a/legal/index.html
+++ b/legal/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/messages_intro/index.html b/messages_intro/index.html
index d738fe2..902b1f3 100644
--- a/messages_intro/index.html
+++ b/messages_intro/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/openj9_defaults/index.html b/openj9_defaults/index.html
index 4a017d3..fc0f413 100644
--- a/openj9_defaults/index.html
+++ b/openj9_defaults/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/openj9_directories/index.html b/openj9_directories/index.html
index f38f511..c276558 100644
--- a/openj9_directories/index.html
+++ b/openj9_directories/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/openj9_newuser/index.html b/openj9_newuser/index.html
index 9e0c32f..e74c0a8 100644
--- a/openj9_newuser/index.html
+++ b/openj9_newuser/index.html
@@ -384,6 +384,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -419,18 +431,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -453,6 +453,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/openj9_releases/index.html b/openj9_releases/index.html
index f0aafa9..3f46910 100644
--- a/openj9_releases/index.html
+++ b/openj9_releases/index.html
@@ -308,6 +308,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -343,18 +355,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -377,6 +377,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/openj9_signals/index.html b/openj9_signals/index.html
index 517f587..12bffd4 100644
--- a/openj9_signals/index.html
+++ b/openj9_signals/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/openj9_support/index.html b/openj9_support/index.html
index 6fa96c2..052931d 100644
--- a/openj9_support/index.html
+++ b/openj9_support/index.html
@@ -296,6 +296,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.29.1/" class="md-nav__link">
+        Version 0.29.1
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.29/" class="md-nav__link">
         Version 0.29.0
       </a>
@@ -331,18 +343,6 @@
   
   
   
-    <li class="md-nav__item">
-      <a href="../version0.25/" class="md-nav__link">
-        Version 0.25.0
-      </a>
-    </li>
-  
-
-          
-            
-  
-  
-  
     
     <li class="md-nav__item md-nav__item--nested">
       
@@ -365,6 +365,18 @@
   
   
     <li class="md-nav__item">
+      <a href="../version0.25/" class="md-nav__link">
+        Version 0.25.0
+      </a>
+    </li>
+  
+
+          
+            
+  
+  
+  
+    <li class="md-nav__item">
       <a href="../version0.24/" class="md-nav__link">
         Version 0.24.0
       </a>
diff --git a/search/search_index.json b/search/search_index.json
index 445880c..c51acc4 100644
--- a/search/search_index.json
+++ b/search/search_index.json
@@ -1 +1 @@
-{"config":{"lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"Eclipse OpenJ9 Welcome to the user documentation for the Eclipse OpenJ9 virtual machine (VM). This user documentation supports the configuration, tuning, and diagnosis of the OpenJ9 VM in an OpenJDK runtime. However, due to differences between the Java SE class libraries, specific options might apply only to one Java SE version. Icons are used to indicate where differences apply. For example: This sentence applies only to Java 11 binaries that include the OpenJ9 VM. Icons for LTS releases are this colour. This sentence applies only to Java 16 or later binaries that include the OpenJ9 VM. Icons for feature releases are this colour. To see which Java releases are LTS releases and which are feature releases, and for information about release cadence, supported platforms, and build environments, see Supported environments . Note: Documentation to support OpenJ9 is still under construction. The current content covers some high level information about OpenJ9 components together with the command-line options and environment variables that you can use to configure the VM when you start your application. Because OpenJ9 was contributed to the Eclipse Foundation by IBM, this content contains some links to additional information that forms part of the IBM\u00ae SDK, Java\u2122 Technology Edition product documentation in IBM Documentation. That content supplements the documentation here until a more complete set of user documentation is available. We welcome contributions to the user documentation. If you would like to get involved, please read our Contribution guidelines . If you spot any errors in the documentation, please raise an issue at our GitHub repository. Supported environments OpenJDK binaries that contain the OpenJ9 VM are supported on a range of hardware and operating systems. This range is expanding as work progresses at the Eclipse foundation. See the current list of supported environments for details. Note: This user guide also contains information about configuring, tuning, and debugging OpenJ9 on the z/OS\u00ae platform. Documentation for specific releases Several versions of the documentation are available, covering all releases of OpenJ9: Online documentation for the last release Online, in-progress documentation for the forthcoming release Downloads of earlier releases : to download a zip file, click the filename, then click Download . After downloading a .zip file, extract it, then open the index.html file in your browser. Useful links Eclipse OpenJ9 website home page Eclipse OpenJ9 GitHub repository Eclipse Foundation OpenJ9 project page","title":"About the docs"},{"location":"#eclipse-openj9","text":"Welcome to the user documentation for the Eclipse OpenJ9 virtual machine (VM). This user documentation supports the configuration, tuning, and diagnosis of the OpenJ9 VM in an OpenJDK runtime. However, due to differences between the Java SE class libraries, specific options might apply only to one Java SE version. Icons are used to indicate where differences apply. For example: This sentence applies only to Java 11 binaries that include the OpenJ9 VM. Icons for LTS releases are this colour. This sentence applies only to Java 16 or later binaries that include the OpenJ9 VM. Icons for feature releases are this colour. To see which Java releases are LTS releases and which are feature releases, and for information about release cadence, supported platforms, and build environments, see Supported environments . Note: Documentation to support OpenJ9 is still under construction. The current content covers some high level information about OpenJ9 components together with the command-line options and environment variables that you can use to configure the VM when you start your application. Because OpenJ9 was contributed to the Eclipse Foundation by IBM, this content contains some links to additional information that forms part of the IBM\u00ae SDK, Java\u2122 Technology Edition product documentation in IBM Documentation. That content supplements the documentation here until a more complete set of user documentation is available. We welcome contributions to the user documentation. If you would like to get involved, please read our Contribution guidelines . If you spot any errors in the documentation, please raise an issue at our GitHub repository.","title":"Eclipse OpenJ9"},{"location":"#supported-environments","text":"OpenJDK binaries that contain the OpenJ9 VM are supported on a range of hardware and operating systems. This range is expanding as work progresses at the Eclipse foundation. See the current list of supported environments for details. Note: This user guide also contains information about configuring, tuning, and debugging OpenJ9 on the z/OS\u00ae platform.","title":"Supported environments"},{"location":"#documentation-for-specific-releases","text":"Several versions of the documentation are available, covering all releases of OpenJ9: Online documentation for the last release Online, in-progress documentation for the forthcoming release Downloads of earlier releases : to download a zip file, click the filename, then click Download . After downloading a .zip file, extract it, then open the index.html file in your browser.","title":"Documentation for specific releases"},{"location":"#useful-links","text":"Eclipse OpenJ9 website home page Eclipse OpenJ9 GitHub repository Eclipse Foundation OpenJ9 project page","title":"Useful links"},{"location":"allocation/","text":"Heap allocation The process of managing memory in the VM is handled by the allocator and the garbage collector. These components operate on an area of memory that is reserved for VM processing called the Java\u2122 heap. The allocator assigns areas of the heap for Java objects. Objects are considered as live when they have a chain of references to them that start from root references, such as those found in thread stacks. When that reference or pointer no longer exists, the objects are considered as garbage . The garbage collector reclaims memory by removing objects when they are no longer required. To find out more about the garbage collector, see Garbage collection . Depending on your application workload or service level agreement, you can choose from a number of OpenJ9 garbage collection (GC) policies . Each GC policy uses a different strategy to manage memory on the heap. The structure of the heap also depends on the strategy in force. For more information about choosing a GC policy, see Garbage collection policies . The allocator The allocator manages pools of free memory and how the free memory is consumed. It is also responsible for allocating areas of storage in the Java heap for objects at the request of applications, class libraries, or the VM. In general, allocation requires a heap lock to synchronize concurrent threads that try to access the same area of memory at the same time. When an object is allocated, the heap lock is released. If there is insufficient space to allocate the object, allocation fails, the heap lock is released, and the garbage collector is called. If GC manages to recover some space on the heap, the allocator can resume operations. If GC does not recover enough space, it returns an OutOfMemoryError exception. Acquiring a heap lock for every allocation would be an intensive operation with an impact to performance. To get around this problem, small objects are allocated to allocation caches. Allocation caches To improve performance, allocation caches are reserved in the heap for different threads. These allocation caches are known as thread local heaps (TLH) and allow each thread to allocate memory from its cache without acquiring the heap lock. Objects are allocated from the TLH unless there is insufficient space remaining in the TLH to satisfy the request. In this situation, the allocation might proceed directly from the heap for larger objects by using a heap lock or the TLH might be refreshed for smaller objects. If a thread allocates a lot of objects, the allocator gives that thread a larger TLH to reduce contention on the heap lock. A TLH is predefined with an initial default size of 2 KB. On every TLH refresh, the requested size for that thread is increased by an increment (default 4 KB). The requested size can grow up to a predefined maximum (default 128 KB). If a TLH refresh fails to complete, a GC cycle is triggered. After every GC cycle, the requested size of the TLH for each thread is reduced, sometimes by as much as 50%, to take account of threads that reduce their allocation rate and no longer need large TLHs. For very inactive threads, the requested size can even drop below the initial value, down to the predefined minimum (512/768 bytes). For very active threads, the maximum TLH requested size might be reached before the next GC occurs. Larger TLHs can help reduce heap lock contention, but might also reduce heap utilization and increase heap fragmentation. The following options control the requested TLH size: -Xgc:tlhMaximumSize=<bytes> -Xgc:tlhInitialSize=<bytes> -Xgc:tlhIncrementSize=<bytes> Typically, when the maximum TLH size is increased, you should also increase the increment proportionally, so that active threads can reach the maximum requested TLH size more quickly. Heap configuration Depending on the memory management strategy in force, the Java heap can be configured in a number of ways. The simplest configuration consists of a single area of memory, often referred to as a flat heap. Other configurations divide the heap into different areas or regions , which might contain objects of different ages (generations) or sizes. Area-based heaps The default GC policy for OpenJ9 uses a heap configuration that is divided into two main areas: the nursery area for new object allocation, and the tenure area for objects that continue to be reachable for a longer period of time. Most objects have short lifecycles and can be reclaimed by the garbage collector more quickly by focusing only on the nursery area. Global GC cycles that cause application pauses in order to clear and defragment the tenure area are less frequent. SOA and LOA All area-based heaps subdivide part of the heap into the Small Object Area (SOA) and the Large Object Area (LOA). The allocator initially attempts to allocate objects in the SOA, regardless of size. If the allocation cannot be satisfied the following actions are possible, depending on object size: If the object is smaller than 64 KB, an allocation failure occurs, which triggers a GC action. If the object is larger than 64 KB, the allocator attempts to allocate the object in the LOA. If the allocation cannot be satisfied, an allocation failure occurs, which triggers a GC action. The GC action that is triggered by the allocation failure depends on the GC policy in force. The overall size of the LOA is calculated when the heap is initialized, and recalculated at the end of each global GC cycle. The garbage collector can expand or contract the LOA, depending on usage, to avoid allocation failures. You can control the size of the LOA by using the -Xloainitial , -Xloaminimum , and -Xloamaximum command line options. If the LOA is not used, the garbage collector contracts the LOA after a few cycles, down to the value of -Xloaminimum . You can also specify -Xnoloa to prevent an LOA being created. An SOA and LOA are used by the OpenJ9 GC policies: gencon , optavgpause and optthruput . For the gencon policy, the LOA and SOA are contained within the tenure area, which is designated for ageing objects. For more information about policies, see Garbage collection policies . Region-based heaps The Java heap can also be subdivided into multiple regions. The balanced GC policy uses a heap that is divided into thousands of equal size regions in order to manage multiple generations of objects. The metronome GC policy also uses multiple regions, which are grouped by size-class to manage a singe generation of objects. To learn more about how the regions are configured for each policy, see Garbage collection policies . In addition to regions, the balanced and metronome policies use structures called arraylets to store large arrays in the heap. Arraylets A Java heap that is subdivided into regions might not be able to contain a large enough region for data arrays. This problem is solved by using arraylets . An arraylet has a spine , which contains the class pointer and size, and leaves , which contain the data associated with the array. The spine also contains arrayoids , which are pointers to the respective arraylet leaves, as shown in the following diagram. There are a number of advantages to using arraylets. Because the heap tends to fragment over time, some GC policies might be forced to run a global garbage collection and defragmentation (compaction) to recover sufficient contiguous memory to allocate a large array. By removing the requirement for large arrays to be allocated in contiguous memory, the garbage collector is more likely to be able to satisfy such an allocation without requiring unscheduled garbage collection, particularly a global defragmentation operation. Additionally, the garbage collector never needs to move an arraylet leaf once it has been allocated. The cost of relocating an array is therefore limited to the cost of relocating the spine, so large arrays do not contribute to higher defragmentation times. Note: Despite the general advantage of using arraylets, they can slow down processing when the Java Native Interface (JNI) is being used. The JNI provides flexibility by enabling Java programs to call native code; for example C or C++, and if direct addressability to the inside of an object is needed, a JNI critical section can be used. However, that requires the object to be in a contiguous region of memory, or at least appear to be so. The JNI therefore creates a temporary contiguous array that is the same size as the original array and copies everything, element by element, to the temporary array. After the JNI critical section is finished, everything is copied from the temporary array back to the arraylet, element by element. Heap sizing The overall size of the Java heap is determined by two command-line options, -Xms , which sets the initial size of the heap, and -Xmx , which sets the maximum size of the heap. Finer tuning of the heap depends on the heap configuration that is being used by a GC policy. For example, an LOA within the heap can be sized by using the -Xloainitial , -Xloaminimum , and -Xloamaximum command-line options. A nursery area within the heap can be sized by using the -Xmn , -Xmns , and -Xmnx command-line options. For more information about policies and the heap configurations that are used, see GC policies . To determine the values that are in use for the Java heap, use the -verbose:sizes option when you run your Java application. When the Java heap runs out of space, OutOfMemoryError exceptions are generated. If you are confident that your heap settings are appropriate for your application but are still receiving an OutOfMemoryError exception, check the Java dump file that gets automatically generated when the error occurs. A Java dump file can tell you more about what your application was attempting to do at the time of the error. For example, see the Java OutOfMemoryError scenario. Expansion and contraction At startup, the VM allocates a single contiguous area of virtual storage to match the value of -Xmx . By default, this is 25% of the available memory up to a maximum of 25 GB. The actual Java heap size starts at the value set by -Xms and expands automatically, as required, up to the maximum heap size. The VM can also contract the size of the Java heap. Expansion and contraction occur as part of a GC cycle when the VM has exclusive access to the heap. The only GC policy that does not support heap expansion and contraction is the metronome GC policy, where the heap is always fully expanded. Note: On operating systems that support paging, the VM allocates a single contiguous area that matches the value of -Xms . Additional memory is committed as the heap expands by using the paging process. Expansion occurs to maintain free space on the Java heap for object allocation. By default, the heap is expanded to maintain 30% free space, but this proportion can be adjusted by setting one of the following command-line options: -Xminf determines the minimum proportion of the heap that must be free after garbage is removed. -Xmaxf determines the maximum proportion of the heap that must be free after garbage is removed. If expansion is required, the amount of memory that the heap can expand by is controlled by the following command-line options: -Xmine sets the minimum amount that the heap can expand by. -Xmaxe sets the maximum amount that the heap can expand by. The default is unlimited expansion up to the maximum heap size ( -Xmx ). Expansion can also be triggered if more time is being spent on GC processing than is specified by the -Xmaxt option. In this case, the heap expands by an amount that provides 17% more free space, within the limits imposed by the -Xmine and -Xmaxe values. Heap contraction occurs under certain conditions and might be preceded by heap compaction. If the last three GC cycles caused a heap expansion, contraction does not occur. Otherwise, contraction is triggered when the proportion of free heap space that is specified by the -Xmaxf option is reached. The amount of memory to reduce the heap by is calculated to the nearest 1024-byte boundary, down to the minimum size specified for the initial Java heap ( -Xms ). To prevent heap contraction, set the -Xmaxf value to 1 , which sets the maximum free space allowed on the heap to 100%. When the heap contracts, physical memory is not released unless paging is supported by the underlying operating system. Compressed references On 64-bit systems, the VM can use compressed references to decrease the size of Java objects and make better use of the available space in the Java heap. By storing objects in a 32-bit representation, the object size is identical to that in a 32-bit VM, which creates a smaller memory footprint. These 4 byte (32-bit) compressed references are converted to 64-bit values at runtime with minimal overhead. Smaller objects enable larger heap sizes that result in less frequent garbage collection and improve memory cache utilization. Overall, the performance of 64-bit applications that store compressed rather than uncompressed 64-bit object references is significantly improved. Compressed references are used by default when the maximum Java heap size is in the range 0 - 57 GB on AIX\u00ae, Linux\u00ae, and Windows\u00ae systems. The upper limit is also 57 GB on z/OS\u00ae systems that have APAR OA49416 installed (25 GB without APAR OA49416). All GC policies observe these limits except for the metronome policy, which can only support a heap size of up to 25 GB with compressed references. When the VM uses compressed references, classes, threads, and monitors are stored in the lowest 4 GB of address space. However, this area of memory is also used by native libraries, the operating system, and for small Java heaps. If you receive native memory OutOfMemoryError exceptions in the lowest 4 GB when running with compressed references enabled, these errors might result from the lowest 4 GB of address space becoming full. Try specifying a large heap with the -Xmx option, which puts the Java heap into a higher area of address space or using the -Xmcrs option to reserve space in the lowest 4 GB of address space for compressed references. To turn off compressed references, use the -Xnocompressedrefs command-line option.","title":"Heap allocation"},{"location":"allocation/#heap-allocation","text":"The process of managing memory in the VM is handled by the allocator and the garbage collector. These components operate on an area of memory that is reserved for VM processing called the Java\u2122 heap. The allocator assigns areas of the heap for Java objects. Objects are considered as live when they have a chain of references to them that start from root references, such as those found in thread stacks. When that reference or pointer no longer exists, the objects are considered as garbage . The garbage collector reclaims memory by removing objects when they are no longer required. To find out more about the garbage collector, see Garbage collection . Depending on your application workload or service level agreement, you can choose from a number of OpenJ9 garbage collection (GC) policies . Each GC policy uses a different strategy to manage memory on the heap. The structure of the heap also depends on the strategy in force. For more information about choosing a GC policy, see Garbage collection policies .","title":"Heap allocation"},{"location":"allocation/#the-allocator","text":"The allocator manages pools of free memory and how the free memory is consumed. It is also responsible for allocating areas of storage in the Java heap for objects at the request of applications, class libraries, or the VM. In general, allocation requires a heap lock to synchronize concurrent threads that try to access the same area of memory at the same time. When an object is allocated, the heap lock is released. If there is insufficient space to allocate the object, allocation fails, the heap lock is released, and the garbage collector is called. If GC manages to recover some space on the heap, the allocator can resume operations. If GC does not recover enough space, it returns an OutOfMemoryError exception. Acquiring a heap lock for every allocation would be an intensive operation with an impact to performance. To get around this problem, small objects are allocated to allocation caches.","title":"The allocator"},{"location":"allocation/#allocation-caches","text":"To improve performance, allocation caches are reserved in the heap for different threads. These allocation caches are known as thread local heaps (TLH) and allow each thread to allocate memory from its cache without acquiring the heap lock. Objects are allocated from the TLH unless there is insufficient space remaining in the TLH to satisfy the request. In this situation, the allocation might proceed directly from the heap for larger objects by using a heap lock or the TLH might be refreshed for smaller objects. If a thread allocates a lot of objects, the allocator gives that thread a larger TLH to reduce contention on the heap lock. A TLH is predefined with an initial default size of 2 KB. On every TLH refresh, the requested size for that thread is increased by an increment (default 4 KB). The requested size can grow up to a predefined maximum (default 128 KB). If a TLH refresh fails to complete, a GC cycle is triggered. After every GC cycle, the requested size of the TLH for each thread is reduced, sometimes by as much as 50%, to take account of threads that reduce their allocation rate and no longer need large TLHs. For very inactive threads, the requested size can even drop below the initial value, down to the predefined minimum (512/768 bytes). For very active threads, the maximum TLH requested size might be reached before the next GC occurs. Larger TLHs can help reduce heap lock contention, but might also reduce heap utilization and increase heap fragmentation. The following options control the requested TLH size: -Xgc:tlhMaximumSize=<bytes> -Xgc:tlhInitialSize=<bytes> -Xgc:tlhIncrementSize=<bytes> Typically, when the maximum TLH size is increased, you should also increase the increment proportionally, so that active threads can reach the maximum requested TLH size more quickly.","title":"Allocation caches"},{"location":"allocation/#heap-configuration","text":"Depending on the memory management strategy in force, the Java heap can be configured in a number of ways. The simplest configuration consists of a single area of memory, often referred to as a flat heap. Other configurations divide the heap into different areas or regions , which might contain objects of different ages (generations) or sizes.","title":"Heap configuration"},{"location":"allocation/#area-based-heaps","text":"The default GC policy for OpenJ9 uses a heap configuration that is divided into two main areas: the nursery area for new object allocation, and the tenure area for objects that continue to be reachable for a longer period of time. Most objects have short lifecycles and can be reclaimed by the garbage collector more quickly by focusing only on the nursery area. Global GC cycles that cause application pauses in order to clear and defragment the tenure area are less frequent.","title":"Area-based heaps"},{"location":"allocation/#soa-and-loa","text":"All area-based heaps subdivide part of the heap into the Small Object Area (SOA) and the Large Object Area (LOA). The allocator initially attempts to allocate objects in the SOA, regardless of size. If the allocation cannot be satisfied the following actions are possible, depending on object size: If the object is smaller than 64 KB, an allocation failure occurs, which triggers a GC action. If the object is larger than 64 KB, the allocator attempts to allocate the object in the LOA. If the allocation cannot be satisfied, an allocation failure occurs, which triggers a GC action. The GC action that is triggered by the allocation failure depends on the GC policy in force. The overall size of the LOA is calculated when the heap is initialized, and recalculated at the end of each global GC cycle. The garbage collector can expand or contract the LOA, depending on usage, to avoid allocation failures. You can control the size of the LOA by using the -Xloainitial , -Xloaminimum , and -Xloamaximum command line options. If the LOA is not used, the garbage collector contracts the LOA after a few cycles, down to the value of -Xloaminimum . You can also specify -Xnoloa to prevent an LOA being created. An SOA and LOA are used by the OpenJ9 GC policies: gencon , optavgpause and optthruput . For the gencon policy, the LOA and SOA are contained within the tenure area, which is designated for ageing objects. For more information about policies, see Garbage collection policies .","title":"SOA and LOA"},{"location":"allocation/#region-based-heaps","text":"The Java heap can also be subdivided into multiple regions. The balanced GC policy uses a heap that is divided into thousands of equal size regions in order to manage multiple generations of objects. The metronome GC policy also uses multiple regions, which are grouped by size-class to manage a singe generation of objects. To learn more about how the regions are configured for each policy, see Garbage collection policies . In addition to regions, the balanced and metronome policies use structures called arraylets to store large arrays in the heap.","title":"Region-based heaps"},{"location":"allocation/#arraylets","text":"A Java heap that is subdivided into regions might not be able to contain a large enough region for data arrays. This problem is solved by using arraylets . An arraylet has a spine , which contains the class pointer and size, and leaves , which contain the data associated with the array. The spine also contains arrayoids , which are pointers to the respective arraylet leaves, as shown in the following diagram. There are a number of advantages to using arraylets. Because the heap tends to fragment over time, some GC policies might be forced to run a global garbage collection and defragmentation (compaction) to recover sufficient contiguous memory to allocate a large array. By removing the requirement for large arrays to be allocated in contiguous memory, the garbage collector is more likely to be able to satisfy such an allocation without requiring unscheduled garbage collection, particularly a global defragmentation operation. Additionally, the garbage collector never needs to move an arraylet leaf once it has been allocated. The cost of relocating an array is therefore limited to the cost of relocating the spine, so large arrays do not contribute to higher defragmentation times. Note: Despite the general advantage of using arraylets, they can slow down processing when the Java Native Interface (JNI) is being used. The JNI provides flexibility by enabling Java programs to call native code; for example C or C++, and if direct addressability to the inside of an object is needed, a JNI critical section can be used. However, that requires the object to be in a contiguous region of memory, or at least appear to be so. The JNI therefore creates a temporary contiguous array that is the same size as the original array and copies everything, element by element, to the temporary array. After the JNI critical section is finished, everything is copied from the temporary array back to the arraylet, element by element.","title":"Arraylets"},{"location":"allocation/#heap-sizing","text":"The overall size of the Java heap is determined by two command-line options, -Xms , which sets the initial size of the heap, and -Xmx , which sets the maximum size of the heap. Finer tuning of the heap depends on the heap configuration that is being used by a GC policy. For example, an LOA within the heap can be sized by using the -Xloainitial , -Xloaminimum , and -Xloamaximum command-line options. A nursery area within the heap can be sized by using the -Xmn , -Xmns , and -Xmnx command-line options. For more information about policies and the heap configurations that are used, see GC policies . To determine the values that are in use for the Java heap, use the -verbose:sizes option when you run your Java application. When the Java heap runs out of space, OutOfMemoryError exceptions are generated. If you are confident that your heap settings are appropriate for your application but are still receiving an OutOfMemoryError exception, check the Java dump file that gets automatically generated when the error occurs. A Java dump file can tell you more about what your application was attempting to do at the time of the error. For example, see the Java OutOfMemoryError scenario.","title":"Heap sizing"},{"location":"allocation/#expansion-and-contraction","text":"At startup, the VM allocates a single contiguous area of virtual storage to match the value of -Xmx . By default, this is 25% of the available memory up to a maximum of 25 GB. The actual Java heap size starts at the value set by -Xms and expands automatically, as required, up to the maximum heap size. The VM can also contract the size of the Java heap. Expansion and contraction occur as part of a GC cycle when the VM has exclusive access to the heap. The only GC policy that does not support heap expansion and contraction is the metronome GC policy, where the heap is always fully expanded. Note: On operating systems that support paging, the VM allocates a single contiguous area that matches the value of -Xms . Additional memory is committed as the heap expands by using the paging process. Expansion occurs to maintain free space on the Java heap for object allocation. By default, the heap is expanded to maintain 30% free space, but this proportion can be adjusted by setting one of the following command-line options: -Xminf determines the minimum proportion of the heap that must be free after garbage is removed. -Xmaxf determines the maximum proportion of the heap that must be free after garbage is removed. If expansion is required, the amount of memory that the heap can expand by is controlled by the following command-line options: -Xmine sets the minimum amount that the heap can expand by. -Xmaxe sets the maximum amount that the heap can expand by. The default is unlimited expansion up to the maximum heap size ( -Xmx ). Expansion can also be triggered if more time is being spent on GC processing than is specified by the -Xmaxt option. In this case, the heap expands by an amount that provides 17% more free space, within the limits imposed by the -Xmine and -Xmaxe values. Heap contraction occurs under certain conditions and might be preceded by heap compaction. If the last three GC cycles caused a heap expansion, contraction does not occur. Otherwise, contraction is triggered when the proportion of free heap space that is specified by the -Xmaxf option is reached. The amount of memory to reduce the heap by is calculated to the nearest 1024-byte boundary, down to the minimum size specified for the initial Java heap ( -Xms ). To prevent heap contraction, set the -Xmaxf value to 1 , which sets the maximum free space allowed on the heap to 100%. When the heap contracts, physical memory is not released unless paging is supported by the underlying operating system.","title":"Expansion and contraction"},{"location":"allocation/#compressed-references","text":"On 64-bit systems, the VM can use compressed references to decrease the size of Java objects and make better use of the available space in the Java heap. By storing objects in a 32-bit representation, the object size is identical to that in a 32-bit VM, which creates a smaller memory footprint. These 4 byte (32-bit) compressed references are converted to 64-bit values at runtime with minimal overhead. Smaller objects enable larger heap sizes that result in less frequent garbage collection and improve memory cache utilization. Overall, the performance of 64-bit applications that store compressed rather than uncompressed 64-bit object references is significantly improved. Compressed references are used by default when the maximum Java heap size is in the range 0 - 57 GB on AIX\u00ae, Linux\u00ae, and Windows\u00ae systems. The upper limit is also 57 GB on z/OS\u00ae systems that have APAR OA49416 installed (25 GB without APAR OA49416). All GC policies observe these limits except for the metronome policy, which can only support a heap size of up to 25 GB with compressed references. When the VM uses compressed references, classes, threads, and monitors are stored in the lowest 4 GB of address space. However, this area of memory is also used by native libraries, the operating system, and for small Java heaps. If you receive native memory OutOfMemoryError exceptions in the lowest 4 GB when running with compressed references enabled, these errors might result from the lowest 4 GB of address space becoming full. Try specifying a large heap with the -Xmx option, which puts the Java heap into a higher area of address space or using the -Xmcrs option to reserve space in the lowest 4 GB of address space for compressed references. To turn off compressed references, use the -Xnocompressedrefs command-line option.","title":"Compressed references"},{"location":"aot/","text":"Ahead-Of-Time (AOT) compiler The AOT compiler dynamically compiles Java methods into native AOT code at runtime and stores them in the shared classes cache. This activity enables the VM to start an application faster the next time it runs because it doesn't need to spend time interpreting Java methods. The VM automatically chooses which methods should be AOT-compiled based on heuristics that identify the start-up phase of large applications. AOT code is always used in combination with class data sharing and is enabled automatically when -Xshareclasses is set on the command line. When a cached AOT method is run it might also be optimized further by the Just-In-Time (JIT) compiler. If you want to turn off AOT compilation and disable the use of AOT-compiled code, set the -Xnoaot suboption. When the AOT compiler is disabled, the JIT compiles frequently used methods into native code. However, because the JIT compiler operates while the application is running, the startup time for an application will increase. See also Diagnosing a JIT or AOT problem JIT compiler Introduction to class data sharing","title":"AOT Compiler"},{"location":"aot/#ahead-of-time-aot-compiler","text":"The AOT compiler dynamically compiles Java methods into native AOT code at runtime and stores them in the shared classes cache. This activity enables the VM to start an application faster the next time it runs because it doesn't need to spend time interpreting Java methods. The VM automatically chooses which methods should be AOT-compiled based on heuristics that identify the start-up phase of large applications. AOT code is always used in combination with class data sharing and is enabled automatically when -Xshareclasses is set on the command line. When a cached AOT method is run it might also be optimized further by the Just-In-Time (JIT) compiler. If you want to turn off AOT compilation and disable the use of AOT-compiled code, set the -Xnoaot suboption. When the AOT compiler is disabled, the JIT compiles frequently used methods into native code. However, because the JIT compiler operates while the application is running, the startup time for an application will increase.","title":"Ahead-Of-Time (AOT) compiler"},{"location":"aot/#see-also","text":"Diagnosing a JIT or AOT problem JIT compiler Introduction to class data sharing","title":"See also"},{"location":"api-conditionhandling/","text":"Condition Handling API documentation","title":"Condition exception handling"},{"location":"api-conditionhandling/#condition-handling-api-documentation","text":"","title":"Condition Handling API documentation"},{"location":"api-cuda/","text":"CUDA4J API documentation","title":"CUDA4J"},{"location":"api-cuda/#cuda4j-api-documentation","text":"","title":"CUDA4J API documentation"},{"location":"api-daa/","text":"Data access acceleration API documentation","title":"Data access acceleration"},{"location":"api-daa/#data-access-acceleration-api-documentation","text":"","title":"Data access acceleration API documentation"},{"location":"api-dtfj/","text":"DTFJ API documentation","title":"DTFJ"},{"location":"api-dtfj/#dtfj-api-documentation","text":"","title":"DTFJ API documentation"},{"location":"api-gpu/","text":"GPU API documentation","title":"GPU"},{"location":"api-gpu/#gpu-api-documentation","text":"","title":"GPU API documentation"},{"location":"api-jdk11/","text":"OpenJ9 JDK 11 API documentation","title":"Java 11 API"},{"location":"api-jdk11/#openj9-jdk-11-api-documentation","text":"","title":"OpenJ9 JDK 11 API documentation"},{"location":"api-jdk17/","text":"OpenJ9 JDK 17 API documentation","title":"Java 17 API"},{"location":"api-jdk17/#openj9-jdk-17-api-documentation","text":"","title":"OpenJ9 JDK 17 API documentation"},{"location":"api-jvm/","text":"JVM diagnostic utilities API documentation","title":"JVM diagnostic utilities"},{"location":"api-jvm/#jvm-diagnostic-utilities-api-documentation","text":"","title":"JVM diagnostic utilities API documentation"},{"location":"api-langmgmt/","text":"Monitoring and management API documentation","title":"Monitoring and management"},{"location":"api-langmgmt/#monitoring-and-management-api-documentation","text":"","title":"Monitoring and management API documentation"},{"location":"api-overview/","text":"API documentation The Eclipse OpenJ9 VM provides supplementary application programming interfaces and extensions, which can be used to improve performance, assist with problem determination, or help monitor and manage the OpenJ9 VM. The documentation also includes links to the API documentation for the Java\u2122 SE and JDK reference implementation. Native data operations If your Java application manipulates native data, the Data Access Accelerator API package ( com.ibm.dataaccess ) can help improve application performance. Classes are available for the following types of operation: performing arithmetic, comparison, and validation of packed decimal data converting between decimal data types as well as to and from BigDecimal and BigInteger types marshalling Java binary types to and from byte arrays GPU acceleration You can improve the performance of your applications by offloading certain processing functions from your processor (CPU) to a graphics processing unit (GPU). If your application contains code that would benefit from parallel processing, you can use the CUDA4J API package ( com.ibm.cuda ) to specify in your code when to offload processing to the GPU. You can also use the GPU API package ( com.ibm.gpu ) to accelerate certain Java functions, such as sort operations. Problem determination The JVM diagnostic utilities API package ( com.ibm.jvm ) provides classes for controlling dump, log, and trace operations. The Diagnostic Tool Framework for Java (DTFJ) API packages ( com.ibm.dtfj.* ) allow custom applications to be written that can access a wide range of information in a system dump or a Java dump. Monitoring and management The shared classes API package ( com.ibm.oti.shared ) provides a large number of classes for managing permissions, finding and storing classes and byte data, and obtaining statistics about a shared classes cache. Classes are also available to enable class sharing for a custom class loader implementation. OpenJ9 includes MXBean extensions to the java.lang.management API ( com.ibm.lang.management and openj9.lang.management ), which can be used to monitor and manage the VM. These extensions provide access to information about the state of the OpenJ9 VM and the environment in which it is running.","title":"Overview"},{"location":"api-overview/#api-documentation","text":"The Eclipse OpenJ9 VM provides supplementary application programming interfaces and extensions, which can be used to improve performance, assist with problem determination, or help monitor and manage the OpenJ9 VM. The documentation also includes links to the API documentation for the Java\u2122 SE and JDK reference implementation.","title":"API documentation"},{"location":"api-overview/#native-data-operations","text":"If your Java application manipulates native data, the Data Access Accelerator API package ( com.ibm.dataaccess ) can help improve application performance. Classes are available for the following types of operation: performing arithmetic, comparison, and validation of packed decimal data converting between decimal data types as well as to and from BigDecimal and BigInteger types marshalling Java binary types to and from byte arrays","title":"Native data operations"},{"location":"api-overview/#gpu-acceleration","text":"You can improve the performance of your applications by offloading certain processing functions from your processor (CPU) to a graphics processing unit (GPU). If your application contains code that would benefit from parallel processing, you can use the CUDA4J API package ( com.ibm.cuda ) to specify in your code when to offload processing to the GPU. You can also use the GPU API package ( com.ibm.gpu ) to accelerate certain Java functions, such as sort operations.","title":"GPU acceleration"},{"location":"api-overview/#problem-determination","text":"The JVM diagnostic utilities API package ( com.ibm.jvm ) provides classes for controlling dump, log, and trace operations. The Diagnostic Tool Framework for Java (DTFJ) API packages ( com.ibm.dtfj.* ) allow custom applications to be written that can access a wide range of information in a system dump or a Java dump.","title":"Problem determination"},{"location":"api-overview/#monitoring-and-management","text":"The shared classes API package ( com.ibm.oti.shared ) provides a large number of classes for managing permissions, finding and storing classes and byte data, and obtaining statistics about a shared classes cache. Classes are also available to enable class sharing for a custom class loader implementation. OpenJ9 includes MXBean extensions to the java.lang.management API ( com.ibm.lang.management and openj9.lang.management ), which can be used to monitor and manage the VM. These extensions provide access to information about the state of the OpenJ9 VM and the environment in which it is running.","title":"Monitoring and management"},{"location":"api-shrc/","text":"Shared classes API documentation","title":"Shared classes"},{"location":"api-shrc/#shared-classes-api-documentation","text":"","title":"Shared classes API documentation"},{"location":"attachapi/","text":"Java Attach API With the Attach API, your application can connect to a running VM and load an agent into that VM to run tasks. The typical use case for this feature is to load an agent that can be used to monitor the application that's running in the target VM. For example, if you wanted to start monitoring an application that is already running with the Attach API enabled, you could use a tool such as the IBM Health Center . In this case, a Health Center agent can start in its own VM and attach to the target VM where the application is running to start recording and sending data to the Health Center client. The OpenJ9 implementation of the Attach API is equivalent to the reference implementation (API documentation is available on the Oracle website ). However, you can only use the Attach API to connect to another OpenJ9 VM. When you run a Java\u2122 application, VM support for the Attach API is enabled by default on all platforms except z/OS\u00ae. For security reasons on z/OS, processes that use the default z/OS OMVS segment cannot enable the Attach API. To enable or disable the Attach API, use the -Dcom.ibm.tools.attach.enable=[yes|no] command line option. Securing the Attach API Because the Attach API can be used to connect to a running application, you must control access to it to ensure that only authorized users or processes can use it. Disable the Attach API if you do not intend to use it. On Windows systems, the Attach API uses the system temporary directory, which is typically C:\\Users\\<USERNAME>\\AppData\\Local\\Temp . The Attach API creates a common subdirectory, which is .com_ibm_tools_attach by default. Because files and directories in the system temporary directory are handled by Windows security, only the process owner can connect to their processes. On UNIX systems, the Attach API uses /tmp and creates a common subdirectory, which is .com_ibm_tools_attach by default. The common subdirectory must be on a local drive, not a network drive. Security is handled by POSIX file permissions. The Attach API directory must be owned by root user and must have read, write, and execute file permissions for user , group , and other ( drwxrwxrwx ). The sticky bit is set so that only the owner and root can delete or rename files or directories within it. A process using the Java Attach API must be owned by the same UNIX user ID as the target process. ~/tmp $ ls -al total 0 drwxr-xr-x 3 user_a staff 96 6 Aug 17:11 . drwxr-xr-x+ 89 user_a staff 2848 6 Aug 17:11 .. drwxrwxrwx+ 7 root staff 224 6 Aug 17:22 .com_ibm_tools_attach In the default Attach API directory you can find certain files that start with an underscore _* , which are involved in synchronization. These files can be owned by any user but must have read and write permissions set. The files are empty and are automatically re-created if deleted. When your application attaches to a VM, a process directory is created. ~/tmp/.com_ibm_tools_attach $ ls -l total 3 -rw-rw-rw- 1 user_a staff 0 6 Aug 17:12 _attach_lock -rw-rw-rw- 1 user_a staff 0 6 Aug 17:12 _master -rw-rw-rw- 1 user_a staff 0 6 Aug 17:12 _notifier drwx--x--x 6 user_b staff 192 6 Aug 17:21 process_a The files in the subdirectory for a process, with the exception of a lock file, are accessible only by the owner of a process. The permissions for these files are rwxr-xr-x with the exception of the attachNotificationSync file, as shown in the following example. ~/tmp/.com_ibm_tools_attach/process_a $ ls -l total 4 -rwxrw-rw- 1 user_b staff 0 6 Aug 17:18 attachNotificationSync -rwxr-xr-x 1 user_b staff 0 6 Aug 17:21 file_a -rwxr-xr-x 1 user_b staff 0 6 Aug 17:21 file_b -rwxr-xr-x 1 user_b staff 0 6 Aug 17:21 file_c Notes for z/OS: z/OS systems must also set POSIX permissions on files and cannot rely on RACF\u00ae or system level security to protect applications. To avoid z/OS console messages reporting security violations in /tmp , add a security exception or specify a different common subdirectory by setting the com.ibm.tools.attach.directory system property. Configuring A number of system properties are available to configure the Attach API when you start a Java application, as shown in the following table: System property Description -Dcom.ibm.tools.attach.directory=<directory_name> Specify a different common directory for Attach API working files. -Dcom.ibm.tools.attach.displayName=<my_display_name> Change the display name recorded by an agent -Dcom.ibm.tools.attach.id=<my_vm_ID> Change the VM identifier recorded by an agent -Dcom.ibm.tools.attach.timeout=<value_in_milliseconds> Change the connection timeout -Dcom.ibm.tools.attach.shutdown_timeout=<value_in_milliseconds> Specify the timeout for ending the Attach API wait loop thread -Dcom.ibm.tools.attach.command_timeout=<value_in_milliseconds> Specify the timeout for sending a command to the target VM after initial attachment To learn more about each property, click the link in the table. Troubleshooting Problems with the Attach API generate one of the following exceptions: com.sun.tools.attach.AgentLoadException com.sun.tools.attach.AgentInitializationException com.sun.tools.attach.AgentNotSupportedException com.sun.tools.attach.AttachOperationFailedException java.io.IOException Exceptions from agents on the target VM go to stderr or stdout for the target VM. These exceptions are not reported in the output of the attaching VM. Here are some problems that you might encounter: On Unix systems, the file permissions are incorrectly set, causing access issues. Resolve these issues by reading and complying with Securing the Attach API . Also check that the Attach API is not disabled. The common directory is deleted, the contents of the common directory are deleted, or permissions of the common directory or subdirectories are changed. As a result, the source VM might not be able list target VMs or attach to them. Deletion of the common directory can also cause semaphore leaks. The system temporary directory is full or inaccessible and the Attach API cannot initialize. Try specifying a different directory in which to create the common subdirectory by using the -Dcom.ibm.tools.attach.directory system property. A short delay between the start of the target VM and the initialization of the Attach API process can cause an AttachNotSupportedException: No provider for virtual machine id issue when the VirtualMachine.attach(String id) method is called. The target process is overloaded, suspended, or no longer running, or the port that is used to connect to the target is subject to a wait time (use the netstat -a command to check for ports in the TIME_WAIT state). These situations can cause an AttachNotSupportedException when the attach method is called. A JVMTI agent is corrupt or attempts to run an operation that is not available after the VM starts. These situations can cause an AgentLoadException or AgentInitializationException when one of the following methods is called: loadAgent() , loadAgentLibrary() , or loadAgentPath() . Depending on the method invoked, try loading the agent at VM startup by using one of the following command-line options -javaagent , -agentlib , or -agentpath . For more information about these options, see Java Virtual Machine Tool Interface . If you have checked for these potential issues but you are still experiencing problems, a number of command line system properties are available to help narrow down the cause. These options are shown in the following table: System property Description -Dcom.ibm.tools.attach.logging=<yes|no> Turn on tracing of attach API events -Dcom.ibm.tools.attach.log.name=<my_log_name> Specify the path and prefix for the log files To learn more about each property, click the link in the table.","title":"Java Attach API"},{"location":"attachapi/#java-attach-api","text":"With the Attach API, your application can connect to a running VM and load an agent into that VM to run tasks. The typical use case for this feature is to load an agent that can be used to monitor the application that's running in the target VM. For example, if you wanted to start monitoring an application that is already running with the Attach API enabled, you could use a tool such as the IBM Health Center . In this case, a Health Center agent can start in its own VM and attach to the target VM where the application is running to start recording and sending data to the Health Center client. The OpenJ9 implementation of the Attach API is equivalent to the reference implementation (API documentation is available on the Oracle website ). However, you can only use the Attach API to connect to another OpenJ9 VM. When you run a Java\u2122 application, VM support for the Attach API is enabled by default on all platforms except z/OS\u00ae. For security reasons on z/OS, processes that use the default z/OS OMVS segment cannot enable the Attach API. To enable or disable the Attach API, use the -Dcom.ibm.tools.attach.enable=[yes|no] command line option.","title":"Java Attach API"},{"location":"attachapi/#securing-the-attach-api","text":"Because the Attach API can be used to connect to a running application, you must control access to it to ensure that only authorized users or processes can use it. Disable the Attach API if you do not intend to use it. On Windows systems, the Attach API uses the system temporary directory, which is typically C:\\Users\\<USERNAME>\\AppData\\Local\\Temp . The Attach API creates a common subdirectory, which is .com_ibm_tools_attach by default. Because files and directories in the system temporary directory are handled by Windows security, only the process owner can connect to their processes. On UNIX systems, the Attach API uses /tmp and creates a common subdirectory, which is .com_ibm_tools_attach by default. The common subdirectory must be on a local drive, not a network drive. Security is handled by POSIX file permissions. The Attach API directory must be owned by root user and must have read, write, and execute file permissions for user , group , and other ( drwxrwxrwx ). The sticky bit is set so that only the owner and root can delete or rename files or directories within it. A process using the Java Attach API must be owned by the same UNIX user ID as the target process. ~/tmp $ ls -al total 0 drwxr-xr-x 3 user_a staff 96 6 Aug 17:11 . drwxr-xr-x+ 89 user_a staff 2848 6 Aug 17:11 .. drwxrwxrwx+ 7 root staff 224 6 Aug 17:22 .com_ibm_tools_attach In the default Attach API directory you can find certain files that start with an underscore _* , which are involved in synchronization. These files can be owned by any user but must have read and write permissions set. The files are empty and are automatically re-created if deleted. When your application attaches to a VM, a process directory is created. ~/tmp/.com_ibm_tools_attach $ ls -l total 3 -rw-rw-rw- 1 user_a staff 0 6 Aug 17:12 _attach_lock -rw-rw-rw- 1 user_a staff 0 6 Aug 17:12 _master -rw-rw-rw- 1 user_a staff 0 6 Aug 17:12 _notifier drwx--x--x 6 user_b staff 192 6 Aug 17:21 process_a The files in the subdirectory for a process, with the exception of a lock file, are accessible only by the owner of a process. The permissions for these files are rwxr-xr-x with the exception of the attachNotificationSync file, as shown in the following example. ~/tmp/.com_ibm_tools_attach/process_a $ ls -l total 4 -rwxrw-rw- 1 user_b staff 0 6 Aug 17:18 attachNotificationSync -rwxr-xr-x 1 user_b staff 0 6 Aug 17:21 file_a -rwxr-xr-x 1 user_b staff 0 6 Aug 17:21 file_b -rwxr-xr-x 1 user_b staff 0 6 Aug 17:21 file_c Notes for z/OS: z/OS systems must also set POSIX permissions on files and cannot rely on RACF\u00ae or system level security to protect applications. To avoid z/OS console messages reporting security violations in /tmp , add a security exception or specify a different common subdirectory by setting the com.ibm.tools.attach.directory system property.","title":"Securing the Attach API"},{"location":"attachapi/#configuring","text":"A number of system properties are available to configure the Attach API when you start a Java application, as shown in the following table: System property Description -Dcom.ibm.tools.attach.directory=<directory_name> Specify a different common directory for Attach API working files. -Dcom.ibm.tools.attach.displayName=<my_display_name> Change the display name recorded by an agent -Dcom.ibm.tools.attach.id=<my_vm_ID> Change the VM identifier recorded by an agent -Dcom.ibm.tools.attach.timeout=<value_in_milliseconds> Change the connection timeout -Dcom.ibm.tools.attach.shutdown_timeout=<value_in_milliseconds> Specify the timeout for ending the Attach API wait loop thread -Dcom.ibm.tools.attach.command_timeout=<value_in_milliseconds> Specify the timeout for sending a command to the target VM after initial attachment To learn more about each property, click the link in the table.","title":"Configuring"},{"location":"attachapi/#troubleshooting","text":"Problems with the Attach API generate one of the following exceptions: com.sun.tools.attach.AgentLoadException com.sun.tools.attach.AgentInitializationException com.sun.tools.attach.AgentNotSupportedException com.sun.tools.attach.AttachOperationFailedException java.io.IOException Exceptions from agents on the target VM go to stderr or stdout for the target VM. These exceptions are not reported in the output of the attaching VM. Here are some problems that you might encounter: On Unix systems, the file permissions are incorrectly set, causing access issues. Resolve these issues by reading and complying with Securing the Attach API . Also check that the Attach API is not disabled. The common directory is deleted, the contents of the common directory are deleted, or permissions of the common directory or subdirectories are changed. As a result, the source VM might not be able list target VMs or attach to them. Deletion of the common directory can also cause semaphore leaks. The system temporary directory is full or inaccessible and the Attach API cannot initialize. Try specifying a different directory in which to create the common subdirectory by using the -Dcom.ibm.tools.attach.directory system property. A short delay between the start of the target VM and the initialization of the Attach API process can cause an AttachNotSupportedException: No provider for virtual machine id issue when the VirtualMachine.attach(String id) method is called. The target process is overloaded, suspended, or no longer running, or the port that is used to connect to the target is subject to a wait time (use the netstat -a command to check for ports in the TIME_WAIT state). These situations can cause an AttachNotSupportedException when the attach method is called. A JVMTI agent is corrupt or attempts to run an operation that is not available after the VM starts. These situations can cause an AgentLoadException or AgentInitializationException when one of the following methods is called: loadAgent() , loadAgentLibrary() , or loadAgentPath() . Depending on the method invoked, try loading the agent at VM startup by using one of the following command-line options -javaagent , -agentlib , or -agentpath . For more information about these options, see Java Virtual Machine Tool Interface . If you have checked for these potential issues but you are still experiencing problems, a number of command line system properties are available to help narrow down the cause. These options are shown in the following table: System property Description -Dcom.ibm.tools.attach.logging=<yes|no> Turn on tracing of attach API events -Dcom.ibm.tools.attach.log.name=<my_log_name> Specify the path and prefix for the log files To learn more about each property, click the link in the table.","title":"Troubleshooting"},{"location":"builds/","text":"OpenJ9 builds Eclipse Foundation projects are not permitted to distribute, market or promote JDK binaries unless they have passed a Java SE Technology Compatibility Kit licensed from Oracle, to which the OpenJ9 project does not currently have access. See the Eclipse Adoptium Project Charter . Supported platforms The community develops and maintains a test infrastructure for the OpenJ9 source across a broad range of platforms. For information about the platforms and minimum operating system levels supported, see the Platform support matrix . Building your own binaries If you want to build your own binaries of OpenJDK with OpenJ9, a complete set of build instructions for several platforms can be found in the OpenJ9 GitHub repository . Installation pre-requisites Note the following: For the best performance, OpenSSL support should be enabled in the build. In builds that aren't configured with --enable-openssl-bundling , the OpenSSL library is expected to be found on the system path. If you want to use OpenSSL cryptographic acceleration, you must install OpenSSL 1.0.2 or 1.1.X on your system. If the library is not found on the system path, the in-built Java crytographic implementation is used instead, which performs less well. On Linux systems, the fontconfig.x86_64 package should be installed to avoid a NullPointerException error when the AWT font subsystem is initialized. From Eclipse OpenJ9 release 0.16.0 (OpenJDK 13) and release 0.17.0 (OpenJDK 8 and 11), CUDA is now enabled on Windows (x86-64) and Linux (x86-64 and IBM POWER LE) platforms, which allows you to offload certain Java application processing tasks to a general purpose graphics processing unit (GPU). To take advantage of this feature, your system must support NVIDIA Compute Unified Device Architecture (CUDA). The JIT requires the CUDA Toolkit 7.5 and your GPU device must have a minimum compute capability of 3.0.","title":"OpenJ9 builds"},{"location":"builds/#openj9-builds","text":"Eclipse Foundation projects are not permitted to distribute, market or promote JDK binaries unless they have passed a Java SE Technology Compatibility Kit licensed from Oracle, to which the OpenJ9 project does not currently have access. See the Eclipse Adoptium Project Charter .","title":"OpenJ9 builds"},{"location":"builds/#supported-platforms","text":"The community develops and maintains a test infrastructure for the OpenJ9 source across a broad range of platforms. For information about the platforms and minimum operating system levels supported, see the Platform support matrix .","title":"Supported platforms"},{"location":"builds/#building-your-own-binaries","text":"If you want to build your own binaries of OpenJDK with OpenJ9, a complete set of build instructions for several platforms can be found in the OpenJ9 GitHub repository .","title":"Building your own binaries"},{"location":"builds/#installation-pre-requisites","text":"Note the following: For the best performance, OpenSSL support should be enabled in the build. In builds that aren't configured with --enable-openssl-bundling , the OpenSSL library is expected to be found on the system path. If you want to use OpenSSL cryptographic acceleration, you must install OpenSSL 1.0.2 or 1.1.X on your system. If the library is not found on the system path, the in-built Java crytographic implementation is used instead, which performs less well. On Linux systems, the fontconfig.x86_64 package should be installed to avoid a NullPointerException error when the AWT font subsystem is initialized. From Eclipse OpenJ9 release 0.16.0 (OpenJDK 13) and release 0.17.0 (OpenJDK 8 and 11), CUDA is now enabled on Windows (x86-64) and Linux (x86-64 and IBM POWER LE) platforms, which allows you to offload certain Java application processing tasks to a general purpose graphics processing unit (GPU). To take advantage of this feature, your system must support NVIDIA Compute Unified Device Architecture (CUDA). The JIT requires the CUDA Toolkit 7.5 and your GPU device must have a minimum compute capability of 3.0.","title":"Installation pre-requisites"},{"location":"cmdline_general/","text":"Standard command-line options The OpenJ9 virtual machine supports the standard Java\u2122 options that are common to all Java virtual machine implementations, including Oracle's HotSpot VM. Some of the common options supported are summarised in the following table: Standard option name Purpose -classpath:<resource_name>[:<resource_name>] Sets the search path for application classes and resources (directories and compressed or .jar files). cp can be used instead of classpath . -help , -? Prints a usage message. -fullversion Prints the build and version information for a VM -showversion Prints product version and continues. -verbose:<option>[,<option>] Enables verbose output. Options include class , dynload , gc , init , jni , sizes , stack , and module . (See Notes ) -version Prints the full build and version information a VM Notes: -verbose:class : Writes an entry to stderr for each class that is loaded. -verbose:dynload : Writes detailed class information to stderr as each bootstrap class is loaded by the VM: -verbose:gc : Provides verbose garbage collection information. -verbose:init : Writes information to stderr describing VM initialization and termination. -verbose:jni : Writes information to stderr describing the JNI services called by the application and VM. -verbose:sizes : Writes information to stderr describing the active memory usage settings. -verbose:stack : Writes information to stderr describing the Java and C stack usage for each thread. -verbose:module : Writes information to stderr for each module that is loaded and unloaded. For more information about standard options, see Oracle Java SE Standard Options OpenJ9 extensions OpenJ9 supports the following extension to the -verbose option: -verbose:stacktrace : Writes either the module name or the Classloader name (with the code source location when available) to the end of each line of a Java stack trace.","title":"Standard options"},{"location":"cmdline_general/#standard-command-line-options","text":"The OpenJ9 virtual machine supports the standard Java\u2122 options that are common to all Java virtual machine implementations, including Oracle's HotSpot VM. Some of the common options supported are summarised in the following table: Standard option name Purpose -classpath:<resource_name>[:<resource_name>] Sets the search path for application classes and resources (directories and compressed or .jar files). cp can be used instead of classpath . -help , -? Prints a usage message. -fullversion Prints the build and version information for a VM -showversion Prints product version and continues. -verbose:<option>[,<option>] Enables verbose output. Options include class , dynload , gc , init , jni , sizes , stack , and module . (See Notes ) -version Prints the full build and version information a VM Notes: -verbose:class : Writes an entry to stderr for each class that is loaded. -verbose:dynload : Writes detailed class information to stderr as each bootstrap class is loaded by the VM: -verbose:gc : Provides verbose garbage collection information. -verbose:init : Writes information to stderr describing VM initialization and termination. -verbose:jni : Writes information to stderr describing the JNI services called by the application and VM. -verbose:sizes : Writes information to stderr describing the active memory usage settings. -verbose:stack : Writes information to stderr describing the Java and C stack usage for each thread. -verbose:module : Writes information to stderr for each module that is loaded and unloaded. For more information about standard options, see Oracle Java SE Standard Options","title":"Standard command-line options"},{"location":"cmdline_general/#openj9-extensions","text":"OpenJ9 supports the following extension to the -verbose option: -verbose:stacktrace : Writes either the module name or the Classloader name (with the code source location when available) to the end of each line of a Java stack trace.","title":"OpenJ9 extensions"},{"location":"cmdline_migration/","text":"Switching to OpenJ9 If you are already familiar with HotSpot command-line options but want the advantages of OpenJ9, the following information will prove helpful. In all cases, check individual topics for minor discrepancies in the way these options might work. Note: For information about HotSpot equivalences and differences for items other than command-line options, see New to OpenJ9? Compatible options You can use the following command-line options in OpenJ9, just as you did in HotSpot; you can continue to use the HotSpot option in OpenJ9 without having to change your code: Option Usage -X Displays help on nonstandard options. -Xbootclasspath Specifies the search path for bootstrap classes and resources. -Xcheck:jni Runs additional checks for JNI functions during VM startup. -Xfuture Turns on strict class-file format checks. -Xint Runs an application in interpreted-only mode. -Xlog Some forms of -Xlog that enable garbage collection logging are recognized. (Equivalent to -Xverbosegclog ). -Xmn Sets the initial and maximum size of the new area when using -Xgcpolicy:gencon. -Xms Sets the initial size of the heap. (Equivalent to -XX:InitialHeapSize ) -Xmx Specifies the maximum size of the object memory allocation pool. (Equivalent to -XX:MaxHeapSize ) -Xnoclassgc Disables class garbage collection (GC). -Xrs Prevents the OpenJ9 run time environment from handling signals. -Xss Sets the Java\u2122 thread stack size. (Equivalent to -XX:ThreadStackSize ). Note: Unlike HotSpot, this option applies only to the Java stack. OpenJ9 has a separate native stack for operating system threads (see -Xmso ) -Xverify:mode Enables or disables the verifier. -XX:ConcGCThreads Configures the number of GC mutator background threads. -XX:[+|-]AlwaysPreTouch Enables/disables committing of memory during initial heap inflation or heap expansion. -XX:[+|-]CompactStrings Enables/disables String compression -XX:DiagnoseSyncOnValueBasedClasses=<number> Configure warnings for value-based classes -XX:[+|-]DisableExplicitGC Enables/disables explicit System.gc() calls. (Alias for -Xdisableexplicitgc / -Xenableexplicitgc ) -XX:[+|-]ExitOnOutOfMemoryError Triggers VM shutdown on out-of-memory conditions. -XX:[+|-]HeapDumpOnOutOfMemory Enables/disables dumps on out-of-memory conditions. -XX:HeapDumpPath Specifies a directory for all VM dumps including heap dumps, javacores, and system dumps. (Alias for -Xdump:directory ) -XX:[+|-]IgnoreUnrecognizedVMOptions Specifies whether to ignore unrecognized top-level VM options -XX:InitialHeapSize Sets the initial size of the heap. (Alias for -Xms ) -XX:InitialRAMPercentage Sets the initial size of the Java heap as a percentage of total memory. -XX:MaxDirectMemorySize Sets a limit on the amount of memory that can be reserved for all direct byte buffers. -XX:MaxHeapSize Specifies the maximum size of the object memory allocation pool. (Alias for -Xmx ) -XX:MaxRAMPercentage Sets the maximum size of the Java heap as a percentage of total memory. -XX:OnOutOfMemoryError Runs specified commands when a java.lang.OutOfMemoryError is thrown. (Equivalent to -Xdump:tool:events=systhrow,filter=java/lang/OutOfMemoryError,exec= ) -XX:ParallelCMSThreads Configures the number of GC mutator background threads. -XX:ParallelGCThreads Configures the number of GC threads. -XX:[+|-]PrintCodeCache Prints code cache usage when the application exits. -XX:[+|-]UseCompressedOops Disables compressed references in 64-bit JVMs. (See also -Xcompressedrefs ) -XX:[+|-]UseContainerSupport Sets a larger fraction of memory to the Java heap when the VM detects that it is running in a container. Equivalent options These HotSpot command-line options have equivalents in OpenJ9 that are not specified in the same way, but perform a related function: HotSpot Option OpenJ9 Option Usage -Xcomp -Xjit:count=0 1 -Xcomp disables interpreted method invocations. -Xgc -Xgcpolicy 2 Configuring your garbage collection policy. -XX:+UseNUMA -Xnuma:none 3 Controls non-uniform memory architecture (NUMA) awareness. Notes: HotSpot uses -Xcomp to force compilation of methods on first invocation. However, this option is deprecated. Whilst it can be used for compatibility, using -Xjit:count=0 is preferred. HotSpot uses -Xgc to both select policies and configure them; OpenJ9 uses -Xgcpolicy to select policies, reserving -Xgc for configuration. In HotSpot, NUMA awareness is turned off by default and is turned on by using the -XX:+UseNUMA option. Conversely, the OpenJ9 VM automatically enables NUMA awareness and uses -Xnuma:none to turn it off . If you were previously using HotSpot in its default mode, you must now explicitly turn off NUMA awareness in OpenJ9. If you are used to using -XX:+UseNUMA in HotSpot, you no longer need to explicitly turn on NUMA awareness; it's on by default. Creating compatible behavior You can set the following options to make OpenJ9 behave in the same way as HotSpot. Option Usage -Djava.lang.string.substring.nocopy=true Avoid String sharing by String.substring() . -Xnuma:none Disable non-uniform memory architecture (NUMA) awareness. -XXHandleSIGABRT Force handling of SIGABRT signals to be compatible with HotSpot Compatible environment variables The JAVA_TOOL_OPTIONS environment variable can be used to set command line options as described in OpenJ9 command-line options and Environment variables .","title":"Switching to OpenJ9"},{"location":"cmdline_migration/#switching-to-openj9","text":"If you are already familiar with HotSpot command-line options but want the advantages of OpenJ9, the following information will prove helpful. In all cases, check individual topics for minor discrepancies in the way these options might work. Note: For information about HotSpot equivalences and differences for items other than command-line options, see New to OpenJ9?","title":"Switching to OpenJ9"},{"location":"cmdline_migration/#compatible-options","text":"You can use the following command-line options in OpenJ9, just as you did in HotSpot; you can continue to use the HotSpot option in OpenJ9 without having to change your code: Option Usage -X Displays help on nonstandard options. -Xbootclasspath Specifies the search path for bootstrap classes and resources. -Xcheck:jni Runs additional checks for JNI functions during VM startup. -Xfuture Turns on strict class-file format checks. -Xint Runs an application in interpreted-only mode. -Xlog Some forms of -Xlog that enable garbage collection logging are recognized. (Equivalent to -Xverbosegclog ). -Xmn Sets the initial and maximum size of the new area when using -Xgcpolicy:gencon. -Xms Sets the initial size of the heap. (Equivalent to -XX:InitialHeapSize ) -Xmx Specifies the maximum size of the object memory allocation pool. (Equivalent to -XX:MaxHeapSize ) -Xnoclassgc Disables class garbage collection (GC). -Xrs Prevents the OpenJ9 run time environment from handling signals. -Xss Sets the Java\u2122 thread stack size. (Equivalent to -XX:ThreadStackSize ). Note: Unlike HotSpot, this option applies only to the Java stack. OpenJ9 has a separate native stack for operating system threads (see -Xmso ) -Xverify:mode Enables or disables the verifier. -XX:ConcGCThreads Configures the number of GC mutator background threads. -XX:[+|-]AlwaysPreTouch Enables/disables committing of memory during initial heap inflation or heap expansion. -XX:[+|-]CompactStrings Enables/disables String compression -XX:DiagnoseSyncOnValueBasedClasses=<number> Configure warnings for value-based classes -XX:[+|-]DisableExplicitGC Enables/disables explicit System.gc() calls. (Alias for -Xdisableexplicitgc / -Xenableexplicitgc ) -XX:[+|-]ExitOnOutOfMemoryError Triggers VM shutdown on out-of-memory conditions. -XX:[+|-]HeapDumpOnOutOfMemory Enables/disables dumps on out-of-memory conditions. -XX:HeapDumpPath Specifies a directory for all VM dumps including heap dumps, javacores, and system dumps. (Alias for -Xdump:directory ) -XX:[+|-]IgnoreUnrecognizedVMOptions Specifies whether to ignore unrecognized top-level VM options -XX:InitialHeapSize Sets the initial size of the heap. (Alias for -Xms ) -XX:InitialRAMPercentage Sets the initial size of the Java heap as a percentage of total memory. -XX:MaxDirectMemorySize Sets a limit on the amount of memory that can be reserved for all direct byte buffers. -XX:MaxHeapSize Specifies the maximum size of the object memory allocation pool. (Alias for -Xmx ) -XX:MaxRAMPercentage Sets the maximum size of the Java heap as a percentage of total memory. -XX:OnOutOfMemoryError Runs specified commands when a java.lang.OutOfMemoryError is thrown. (Equivalent to -Xdump:tool:events=systhrow,filter=java/lang/OutOfMemoryError,exec= ) -XX:ParallelCMSThreads Configures the number of GC mutator background threads. -XX:ParallelGCThreads Configures the number of GC threads. -XX:[+|-]PrintCodeCache Prints code cache usage when the application exits. -XX:[+|-]UseCompressedOops Disables compressed references in 64-bit JVMs. (See also -Xcompressedrefs ) -XX:[+|-]UseContainerSupport Sets a larger fraction of memory to the Java heap when the VM detects that it is running in a container.","title":"Compatible options"},{"location":"cmdline_migration/#equivalent-options","text":"These HotSpot command-line options have equivalents in OpenJ9 that are not specified in the same way, but perform a related function: HotSpot Option OpenJ9 Option Usage -Xcomp -Xjit:count=0 1 -Xcomp disables interpreted method invocations. -Xgc -Xgcpolicy 2 Configuring your garbage collection policy. -XX:+UseNUMA -Xnuma:none 3 Controls non-uniform memory architecture (NUMA) awareness. Notes: HotSpot uses -Xcomp to force compilation of methods on first invocation. However, this option is deprecated. Whilst it can be used for compatibility, using -Xjit:count=0 is preferred. HotSpot uses -Xgc to both select policies and configure them; OpenJ9 uses -Xgcpolicy to select policies, reserving -Xgc for configuration. In HotSpot, NUMA awareness is turned off by default and is turned on by using the -XX:+UseNUMA option. Conversely, the OpenJ9 VM automatically enables NUMA awareness and uses -Xnuma:none to turn it off . If you were previously using HotSpot in its default mode, you must now explicitly turn off NUMA awareness in OpenJ9. If you are used to using -XX:+UseNUMA in HotSpot, you no longer need to explicitly turn on NUMA awareness; it's on by default.","title":"Equivalent options"},{"location":"cmdline_migration/#creating-compatible-behavior","text":"You can set the following options to make OpenJ9 behave in the same way as HotSpot. Option Usage -Djava.lang.string.substring.nocopy=true Avoid String sharing by String.substring() . -Xnuma:none Disable non-uniform memory architecture (NUMA) awareness. -XXHandleSIGABRT Force handling of SIGABRT signals to be compatible with HotSpot","title":"Creating compatible behavior"},{"location":"cmdline_migration/#compatible-environment-variables","text":"The JAVA_TOOL_OPTIONS environment variable can be used to set command line options as described in OpenJ9 command-line options and Environment variables .","title":"Compatible environment variables"},{"location":"cmdline_specifying/","text":"OpenJ9 command-line options When you start a Java\u2122 application you can specify various options on the command line to configure the runtime environment. These options include: System properties Standard options Nonstandard (or -X) options -XX options Although the command line is the traditional way to specify command-line options, you can also pass options to the OpenJ9 virtual machine (VM) by using a manifest file, options files, and environment variables. Options specified on the command line override the equivalent environment variables. For example, specifying java -cp <dir1> completely overrides setting the environment variable CLASSPATH=<dir2> . Quotation marks Use single or double quotation marks for command-line options only when explicitly directed to do so. Single and double quotation marks have different meanings on different platforms, operating systems, and shells. Do not use '-X<option>' or \"-X<option>\" . Instead, you must use -X<option> . For example, do not use '-Xmx500m' and \"-Xmx500m\" . Write this option as -Xmx500m . Precedence The sequence of the Java options on the command line defines which options take precedence during startup. Rightmost options have precedence over leftmost options. In the following example, the -Xjit option takes precedence: java -Xint -Xjit myClass At startup, the list of VM arguments is constructed in the following order, with the lowest precedence first: Certain options are created automatically by the VM, which specify arguments such as search paths and version information. The VM automatically adds -Xoptionsfile=<path>/options.default at the beginning of the command line, where <path> is the path to the VM directory. You can modify the options.default file to include any options that you want to specify for your application instead of entering these options on the command line. For more information about the path and construction of the file, see -Xoptionsfile . Options can be specified in an executable JAR file by using the META-INF/MANIFEST.MF file. Options are placed in the main section in a header named IBM-Java-Options . Only one IBM-Java-Options header is permitted, but the header can contain multiple options, separated by spaces. A long sequence of options can be split using a header continuation but are treated as a single line. Example manifest file: Manifest-Version: 1.0 Class-Path: . Main-Class: HelloWorld IBM-Java-Options: -Xshareclasses:name=mycache,nonfa tal,cacheDirPerm=1000 -Dproperty=example -Da.long.system.pro perty=\"this is a long system property value to demonstrate long VM arguments in the manifest file\" This example manifest file is parsed as the following string: -Xshareclasses:name=mycache,nonfatal,cacheDirPerm=1000 -Dproperty=example -Da.long.system.property=this is a long system property value to demonstrate long VM arguments in the manifest file Options specified in the manifest file are subject to the same restrictions as options files. For more information, see the -Xoptionsfile topic in the user guide. Environment variables that are described in OpenJ9 environment variables are translated into command-line options. For example, the following environment variable adds the parameter -Xrs to the list of arguments: On Windows\u2122 systems: set IBM_NOSIGHANDLER=<non_null_string> On AIX\u00ae, Linux\u00ae, macOS\u00ae, and z/OS\u00ae systems: export IBM_NOSIGHANDLER=<non_null_string> The OPENJ9_JAVA_OPTIONS environment variable. You can set command-line options using this environment variable. The options that you specify with this environment variable are added to the command line when a VM starts in that environment. The environment variable can contain multiple blank-delimited argument strings, but must not contain comments. For example: On Windows systems: set OPENJ9_JAVA_OPTIONS=-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump On AIX, Linux, macOS, and z/OS systems: export OPENJ9_JAVA_OPTIONS=\"-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump\" Note: The environment variable JAVA_TOOL_OPTIONS is equivalent to OPENJ9_JAVA_OPTIONS and is available for compatibility with JVMTI. The equivalent IBM_JAVA_OPTIONS environment variable is deprecated and will be removed in a future release. Options that are specified on the command line. For example: java -Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump MyJavaClass The Java launcher adds some automatically generated arguments to this list, such as the names of the main class. You can also use the -Xoptionsfile parameter to specify VM options. This parameter can be used on the command line, or as part of the OPENJ9_JAVA_OPTIONS environment variable. The contents of an option file are expanded in place during startup. For more information about the structure and contents of this type of file, see -Xoptionsfile . To troubleshoot startup problems, you can check which options are used by the OpenJ9 VM. Append the following command-line option, and inspect the Java core file that is generated: -Xdump:java:events=vmstart Here is an extract from a Java core file that shows the options that are used: 2CIUSERARG -Xdump:java:file=/home/test_javacore.txt,events=vmstop 2CIUSERARG -Dtest.cmdlineOption=1 2CIUSERARG -XXallowvmshutdown:true 2CIUSERARG -Xoptionsfile=test1.test_options_file The _JAVA_OPTIONS environment variable. You can override previous options using this environment variable. The options that you specify with this environment variable are added to the end of the command line when a VM starts in that environment. The environment variable can contain multiple blank-delimited argument strings, but must not contain comments. For example: On Windows systems: set _JAVA_OPTIONS=-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump On AIX, Linux, macOS, and z/OS systems: export _JAVA_OPTIONS=\"-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump\"","title":"Specifying options"},{"location":"cmdline_specifying/#openj9-command-line-options","text":"When you start a Java\u2122 application you can specify various options on the command line to configure the runtime environment. These options include: System properties Standard options Nonstandard (or -X) options -XX options Although the command line is the traditional way to specify command-line options, you can also pass options to the OpenJ9 virtual machine (VM) by using a manifest file, options files, and environment variables. Options specified on the command line override the equivalent environment variables. For example, specifying java -cp <dir1> completely overrides setting the environment variable CLASSPATH=<dir2> .","title":"OpenJ9 command-line options"},{"location":"cmdline_specifying/#quotation-marks","text":"Use single or double quotation marks for command-line options only when explicitly directed to do so. Single and double quotation marks have different meanings on different platforms, operating systems, and shells. Do not use '-X<option>' or \"-X<option>\" . Instead, you must use -X<option> . For example, do not use '-Xmx500m' and \"-Xmx500m\" . Write this option as -Xmx500m .","title":"Quotation marks"},{"location":"cmdline_specifying/#precedence","text":"The sequence of the Java options on the command line defines which options take precedence during startup. Rightmost options have precedence over leftmost options. In the following example, the -Xjit option takes precedence: java -Xint -Xjit myClass At startup, the list of VM arguments is constructed in the following order, with the lowest precedence first: Certain options are created automatically by the VM, which specify arguments such as search paths and version information. The VM automatically adds -Xoptionsfile=<path>/options.default at the beginning of the command line, where <path> is the path to the VM directory. You can modify the options.default file to include any options that you want to specify for your application instead of entering these options on the command line. For more information about the path and construction of the file, see -Xoptionsfile . Options can be specified in an executable JAR file by using the META-INF/MANIFEST.MF file. Options are placed in the main section in a header named IBM-Java-Options . Only one IBM-Java-Options header is permitted, but the header can contain multiple options, separated by spaces. A long sequence of options can be split using a header continuation but are treated as a single line. Example manifest file: Manifest-Version: 1.0 Class-Path: . Main-Class: HelloWorld IBM-Java-Options: -Xshareclasses:name=mycache,nonfa tal,cacheDirPerm=1000 -Dproperty=example -Da.long.system.pro perty=\"this is a long system property value to demonstrate long VM arguments in the manifest file\" This example manifest file is parsed as the following string: -Xshareclasses:name=mycache,nonfatal,cacheDirPerm=1000 -Dproperty=example -Da.long.system.property=this is a long system property value to demonstrate long VM arguments in the manifest file Options specified in the manifest file are subject to the same restrictions as options files. For more information, see the -Xoptionsfile topic in the user guide. Environment variables that are described in OpenJ9 environment variables are translated into command-line options. For example, the following environment variable adds the parameter -Xrs to the list of arguments: On Windows\u2122 systems: set IBM_NOSIGHANDLER=<non_null_string> On AIX\u00ae, Linux\u00ae, macOS\u00ae, and z/OS\u00ae systems: export IBM_NOSIGHANDLER=<non_null_string> The OPENJ9_JAVA_OPTIONS environment variable. You can set command-line options using this environment variable. The options that you specify with this environment variable are added to the command line when a VM starts in that environment. The environment variable can contain multiple blank-delimited argument strings, but must not contain comments. For example: On Windows systems: set OPENJ9_JAVA_OPTIONS=-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump On AIX, Linux, macOS, and z/OS systems: export OPENJ9_JAVA_OPTIONS=\"-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump\" Note: The environment variable JAVA_TOOL_OPTIONS is equivalent to OPENJ9_JAVA_OPTIONS and is available for compatibility with JVMTI. The equivalent IBM_JAVA_OPTIONS environment variable is deprecated and will be removed in a future release. Options that are specified on the command line. For example: java -Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump MyJavaClass The Java launcher adds some automatically generated arguments to this list, such as the names of the main class. You can also use the -Xoptionsfile parameter to specify VM options. This parameter can be used on the command line, or as part of the OPENJ9_JAVA_OPTIONS environment variable. The contents of an option file are expanded in place during startup. For more information about the structure and contents of this type of file, see -Xoptionsfile . To troubleshoot startup problems, you can check which options are used by the OpenJ9 VM. Append the following command-line option, and inspect the Java core file that is generated: -Xdump:java:events=vmstart Here is an extract from a Java core file that shows the options that are used: 2CIUSERARG -Xdump:java:file=/home/test_javacore.txt,events=vmstop 2CIUSERARG -Dtest.cmdlineOption=1 2CIUSERARG -XXallowvmshutdown:true 2CIUSERARG -Xoptionsfile=test1.test_options_file The _JAVA_OPTIONS environment variable. You can override previous options using this environment variable. The options that you specify with this environment variable are added to the end of the command line when a VM starts in that environment. The environment variable can contain multiple blank-delimited argument strings, but must not contain comments. For example: On Windows systems: set _JAVA_OPTIONS=-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump On AIX, Linux, macOS, and z/OS systems: export _JAVA_OPTIONS=\"-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump\"","title":"Precedence"},{"location":"configuring/","text":"Configuring your system Configuring your local system can help you optimize the runtime environment for your Java application. Options include setting operating system environment variables and configuring system resources so that OpenJ9 can exploit the underlying operating system and hardware capabilities. When you install a Java\u2122 runtime environment on your system you can set the PATH environment variable so that the operating system can find the Java programs and utilities to run your application. To tell your application where to find user classes, you can use the -cp option or set the CLASSPATH environment variable. However, if you set CLASSPATH globally, all invocations of Java are affected. How to set these environment variables is covered in many publications about Java, such as The Java Tutorials: PATH and CLASSPATH . On some systems, a further environment variable might be required if your application requires shared libraries but does not specify their exact location. You can set the following environment variables to specify the directory location of the shared libraries, although setting a global value affects all invocations of Java: LIBPATH (AIX\u00ae and z/OS\u00ae) LD_LIBRARY_PATH (Linux\u00ae) DYLD_LIBRARY_PATH (macOS\u00ae) PATH (Windows\u00ae) Although most Java applications should run without changing anything on the underlying system, a unique pre-requisite exists for AIX systems on OpenJDK version 14 and later; you must have the XL C++ Runtime installed. Setting resource limits (AIX, Linux, and macOS) The operating system sets resource limits for a shell, and to processes started by the shell, to ensure that a single process cannot consume all available resources. However, these limits can affect certain operations that might need to run for a Java application, such as producing a dump file. Setting ulimit values Some resource limits are controlled by the ulimit command. A soft limit is the value set by the kernel for a resource and a hard limit imposes a maximum value on the soft limit. A privileged process can change either limit, but an unprivileged process can change only its soft limit (between 0 and the hard limit) or irreversibly lower its hard limit. To see the current limits set for a system, run ulimit -a . The output is similar to the following example: core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 256 pipe size (512 bytes, -p) 1 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 2784 virtual memory (kbytes, -v) unlimited To show hard limits, use ulimit -Ha . You can change limits for specific resources on a temporary basis by running the ulimit command. Alternatively, you can store limit settings in a configuration file, which is /etc/security/limits for AIX or etc/security/limits.conf for Linux. For more information about configuring resource limits, refer to the documentation for your operating system. The main use case for changing ulimit resources is when enabling a system dump to ensure that all the required data can be collected for analysis. For more information, see Enabling a full system dump . Setting shared memory values Another use case for changing resource limits is to ensure that there is sufficient shared memory allocated for class data sharing. By default, the shared classes cache consists of memory-mapped files that are created on disk and persist when the system is restarted. If you choose to use non-persistent caches by setting the -Xshareclasses:nonpersistent option, caches are not retained on startup and are allocated by using the System V IPC shared memory mechanism. On AIX systems, the kernel dynamically adjusts the shared memory settings as required. No special configuration is required. On Linux systems, the SHMMAX setting limits the amount of shared memory that can be allocated, which affects the shared classes cache size. You can find the value of SHMMAX for your system in the /proc/sys/kernel/shmmax file. For non-persistent caches, set this value to an appropriate size for your applications. To make these changes permanent, edit /etc/sysctl.conf and reboot your system. On macOS systems, you must set kern.sysv.shmmax and kern.sysv.shmall when using a nonpersistent cache. Modify the settings in your /etc/sysctl.conf file and reboot your system. To check the value, run sysctl kern.sysv.shmmax . Note: The virtual address space of a process is shared between the shared classes cache and the Java heap. Increasing the maximum size for the shared classes cache might reduce the size of the Java heap that you can create. Shared memory limits are also important when configuring large page memory allocation on Linux systems. For more information, see Configuring large page memory allocation: Linux systems . Setting resource limits (z/OS) Resource limits imposed by z/OS might affect Java operations. To learn how these resource limits are set, see Customizing the BPXPRMxx member of SYS1.PARMLIB . The OpenJ9 class data sharing feature is implemented by using shared memory segments on z/OS. Special consideration should be given to the following parameters that relate to the shared memory and IPC semaphore settings: IPCSHMSPAGES IPCSHMMPAGES IPCSHMNSEGS Incorrect or suboptimal settings might prevent shared classes from working or impact performance. By default, the VM attempts to create a 16 MB cache. If you set a cache size for your application by specifying the -Xscmx option on the command line, the VM rounds the value up to the nearest megabyte. Ensure that the value set for IPCSHMMPAGES takes this adjustment into consideration. To see the current settings, enter the following z/OS operator command: D OMVS,O The suggested minimum values for Java applications are shown in the following table: Parameter Value MAXPROCSYS 900 MAXPROCUSER 512 MAXUIDS 500 MAXTHREADS 10000 MAXTHREADTASKS 5000 MAXASSIZE 2147483647 MAXCPUTIME 2147483647 MAXMMAPAREA 40960 IPCSHMSPAGES 262144 IPCSHMMPAGES 256 IPCSHMNSEGS 10 IPCSEMNIDS 500 IPCSEMNSEMS 1000 Note: The number of threads that can be created by a Java process is limited by the lower of the two values for MAXTHREADS and MAXTHREADSTASKS . You can change these settings dynamically without re-IPLing the system. For example, to set MACPROCUSER to 256, run SETOMVS MAXPROCUSER=256 z/OS uses region sizes to determine the amount of storage available to running programs. For a Java runtime environment, the region size must be sufficiently large to avoid storage related error messages or abends. Rather than restricting region size, allow the VM to use what it needs. Region size can be affected by one of the following parameters: JCL REGION , BPXPRMxx MAXASSIZE , the RACF OMVS segment ASSIZEMAX , or IEFUSI (Step initiation exit). Configuring Language Environment runtime options Language Environment\u00ae runtime options affect performance and storage usage. These options can be optimized for your application. Runtime options are typically embedded in programs by using #pragma runopts settings. In many cases, these options provide suitable default values that are known to produce good performance results. However, these options can be overridden to tune the runtime environment of your application. On 64-bit z/OS systems, the following runtime options affect Java applications: HEAP64 : Controls allocation of the user heap. A suggested starting point for an override is HEAP64(512M,4M,KEEP,16M,4M,KEEP,0K,0K,FREE) . HEAPPOOLS64 : Used to manage Java heap storage above the 2 G bar. The Java USS launcher sets HEAPPOOLS64(ALIGN) for more optimal management of multi-threaded applications. Other Java launchers might have different settings. Before you set an override for HEAPPOOLS64 , use RPTOPTS(ON) to confirm the active settings for your environment and RPTSTG(ON) to review storage usage and tuning recommendations. Note that the host product might have already set cell sizes and numbers that are known to produce good performance. STACK64 : Controls the allocation and management of stack storage. A suggested default is STACK64(1M,1M,128M) . THREADSTACK64 : Controls the allocation of thread-level stack storage for both the upward and downward-growing stack. A suggested default is THREADSTACK64(OFF,1M,1M,128M) . A suitable MEMLIMIT value is also required. The OpenJ9 VM requirement is the sum of the following amounts: User heap storage required by the VM and native libraries, as controlled by HEAP64 (minimum 512 M) settings. User stack storage (3 MB multiplied by the expected number of concurrent threads), as controlled by STACK64 settings. -Xmx largest expected VM heap size. The JIT data cache maximum size. The JIT code cache maximum size, if RMODE64 is supported. Note: If you intend to use the Concurrent Scavenge mode of the default Generational Concurrent ( gencon ) garbage collection policy by using hardware-based support, the virtual storage used might exceed the Java maximum heap size. Set the z/OS memory limit to a larger value than the maximum heap size. For more information, see -Xgc:concurrentScavenge . The following guides are available to help you configure Language Environment runtime options and callable services: See z/OS Language Environment Programming Guide for guidance on how to override the default options. Use RPTOPTS (ON) to write the options that are in effect to stderr on termination. See z/OS Language Environment Programming Reference for a full list of the available runtime options. See z/OS Language Environment Debugging Guide for tuning guidance by using RPTSTG (ON) . Warning: Changing the runtime options can often degrade performance. Configuring large page memory allocation If your application allocates a large amount of memory and frequently accesses that memory, you might be able to improve performance by enabling large page support on your system. Some Linux kernels implement Transparent HugePage Support (THP), which automates the provision of large pages to back virtual memory, as described in Linux systems . Alternatively, you can enable large page support by setting the -Xlp:objectheap and -Xlp:codecache options on the command line when you start your application. These options have the following effects: The -Xlp:objectheap option requests that the Java object heap is allocated by using large pages. The -Xlp:codecache option requests that the JIT code cache is allocated by using large pages. You must also enable large pages on your local system. This process differs according to the operating system. AIX systems AIX supports large page sizes of 64 KB and 16 MB, and a huge page size of 16 GB depending on the underlying system P hardware. To determine which page sizes are supported on a particular system, run pagesize -a . To use large pages to back an application's data and heap segments, specify the LDR_CNTRL environment variable. You can set different page sizes for different purposes. The following variables can be used: TEXTPSIZE : Page size to use for text STACKPSIZE : Page size to use for stacks DATAPSIZE : Page size to use for native data or HEAP64 The following example sets 4 KB for text and 64 KB for stack, native data, and heap areas: LDR_CNTRL=TEXTPSIZE=4K@STACKPSIZE=64K@DATAPSIZE=64K For more information, including support considerations, see Large pages and Multiple page size support in the AIX documentation. The 16 MB and 16 GB page sizes, which are intended for very high performance environments, require special user permissions. You must also configure the number of pages that you require, which cannot be adjusted on demand. For 16 MB large pages, you set the number of large pages by using the vmo command. For 16 GB huge pages you must define the number of pages by using the hardware management console. For more information, see Page sizes for very high-performance environments in the AIX documentation. Linux systems Large pages are typically referred to as huge pages on Linux systems. To configure huge page memory allocation, the kernel must support huge pages. If huge pages are supported, the following lines are present in the /proc/meminfo file: HugePages_Total: HugePages_Free: Hugepagesize: If these lines do not exist, update your Linux kernel. If HugePages_Total has a value of 0 , huge pages are available, but not enabled. To enable huge pages, add the following line to your /etc/sysctl.conf file and reload the configuration by running sysctl -p : vm.nr_hugepages=<number> Where <number> is the number of huge pages required. Configure the number of huge pages that you require at boot time to ensure that the VM has access to sufficient contiguous pages. The following kernel parameters must be set appropriately for your system: SHMMAX : The maximum size of the shared memory segment (bytes). SHMALL : The total amount of shared memory in the system (bytes or pages). The user running the Java process must either be ROOT or have permissions to use huge pages. For the appropriate permissions, the user must be a member of a group that has its group identifier (gid) stored in /proc/sys/vm/hugetlb_shm_group . The locked memory limit must also be increased to at least the size of the Java heap by using the ulimit -l command. Where huge page support is available, the following default sizes apply for the object heap: Linux on x86: 2 MB Linux on IBM Power Systems: Varies depending on kernel version, check /proc/meminfo Linux on IBM Z: 1 MB Transparent HugePage Support (THP) is an automated mechanism of using huge pages to back virtual memory. On Linux kernels that support THP, it is typically enabled by default with the madvise option and can be relied on to provide huge pages as required without any user configuration. To disable THP for your application, use the OpenJ9 -XX:-TransparentHugePage option on the command line. To disable THP system-wide, change the sysfs boot time defaults with the command transparent_hugepage=never . For more information about THP see Transparent HugePage Support . Windows systems On Windows systems, large pages are typically 2 MB in size. To use large pages, the VM user must have the Windows Lock pages in memory setting enabled in the Local Security Policy. Applications must also be run with Admin privileges in order to use large page memory allocations. For more information, see the following resources from Microsoft: Large page support GetLargePageMinimum function ( memoryapi.h ) z/OS systems When available, 1 MB pageable pages are the default size for the object heap and the code cache. Other page sizes are available for the object heap, depending on the system architecture as shown in the following table: Large page size System architecture required -Xlp:codecache -Xlp:objectheap 2 GB nonpageable IBM zEnterprise EC12 processor or later Not supported Supported (64-bit VM only) 1 MB nonpageable System z10 processor or later Not supported Supported (64-bit VM only) 1 MB pageable IBM zEnterprise EC12 processor or later (see Note) Supported Supported Note: The Flash Express feature (#0402) helps avoid demoting 1 MB pageable pages to 4 KB pages when there is system paging activity. If a particular page size cannot be allocated, a smaller page size is attempted, in descending order. For example, if 2 GB nonpageable pages are requested but not available, the VM tries to allocate 1MB nonpageable pages. If 1 MB nonpageable pages are not available, the VM tries to allocate 1MB pageable pages. If large pages are not available, 4 KB pages are allocated. If you want to use nonpageable large pages for the object heap, a system programmer must configure z/OS for nonpageable large pages in the IEASYSxx parmlib member. Users who require large pages must also be authorized to the IARRSM.LRGPAGES resource in the RACF FACILITY class with read authority. Use the following z/OS system command to show large page usage for an LPAR: MODIFY AXR,IAXDMEM For more information, see Displaying real storage memory statistics in the z/OS product documentation. For usage information, including examples, see -Xlp:objectheap . Configuring Dynamic LPAR support (AIX only) Dynamic logical partitioning (DLPAR) provides a mechanism to add or remove system resources, such as memory or CPU, to or from the operating system in a logical partition without rebooting. Changing these resources dynamically can have an impact on Java applications that are running on the LPAR. To enable an application to respond to DLPAR events, you can use OpenJ9 MXBean extensions to the java.lang.management API. The following classes are available in the com.ibm.lang.management package: AvailableProcessorsNotificationInfo : Use to listen for changes to the number of available processors. ProcessingCapacityNotificationInfo : Use to listen for changes to processing capacity. TotalPhysicalMemoryNotificationInfo : Use to listen for changes to the total amount of physical memory that is available. These extensions can listen for events and trigger any necessary adjustments to the runtime environment. For example, if a Java VM is running in an LPAR with 2GB of memory, but the available memory might be adjusted between 1GB and 8GB, you might set the following options for the Java heap at run time: \u2013Xms1g \u2013Xsoftmx2g \u2013Xmx8g This command-line string sets an initial heap size of 1 GB, a soft (adjustable) maximum heap size of 2 GB, and a maximum heap size of 8 GB. You can then use the MemoryMXBean API to dynamically respond to changes in memory resources. The following classes can be used: getMaxHeapSize() : Query the maximum heap size. isSetMaxHeapSizeSupported() : Query whether the VM can support dynamic updates. setMaxHeapSize() : Adjust the maximum heap size. For more information about the com.ibm.lang.managment package, which extends the jdk.management module, see the API documentation .","title":"Configuring your system"},{"location":"configuring/#configuring-your-system","text":"Configuring your local system can help you optimize the runtime environment for your Java application. Options include setting operating system environment variables and configuring system resources so that OpenJ9 can exploit the underlying operating system and hardware capabilities. When you install a Java\u2122 runtime environment on your system you can set the PATH environment variable so that the operating system can find the Java programs and utilities to run your application. To tell your application where to find user classes, you can use the -cp option or set the CLASSPATH environment variable. However, if you set CLASSPATH globally, all invocations of Java are affected. How to set these environment variables is covered in many publications about Java, such as The Java Tutorials: PATH and CLASSPATH . On some systems, a further environment variable might be required if your application requires shared libraries but does not specify their exact location. You can set the following environment variables to specify the directory location of the shared libraries, although setting a global value affects all invocations of Java: LIBPATH (AIX\u00ae and z/OS\u00ae) LD_LIBRARY_PATH (Linux\u00ae) DYLD_LIBRARY_PATH (macOS\u00ae) PATH (Windows\u00ae) Although most Java applications should run without changing anything on the underlying system, a unique pre-requisite exists for AIX systems on OpenJDK version 14 and later; you must have the XL C++ Runtime installed.","title":"Configuring your system"},{"location":"configuring/#setting-resource-limits-aix-linux-and-macos","text":"The operating system sets resource limits for a shell, and to processes started by the shell, to ensure that a single process cannot consume all available resources. However, these limits can affect certain operations that might need to run for a Java application, such as producing a dump file.","title":"Setting resource limits (AIX, Linux, and macOS)"},{"location":"configuring/#setting-ulimit-values","text":"Some resource limits are controlled by the ulimit command. A soft limit is the value set by the kernel for a resource and a hard limit imposes a maximum value on the soft limit. A privileged process can change either limit, but an unprivileged process can change only its soft limit (between 0 and the hard limit) or irreversibly lower its hard limit. To see the current limits set for a system, run ulimit -a . The output is similar to the following example: core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 256 pipe size (512 bytes, -p) 1 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 2784 virtual memory (kbytes, -v) unlimited To show hard limits, use ulimit -Ha . You can change limits for specific resources on a temporary basis by running the ulimit command. Alternatively, you can store limit settings in a configuration file, which is /etc/security/limits for AIX or etc/security/limits.conf for Linux. For more information about configuring resource limits, refer to the documentation for your operating system. The main use case for changing ulimit resources is when enabling a system dump to ensure that all the required data can be collected for analysis. For more information, see Enabling a full system dump .","title":"Setting ulimit values"},{"location":"configuring/#setting-shared-memory-values","text":"Another use case for changing resource limits is to ensure that there is sufficient shared memory allocated for class data sharing. By default, the shared classes cache consists of memory-mapped files that are created on disk and persist when the system is restarted. If you choose to use non-persistent caches by setting the -Xshareclasses:nonpersistent option, caches are not retained on startup and are allocated by using the System V IPC shared memory mechanism. On AIX systems, the kernel dynamically adjusts the shared memory settings as required. No special configuration is required. On Linux systems, the SHMMAX setting limits the amount of shared memory that can be allocated, which affects the shared classes cache size. You can find the value of SHMMAX for your system in the /proc/sys/kernel/shmmax file. For non-persistent caches, set this value to an appropriate size for your applications. To make these changes permanent, edit /etc/sysctl.conf and reboot your system. On macOS systems, you must set kern.sysv.shmmax and kern.sysv.shmall when using a nonpersistent cache. Modify the settings in your /etc/sysctl.conf file and reboot your system. To check the value, run sysctl kern.sysv.shmmax . Note: The virtual address space of a process is shared between the shared classes cache and the Java heap. Increasing the maximum size for the shared classes cache might reduce the size of the Java heap that you can create. Shared memory limits are also important when configuring large page memory allocation on Linux systems. For more information, see Configuring large page memory allocation: Linux systems .","title":"Setting shared memory values"},{"location":"configuring/#setting-resource-limits-zos","text":"Resource limits imposed by z/OS might affect Java operations. To learn how these resource limits are set, see Customizing the BPXPRMxx member of SYS1.PARMLIB . The OpenJ9 class data sharing feature is implemented by using shared memory segments on z/OS. Special consideration should be given to the following parameters that relate to the shared memory and IPC semaphore settings: IPCSHMSPAGES IPCSHMMPAGES IPCSHMNSEGS Incorrect or suboptimal settings might prevent shared classes from working or impact performance. By default, the VM attempts to create a 16 MB cache. If you set a cache size for your application by specifying the -Xscmx option on the command line, the VM rounds the value up to the nearest megabyte. Ensure that the value set for IPCSHMMPAGES takes this adjustment into consideration. To see the current settings, enter the following z/OS operator command: D OMVS,O The suggested minimum values for Java applications are shown in the following table: Parameter Value MAXPROCSYS 900 MAXPROCUSER 512 MAXUIDS 500 MAXTHREADS 10000 MAXTHREADTASKS 5000 MAXASSIZE 2147483647 MAXCPUTIME 2147483647 MAXMMAPAREA 40960 IPCSHMSPAGES 262144 IPCSHMMPAGES 256 IPCSHMNSEGS 10 IPCSEMNIDS 500 IPCSEMNSEMS 1000 Note: The number of threads that can be created by a Java process is limited by the lower of the two values for MAXTHREADS and MAXTHREADSTASKS . You can change these settings dynamically without re-IPLing the system. For example, to set MACPROCUSER to 256, run SETOMVS MAXPROCUSER=256 z/OS uses region sizes to determine the amount of storage available to running programs. For a Java runtime environment, the region size must be sufficiently large to avoid storage related error messages or abends. Rather than restricting region size, allow the VM to use what it needs. Region size can be affected by one of the following parameters: JCL REGION , BPXPRMxx MAXASSIZE , the RACF OMVS segment ASSIZEMAX , or IEFUSI (Step initiation exit).","title":"Setting resource limits (z/OS)"},{"location":"configuring/#configuring-language-environment-runtime-options","text":"Language Environment\u00ae runtime options affect performance and storage usage. These options can be optimized for your application. Runtime options are typically embedded in programs by using #pragma runopts settings. In many cases, these options provide suitable default values that are known to produce good performance results. However, these options can be overridden to tune the runtime environment of your application. On 64-bit z/OS systems, the following runtime options affect Java applications: HEAP64 : Controls allocation of the user heap. A suggested starting point for an override is HEAP64(512M,4M,KEEP,16M,4M,KEEP,0K,0K,FREE) . HEAPPOOLS64 : Used to manage Java heap storage above the 2 G bar. The Java USS launcher sets HEAPPOOLS64(ALIGN) for more optimal management of multi-threaded applications. Other Java launchers might have different settings. Before you set an override for HEAPPOOLS64 , use RPTOPTS(ON) to confirm the active settings for your environment and RPTSTG(ON) to review storage usage and tuning recommendations. Note that the host product might have already set cell sizes and numbers that are known to produce good performance. STACK64 : Controls the allocation and management of stack storage. A suggested default is STACK64(1M,1M,128M) . THREADSTACK64 : Controls the allocation of thread-level stack storage for both the upward and downward-growing stack. A suggested default is THREADSTACK64(OFF,1M,1M,128M) . A suitable MEMLIMIT value is also required. The OpenJ9 VM requirement is the sum of the following amounts: User heap storage required by the VM and native libraries, as controlled by HEAP64 (minimum 512 M) settings. User stack storage (3 MB multiplied by the expected number of concurrent threads), as controlled by STACK64 settings. -Xmx largest expected VM heap size. The JIT data cache maximum size. The JIT code cache maximum size, if RMODE64 is supported. Note: If you intend to use the Concurrent Scavenge mode of the default Generational Concurrent ( gencon ) garbage collection policy by using hardware-based support, the virtual storage used might exceed the Java maximum heap size. Set the z/OS memory limit to a larger value than the maximum heap size. For more information, see -Xgc:concurrentScavenge . The following guides are available to help you configure Language Environment runtime options and callable services: See z/OS Language Environment Programming Guide for guidance on how to override the default options. Use RPTOPTS (ON) to write the options that are in effect to stderr on termination. See z/OS Language Environment Programming Reference for a full list of the available runtime options. See z/OS Language Environment Debugging Guide for tuning guidance by using RPTSTG (ON) . Warning: Changing the runtime options can often degrade performance.","title":"Configuring Language Environment runtime options"},{"location":"configuring/#configuring-large-page-memory-allocation","text":"If your application allocates a large amount of memory and frequently accesses that memory, you might be able to improve performance by enabling large page support on your system. Some Linux kernels implement Transparent HugePage Support (THP), which automates the provision of large pages to back virtual memory, as described in Linux systems . Alternatively, you can enable large page support by setting the -Xlp:objectheap and -Xlp:codecache options on the command line when you start your application. These options have the following effects: The -Xlp:objectheap option requests that the Java object heap is allocated by using large pages. The -Xlp:codecache option requests that the JIT code cache is allocated by using large pages. You must also enable large pages on your local system. This process differs according to the operating system.","title":"Configuring large page memory allocation"},{"location":"configuring/#aix-systems","text":"AIX supports large page sizes of 64 KB and 16 MB, and a huge page size of 16 GB depending on the underlying system P hardware. To determine which page sizes are supported on a particular system, run pagesize -a . To use large pages to back an application's data and heap segments, specify the LDR_CNTRL environment variable. You can set different page sizes for different purposes. The following variables can be used: TEXTPSIZE : Page size to use for text STACKPSIZE : Page size to use for stacks DATAPSIZE : Page size to use for native data or HEAP64 The following example sets 4 KB for text and 64 KB for stack, native data, and heap areas: LDR_CNTRL=TEXTPSIZE=4K@STACKPSIZE=64K@DATAPSIZE=64K For more information, including support considerations, see Large pages and Multiple page size support in the AIX documentation. The 16 MB and 16 GB page sizes, which are intended for very high performance environments, require special user permissions. You must also configure the number of pages that you require, which cannot be adjusted on demand. For 16 MB large pages, you set the number of large pages by using the vmo command. For 16 GB huge pages you must define the number of pages by using the hardware management console. For more information, see Page sizes for very high-performance environments in the AIX documentation.","title":"AIX systems"},{"location":"configuring/#linux-systems","text":"Large pages are typically referred to as huge pages on Linux systems. To configure huge page memory allocation, the kernel must support huge pages. If huge pages are supported, the following lines are present in the /proc/meminfo file: HugePages_Total: HugePages_Free: Hugepagesize: If these lines do not exist, update your Linux kernel. If HugePages_Total has a value of 0 , huge pages are available, but not enabled. To enable huge pages, add the following line to your /etc/sysctl.conf file and reload the configuration by running sysctl -p : vm.nr_hugepages=<number> Where <number> is the number of huge pages required. Configure the number of huge pages that you require at boot time to ensure that the VM has access to sufficient contiguous pages. The following kernel parameters must be set appropriately for your system: SHMMAX : The maximum size of the shared memory segment (bytes). SHMALL : The total amount of shared memory in the system (bytes or pages). The user running the Java process must either be ROOT or have permissions to use huge pages. For the appropriate permissions, the user must be a member of a group that has its group identifier (gid) stored in /proc/sys/vm/hugetlb_shm_group . The locked memory limit must also be increased to at least the size of the Java heap by using the ulimit -l command. Where huge page support is available, the following default sizes apply for the object heap: Linux on x86: 2 MB Linux on IBM Power Systems: Varies depending on kernel version, check /proc/meminfo Linux on IBM Z: 1 MB Transparent HugePage Support (THP) is an automated mechanism of using huge pages to back virtual memory. On Linux kernels that support THP, it is typically enabled by default with the madvise option and can be relied on to provide huge pages as required without any user configuration. To disable THP for your application, use the OpenJ9 -XX:-TransparentHugePage option on the command line. To disable THP system-wide, change the sysfs boot time defaults with the command transparent_hugepage=never . For more information about THP see Transparent HugePage Support .","title":"Linux systems"},{"location":"configuring/#windows-systems","text":"On Windows systems, large pages are typically 2 MB in size. To use large pages, the VM user must have the Windows Lock pages in memory setting enabled in the Local Security Policy. Applications must also be run with Admin privileges in order to use large page memory allocations. For more information, see the following resources from Microsoft: Large page support GetLargePageMinimum function ( memoryapi.h )","title":"Windows systems"},{"location":"configuring/#zos-systems","text":"When available, 1 MB pageable pages are the default size for the object heap and the code cache. Other page sizes are available for the object heap, depending on the system architecture as shown in the following table: Large page size System architecture required -Xlp:codecache -Xlp:objectheap 2 GB nonpageable IBM zEnterprise EC12 processor or later Not supported Supported (64-bit VM only) 1 MB nonpageable System z10 processor or later Not supported Supported (64-bit VM only) 1 MB pageable IBM zEnterprise EC12 processor or later (see Note) Supported Supported Note: The Flash Express feature (#0402) helps avoid demoting 1 MB pageable pages to 4 KB pages when there is system paging activity. If a particular page size cannot be allocated, a smaller page size is attempted, in descending order. For example, if 2 GB nonpageable pages are requested but not available, the VM tries to allocate 1MB nonpageable pages. If 1 MB nonpageable pages are not available, the VM tries to allocate 1MB pageable pages. If large pages are not available, 4 KB pages are allocated. If you want to use nonpageable large pages for the object heap, a system programmer must configure z/OS for nonpageable large pages in the IEASYSxx parmlib member. Users who require large pages must also be authorized to the IARRSM.LRGPAGES resource in the RACF FACILITY class with read authority. Use the following z/OS system command to show large page usage for an LPAR: MODIFY AXR,IAXDMEM For more information, see Displaying real storage memory statistics in the z/OS product documentation. For usage information, including examples, see -Xlp:objectheap .","title":"z/OS systems"},{"location":"configuring/#configuring-dynamic-lpar-support-aix-only","text":"Dynamic logical partitioning (DLPAR) provides a mechanism to add or remove system resources, such as memory or CPU, to or from the operating system in a logical partition without rebooting. Changing these resources dynamically can have an impact on Java applications that are running on the LPAR. To enable an application to respond to DLPAR events, you can use OpenJ9 MXBean extensions to the java.lang.management API. The following classes are available in the com.ibm.lang.management package: AvailableProcessorsNotificationInfo : Use to listen for changes to the number of available processors. ProcessingCapacityNotificationInfo : Use to listen for changes to processing capacity. TotalPhysicalMemoryNotificationInfo : Use to listen for changes to the total amount of physical memory that is available. These extensions can listen for events and trigger any necessary adjustments to the runtime environment. For example, if a Java VM is running in an LPAR with 2GB of memory, but the available memory might be adjusted between 1GB and 8GB, you might set the following options for the Java heap at run time: \u2013Xms1g \u2013Xsoftmx2g \u2013Xmx8g This command-line string sets an initial heap size of 1 GB, a soft (adjustable) maximum heap size of 2 GB, and a maximum heap size of 8 GB. You can then use the MemoryMXBean API to dynamically respond to changes in memory resources. The following classes can be used: getMaxHeapSize() : Query the maximum heap size. isSetMaxHeapSizeSupported() : Query whether the VM can support dynamic updates. setMaxHeapSize() : Adjust the maximum heap size. For more information about the com.ibm.lang.managment package, which extends the jdk.management module, see the API documentation .","title":"Configuring Dynamic LPAR support (AIX only)"},{"location":"d_jvm_commands/","text":"Using system property command-line options Java\u2122 system properties determine the environment in which a Java program runs by starting a Java virtual machine with a set of values. You can choose to use the default values for Java system properties or you can specify values for them by adding parameters to the command line when you start your application. To set a system property from the command line, use: java -D<property_name>=<value> <program_name> For example, to specify the UTF-8 file encoding for your application MyProgram , use: java -Dfile.encoding=UTF-8 MyProgram","title":"Using System properties"},{"location":"d_jvm_commands/#using-system-property-command-line-options","text":"Java\u2122 system properties determine the environment in which a Java program runs by starting a Java virtual machine with a set of values. You can choose to use the default values for Java system properties or you can specify values for them by adding parameters to the command line when you start your application. To set a system property from the command line, use: java -D<property_name>=<value> <program_name> For example, to specify the UTF-8 file encoding for your application MyProgram , use: java -Dfile.encoding=UTF-8 MyProgram","title":"Using system property command-line options"},{"location":"dcomibmenableclasscaching/","text":"-Dcom.ibm.enableClassCaching Setting this property to true enables caching of the Latest User Defined Class Loader (LUDCL). Syntax -Dcom.ibm.enableClassCaching=[true|false] Setting Effect Default true Enable yes false Disable Explanation By reducing repeated lookups, Java\u2122 applications that use deserialization extensively can see a performance improvement. See also Java Object Serialization Specification","title":"-Dcom.ibm.enableClassCaching"},{"location":"dcomibmenableclasscaching/#-dcomibmenableclasscaching","text":"Setting this property to true enables caching of the Latest User Defined Class Loader (LUDCL).","title":"-Dcom.ibm.enableClassCaching"},{"location":"dcomibmenableclasscaching/#syntax","text":"-Dcom.ibm.enableClassCaching=[true|false] Setting Effect Default true Enable yes false Disable","title":"Syntax"},{"location":"dcomibmenableclasscaching/#explanation","text":"By reducing repeated lookups, Java\u2122 applications that use deserialization extensively can see a performance improvement.","title":"Explanation"},{"location":"dcomibmenableclasscaching/#see-also","text":"Java Object Serialization Specification","title":"See also"},{"location":"dcomibmenablelegacydumpsecurity/","text":"-Dcom.ibm.enableLegacyDumpSecurity To improve security, the security checks in the certain com.ibm.jvm.Dump APIs are now enabled by default, when the SecurityManger is enabled. Use this system property to turn off security checking for these APIs. Syntax -Dcom.ibm.enableLegacyDumpSecurity=[true|false] Setting Effect Default true Enable yes false Disable Explanation Security checking is enabled in the following APIs: com.ibm.jvm.Dump.JavaDump() com.ibm.jvm.Dump.HeapDump() com.ibm.jvm.Dump.SnapDump() See also -Dcom.ibm.enableLegacyLogSecurity -Dcom.ibm.enableLegacyTraceSecurity","title":"-Dcom.ibm.enableLegacyDumpSecurity"},{"location":"dcomibmenablelegacydumpsecurity/#-dcomibmenablelegacydumpsecurity","text":"To improve security, the security checks in the certain com.ibm.jvm.Dump APIs are now enabled by default, when the SecurityManger is enabled. Use this system property to turn off security checking for these APIs.","title":"-Dcom.ibm.enableLegacyDumpSecurity"},{"location":"dcomibmenablelegacydumpsecurity/#syntax","text":"-Dcom.ibm.enableLegacyDumpSecurity=[true|false] Setting Effect Default true Enable yes false Disable","title":"Syntax"},{"location":"dcomibmenablelegacydumpsecurity/#explanation","text":"Security checking is enabled in the following APIs: com.ibm.jvm.Dump.JavaDump() com.ibm.jvm.Dump.HeapDump() com.ibm.jvm.Dump.SnapDump()","title":"Explanation"},{"location":"dcomibmenablelegacydumpsecurity/#see-also","text":"-Dcom.ibm.enableLegacyLogSecurity -Dcom.ibm.enableLegacyTraceSecurity","title":"See also"},{"location":"dcomibmenablelegacylogsecurity/","text":"-Dcom.ibm.enableLegacyLogSecurity To improve security, the security checks in the certain com.ibm.jvm.Log APIs are now enabled by default, when the SecurityManger is enabled. Use this system property to turn off security checking for these APIs. Syntax -Dcom.ibm.enableLegacyLogSecurity=[true|false] Setting Effect Default true Enable yes false Disable Explanation Security checking is enabled in the following APIs: com.ibm.jvm.Log.QueryOptions() com.ibm.jvm.Log.SetOptions(String) See also -Dcom.ibm.enableLegacyDumpSecurity -Dcom.ibm.enableLegacyTraceSecurity","title":"-Dcom.ibm.enableLegacyLogSecurity"},{"location":"dcomibmenablelegacylogsecurity/#-dcomibmenablelegacylogsecurity","text":"To improve security, the security checks in the certain com.ibm.jvm.Log APIs are now enabled by default, when the SecurityManger is enabled. Use this system property to turn off security checking for these APIs.","title":"-Dcom.ibm.enableLegacyLogSecurity"},{"location":"dcomibmenablelegacylogsecurity/#syntax","text":"-Dcom.ibm.enableLegacyLogSecurity=[true|false] Setting Effect Default true Enable yes false Disable","title":"Syntax"},{"location":"dcomibmenablelegacylogsecurity/#explanation","text":"Security checking is enabled in the following APIs: com.ibm.jvm.Log.QueryOptions() com.ibm.jvm.Log.SetOptions(String)","title":"Explanation"},{"location":"dcomibmenablelegacylogsecurity/#see-also","text":"-Dcom.ibm.enableLegacyDumpSecurity -Dcom.ibm.enableLegacyTraceSecurity","title":"See also"},{"location":"dcomibmenablelegacytracesecurity/","text":"-Dcom.ibm.enableLegacyTraceSecurity To improve security, the security checks in certain com.ibm.jvm.Trace APIs are now enabled by default, when the SecurityManger is enabled. Use this system property to turn off security checking for these APIs. Syntax -Dcom.ibm.enableLegacyTraceSecurity=[true|false] Setting Effect Default true Enable yes false Disable Explanation Security checking is enabled in the following APIs: com.ibm.jvm.Trace.set(String) com.ibm.jvm.Trace.snap() com.ibm.jvm.Trace.suspend() com.ibm.jvm.Trace.suspendThis() com.ibm.jvm.Trace.resume() com.ibm.jvm.Trace.resumeThis() com.ibm.jvm.Trace.registerApplication(String, String[]) See also -Dcom.ibm.enableLegacyDumpSecurity -Dcom.ibm.enableLegacyLogSecurity","title":"-Dcom.ibm.enableLegacyTraceSecurity"},{"location":"dcomibmenablelegacytracesecurity/#-dcomibmenablelegacytracesecurity","text":"To improve security, the security checks in certain com.ibm.jvm.Trace APIs are now enabled by default, when the SecurityManger is enabled. Use this system property to turn off security checking for these APIs.","title":"-Dcom.ibm.enableLegacyTraceSecurity"},{"location":"dcomibmenablelegacytracesecurity/#syntax","text":"-Dcom.ibm.enableLegacyTraceSecurity=[true|false] Setting Effect Default true Enable yes false Disable","title":"Syntax"},{"location":"dcomibmenablelegacytracesecurity/#explanation","text":"Security checking is enabled in the following APIs: com.ibm.jvm.Trace.set(String) com.ibm.jvm.Trace.snap() com.ibm.jvm.Trace.suspend() com.ibm.jvm.Trace.suspendThis() com.ibm.jvm.Trace.resume() com.ibm.jvm.Trace.resumeThis() com.ibm.jvm.Trace.registerApplication(String, String[])","title":"Explanation"},{"location":"dcomibmenablelegacytracesecurity/#see-also","text":"-Dcom.ibm.enableLegacyDumpSecurity -Dcom.ibm.enableLegacyLogSecurity","title":"See also"},{"location":"dcomibmgpudisable/","text":"-Dcom.ibm.gpu.disable Restriction: This system property is supported only on Java\u2122 11 and later If you have enabled GPU processing with -Dcom.ibm.gpu.enable , use this system property to turn off processing that can be offloaded to a graphics processing unit (GPU). Syntax -Dcom.ibm.gpu.disable Explanation Because establishing and completing communication with a GPU incurs an additional overhead, not all processing requirements benefit from being offloaded to the GPU. GPU processing is therefore disabled by default. However, if you have enabled GPU processing with -Dcom.ibm.gpu.enable , this property turns GPU processing off. See also Exploiting GPUs -Dcom.ibm.gpu.enable -Dcom.ibm.gpu.verbose","title":"-Dcom.ibm.gpu.disable"},{"location":"dcomibmgpudisable/#-dcomibmgpudisable","text":"Restriction: This system property is supported only on Java\u2122 11 and later If you have enabled GPU processing with -Dcom.ibm.gpu.enable , use this system property to turn off processing that can be offloaded to a graphics processing unit (GPU).","title":"-Dcom.ibm.gpu.disable"},{"location":"dcomibmgpudisable/#syntax","text":"-Dcom.ibm.gpu.disable","title":"Syntax"},{"location":"dcomibmgpudisable/#explanation","text":"Because establishing and completing communication with a GPU incurs an additional overhead, not all processing requirements benefit from being offloaded to the GPU. GPU processing is therefore disabled by default. However, if you have enabled GPU processing with -Dcom.ibm.gpu.enable , this property turns GPU processing off.","title":"Explanation"},{"location":"dcomibmgpudisable/#see-also","text":"Exploiting GPUs -Dcom.ibm.gpu.enable -Dcom.ibm.gpu.verbose","title":"See also"},{"location":"dcomibmgpuenable/","text":"-Dcom.ibm.gpu.enable Restriction: This system property is supported only on Java\u2122 11 and later Use this system property to control the type of processing that can be offloaded to a graphics processing unit (GPU) when processing requirements meet a specific threshold. This feature can improve the performance of certain Java functions. Syntax -Dcom.ibm.gpu.enable=[all|sort] Setting Effect all Turns on GPU processing for all possible Java functions. sort Turns on GPU processing only for the Java sort() function. By default, this property is not set. Explanation Because establishing and completing communication with a GPU incurs an additional overhead, not all processing requirements benefit from being offloaded to the GPU. When set, this property enables GPU processing for any array that meets a minimum size. See also Exploiting GPUs -Dcom.ibm.gpu.disable -Dcom.ibm.gpu.verbose","title":"-Dcom.ibm.gpu.enable"},{"location":"dcomibmgpuenable/#-dcomibmgpuenable","text":"Restriction: This system property is supported only on Java\u2122 11 and later Use this system property to control the type of processing that can be offloaded to a graphics processing unit (GPU) when processing requirements meet a specific threshold. This feature can improve the performance of certain Java functions.","title":"-Dcom.ibm.gpu.enable"},{"location":"dcomibmgpuenable/#syntax","text":"-Dcom.ibm.gpu.enable=[all|sort] Setting Effect all Turns on GPU processing for all possible Java functions. sort Turns on GPU processing only for the Java sort() function. By default, this property is not set.","title":"Syntax"},{"location":"dcomibmgpuenable/#explanation","text":"Because establishing and completing communication with a GPU incurs an additional overhead, not all processing requirements benefit from being offloaded to the GPU. When set, this property enables GPU processing for any array that meets a minimum size.","title":"Explanation"},{"location":"dcomibmgpuenable/#see-also","text":"Exploiting GPUs -Dcom.ibm.gpu.disable -Dcom.ibm.gpu.verbose","title":"See also"},{"location":"dcomibmgpuverbose/","text":"-Dcom.ibm.gpu.verbose Restriction: This system property is supported only on Java\u2122 11 and later This system property can be used to help identify problems with graphics processing unit (GPU) processing. Syntax -Dcom.ibm.gpu.verbose This property is not set by default. Explanation When specified, this option generates verbose output to STDOUT, which can be piped to a file. See also Exploiting GPUs -Dcom.ibm.gpu.disable -Dcom.ibm.gpu.enable","title":"-Dcom.ibm.gpu.verbose"},{"location":"dcomibmgpuverbose/#-dcomibmgpuverbose","text":"Restriction: This system property is supported only on Java\u2122 11 and later This system property can be used to help identify problems with graphics processing unit (GPU) processing.","title":"-Dcom.ibm.gpu.verbose"},{"location":"dcomibmgpuverbose/#syntax","text":"-Dcom.ibm.gpu.verbose This property is not set by default.","title":"Syntax"},{"location":"dcomibmgpuverbose/#explanation","text":"When specified, this option generates verbose output to STDOUT, which can be piped to a file.","title":"Explanation"},{"location":"dcomibmgpuverbose/#see-also","text":"Exploiting GPUs -Dcom.ibm.gpu.disable -Dcom.ibm.gpu.enable","title":"See also"},{"location":"dcomibmlangmanagementosmxbeaniscputime100ns/","text":"-Dcom.ibm.lang.management. OperatingSystemMXBean.isCpuTime100ns Changes the unit of the return value of the OperatingSystemMXBean.getProcessCpuTime() method. Syntax -Dcom.ibm.lang.management.OperatingSystemMXBean.isCpuTime100ns=[true|false] Setting Effect Default true Enable false Disable yes Explanation The Oracle java.lang.management package includes MBean categories such as Memory , OperatingSystem , and GarbageCollector . The OpenJ9 VM provides additional MXBeans to extend the monitoring and management capabilities. For example, the OperatingSystemMXBean , which monitors operating system settings such as physical and virtual memory size, processor capacity, and processor utilization. The OperatingSystemMXBean.getProcessCpuTime() method returns a value in nanoseconds (10 -9 s), for compatibility with the com.sun.management.OperatingSystemMXBean and UnixOperatingSystemMXBean interfaces. In earlier VM releases, the return value was in hundreds of nanoseconds. If you want to revert to this behavior, set the -Dcom.ibm.lang.management.OperatingSystemMXBean.isCpuTime100ns property to true . The default value for this property is false . See also Monitoring and management API documentation","title":"-Dcom.ibm.lang.management.OperatingSystemMXBean.isCpuTime100ns"},{"location":"dcomibmlangmanagementosmxbeaniscputime100ns/#-dcomibmlangmanagementoperatingsystemmxbeaniscputime100ns","text":"Changes the unit of the return value of the OperatingSystemMXBean.getProcessCpuTime() method.","title":"-Dcom.ibm.lang.management.OperatingSystemMXBean.isCpuTime100ns"},{"location":"dcomibmlangmanagementosmxbeaniscputime100ns/#syntax","text":"-Dcom.ibm.lang.management.OperatingSystemMXBean.isCpuTime100ns=[true|false] Setting Effect Default true Enable false Disable yes","title":"Syntax"},{"location":"dcomibmlangmanagementosmxbeaniscputime100ns/#explanation","text":"The Oracle java.lang.management package includes MBean categories such as Memory , OperatingSystem , and GarbageCollector . The OpenJ9 VM provides additional MXBeans to extend the monitoring and management capabilities. For example, the OperatingSystemMXBean , which monitors operating system settings such as physical and virtual memory size, processor capacity, and processor utilization. The OperatingSystemMXBean.getProcessCpuTime() method returns a value in nanoseconds (10 -9 s), for compatibility with the com.sun.management.OperatingSystemMXBean and UnixOperatingSystemMXBean interfaces. In earlier VM releases, the return value was in hundreds of nanoseconds. If you want to revert to this behavior, set the -Dcom.ibm.lang.management.OperatingSystemMXBean.isCpuTime100ns property to true . The default value for this property is false .","title":"Explanation"},{"location":"dcomibmlangmanagementosmxbeaniscputime100ns/#see-also","text":"Monitoring and management API documentation","title":"See also"},{"location":"dcomibmlangmanagementverbose/","text":"-Dcom.ibm.lang.management.verbose Enables verbose information from java.lang.management operations to be written to the output channel during VM operations. Syntax -Dcom.ibm.lang.management.verbose There are no options for this system property.","title":"-Dcom.ibm.lang.management.verbose"},{"location":"dcomibmlangmanagementverbose/#-dcomibmlangmanagementverbose","text":"Enables verbose information from java.lang.management operations to be written to the output channel during VM operations.","title":"-Dcom.ibm.lang.management.verbose"},{"location":"dcomibmlangmanagementverbose/#syntax","text":"-Dcom.ibm.lang.management.verbose There are no options for this system property.","title":"Syntax"},{"location":"dcomibmotisharedsharedclassglobalfilterclass/","text":"-Dcom.ibm.oti.shared.SharedClassGlobalFilterClass This system property applies a global filter to all non-bootstrap class loaders that share classes. Syntax -Dcom.ibm.oti.shared.SharedClassGlobalFilterClass=<filter_class_name> This property is not set by default. Explanation A filter can be used to decide which classes are found and stored by a custom class loader in a shared classes cache. The filter is applied to a particular package by implementing the SharedClassFilter interface. See also The Java shared classes Helper API Shared classes Helper API package: com.ibm.oti.shared","title":"-Dcom.ibm.oti.shared.SharedClassGlobalFilterClass"},{"location":"dcomibmotisharedsharedclassglobalfilterclass/#-dcomibmotisharedsharedclassglobalfilterclass","text":"This system property applies a global filter to all non-bootstrap class loaders that share classes.","title":"-Dcom.ibm.oti.shared.SharedClassGlobalFilterClass"},{"location":"dcomibmotisharedsharedclassglobalfilterclass/#syntax","text":"-Dcom.ibm.oti.shared.SharedClassGlobalFilterClass=<filter_class_name> This property is not set by default.","title":"Syntax"},{"location":"dcomibmotisharedsharedclassglobalfilterclass/#explanation","text":"A filter can be used to decide which classes are found and stored by a custom class loader in a shared classes cache. The filter is applied to a particular package by implementing the SharedClassFilter interface.","title":"Explanation"},{"location":"dcomibmotisharedsharedclassglobalfilterclass/#see-also","text":"The Java shared classes Helper API Shared classes Helper API package: com.ibm.oti.shared","title":"See also"},{"location":"dcomibmtoolsattachcommand_timeout/","text":"-Dcom.ibm.tools.attach.command_timeout Specify the timeout for sending a command to the target VM after the initial attachment. Syntax -Dcom.ibm.tools.attach.command_timeout=<ms> Setting Value Default <ms> [1 millisecond or greater] 0 milliseconds (no timeout) See also Java\u2122 Attach API -Dcom.ibm.tools.attach.directory -Dcom.ibm.tools.attach.displayName -Dcom.ibm.tools.attach.enable -Dcom.ibm.tools.attach.id -Dcom.ibm.tools.attach.logging -Dcom.ibm.tools.attach.log.name -Dcom.ibm.tools.attach.shutdown_timeout -Dcom.ibm.tools.attach.timeout","title":"-Dcom.ibm.tools.attach.command_timeout"},{"location":"dcomibmtoolsattachcommand_timeout/#-dcomibmtoolsattachcommand_timeout","text":"Specify the timeout for sending a command to the target VM after the initial attachment.","title":"-Dcom.ibm.tools.attach.command_timeout"},{"location":"dcomibmtoolsattachcommand_timeout/#syntax","text":"-Dcom.ibm.tools.attach.command_timeout=<ms> Setting Value Default <ms> [1 millisecond or greater] 0 milliseconds (no timeout)","title":"Syntax"},{"location":"dcomibmtoolsattachcommand_timeout/#see-also","text":"Java\u2122 Attach API -Dcom.ibm.tools.attach.directory -Dcom.ibm.tools.attach.displayName -Dcom.ibm.tools.attach.enable -Dcom.ibm.tools.attach.id -Dcom.ibm.tools.attach.logging -Dcom.ibm.tools.attach.log.name -Dcom.ibm.tools.attach.shutdown_timeout -Dcom.ibm.tools.attach.timeout","title":"See also"},{"location":"dcomibmtoolsattachdirectory/","text":"-Dcom.ibm.tools.attach.directory Specify a different common directory for Attach API working files. Syntax -Dcom.ibm.tools.attach.directory=<directory_name> Setting Value Default <directory_name> [string] .com_ibm_tools_attach To change the value for directory_name , specify a different directory name. If the directory does not exist, it is created. However, if a parent directory is specified, it must exist. The common directory must be on a local drive, not a network drive. See also Java\u2122 Attach API -Dcom.ibm.tools.attach.command_timeout -Dcom.ibm.tools.attach.displayName -Dcom.ibm.tools.attach.enable -Dcom.ibm.tools.attach.id -Dcom.ibm.tools.attach.logging -Dcom.ibm.tools.attach.log.name -Dcom.ibm.tools.attach.shutdown_timeout -Dcom.ibm.tools.attach.timeout","title":"-Dcom.ibm.tools.attach.directory"},{"location":"dcomibmtoolsattachdirectory/#-dcomibmtoolsattachdirectory","text":"Specify a different common directory for Attach API working files.","title":"-Dcom.ibm.tools.attach.directory"},{"location":"dcomibmtoolsattachdirectory/#syntax","text":"-Dcom.ibm.tools.attach.directory=<directory_name> Setting Value Default <directory_name> [string] .com_ibm_tools_attach To change the value for directory_name , specify a different directory name. If the directory does not exist, it is created. However, if a parent directory is specified, it must exist. The common directory must be on a local drive, not a network drive.","title":"Syntax"},{"location":"dcomibmtoolsattachdirectory/#see-also","text":"Java\u2122 Attach API -Dcom.ibm.tools.attach.command_timeout -Dcom.ibm.tools.attach.displayName -Dcom.ibm.tools.attach.enable -Dcom.ibm.tools.attach.id -Dcom.ibm.tools.attach.logging -Dcom.ibm.tools.attach.log.name -Dcom.ibm.tools.attach.shutdown_timeout -Dcom.ibm.tools.attach.timeout","title":"See also"},{"location":"dcomibmtoolsattachdisplayname/","text":"-Dcom.ibm.tools.attach.displayName Change the default display name for the target virtual machine. Syntax -Dcom.ibm.tools.attach.displayName=<my_display_name> Setting Value Default <my_display_name> [string] The command line invocation used to start the application To change the value for <my_display_name> that is recorded by an agent, enter a character string of your choice. See also Java\u2122 Attach API -Dcom.ibm.tools.attach.command_timeout -Dcom.ibm.tools.attach.directory -Dcom.ibm.tools.attach.enable -Dcom.ibm.tools.attach.id -Dcom.ibm.tools.attach.logging -Dcom.ibm.tools.attach.log.name -Dcom.ibm.tools.attach.shutdown_timeout -Dcom.ibm.tools.attach.timeout","title":"-Dcom.ibm.tools.attach.displayName"},{"location":"dcomibmtoolsattachdisplayname/#-dcomibmtoolsattachdisplayname","text":"Change the default display name for the target virtual machine.","title":"-Dcom.ibm.tools.attach.displayName"},{"location":"dcomibmtoolsattachdisplayname/#syntax","text":"-Dcom.ibm.tools.attach.displayName=<my_display_name> Setting Value Default <my_display_name> [string] The command line invocation used to start the application To change the value for <my_display_name> that is recorded by an agent, enter a character string of your choice.","title":"Syntax"},{"location":"dcomibmtoolsattachdisplayname/#see-also","text":"Java\u2122 Attach API -Dcom.ibm.tools.attach.command_timeout -Dcom.ibm.tools.attach.directory -Dcom.ibm.tools.attach.enable -Dcom.ibm.tools.attach.id -Dcom.ibm.tools.attach.logging -Dcom.ibm.tools.attach.log.name -Dcom.ibm.tools.attach.shutdown_timeout -Dcom.ibm.tools.attach.timeout","title":"See also"},{"location":"dcomibmtoolsattachenable/","text":"-Dcom.ibm.tools.attach.enable Enable the Attach API for this application. Syntax -Dcom.ibm.tools.attach.enable=[yes|no] On AIX\u00ae, Linux\u00ae, macOS\u00ae, and Windows\u2122 systems, the following default applies: Value Effect Default yes Enable yes no Disable On z/OS\u00ae systems, the following default applies: Value Effect Default yes Enable no Disable yes Explanation A useful reference for information about the Java\u2122 Attach API can be found at http://docs.oracle.com/javase/8/docs/technotes/guides/attach/index.html . The following extract is taken from the Oracle documentation: The Attach API is an extension that provides a mechanism to attach to a Java virtual machine. A tool written in the Java Language, uses this API to attach to a target virtual machine and load its tool agent into that virtual machine. A usage example is to late attach the IBM\u00ae Health Center agent to a virtual machine (VM) that is already running. The OpenJ9 implementation of the Attach API is equivalent to the Oracle implementation. However, the OpenJ9 implementation cannot be used to attach to, or accept attach requests from, other VM implementations. See also Java\u2122 Attach API -Dcom.ibm.tools.attach.command_timeout -Dcom.ibm.tools.attach.directory -Dcom.ibm.tools.attach.displayName -Dcom.ibm.tools.attach.id -Dcom.ibm.tools.attach.logging -Dcom.ibm.tools.attach.log.name -Dcom.ibm.tools.attach.shutdown_timeout -Dcom.ibm.tools.attach.timeout","title":"-Dcom.ibm.tools.attach.enable"},{"location":"dcomibmtoolsattachenable/#-dcomibmtoolsattachenable","text":"Enable the Attach API for this application.","title":"-Dcom.ibm.tools.attach.enable"},{"location":"dcomibmtoolsattachenable/#syntax","text":"-Dcom.ibm.tools.attach.enable=[yes|no] On AIX\u00ae, Linux\u00ae, macOS\u00ae, and Windows\u2122 systems, the following default applies: Value Effect Default yes Enable yes no Disable On z/OS\u00ae systems, the following default applies: Value Effect Default yes Enable no Disable yes","title":"Syntax"},{"location":"dcomibmtoolsattachenable/#explanation","text":"A useful reference for information about the Java\u2122 Attach API can be found at http://docs.oracle.com/javase/8/docs/technotes/guides/attach/index.html . The following extract is taken from the Oracle documentation: The Attach API is an extension that provides a mechanism to attach to a Java virtual machine. A tool written in the Java Language, uses this API to attach to a target virtual machine and load its tool agent into that virtual machine. A usage example is to late attach the IBM\u00ae Health Center agent to a virtual machine (VM) that is already running. The OpenJ9 implementation of the Attach API is equivalent to the Oracle implementation. However, the OpenJ9 implementation cannot be used to attach to, or accept attach requests from, other VM implementations.","title":"Explanation"},{"location":"dcomibmtoolsattachenable/#see-also","text":"Java\u2122 Attach API -Dcom.ibm.tools.attach.command_timeout -Dcom.ibm.tools.attach.directory -Dcom.ibm.tools.attach.displayName -Dcom.ibm.tools.attach.id -Dcom.ibm.tools.attach.logging -Dcom.ibm.tools.attach.log.name -Dcom.ibm.tools.attach.shutdown_timeout -Dcom.ibm.tools.attach.timeout","title":"See also"},{"location":"dcomibmtoolsattachid/","text":"-Dcom.ibm.tools.attach.id Specify a different virtual machine (VM) identifier. Syntax -Dcom.ibm.tools.attach.id=<my_vm_ID> Setting Value Default <my_vm_ID> [string] Target VM process ID To change the VM identifier recorded by an agent, change the value for <my_vm_ID> . The string must start with an alphabetic character. The remaining characters must be alphanumeric or underscore. Case-sensitivity is system dependent. If the VM identifier is already in use, the attach API modifies it to create a unique value. See also Java\u2122 Attach API -Dcom.ibm.tools.attach.command_timeout -Dcom.ibm.tools.attach.directory -Dcom.ibm.tools.attach.displayName -Dcom.ibm.tools.attach.enable -Dcom.ibm.tools.attach.logging -Dcom.ibm.tools.attach.log.name -Dcom.ibm.tools.attach.shutdown_timeout -Dcom.ibm.tools.attach.timeout","title":"-Dcom.ibm.tools.attach.id"},{"location":"dcomibmtoolsattachid/#-dcomibmtoolsattachid","text":"Specify a different virtual machine (VM) identifier.","title":"-Dcom.ibm.tools.attach.id"},{"location":"dcomibmtoolsattachid/#syntax","text":"-Dcom.ibm.tools.attach.id=<my_vm_ID> Setting Value Default <my_vm_ID> [string] Target VM process ID To change the VM identifier recorded by an agent, change the value for <my_vm_ID> . The string must start with an alphabetic character. The remaining characters must be alphanumeric or underscore. Case-sensitivity is system dependent. If the VM identifier is already in use, the attach API modifies it to create a unique value.","title":"Syntax"},{"location":"dcomibmtoolsattachid/#see-also","text":"Java\u2122 Attach API -Dcom.ibm.tools.attach.command_timeout -Dcom.ibm.tools.attach.directory -Dcom.ibm.tools.attach.displayName -Dcom.ibm.tools.attach.enable -Dcom.ibm.tools.attach.logging -Dcom.ibm.tools.attach.log.name -Dcom.ibm.tools.attach.shutdown_timeout -Dcom.ibm.tools.attach.timeout","title":"See also"},{"location":"dcomibmtoolsattachlogging/","text":"-Dcom.ibm.tools.attach.logging Enable logging for Attach API events. Syntax -Dcom.ibm.tools.attach.logging=[yes|no] Value Effect Default yes Enable no Disable yes Explanation Turn on tracing and logging of Attach API events to help diagnose problems. One timestamped log file is created for each Java process in the current directory for the running JVM . See also Java Attach API -Dcom.ibm.tools.attach.command_timeout -Dcom.ibm.tools.attach.directory -Dcom.ibm.tools.attach.displayName -Dcom.ibm.tools.attach.enable -Dcom.ibm.tools.attach.id -Dcom.ibm.tools.attach.log.name -Dcom.ibm.tools.attach.shutdown_timeout -Dcom.ibm.tools.attach.timeout","title":"-Dcom.ibm.tools.attach.logging"},{"location":"dcomibmtoolsattachlogging/#-dcomibmtoolsattachlogging","text":"Enable logging for Attach API events.","title":"-Dcom.ibm.tools.attach.logging"},{"location":"dcomibmtoolsattachlogging/#syntax","text":"-Dcom.ibm.tools.attach.logging=[yes|no] Value Effect Default yes Enable no Disable yes","title":"Syntax"},{"location":"dcomibmtoolsattachlogging/#explanation","text":"Turn on tracing and logging of Attach API events to help diagnose problems. One timestamped log file is created for each Java process in the current directory for the running JVM .","title":"Explanation"},{"location":"dcomibmtoolsattachlogging/#see-also","text":"Java Attach API -Dcom.ibm.tools.attach.command_timeout -Dcom.ibm.tools.attach.directory -Dcom.ibm.tools.attach.displayName -Dcom.ibm.tools.attach.enable -Dcom.ibm.tools.attach.id -Dcom.ibm.tools.attach.log.name -Dcom.ibm.tools.attach.shutdown_timeout -Dcom.ibm.tools.attach.timeout","title":"See also"},{"location":"dcomibmtoolsattachlogname/","text":"-Dcom.ibm.tools.attach.log.name Specify the path and prefix for the log files. Syntax -Dcom.ibm.tools.attach.log.name=<path/prefix> Setting Value Default <path/prefix> [string] VM process directory By default, when -Dcom.ibm.tools.attach.logging=true is set, timestamped log files are written to the current directory for the running VM. Use the -Dcom.ibm.tools.attach.log.name option to change the path and prefix for the logfiles. See also Java\u2122 Attach API -Dcom.ibm.tools.attach.command_timeout -Dcom.ibm.tools.attach.directory -Dcom.ibm.tools.attach.displayName -Dcom.ibm.tools.attach.enable -Dcom.ibm.tools.attach.id -Dcom.ibm.tools.attach.logging -Dcom.ibm.tools.attach.shutdown_timeout -Dcom.ibm.tools.attach.timeout","title":"-Dcom.ibm.tools.attach.log.name"},{"location":"dcomibmtoolsattachlogname/#-dcomibmtoolsattachlogname","text":"Specify the path and prefix for the log files.","title":"-Dcom.ibm.tools.attach.log.name"},{"location":"dcomibmtoolsattachlogname/#syntax","text":"-Dcom.ibm.tools.attach.log.name=<path/prefix> Setting Value Default <path/prefix> [string] VM process directory By default, when -Dcom.ibm.tools.attach.logging=true is set, timestamped log files are written to the current directory for the running VM. Use the -Dcom.ibm.tools.attach.log.name option to change the path and prefix for the logfiles.","title":"Syntax"},{"location":"dcomibmtoolsattachlogname/#see-also","text":"Java\u2122 Attach API -Dcom.ibm.tools.attach.command_timeout -Dcom.ibm.tools.attach.directory -Dcom.ibm.tools.attach.displayName -Dcom.ibm.tools.attach.enable -Dcom.ibm.tools.attach.id -Dcom.ibm.tools.attach.logging -Dcom.ibm.tools.attach.shutdown_timeout -Dcom.ibm.tools.attach.timeout","title":"See also"},{"location":"dcomibmtoolsattachshutdown_timeout/","text":"-Dcom.ibm.tools.attach.shutdown_timeout Specify a timeout before ending the Attach API wait loop thread. Syntax -Dcom.ibm.tools.attach.shutdown_timeout=<ms> Setting Value Default <ms> [1 millisecond or greater] 10000 milliseconds (10 seconds) See also Java\u2122 Attach API -Dcom.ibm.tools.attach.command_timeout -Dcom.ibm.tools.attach.directory -Dcom.ibm.tools.attach.displayName -Dcom.ibm.tools.attach.enable -Dcom.ibm.tools.attach.id -Dcom.ibm.tools.attach.logging -Dcom.ibm.tools.attach.log.name -Dcom.ibm.tools.attach.timeout","title":"-Dcom.ibm.tools.attach.shutdown_timeout"},{"location":"dcomibmtoolsattachshutdown_timeout/#-dcomibmtoolsattachshutdown_timeout","text":"Specify a timeout before ending the Attach API wait loop thread.","title":"-Dcom.ibm.tools.attach.shutdown_timeout"},{"location":"dcomibmtoolsattachshutdown_timeout/#syntax","text":"-Dcom.ibm.tools.attach.shutdown_timeout=<ms> Setting Value Default <ms> [1 millisecond or greater] 10000 milliseconds (10 seconds)","title":"Syntax"},{"location":"dcomibmtoolsattachshutdown_timeout/#see-also","text":"Java\u2122 Attach API -Dcom.ibm.tools.attach.command_timeout -Dcom.ibm.tools.attach.directory -Dcom.ibm.tools.attach.displayName -Dcom.ibm.tools.attach.enable -Dcom.ibm.tools.attach.id -Dcom.ibm.tools.attach.logging -Dcom.ibm.tools.attach.log.name -Dcom.ibm.tools.attach.timeout","title":"See also"},{"location":"dcomibmtoolsattachtimeout/","text":"-Dcom.ibm.tools.attach.timeout Specify a time that an application should wait when attempting to connect to a target virtual machine (VM) before ending. Syntax -Dcom.ibm.tools.attach.timeout=<ms> Setting Value Default <ms> [501 milliseconds or greater] 120000 milliseconds (120 seconds) If you specify a value of 500 milliseconds or lower, no connection attempt is made. Example To timeout after 60 seconds, specify: -Dcom.ibm.tools.attach.timeout=60000 See also Java\u2122 Attach API -Dcom.ibm.tools.attach.command_timeout -Dcom.ibm.tools.attach.directory -Dcom.ibm.tools.attach.displayName -Dcom.ibm.tools.attach.enable -Dcom.ibm.tools.attach.id -Dcom.ibm.tools.attach.logging -Dcom.ibm.tools.attach.log.name -Dcom.ibm.tools.attach.shutdown_timeout","title":"-Dcom.ibm.tools.attach.timeout"},{"location":"dcomibmtoolsattachtimeout/#-dcomibmtoolsattachtimeout","text":"Specify a time that an application should wait when attempting to connect to a target virtual machine (VM) before ending.","title":"-Dcom.ibm.tools.attach.timeout"},{"location":"dcomibmtoolsattachtimeout/#syntax","text":"-Dcom.ibm.tools.attach.timeout=<ms> Setting Value Default <ms> [501 milliseconds or greater] 120000 milliseconds (120 seconds) If you specify a value of 500 milliseconds or lower, no connection attempt is made.","title":"Syntax"},{"location":"dcomibmtoolsattachtimeout/#example","text":"To timeout after 60 seconds, specify: -Dcom.ibm.tools.attach.timeout=60000","title":"Example"},{"location":"dcomibmtoolsattachtimeout/#see-also","text":"Java\u2122 Attach API -Dcom.ibm.tools.attach.command_timeout -Dcom.ibm.tools.attach.directory -Dcom.ibm.tools.attach.displayName -Dcom.ibm.tools.attach.enable -Dcom.ibm.tools.attach.id -Dcom.ibm.tools.attach.logging -Dcom.ibm.tools.attach.log.name -Dcom.ibm.tools.attach.shutdown_timeout","title":"See also"},{"location":"dfileencoding/","text":"-Dfile.encoding Use this OpenJDK property to define the file encoding that is required. Syntax -Dfile.encoding=<value> Setting Value Default <value> [string] Unicode 3.0 standards where <value> defines the file encoding that is required. Explanation By default the GBK converter follows Unicode 3.0 standards. To force the GBK converter to follow Unicode 2.0 standards, use a value of bestfit936 .","title":"-Dfile.encoding"},{"location":"dfileencoding/#-dfileencoding","text":"Use this OpenJDK property to define the file encoding that is required.","title":"-Dfile.encoding"},{"location":"dfileencoding/#syntax","text":"-Dfile.encoding=<value> Setting Value Default <value> [string] Unicode 3.0 standards where <value> defines the file encoding that is required.","title":"Syntax"},{"location":"dfileencoding/#explanation","text":"By default the GBK converter follows Unicode 3.0 standards. To force the GBK converter to follow Unicode 2.0 standards, use a value of bestfit936 .","title":"Explanation"},{"location":"diag_overview/","text":"Diagnostic data and tooling OpenJ9 contains a broad range of diagnostic capabilities to help identify, isolate, and solve run time problems. These capabilities include dump files, verbose logs, and trace files, which are supported by a variety of diagnostic tools and interfaces. Dumps Various types of dumps are produced by default in response to certain events, such as a GPF fault or an OutOfMemoryError exception. You can also trigger the production of dumps by using the com.ibm.jvm.Dump API or by specifying -Xdump options on the command line. All dumps are produced by dump agents, which are initialized when the OpenJ9 VM starts. Different dumps target different areas of the runtime environment. If you want to generate a dump to diagnose a particular type of problem, you need to understand what data the dump will provide. The following dumps are typically used for problem diagnosis: Java dumps ( -Xdump:java ) contain information that relates to the OpenJ9 VM and the Java\u2122 application, such as the operating environment, locks, threads, hooks, shared classes, and class loaders. Heap dumps ( -Xdump:heap ) show the content of the Java heap. System dumps ( -Xdump:system ) contain a raw process image or address space of an application. Other types of dump include binary JIT dumps, stack dumps, and snap dumps. For a complete list of dump agents and the diagnostic data they produce, see Dump agents . Verbose log files Some components of OpenJ9 can also produce verbose output or log files to assist with problem determination. Class data sharing provides a number of -Xshareclasses suboptions to provide detailed data about the content of a shared classes cache, cache I/O activity, and information about the Java Helper API (where used). For example, the -Xshareclasses:printAllStats suboption lists every class in chronological order with a reference to the location from which it was loaded. For more information, see -Xshareclasses . Garbage collection operations can be analyzed by producing verbose output from the -verbose:gc standard option. This output can be redirected to a file by specifying the -Xverbosegclog option. Information can be obtained about GC initialization, stop-the-world processing, finalization, reference processing, and allocation failures. Even more granular information can be obtained with the -Xtgc option. For more information, see verbose GC logs . The JIT compiler provides verbose logging, which records all compiler operations. To find out how to enable logging, read the JIT troubleshooting content. Class loader operations can be analyzed by producing verbose output from the -verbose:dynload standard option, which shows detailed information as each class is loaded by the VM. Trace files The OpenJ9 trace facility can be used to trace applications, Java methods, or internal JVM operations with minimal impact on performance. Trace is configured by using the -Xtrace command line option, which allows you to control what is traced and when. Trace data is produced in binary format and must be processed by the OpenJ9 trace formatter to convert it to a readable form. For more information, see Trace formatter . Diagnostic tools A number of diagnostic tools are available with OpenJ9 to assist with the analysis of dump and trace files. Dump extractor The dump extractor ( jpackcore ) supports a full analysis of core files on specific platforms by collecting key files from a system and packaging them into an archive along with a core dump. This archive file is extremely useful when reporting issues to the OpenJ9 community, helping to ensure a faster analysis and turnaround. For more information, see Dump extractor . Dump viewer Because system dumps are binary files, OpenJ9 provides a dump viewer tool ( jdmpview ) to analyze the contents. This tool can work with dumps from any platforms independently of a system debugger. For more information, see Dump viewer . Trace formatter The trace formatter tool converts binary trace point data in a trace file into a readable format for analysis. For more information, see Trace formatter . Option builder OpenJ9 contains an extensive set of command-line options to assist with problem diagnosis. Certain options are complex, containing many sub-options with numerous parameters. Whilst these offer a great degree of flexibility, the syntax can be difficult to construct. Option builder tools are available that provide a simple graphical user interface to help you construct your command-line argument. For more information, see Option builder . HotSpot-compatible tools A number of tools are available for compatibility with the reference implementation. These tools are independently implemented by OpenJ9 but have similar functions, allowing users to migrate more easily. The available tools are listed in the Tools section. Note: If you are already familiar with tools that are provided with HotSpot, see Switching to OpenJ9 , which explains some of the differences you might encounter when using OpenJ9. Eclipse marketplace tools OpenJ9 provides support for a number of monitoring and diagnostic tools that can be found in the Eclipse marketplace . Each tool provides a graphical user interface to help you visualize data and, in some cases, can provide tuning or debugging recommendations. Health Center: Provides real-time monitoring of running applications with minimal overhead over the network. You can monitor a whole range of operations including, class loading, CPU usage, GC heap and pause times, I/O activity, lock contention, method trace, native memory usage, profiling, and live threads. For more information, read the Health Center documentation . Garbage Collection Memory Vizualizer (GCMV): Plots GC and native memory data over time. You can view and save data as a report, raw log, tabulated data, or in graphical format. The tool helps to diagnose problems such as memory leaks with data presented in various visual formats for analysis. Tuning recommendations are also provided. For more information, read the GCMV documentation . Memory Analyzer: Examines the Java object heap to help find memory leaks or reduce memory consumption. Support is available for OpenJ9 via the DTFJ interface (Install from the Eclipse Help menu; Install New Software > Work with \"IBM Diagnostic Tool Framework for Java\" > IBM Monitoring and Diagnostic Tools > Diagnostic Tool Framework for Java). More information about Eclipse MAT can be found on the project website page . If you are familiar with using HotSpot as part of an Oracle JDK or OpenJDK, the Java VisualVM utility is functionally similar to Health Center. Interfaces JVM tool interface (JVMTI) OpenJ9 supports the Java Virtual Machine Tool Interface (JVMTI) and provides extensions that allow JVMTI tools to obtain diagnostic information or trigger diagnostic operations in the VM. For more information, see Java Virtual Machine Tool Interface . DTFJ Interface OpenJ9 includes the Diagnostic Tool Framework for Java (DTFJ) API. Custom applications can be written that use this API to access a wide range of information in a system dump or a Java dump. DTFJ can be used with the Eclipse Memory Analyzer Toolkit (MAT) to examine the Java object heap for memory leaks and to reduce memory consumption. For more information, see Diagnostic Tool Framework for Java . Language Management interface OpenJ9 provides MXBean additions and extensions to the standard java.lang.management API, which enables you to use tools such as JConsole to monitor and manage your Java applications. For more information, see Language management interface . JPDA tools OpenJ9 is compliant with the Java Platform Debugging Architecture (JPDA), which means you can use any JPDA tool for diagnosis, including Eclipse JDT Debug .","title":"Overview"},{"location":"diag_overview/#diagnostic-data-and-tooling","text":"OpenJ9 contains a broad range of diagnostic capabilities to help identify, isolate, and solve run time problems. These capabilities include dump files, verbose logs, and trace files, which are supported by a variety of diagnostic tools and interfaces.","title":"Diagnostic data and tooling"},{"location":"diag_overview/#dumps","text":"Various types of dumps are produced by default in response to certain events, such as a GPF fault or an OutOfMemoryError exception. You can also trigger the production of dumps by using the com.ibm.jvm.Dump API or by specifying -Xdump options on the command line. All dumps are produced by dump agents, which are initialized when the OpenJ9 VM starts. Different dumps target different areas of the runtime environment. If you want to generate a dump to diagnose a particular type of problem, you need to understand what data the dump will provide. The following dumps are typically used for problem diagnosis: Java dumps ( -Xdump:java ) contain information that relates to the OpenJ9 VM and the Java\u2122 application, such as the operating environment, locks, threads, hooks, shared classes, and class loaders. Heap dumps ( -Xdump:heap ) show the content of the Java heap. System dumps ( -Xdump:system ) contain a raw process image or address space of an application. Other types of dump include binary JIT dumps, stack dumps, and snap dumps. For a complete list of dump agents and the diagnostic data they produce, see Dump agents .","title":"Dumps"},{"location":"diag_overview/#verbose-log-files","text":"Some components of OpenJ9 can also produce verbose output or log files to assist with problem determination. Class data sharing provides a number of -Xshareclasses suboptions to provide detailed data about the content of a shared classes cache, cache I/O activity, and information about the Java Helper API (where used). For example, the -Xshareclasses:printAllStats suboption lists every class in chronological order with a reference to the location from which it was loaded. For more information, see -Xshareclasses . Garbage collection operations can be analyzed by producing verbose output from the -verbose:gc standard option. This output can be redirected to a file by specifying the -Xverbosegclog option. Information can be obtained about GC initialization, stop-the-world processing, finalization, reference processing, and allocation failures. Even more granular information can be obtained with the -Xtgc option. For more information, see verbose GC logs . The JIT compiler provides verbose logging, which records all compiler operations. To find out how to enable logging, read the JIT troubleshooting content. Class loader operations can be analyzed by producing verbose output from the -verbose:dynload standard option, which shows detailed information as each class is loaded by the VM.","title":"Verbose log files"},{"location":"diag_overview/#trace-files","text":"The OpenJ9 trace facility can be used to trace applications, Java methods, or internal JVM operations with minimal impact on performance. Trace is configured by using the -Xtrace command line option, which allows you to control what is traced and when. Trace data is produced in binary format and must be processed by the OpenJ9 trace formatter to convert it to a readable form. For more information, see Trace formatter .","title":"Trace files"},{"location":"diag_overview/#diagnostic-tools","text":"A number of diagnostic tools are available with OpenJ9 to assist with the analysis of dump and trace files.","title":"Diagnostic tools"},{"location":"diag_overview/#dump-extractor","text":"The dump extractor ( jpackcore ) supports a full analysis of core files on specific platforms by collecting key files from a system and packaging them into an archive along with a core dump. This archive file is extremely useful when reporting issues to the OpenJ9 community, helping to ensure a faster analysis and turnaround. For more information, see Dump extractor .","title":"Dump extractor"},{"location":"diag_overview/#dump-viewer","text":"Because system dumps are binary files, OpenJ9 provides a dump viewer tool ( jdmpview ) to analyze the contents. This tool can work with dumps from any platforms independently of a system debugger. For more information, see Dump viewer .","title":"Dump viewer"},{"location":"diag_overview/#trace-formatter","text":"The trace formatter tool converts binary trace point data in a trace file into a readable format for analysis. For more information, see Trace formatter .","title":"Trace formatter"},{"location":"diag_overview/#option-builder","text":"OpenJ9 contains an extensive set of command-line options to assist with problem diagnosis. Certain options are complex, containing many sub-options with numerous parameters. Whilst these offer a great degree of flexibility, the syntax can be difficult to construct. Option builder tools are available that provide a simple graphical user interface to help you construct your command-line argument. For more information, see Option builder .","title":"Option builder"},{"location":"diag_overview/#hotspot-compatible-tools","text":"A number of tools are available for compatibility with the reference implementation. These tools are independently implemented by OpenJ9 but have similar functions, allowing users to migrate more easily. The available tools are listed in the Tools section. Note: If you are already familiar with tools that are provided with HotSpot, see Switching to OpenJ9 , which explains some of the differences you might encounter when using OpenJ9.","title":"HotSpot-compatible tools"},{"location":"diag_overview/#eclipse-marketplace-tools","text":"OpenJ9 provides support for a number of monitoring and diagnostic tools that can be found in the Eclipse marketplace . Each tool provides a graphical user interface to help you visualize data and, in some cases, can provide tuning or debugging recommendations. Health Center: Provides real-time monitoring of running applications with minimal overhead over the network. You can monitor a whole range of operations including, class loading, CPU usage, GC heap and pause times, I/O activity, lock contention, method trace, native memory usage, profiling, and live threads. For more information, read the Health Center documentation . Garbage Collection Memory Vizualizer (GCMV): Plots GC and native memory data over time. You can view and save data as a report, raw log, tabulated data, or in graphical format. The tool helps to diagnose problems such as memory leaks with data presented in various visual formats for analysis. Tuning recommendations are also provided. For more information, read the GCMV documentation . Memory Analyzer: Examines the Java object heap to help find memory leaks or reduce memory consumption. Support is available for OpenJ9 via the DTFJ interface (Install from the Eclipse Help menu; Install New Software > Work with \"IBM Diagnostic Tool Framework for Java\" > IBM Monitoring and Diagnostic Tools > Diagnostic Tool Framework for Java). More information about Eclipse MAT can be found on the project website page . If you are familiar with using HotSpot as part of an Oracle JDK or OpenJDK, the Java VisualVM utility is functionally similar to Health Center.","title":"Eclipse marketplace tools"},{"location":"diag_overview/#interfaces","text":"","title":"Interfaces"},{"location":"diag_overview/#jvm-tool-interface-jvmti","text":"OpenJ9 supports the Java Virtual Machine Tool Interface (JVMTI) and provides extensions that allow JVMTI tools to obtain diagnostic information or trigger diagnostic operations in the VM. For more information, see Java Virtual Machine Tool Interface .","title":"JVM tool interface (JVMTI)"},{"location":"diag_overview/#dtfj-interface","text":"OpenJ9 includes the Diagnostic Tool Framework for Java (DTFJ) API. Custom applications can be written that use this API to access a wide range of information in a system dump or a Java dump. DTFJ can be used with the Eclipse Memory Analyzer Toolkit (MAT) to examine the Java object heap for memory leaks and to reduce memory consumption. For more information, see Diagnostic Tool Framework for Java .","title":"DTFJ Interface"},{"location":"diag_overview/#language-management-interface","text":"OpenJ9 provides MXBean additions and extensions to the standard java.lang.management API, which enables you to use tools such as JConsole to monitor and manage your Java applications. For more information, see Language management interface .","title":"Language Management interface"},{"location":"diag_overview/#jpda-tools","text":"OpenJ9 is compliant with the Java Platform Debugging Architecture (JPDA), which means you can use any JPDA tool for diagnosis, including Eclipse JDT Debug .","title":"JPDA tools"},{"location":"djavacompiler/","text":"-Djava.compiler This Oracle HotSpot property is used for loading a JIT compiler from a named, native library. This option can be used on the command line to specify the JIT compiler for the OpenJ9 VM. Syntax -Djava.compiler=j9jit29","title":"-Djava.compiler"},{"location":"djavacompiler/#-djavacompiler","text":"This Oracle HotSpot property is used for loading a JIT compiler from a named, native library. This option can be used on the command line to specify the JIT compiler for the OpenJ9 VM.","title":"-Djava.compiler"},{"location":"djavacompiler/#syntax","text":"-Djava.compiler=j9jit29","title":"Syntax"},{"location":"djavalangstringbuffergrowaggressively/","text":"-Djava.lang.stringBuffer.growAggressively Restriction: This system property is supported only on Java\u2122 8. Setting this property to false reverts to the behavior (OpenJ9 0.18 and earlier) of growing a 1 G char[] or larger StringBuffer or StringBuilder only as much as necessary to accommodate the String being added. The default behavior is to immediately grow to the maximum possible size, similarly to Java 11 and later. The default behavior is compatible with the Oracle HotSpot VM. Syntax -Djava.lang.stringBufferAndBuilder.growAggressively=[true|false] Setting Effect Default true Above 1 G, grow to the maximum size yes false Above 1 G, grow only as required","title":"-Djava.lang.stringBuffer.growAggressively"},{"location":"djavalangstringbuffergrowaggressively/#-djavalangstringbuffergrowaggressively","text":"Restriction: This system property is supported only on Java\u2122 8. Setting this property to false reverts to the behavior (OpenJ9 0.18 and earlier) of growing a 1 G char[] or larger StringBuffer or StringBuilder only as much as necessary to accommodate the String being added. The default behavior is to immediately grow to the maximum possible size, similarly to Java 11 and later. The default behavior is compatible with the Oracle HotSpot VM.","title":"-Djava.lang.stringBuffer.growAggressively"},{"location":"djavalangstringbuffergrowaggressively/#syntax","text":"-Djava.lang.stringBufferAndBuilder.growAggressively=[true|false] Setting Effect Default true Above 1 G, grow to the maximum size yes false Above 1 G, grow only as required","title":"Syntax"},{"location":"djavalangstringsubstringnocopy/","text":"-Djava.lang.string.substring.nocopy Restriction: This system property is supported only on Java\u2122 8. String sharing cannot be enabled on Java 11 and later. Setting this property to true avoids sharing a String object when substring() is used to subset a String beginning from offset zero. Avoiding sharing is compatible with the Oracle HotSpot VM. Syntax -Djava.lang.string.substring.nocopy=[true|false] Setting Effect Default true No sharing false Sharing yes","title":"-Djava.lang.string.substring.nocopy"},{"location":"djavalangstringsubstringnocopy/#-djavalangstringsubstringnocopy","text":"Restriction: This system property is supported only on Java\u2122 8. String sharing cannot be enabled on Java 11 and later. Setting this property to true avoids sharing a String object when substring() is used to subset a String beginning from offset zero. Avoiding sharing is compatible with the Oracle HotSpot VM.","title":"-Djava.lang.string.substring.nocopy"},{"location":"djavalangstringsubstringnocopy/#syntax","text":"-Djava.lang.string.substring.nocopy=[true|false] Setting Effect Default true No sharing false Sharing yes","title":"Syntax"},{"location":"djdknativecbc/","text":"-Djdk.nativeCBC This option enables or disables OpenSSL native cryptographic support for the CBC algorithm. Syntax -Djdk.nativeCBC=[true|false] Setting value Default -Djdk.nativeCBC true yes -Djdk.nativeCBC false Explanation OpenSSL support is enabled by default for the CBC algorithm. If you want to turn off this algorithm only, set this option to false . To turn off all the algorithms, see the -Djdk.nativeCrypto system property command line option.","title":"-Djdk.nativeCBC"},{"location":"djdknativecbc/#-djdknativecbc","text":"This option enables or disables OpenSSL native cryptographic support for the CBC algorithm.","title":"-Djdk.nativeCBC"},{"location":"djdknativecbc/#syntax","text":"-Djdk.nativeCBC=[true|false] Setting value Default -Djdk.nativeCBC true yes -Djdk.nativeCBC false","title":"Syntax"},{"location":"djdknativecbc/#explanation","text":"OpenSSL support is enabled by default for the CBC algorithm. If you want to turn off this algorithm only, set this option to false . To turn off all the algorithms, see the -Djdk.nativeCrypto system property command line option.","title":"Explanation"},{"location":"djdknativechacha20/","text":"-Djdk.nativeChaCha20 This option enables or disables OpenSSL native cryptographic support for the ChaCha20 and ChaCha20-Poly1305 algorithms. Restrictions: These algorithms are not supported on Java 8. These algorithms are not supported on OpenSSL 1.0.x. Syntax -Djdk.nativeChaCha20=[true|false] Setting value Default -Djdk.nativeChaCha20 true yes -Djdk.nativeChaCha20 false Explanation OpenSSL support is enabled by default for the ChaCha20 and ChaCha20-Poly1305 algorithms. If you want to turn off support for these algorithms only, set this option to false . To turn off support for these and other algorithms, see the -Djdk.nativeCrypto system property command line option.","title":"-Djdk.nativeChaCha20"},{"location":"djdknativechacha20/#-djdknativechacha20","text":"This option enables or disables OpenSSL native cryptographic support for the ChaCha20 and ChaCha20-Poly1305 algorithms. Restrictions: These algorithms are not supported on Java 8. These algorithms are not supported on OpenSSL 1.0.x.","title":"-Djdk.nativeChaCha20"},{"location":"djdknativechacha20/#syntax","text":"-Djdk.nativeChaCha20=[true|false] Setting value Default -Djdk.nativeChaCha20 true yes -Djdk.nativeChaCha20 false","title":"Syntax"},{"location":"djdknativechacha20/#explanation","text":"OpenSSL support is enabled by default for the ChaCha20 and ChaCha20-Poly1305 algorithms. If you want to turn off support for these algorithms only, set this option to false . To turn off support for these and other algorithms, see the -Djdk.nativeCrypto system property command line option.","title":"Explanation"},{"location":"djdknativecrypto/","text":"-Djdk.nativeCrypto This option controls the use of OpenSSL native cryptographic support. Syntax -Djdk.nativeCrypto=[true|false] Setting value Default -Djdk.nativeCrypto true yes -Djdk.nativeCrypto false Explanation OpenSSL support is enabled by default for the Digest, CBC, GCM, RSA, and ChaCha20 and ChaCha20-Poly1305 algorithms. If you want to turn off the OpenSSL implementation, set this option to false . Restriction: The ChaCha20 and ChaCha20-Poly1305 algorithms are not supported on Java 8. If you want to turn off the algorithms individually, use the following system properties: -Djdk.nativeCBC -Djdk.nativeChaCha20 ( Not supported on Java 8. ) -Djdk.nativeGCM -Djdk.nativeRSA -Djdk.nativeDigest","title":"-Djdk.nativeCrypto"},{"location":"djdknativecrypto/#-djdknativecrypto","text":"This option controls the use of OpenSSL native cryptographic support.","title":"-Djdk.nativeCrypto"},{"location":"djdknativecrypto/#syntax","text":"-Djdk.nativeCrypto=[true|false] Setting value Default -Djdk.nativeCrypto true yes -Djdk.nativeCrypto false","title":"Syntax"},{"location":"djdknativecrypto/#explanation","text":"OpenSSL support is enabled by default for the Digest, CBC, GCM, RSA, and ChaCha20 and ChaCha20-Poly1305 algorithms. If you want to turn off the OpenSSL implementation, set this option to false . Restriction: The ChaCha20 and ChaCha20-Poly1305 algorithms are not supported on Java 8. If you want to turn off the algorithms individually, use the following system properties: -Djdk.nativeCBC -Djdk.nativeChaCha20 ( Not supported on Java 8. ) -Djdk.nativeGCM -Djdk.nativeRSA -Djdk.nativeDigest","title":"Explanation"},{"location":"djdknativedigest/","text":"-Djdk.nativeDigest This option enables or disables OpenSSL native cryptographic support for the Digest algorithm. Syntax -Djdk.nativeDigest=[true|false] Setting value Default -Djdk.nativeDigest true yes -Djdk.nativeDigest false Explanation To turn off all the algorithms, see the -Djdk.nativeCrypto system property command line option.","title":"-Djdk.nativeDigest"},{"location":"djdknativedigest/#-djdknativedigest","text":"This option enables or disables OpenSSL native cryptographic support for the Digest algorithm.","title":"-Djdk.nativeDigest"},{"location":"djdknativedigest/#syntax","text":"-Djdk.nativeDigest=[true|false] Setting value Default -Djdk.nativeDigest true yes -Djdk.nativeDigest false","title":"Syntax"},{"location":"djdknativedigest/#explanation","text":"To turn off all the algorithms, see the -Djdk.nativeCrypto system property command line option.","title":"Explanation"},{"location":"djdknativegcm/","text":"-Djdk.nativeGCM This option enables or disables OpenSSL native cryptographic support for the GCM algorithm. Syntax -Djdk.nativeGCM=[true|false] Setting value Default -Djdk.nativeGCM true yes -Djdk.nativeGCM false Explanation OpenSSL support is enabled by default for the GCM algorithm. If you want to turn off this algorithm only, set this option to false . To turn off all the algorithms, see the -Djdk.nativeCrypto system property command line option.","title":"-Djdk.nativeGCM"},{"location":"djdknativegcm/#-djdknativegcm","text":"This option enables or disables OpenSSL native cryptographic support for the GCM algorithm.","title":"-Djdk.nativeGCM"},{"location":"djdknativegcm/#syntax","text":"-Djdk.nativeGCM=[true|false] Setting value Default -Djdk.nativeGCM true yes -Djdk.nativeGCM false","title":"Syntax"},{"location":"djdknativegcm/#explanation","text":"OpenSSL support is enabled by default for the GCM algorithm. If you want to turn off this algorithm only, set this option to false . To turn off all the algorithms, see the -Djdk.nativeCrypto system property command line option.","title":"Explanation"},{"location":"djdknativersa/","text":"-Djdk.nativeRSA This option enables or disables OpenSSL native cryptographic support for the RSA algorithm. Syntax -Djdk.nativeRSA=[true|false] Setting value Default -Djdk.nativeRSA true yes -Djdk.nativeRSA false Explanation OpenSSL support is enabled by default for the RSA algorithm. If you want to turn off support for this algorithm only, set this option to false . To turn off all the algorithms, see the -Djdk.nativeCrypto system property command line option.","title":"-Djdk.nativeRSA"},{"location":"djdknativersa/#-djdknativersa","text":"This option enables or disables OpenSSL native cryptographic support for the RSA algorithm.","title":"-Djdk.nativeRSA"},{"location":"djdknativersa/#syntax","text":"-Djdk.nativeRSA=[true|false] Setting value Default -Djdk.nativeRSA true yes -Djdk.nativeRSA false","title":"Syntax"},{"location":"djdknativersa/#explanation","text":"OpenSSL support is enabled by default for the RSA algorithm. If you want to turn off support for this algorithm only, set this option to false . To turn off all the algorithms, see the -Djdk.nativeCrypto system property command line option.","title":"Explanation"},{"location":"dump_heapdump/","text":"Heap dump Heap dumps contain a snapshot of all the live objects that are being used by a running Java\u2122 application on the Java heap. You can obtain detailed information for each object instance, such as the address, type, class name, or size, and whether the instance has references to other objects. There are two formats for heap dumps; the classic format and the Portable Heap Dump (PHD) format, which is the default. Whilst the classic format is generated in ascii text and can be read, the PHD format is binary and and must be processed for analysis. Obtaining dumps Heap dumps are generated by default in PHD format when the Java heap runs out of space. If you want to trigger the production of a heap dump in response to other situations, or in classic format, you can use one of the following options: Configure the heap dump agent. For more information, see the -Xdump option. Use the com.ibm.jvm.Dump API programmatically in your application code. For more information, see the JVM diagnostic utilities API documentation . Analyzing dumps The best method to analyze a PHD heap dump is to use the Eclipse Memory Analyzer tool (MAT) or the IBM Memory Analyzer tool . These tools process the dump file and provide a visual representation of the objects in the Java Heap. Both tools require the Diagnostic Tool Framework for Java (DTFJ) plugin. To install the DTFJ plugin in the Eclipse IDE, select the following menu items: Help > Install New Software > Work with \"IBM Diagnostic Tool Framework for Java\" > IBM Monitoring and Diagnostic Tools > Diagnostic Tool Framework for Java The following sections contain detailed information about the content of each type of heap dump file. Portable Heap Dump (PHD) format A PHD format dump file contains a header section and a body section. The body section can contain information about object, array, or class records. Primitive numbers are used to describe the file format, as detailed in the following table: Primitive number Length in bytes byte 1 short 2 int 4 long 8 word 4 (32-bit platforms) or 8 (64-bit platforms) General structure The following structure comprises the header section of a PHD file: A UTF string indicating that the file is a portable heap dump An int containing the PHD version number An int containing flags: 1 indicates that the word length is 64-bit. 2 indicates that all the objects in the dump are hashed. This flag is set for heap dumps that use 16-bit hash codes. OpenJ9 heap dumps use 32-bit hash codes that are created only when used. For example, these hash codes are created when the APIs Object.hashCode() or Object.toString() are called in a Java application. If this flag is not set, the presence of a hash code is indicated by the hash code flag on the individual PHD records. 4 indicates that the dump is from an OpenJ9 VM. A byte containing a tag with a value of 1 that indicates the start of the header. A number of optional header records, each preceded by a one-byte header tag. Header record tags have a different range of values from the body, or object record tags. The end of the header is indicated by the end of header tag. The following tags are included: header tag 1 - not used header tag 2 - indicates the end of the header header tag 3 - not used header tag 4 - indicates the VM version (Variable length UTF string) The body of a PHD file is indicated by a byte that contains a tag with a value of 2, after which there are a number of dump records. Dump records are preceded by a 1 byte tag with the following record types: Short object: 0x80 bit of the tag is set Medium object: 0x40 bit of the tag is set (top bit value is 0) Primitive Array: 0x20 bit if the tag is set (all other tag values have the top 3 bits with a value of 0) Long record: tag value is 4 Class record: tag value is 6 Long primitive array: tag value is 7 Object array: tag value is 8 These records are described in more detail in the sections that follow. The end of the PHD body is indicated by a byte that contains a tag with a value of 3. Object records Object records can be short, medium, or long, depending on the number of object references in the heap dump. 1. Short object record The following information is contained within the tag byte: The 1 byte tag, which consists of the following bits: Bit number Value or description 1 Bit is set (0x80) 2 and 3 Indicates the class cache index. The value represents an index into a cache of the last 4 classes used. 4 and 5 Contain the number of references. Most objects contain 0 - 3 references. If there are 4 - 7 references, the Medium object record is used. If there are more than 7 references, the Long object record is used. 6 Indicates whether the gap is a 1 byte value or a short . The gap is the difference between the address of this object and the previous object. If set, the gap is a short . If the gap does not fit into a short , the Long object record format is used. 7 and 8 Indicates the size of each reference (0= byte , 1= short , 2= int , 3= long ) A byte or a short containing the gap between the address of this object and the address of the preceding object. The value is signed and represents the number of 32-bit words between the two addresses. Most gaps fit into 1 byte. If all objects are hashed, a short containing the hash code. The array of references, if references exist. The tag shows the number of elements, and the size of each element. The value in each element is the gap between the address of the references and the address of the current object. The value is a signed number of 32-bit words. Null references are not included. 2. Medium object record These records provide the actual address of the class rather than a cache index. The following format is used: The 1 byte tag, consisting of the following bits: Bit number Value or description 1 0 2 Set (0x40) 3, 4, and 5 Contain the number of references 6 Indicates whether the gap is a 1 byte value or a short (see Short object record description) 7 and 8 Indicates the size of each reference (0= byte , 1= short , 2= int , 3= long ) A byte or a short containing the gap between the address of this object and the address of the preceding object (See the Short object record description) A word containing the address of the class of this object. If all objects are hashed, a short containing the hash code. The array of references (See the Short object record description). 3. Long object record This record format is used when there are more than 7 references, or if there are extra flags or a hash code. The following format is used: The 1 byte tag, containing the value 4. A byte containing flags, consisting of the following bits: Bit number Value or description 1 and 2 Indicates whether the gap is a byte , short , int or long format 3 and 4 Indicates the size of each reference (0= byte , 1= short , 2= int , 3= long ) 5 and 6 Unused 7 Indicates if the object was hashed and moved. If this bit is set, the record includes the hash code 8 Indicates if the object was hashed A byte , short , int , or long containing the gap between the address of this object and the address of the preceding object (See the Short object record description). A word containing the address of the class of this object. If all objects are hashed, a short containing the hash code. Otherwise, an optional int containing the hash code if the hashed and moved bit is set in the record flag byte. An int containing the length of the array of references. The array of references (See the Short object record description). Array records PHD arrays can be primitive arrays or object arrays, as described in the sections that follow. 1. Primitive array record The following information is contained in an array record: The 1 byte tag, consisting of the following bits: Bit number Value or description 1 and 2 0 3 Set (0x20) 4, 5, and 6 Contains the array type ( 0=bool, 1=char, 2=float, 3=double, 4= byte , 5= short , 6= int , and 7= long ) 7 and 8 Indicates the length of the array size and the length of the gap (0= byte , 1= short , 2= int , 3= long ) byte , short , int or long containing the gap between the address of this object and the address of the preceding object (See the Short object record description). byte , short , int or long containing the array length. If all objects are hashed, a short containing the hash code. An unsigned int containing the size of the instance of the array on the heap, including header and padding. The size is measured in 32-bit words, which you can multiply by four to obtain the size in bytes. This format allows encoding of lengths up to 16GB in an unsigned int . 2. Long primitive array record This type of record is used when a primitive array has been hashed. The 1 byte tag with a value of 7. A byte containing the following flags: Bit number Value or description 1, 2, and 3 Contains the array type ( 0=bool, 1=char, 2=float, 3=double, 4= byte , 5= short , 6= int , and 7= long ) 4 Indicates the length of the array size and the length of the gap (0= byte , 1= word ). 5 and 6 Unused 7 Indicates if the object was hashed and moved. If this bit is set, the record includes the hash code. 8 Indicates if the object was hashed a byte or word containing the gap between the address of this object and the address of the preceding object (See the Short object record description). a byte or word containing the array length. If all objects are hashed, a short containing the hash code. Otherwise, an optional int containing the hash code if the hashed and moved bit is set in the record flag byte. An unsigned int containing the size of the instance of the array on the heap, including header and padding. The size is measured in 32-bit words, which you can multiply by four to obtain the size in bytes. This format allows encoding of lengths up to 16GB in an unsigned int . 3. Object array record The following format applies: The 1 byte tag with a value of 8. A byte containing the following flags: Bit number Value or description 1 and 2 Indicates whether the gap is byte , short , int or long . 3 and 4 Indicates the size of each reference (0= byte , 1= short , 2= int , 3= long ) 5 and 6 Unused 7 Indicates if the object was hashed and moved. If this bit is set, the record includes the hash code. 8 Indicates if the object was hashed A byte , short , int or long containing the gap between the address of this object and the address of the preceding object (See the Short object record format description). A word containing the address of the class of the objects in the array. Object array records do not update the class cache. If all objects are hashed, a short containing the hash code. If the hashed and moved bit is set in the records flag, this field contains an int . An int containing the length of the array of references. The array of references (See the Short object record description). An unsigned int containing the size of the instance of the array on the heap, including header and padding. The size is measured in 32-bit words, which you can multiply by four to obtain the size in bytes. This format allows encoding of lengths up to 16GB in an unsigned int . An final int value is shown at the end. This int contains the true array length, shown as a number of array elements. The true array length might differ from the length of the array of references because null references are excluded. Class records The PHD class record encodes a class object and contains the following format: The 1 byte tag, containing the value 6. A byte containing the following flags: Bit number Value or description 1 and 2 Indicates whether the gap is byte, short , int or long 3 and 4 Indicates the size of each static reference (0= byte , 1= short , 2= int , 3= long ) 5 Indicates if the object was hashed A byte, short , int or long containing the gap between the address of this class and the address of the preceding object (See the Short object record description). An int containing the instance size. If all objects are hashed, a short containing the hash code. Otherwise, an optional int containing the hash code if the hashed and moved bit is set in the record flag byte. A word containing the address of the superclass. A UTF string containing the name of this class. An int containing the number of static references. The array of static references (See the Short object record description). Classic Heap Dump format Classic heap dumps are produced in ascii text on all platforms except z/OS, which are encoded in EBCDIC. The dump is divided into the following sections: Header record A single string containing information about the runtime environment, platform, and build levels, similar to the following example: // Version: JRE 1.8.0 Linux amd64-64 (build 1.8.0_232-b09) Object records A record of each object instance in the heap with the following format: <object address, in hexadecimal> [<length in bytes of object instance, in decimal>] OBJ <object type> <heap reference, in hexadecimal> <heap reference, in hexadecimal> ... The following object types ( object type ) might be shown: class name (including package name) class array type primitive array type These types are abbreviated in the record. To determine the type, see the Java VM Type Signature table . Any references found are also listed, excluding references to an object's class or NULL references. The following example shows an object instance (16 bytes in length) of type java/lang/String , with a reference to a char array: 0x00000000E0000AF0 [16] OBJ java/lang/String 0x00000000E0000B00 The object instance (length 32 bytes) of type char array, as referenced from the java/lang/String , is shown in the following example: 0x00000000E0000B00 [32] OBJ [C The following example shows an object instance (24 bytes in length) of type array of java/lang/String : 0x00000000FFF07498 [24] OBJ [Ljava/lang/String; 0x00000000E0005D78 0x00000000E0005D50 0x00000000E0005D28 0x00000000E0005D00 Class records A record of each class in the following format: <class object address, in hexadecimal> [<length in bytes of class object, in decimal>] CLS <class type> <heap reference, in hexadecimal> <heap reference, in hexadecimal>... The following class types ( <class type> ) might be shown: class name (including package name) class array type primitive array types These types are abbreviated in the record. To determine the type, see the Java VM Type Signature table . Any references found in the class block are also listed, excluding NULL references. The following example shows a class object (80 bytes in length) for java/util/Date , with heap references: 0x00000000E00174F0 [80] CLS java/util/Date 0x00000000FFF1BB60 0x00000000FFF29630 Trailer record 1 A single record containing record counts, in decimal. For example: // Breakdown - Classes: 630, Objects: 3692, ObjectArrays: 576, PrimitiveArrays: 2249 Trailer record 2 A single record containing totals, in decimal. For example: // EOF: Total 'Objects',Refs(null) : 7147,22040(12379) The values in the example reflect the following counts: 7147 total objects 22040 total references (12379) total NULL references as a proportion of the total references count Java VM Type Signatures The following table shows the abbreviations used for different Java types in the heap dump records: Java VM Type Signature Java Type Z boolean B byte C char S short I int J long F float D double L<fully-qualified class>; <fully-qualified class> [<type> <type>[](array of <type>) (<arg-types>)<ret-type> method See also DTFJ interface","title":"Heap dump"},{"location":"dump_heapdump/#heap-dump","text":"Heap dumps contain a snapshot of all the live objects that are being used by a running Java\u2122 application on the Java heap. You can obtain detailed information for each object instance, such as the address, type, class name, or size, and whether the instance has references to other objects. There are two formats for heap dumps; the classic format and the Portable Heap Dump (PHD) format, which is the default. Whilst the classic format is generated in ascii text and can be read, the PHD format is binary and and must be processed for analysis.","title":"Heap dump"},{"location":"dump_heapdump/#obtaining-dumps","text":"Heap dumps are generated by default in PHD format when the Java heap runs out of space. If you want to trigger the production of a heap dump in response to other situations, or in classic format, you can use one of the following options: Configure the heap dump agent. For more information, see the -Xdump option. Use the com.ibm.jvm.Dump API programmatically in your application code. For more information, see the JVM diagnostic utilities API documentation .","title":"Obtaining dumps"},{"location":"dump_heapdump/#analyzing-dumps","text":"The best method to analyze a PHD heap dump is to use the Eclipse Memory Analyzer tool (MAT) or the IBM Memory Analyzer tool . These tools process the dump file and provide a visual representation of the objects in the Java Heap. Both tools require the Diagnostic Tool Framework for Java (DTFJ) plugin. To install the DTFJ plugin in the Eclipse IDE, select the following menu items: Help > Install New Software > Work with \"IBM Diagnostic Tool Framework for Java\" > IBM Monitoring and Diagnostic Tools > Diagnostic Tool Framework for Java The following sections contain detailed information about the content of each type of heap dump file.","title":"Analyzing dumps"},{"location":"dump_heapdump/#portable-heap-dump-phd-format","text":"A PHD format dump file contains a header section and a body section. The body section can contain information about object, array, or class records. Primitive numbers are used to describe the file format, as detailed in the following table: Primitive number Length in bytes byte 1 short 2 int 4 long 8 word 4 (32-bit platforms) or 8 (64-bit platforms)","title":"Portable Heap Dump (PHD) format"},{"location":"dump_heapdump/#general-structure","text":"The following structure comprises the header section of a PHD file: A UTF string indicating that the file is a portable heap dump An int containing the PHD version number An int containing flags: 1 indicates that the word length is 64-bit. 2 indicates that all the objects in the dump are hashed. This flag is set for heap dumps that use 16-bit hash codes. OpenJ9 heap dumps use 32-bit hash codes that are created only when used. For example, these hash codes are created when the APIs Object.hashCode() or Object.toString() are called in a Java application. If this flag is not set, the presence of a hash code is indicated by the hash code flag on the individual PHD records. 4 indicates that the dump is from an OpenJ9 VM. A byte containing a tag with a value of 1 that indicates the start of the header. A number of optional header records, each preceded by a one-byte header tag. Header record tags have a different range of values from the body, or object record tags. The end of the header is indicated by the end of header tag. The following tags are included: header tag 1 - not used header tag 2 - indicates the end of the header header tag 3 - not used header tag 4 - indicates the VM version (Variable length UTF string) The body of a PHD file is indicated by a byte that contains a tag with a value of 2, after which there are a number of dump records. Dump records are preceded by a 1 byte tag with the following record types: Short object: 0x80 bit of the tag is set Medium object: 0x40 bit of the tag is set (top bit value is 0) Primitive Array: 0x20 bit if the tag is set (all other tag values have the top 3 bits with a value of 0) Long record: tag value is 4 Class record: tag value is 6 Long primitive array: tag value is 7 Object array: tag value is 8 These records are described in more detail in the sections that follow. The end of the PHD body is indicated by a byte that contains a tag with a value of 3.","title":"General structure"},{"location":"dump_heapdump/#object-records","text":"Object records can be short, medium, or long, depending on the number of object references in the heap dump. 1. Short object record The following information is contained within the tag byte: The 1 byte tag, which consists of the following bits: Bit number Value or description 1 Bit is set (0x80) 2 and 3 Indicates the class cache index. The value represents an index into a cache of the last 4 classes used. 4 and 5 Contain the number of references. Most objects contain 0 - 3 references. If there are 4 - 7 references, the Medium object record is used. If there are more than 7 references, the Long object record is used. 6 Indicates whether the gap is a 1 byte value or a short . The gap is the difference between the address of this object and the previous object. If set, the gap is a short . If the gap does not fit into a short , the Long object record format is used. 7 and 8 Indicates the size of each reference (0= byte , 1= short , 2= int , 3= long ) A byte or a short containing the gap between the address of this object and the address of the preceding object. The value is signed and represents the number of 32-bit words between the two addresses. Most gaps fit into 1 byte. If all objects are hashed, a short containing the hash code. The array of references, if references exist. The tag shows the number of elements, and the size of each element. The value in each element is the gap between the address of the references and the address of the current object. The value is a signed number of 32-bit words. Null references are not included. 2. Medium object record These records provide the actual address of the class rather than a cache index. The following format is used: The 1 byte tag, consisting of the following bits: Bit number Value or description 1 0 2 Set (0x40) 3, 4, and 5 Contain the number of references 6 Indicates whether the gap is a 1 byte value or a short (see Short object record description) 7 and 8 Indicates the size of each reference (0= byte , 1= short , 2= int , 3= long ) A byte or a short containing the gap between the address of this object and the address of the preceding object (See the Short object record description) A word containing the address of the class of this object. If all objects are hashed, a short containing the hash code. The array of references (See the Short object record description). 3. Long object record This record format is used when there are more than 7 references, or if there are extra flags or a hash code. The following format is used: The 1 byte tag, containing the value 4. A byte containing flags, consisting of the following bits: Bit number Value or description 1 and 2 Indicates whether the gap is a byte , short , int or long format 3 and 4 Indicates the size of each reference (0= byte , 1= short , 2= int , 3= long ) 5 and 6 Unused 7 Indicates if the object was hashed and moved. If this bit is set, the record includes the hash code 8 Indicates if the object was hashed A byte , short , int , or long containing the gap between the address of this object and the address of the preceding object (See the Short object record description). A word containing the address of the class of this object. If all objects are hashed, a short containing the hash code. Otherwise, an optional int containing the hash code if the hashed and moved bit is set in the record flag byte. An int containing the length of the array of references. The array of references (See the Short object record description).","title":"Object records"},{"location":"dump_heapdump/#array-records","text":"PHD arrays can be primitive arrays or object arrays, as described in the sections that follow. 1. Primitive array record The following information is contained in an array record: The 1 byte tag, consisting of the following bits: Bit number Value or description 1 and 2 0 3 Set (0x20) 4, 5, and 6 Contains the array type ( 0=bool, 1=char, 2=float, 3=double, 4= byte , 5= short , 6= int , and 7= long ) 7 and 8 Indicates the length of the array size and the length of the gap (0= byte , 1= short , 2= int , 3= long ) byte , short , int or long containing the gap between the address of this object and the address of the preceding object (See the Short object record description). byte , short , int or long containing the array length. If all objects are hashed, a short containing the hash code. An unsigned int containing the size of the instance of the array on the heap, including header and padding. The size is measured in 32-bit words, which you can multiply by four to obtain the size in bytes. This format allows encoding of lengths up to 16GB in an unsigned int . 2. Long primitive array record This type of record is used when a primitive array has been hashed. The 1 byte tag with a value of 7. A byte containing the following flags: Bit number Value or description 1, 2, and 3 Contains the array type ( 0=bool, 1=char, 2=float, 3=double, 4= byte , 5= short , 6= int , and 7= long ) 4 Indicates the length of the array size and the length of the gap (0= byte , 1= word ). 5 and 6 Unused 7 Indicates if the object was hashed and moved. If this bit is set, the record includes the hash code. 8 Indicates if the object was hashed a byte or word containing the gap between the address of this object and the address of the preceding object (See the Short object record description). a byte or word containing the array length. If all objects are hashed, a short containing the hash code. Otherwise, an optional int containing the hash code if the hashed and moved bit is set in the record flag byte. An unsigned int containing the size of the instance of the array on the heap, including header and padding. The size is measured in 32-bit words, which you can multiply by four to obtain the size in bytes. This format allows encoding of lengths up to 16GB in an unsigned int . 3. Object array record The following format applies: The 1 byte tag with a value of 8. A byte containing the following flags: Bit number Value or description 1 and 2 Indicates whether the gap is byte , short , int or long . 3 and 4 Indicates the size of each reference (0= byte , 1= short , 2= int , 3= long ) 5 and 6 Unused 7 Indicates if the object was hashed and moved. If this bit is set, the record includes the hash code. 8 Indicates if the object was hashed A byte , short , int or long containing the gap between the address of this object and the address of the preceding object (See the Short object record format description). A word containing the address of the class of the objects in the array. Object array records do not update the class cache. If all objects are hashed, a short containing the hash code. If the hashed and moved bit is set in the records flag, this field contains an int . An int containing the length of the array of references. The array of references (See the Short object record description). An unsigned int containing the size of the instance of the array on the heap, including header and padding. The size is measured in 32-bit words, which you can multiply by four to obtain the size in bytes. This format allows encoding of lengths up to 16GB in an unsigned int . An final int value is shown at the end. This int contains the true array length, shown as a number of array elements. The true array length might differ from the length of the array of references because null references are excluded.","title":"Array records"},{"location":"dump_heapdump/#class-records","text":"The PHD class record encodes a class object and contains the following format: The 1 byte tag, containing the value 6. A byte containing the following flags: Bit number Value or description 1 and 2 Indicates whether the gap is byte, short , int or long 3 and 4 Indicates the size of each static reference (0= byte , 1= short , 2= int , 3= long ) 5 Indicates if the object was hashed A byte, short , int or long containing the gap between the address of this class and the address of the preceding object (See the Short object record description). An int containing the instance size. If all objects are hashed, a short containing the hash code. Otherwise, an optional int containing the hash code if the hashed and moved bit is set in the record flag byte. A word containing the address of the superclass. A UTF string containing the name of this class. An int containing the number of static references. The array of static references (See the Short object record description).","title":"Class records"},{"location":"dump_heapdump/#classic-heap-dump-format","text":"Classic heap dumps are produced in ascii text on all platforms except z/OS, which are encoded in EBCDIC. The dump is divided into the following sections:","title":"Classic Heap Dump format"},{"location":"dump_heapdump/#header-record","text":"A single string containing information about the runtime environment, platform, and build levels, similar to the following example: // Version: JRE 1.8.0 Linux amd64-64 (build 1.8.0_232-b09)","title":"Header record"},{"location":"dump_heapdump/#object-records_1","text":"A record of each object instance in the heap with the following format: <object address, in hexadecimal> [<length in bytes of object instance, in decimal>] OBJ <object type> <heap reference, in hexadecimal> <heap reference, in hexadecimal> ... The following object types ( object type ) might be shown: class name (including package name) class array type primitive array type These types are abbreviated in the record. To determine the type, see the Java VM Type Signature table . Any references found are also listed, excluding references to an object's class or NULL references. The following example shows an object instance (16 bytes in length) of type java/lang/String , with a reference to a char array: 0x00000000E0000AF0 [16] OBJ java/lang/String 0x00000000E0000B00 The object instance (length 32 bytes) of type char array, as referenced from the java/lang/String , is shown in the following example: 0x00000000E0000B00 [32] OBJ [C The following example shows an object instance (24 bytes in length) of type array of java/lang/String : 0x00000000FFF07498 [24] OBJ [Ljava/lang/String; 0x00000000E0005D78 0x00000000E0005D50 0x00000000E0005D28 0x00000000E0005D00","title":"Object records"},{"location":"dump_heapdump/#class-records_1","text":"A record of each class in the following format: <class object address, in hexadecimal> [<length in bytes of class object, in decimal>] CLS <class type> <heap reference, in hexadecimal> <heap reference, in hexadecimal>... The following class types ( <class type> ) might be shown: class name (including package name) class array type primitive array types These types are abbreviated in the record. To determine the type, see the Java VM Type Signature table . Any references found in the class block are also listed, excluding NULL references. The following example shows a class object (80 bytes in length) for java/util/Date , with heap references: 0x00000000E00174F0 [80] CLS java/util/Date 0x00000000FFF1BB60 0x00000000FFF29630","title":"Class records"},{"location":"dump_heapdump/#trailer-record-1","text":"A single record containing record counts, in decimal. For example: // Breakdown - Classes: 630, Objects: 3692, ObjectArrays: 576, PrimitiveArrays: 2249","title":"Trailer record 1"},{"location":"dump_heapdump/#trailer-record-2","text":"A single record containing totals, in decimal. For example: // EOF: Total 'Objects',Refs(null) : 7147,22040(12379) The values in the example reflect the following counts: 7147 total objects 22040 total references (12379) total NULL references as a proportion of the total references count","title":"Trailer record 2"},{"location":"dump_heapdump/#java-vm-type-signatures","text":"The following table shows the abbreviations used for different Java types in the heap dump records: Java VM Type Signature Java Type Z boolean B byte C char S short I int J long F float D double L<fully-qualified class>; <fully-qualified class> [<type> <type>[](array of <type>) (<arg-types>)<ret-type> method","title":"Java VM Type Signatures"},{"location":"dump_heapdump/#see-also","text":"DTFJ interface","title":"See also"},{"location":"dump_javadump/","text":"Java dump Java dumps, sometimes referred to as Java cores , are produced when the VM ends unexpectedly because of an operating system signal, OutOfMemoryError , or a user-initiated keystroke combination. You can also generate a Java dump by calling the Dump API programmatically from your application or specifying the -Xdump:java option on the command line. If your Java application crashes or hangs, Java dumps can provide useful information to help you diagnose the root cause. If your application crashes, Java dumps are generated automatically for the following types of failure: the VM receives an unexpected signal or an assertion failure the VM runs out of memory If your application hangs, you can trigger the generation of a Java dump by sending a SIGQUIT signal ( kill -3 ) to the VM. Note: On Windows, if you started the VM in a console window you can force the VM to produce a Java dump in response to a SIGBREAK signal (Ctrl-Break keyboard combination). If you didn't start in a console window there is no equivalent to a Linux kill command on Windows for sending signals. The only option here is to trigger a full system dump by finding the VM process in the Processes tab of the Windows Task Manager and clicking Create dump file . To help you understand how a Java dump can help you with problem diagnosis, this topic includes a few scenarios to help you interpret the data: A crash caused by a general protection fault (gpf) A Java heap OutOfMemoryError (OOM) A native OutOfMemoryError (OOM) A deadlock situation A hang Java dump contents Java dumps summarize the state of the VM when the event occurs, with most of the information relating to components of the VM. The file is made up of a number of sections that provide different types of information. TITLE The first section of the Java dump file provides information about the event that triggered the production of the dump. In the following example you can see that a vmstop event triggered the dump at a specified date and time. 0SECTION TITLE subcomponent dump routine NULL =============================== 1TICHARSET UTF-8 1TISIGINFO Dump Event \"vmstop\" (00000002) Detail \"#0000000000000000\" received 1TIDATETIMEUTC Date: 2021/04/23 at 18:02:44:017 (UTC) 1TIDATETIME Date: 2021/04/23 at 14:02:44:017 1TITIMEZONE Timezone: UTC-4 (EDT) 1TINANOTIME System nanotime: 379202644260787 1TIFILENAME Javacore filename: /home/doc-javacore/javacore.20210423.140244.1175.0001.txt 1TIREQFLAGS Request Flags: 0x81 (exclusive+preempt) 1TIPREPSTATE Prep State: 0x106 (vm_access+exclusive_vm_access+trace_disabled) GPINFO The GPINFO section provides general information about the system that the VM is running on. The following example is taken from a Java dump that was generated on a Linux system. NULL ------------------------------------------------------------------------ 0SECTION GPINFO subcomponent dump routine NULL ================================ 2XHOSLEVEL OS Level : Linux 3.10.0-862.11.6.el7.x86_64 2XHCPUS Processors - 3XHCPUARCH Architecture : amd64 3XHNUMCPUS How Many : 4 3XHNUMASUP NUMA is either not supported or has been disabled by user NULL 1XHERROR2 Register dump section only produced for SIGSEGV, SIGILL or SIGFPE. NULL The content of this section can vary, depending on the cause of the dump. For example, if the dump was caused by a general protection fault (gpf), the library in which the crash occurred is also recorded, together with a value shown as VM flags . This value can provide some clues about which component of the VM might have been involved. Look for the following line in the output: 1XHFLAGS VM flags:0000000000000000 The hexadecimal number recorded for VM flags ends in MSSSS, where M is the VM component and SSSS is component-specific code as shown in the following table: Component Code value INTERPRETER 0x10000 GC 0x20000 GROW_STACK 0x30000 JNI 0x40000 JIT_CODEGEN 0x50000 BCVERIFY 0x60000 RTVERIFY 0x70000 SHAREDCLASSES 0x80000 A value of 0000000000000000 (0x00000) indicates that a crash occurred outside of the VM. ENVINFO This section contains useful information about the environment in which the crash took place, including the following data: Java version ( 1CIJAVAVERSION ) OpenJ9 VM and subcomponent version information ( 1CIVMVERSION , 1CIJ9VMVERSION , 1CIJITVERSION , 1CIOMRVERSION , 1CIJCLVERSION ) VM start time ( 1CISTARTTIME ) and process information ( 1CIPROCESSID ) Java home ( 1CIJAVAHOMEDIR ) and DLL ( 1CIJAVADLLDIR ) directories User arguments passed on the command line ( 1CIUSERARG ) User limits imposed by the system ( 1CIUSERLIMITS ) Environment variables in place ( 1CIENVVARS ) System information ( 1CISYSINFO ) CPU information ( 1CICPUINFO ) Control group (Cgroup) information ( 1CICGRPINFO ) For clarity, the following example shows a shortened version of this section, where ... indicates that lines are removed: NULL ------------------------------------------------------------------------ 0SECTION ENVINFO subcomponent dump routine NULL ================================= 1CIJAVAVERSION JRE 9 Linux amd64-64 (build 9.0.4-internal+0-adhoc..openj9-openjdk-jdk9) 1CIVMVERSION 20180830_000000 1CIJ9VMVERSION 8e7c6ec 1CIJITVERSION 8e7c6ec 1CIOMRVERSION 553811b_CMPRSS 1CIJCLVERSION ec1d223 based on jdk-9.0.4+12 1CIJITMODES JIT enabled, AOT enabled, FSD disabled, HCR enabled 1CIRUNNINGAS Running as a standalone JVM 1CIVMIDLESTATE VM Idle State: ACTIVE 1CICONTINFO Running in container : FALSE 1CICGRPINFO JVM support for cgroups enabled : TRUE 1CISTARTTIME JVM start time: 2018/08/30 at 21:55:47:387 1CISTARTNANO JVM start nanotime: 22012135233549 1CIPROCESSID Process ID: 30285 (0x764D) 1CICMDLINE [not available] 1CIJAVAHOMEDIR Java Home Dir: /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk 1CIJAVADLLDIR Java DLL Dir: /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/bin 1CISYSCP Sys Classpath: 1CIUSERARGS UserArgs: 2CIUSERARG -Xoptionsfile=/home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/options.default ... NULL 1CIUSERLIMITS User Limits (in bytes except for NOFILE and NPROC) NULL ------------------------------------------------------------------------ NULL type soft limit hard limit 2CIUSERLIMIT RLIMIT_AS unlimited unlimited 2CIUSERLIMIT RLIMIT_CORE 0 unlimited 2CIUSERLIMIT RLIMIT_CPU unlimited unlimited 2CIUSERLIMIT RLIMIT_DATA unlimited unlimited 2CIUSERLIMIT RLIMIT_FSIZE unlimited unlimited 2CIUSERLIMIT RLIMIT_LOCKS unlimited unlimited 2CIUSERLIMIT RLIMIT_MEMLOCK 65536 65536 2CIUSERLIMIT RLIMIT_NOFILE 4096 4096 2CIUSERLIMIT RLIMIT_NPROC 4096 30592 2CIUSERLIMIT RLIMIT_RSS unlimited unlimited 2CIUSERLIMIT RLIMIT_STACK 8388608 unlimited 2CIUSERLIMIT RLIMIT_MSGQUEUE 819200 819200 2CIUSERLIMIT RLIMIT_NICE 0 0 2CIUSERLIMIT RLIMIT_RTPRIO 0 0 2CIUSERLIMIT RLIMIT_SIGPENDING 30592 30592 NULL 1CIENVVARS Environment Variables NULL ------------------------------------------------------------------------ 2CIENVVAR XDG_VTNR=1 2CIENVVAR SSH_AGENT_PID=2653 ... NULL 1CISYSINFO System Information NULL ------------------------------------------------------------------------ 2CISYSINFO /proc/sys/kernel/core_pattern = core 2CISYSINFO /proc/sys/kernel/core_uses_pid = 1 NULL 1CICPUINFO CPU Information NULL ------------------------------------------------------------------------ 2CIPHYSCPU Physical CPUs: 8 2CIONLNCPU Online CPUs: 8 2CIBOUNDCPU Bound CPUs: 8 2CIACTIVECPU Active CPUs: 0 2CITARGETCPU Target CPUs: 8 2CIJITFEATURE CPU features (JIT): fpu cx8 cmov mmx sse sse2 ssse3 fma sse4_1 popcnt aesni osxsave avx avx2 rdt_m 2CIAOTFEATURE CPU features (AOT): fpu cx8 cmov mmx sse sse2 ssse3 fma sse4_1 popcnt aesni osxsave avx avx2 rdt_m NULL 1CICGRPINFO Cgroup Information NULL ------------------------------------------------------------------------ 2CICGRPINFO subsystem : cpu 2CICGRPINFO cgroup name : / 3CICGRPINFO CPU Period : 100000 microseconds 3CICGRPINFO CPU Quota : Not Set 3CICGRPINFO CPU Shares : 1024 3CICGRPINFO Period intervals elapsed count : 0 3CICGRPINFO Throttled count : 0 3CICGRPINFO Total throttle time : 0 nanoseconds 2CICGRPINFO subsystem : cpuset 2CICGRPINFO cgroup name : / 3CICGRPINFO CPU exclusive : 1 3CICGRPINFO Mem exclusive : 1 3CICGRPINFO CPUs : 0-7 3CICGRPINFO Mems : 0 2CICGRPINFO subsystem : memory 2CICGRPINFO cgroup name : / 3CICGRPINFO Memory Limit : Not Set 3CICGRPINFO Memory + Swap Limit : Not Set 3CICGRPINFO Memory Usage : 5363396608 bytes 3CICGRPINFO Memory + Swap Usage : 5363396608 bytes 3CICGRPINFO Memory Max Usage : 0 bytes 3CICGRPINFO Memory + Swap Max Usage : 0 bytes 3CICGRPINFO Memory limit exceeded count : 0 3CICGRPINFO Memory + Swap limit exceeded count : 0 3CICGRPINFO OOM Killer Disabled : 0 3CICGRPINFO Under OOM : 0 NULL NATIVEMEMINFO This section records information about native memory that is requested by using library functions such as malloc() and mmap() . Values are provided as a breakdown, per component, indicating the total number of bytes allocated and the number of native memory allocations. In the following example, 4,682,840 bytes of native memory are allocated (but not yet freed) to VM Classes, which corresponds to 141 allocations. NULL ------------------------------------------------------------------------ 0SECTION NATIVEMEMINFO subcomponent dump routine NULL ================================= 0MEMUSER 1MEMUSER JRE: 2,569,088,312 bytes / 4653 allocations 1MEMUSER | 2MEMUSER +--VM: 2,280,088,336 bytes / 2423 allocations 2MEMUSER | | 3MEMUSER | +--Classes: 4,682,840 bytes / 141 allocations 2MEMUSER | | 3MEMUSER | +--Memory Manager (GC): 2,054,966,784 bytes / 433 allocations 3MEMUSER | | | 4MEMUSER | | +--Java Heap: 2,014,113,792 bytes / 1 allocation 3MEMUSER | | | 4MEMUSER | | +--Other: 40,852,992 bytes / 432 allocations 2MEMUSER | | 3MEMUSER | +--Threads: 10,970,016 bytes / 156 allocations 3MEMUSER | | | 4MEMUSER | | +--Java Stack: 197,760 bytes / 16 allocations 3MEMUSER | | | 4MEMUSER | | +--Native Stack: 10,616,832 bytes / 17 allocations 3MEMUSER | | | 4MEMUSER | | +--Other: 155,424 bytes / 123 allocations 2MEMUSER | | 3MEMUSER | +--Trace: 180,056 bytes / 263 allocations 2MEMUSER | | 3MEMUSER | +--JVMTI: 17,776 bytes / 13 allocations 2MEMUSER | | 3MEMUSER | +--JNI: 36,184 bytes / 52 allocations 2MEMUSER | | 3MEMUSER | +--Port Library: 208,179,632 bytes / 72 allocations 3MEMUSER | | | 4MEMUSER | | +--Unused <32bit allocation regions: 208,168,752 bytes / 1 allocation 3MEMUSER | | | 4MEMUSER | | +--Other: 10,880 bytes / 71 allocations 2MEMUSER | | 3MEMUSER | +--Other: 1,055,048 bytes / 1293 allocations 1MEMUSER | 2MEMUSER +--JIT: 288,472,816 bytes / 140 allocations 2MEMUSER | | 3MEMUSER | +--JIT Code Cache: 268,435,456 bytes / 1 allocation 2MEMUSER | | 3MEMUSER | +--JIT Data Cache: 2,097,216 bytes / 1 allocation 2MEMUSER | | 3MEMUSER | +--Other: 17,940,144 bytes / 138 allocations 1MEMUSER | 2MEMUSER +--Class Libraries: 13,432 bytes / 25 allocations 2MEMUSER | | 3MEMUSER | +--VM Class Libraries: 13,432 bytes / 25 allocations 3MEMUSER | | | 4MEMUSER | | +--sun.misc.Unsafe: 3,184 bytes / 13 allocations 4MEMUSER | | | | 5MEMUSER | | | +--Direct Byte Buffers: 1,056 bytes / 12 allocations 4MEMUSER | | | | 5MEMUSER | | | +--Other: 2,128 bytes / 1 allocation 3MEMUSER | | | 4MEMUSER | | +--Other: 10,248 bytes / 12 allocations 1MEMUSER | 2MEMUSER +--Unknown: 513,728 bytes / 2065 allocations NULL This section does not record memory that is allocated by application or JNI code and is typically a little less than the value recorded by operating system tools. MEMINFO This section relates to memory management, providing a breakdown of memory usage in the VM for the object heap, internal memory, memory used for classes, the JIT code cache, and JIT data cache in decimal and hexadecimal format. You can also find out which garbage collection policy is in use when the dump is produced. The object memory area ( 1STHEAPTYPE ) records each memory region in use, its start and end address, and region size. Further information is recorded about the memory segments used for internal memory, class memory, the JIT code cache and JIT data cache ( 1STSEGMENT ). This information includes the address of the segment control data structure, the start and end address of the native memory segment, as well as the segment size. For clarity, the following example shows a shortened version of this section, where ... indicates that lines are removed: NULL ------------------------------------------------------------------------ 0SECTION MEMINFO subcomponent dump routine NULL ================================= NULL 1STHEAPTYPE Object Memory NULL id start end size space/region 1STHEAPSPACE 0x00007FF4F00744A0 -- -- -- Generational 1STHEAPREGION 0x00007FF4F0074CE0 0x0000000087F40000 0x0000000088540000 0x0000000000600000 Generational/Tenured Region 1STHEAPREGION 0x00007FF4F0074930 0x00000000FFE00000 0x00000000FFF00000 0x0000000000100000 Generational/Nursery Region 1STHEAPREGION 0x00007FF4F0074580 0x00000000FFF00000 0x0000000100000000 0x0000000000100000 Generational/Nursery Region NULL 1STHEAPTOTAL Total memory: 8388608 (0x0000000000800000) 1STHEAPINUSE Total memory in use: 2030408 (0x00000000001EFB48) 1STHEAPFREE Total memory free: 6358200 (0x00000000006104B8) NULL 1STSEGTYPE Internal Memory NULL segment start alloc end type size 1STSEGMENT 0x00007FF4F004CBC8 0x00007FF4CD33C000 0x00007FF4CD33C000 0x00007FF4CE33C000 0x01000440 0x0000000001000000 1STSEGMENT 0x00007FF4F004CB08 0x00007FF4DE43D030 0x00007FF4DE517770 0x00007FF4DE53D030 0x00800040 0x0000000000100000 NULL 1STSEGTOTAL Total memory: 17825792 (0x0000000001100000) 1STSEGINUSE Total memory in use: 894784 (0x00000000000DA740) 1STSEGFREE Total memory free: 16931008 (0x00000000010258C0) NULL 1STSEGTYPE Class Memory NULL segment start alloc end type size 1STSEGMENT 0x00007FF4F03B5638 0x0000000001053D98 0x000000000105BD98 0x000000000105BD98 0x00010040 0x0000000000008000 1STSEGMENT 0x00007FF4F03B5578 0x0000000001048188 0x0000000001050188 0x0000000001050188 0x00010040 0x0000000000008000 ... NULL 1STSEGTOTAL Total memory: 3512520 (0x00000000003598C8) 1STSEGINUSE Total memory in use: 3433944 (0x00000000003465D8) 1STSEGFREE Total memory free: 78576 (0x00000000000132F0) NULL 1STSEGTYPE JIT Code Cache NULL segment start alloc end type size 1STSEGMENT 0x00007FF4F00961F8 0x00007FF4CE43D000 0x00007FF4CE445790 0x00007FF4DE43D000 0x00000068 0x0000000010000000 NULL 1STSEGTOTAL Total memory: 268435456 (0x0000000010000000) 1STSEGINUSE Total memory in use: 34704 (0x0000000000008790) 1STSEGFREE Total memory free: 268400752 (0x000000000FFF7870) 1STSEGLIMIT Allocation limit: 268435456 (0x0000000010000000) NULL 1STSEGTYPE JIT Data Cache NULL segment start alloc end type size 1STSEGMENT 0x00007FF4F0096668 0x00007FF4CC553030 0x00007FF4CC753030 0x00007FF4CC753030 0x00000048 0x0000000000200000 NULL 1STSEGTOTAL Total memory: 2097152 (0x0000000000200000) 1STSEGINUSE Total memory in use: 2097152 (0x0000000000200000) 1STSEGFREE Total memory free: 0 (0x0000000000000000) 1STSEGLIMIT Allocation limit: 402653184 (0x0000000018000000) NULL 1STGCHTYPE GC History NULL In the example, the GC History ( 1STGCHTYPE ) section is blank. This section is populated if a garbage collection cycle occurred in a VM that is being diagnosed with the trace facility. LOCKS This section of the Java dump provides information about locks, which protect shared resources from being accessed by more than one entity at a time. The information is essential in a deadlock situation, where two threads attempt to synchronize on an object and lock an instance of a class. Precise information is recorded about the threads that are causing the problem, which enables you to identify the root cause. The following example shows a typical LOCKS section, where no deadlocks existed at the time the dump was triggered. For clarity, the following example shows a shortened version of this section, where ... indicates that lines are removed: NULL ------------------------------------------------------------------------ 0SECTION LOCKS subcomponent dump routine NULL =============================== NULL 1LKPOOLINFO Monitor pool info: 2LKPOOLTOTAL Current total number of monitors: 3 NULL 1LKMONPOOLDUMP Monitor Pool Dump (flat & inflated object-monitors): 2LKMONINUSE sys_mon_t:0x00007FF4B0001D78 infl_mon_t: 0x00007FF4B0001DF8: 3LKMONOBJECT java/lang/ref/ReferenceQueue@0x00000000FFE26A10: <unowned> 3LKNOTIFYQ Waiting to be notified: 3LKWAITNOTIFY \"Common-Cleaner\" (J9VMThread:0x0000000000FD0100) NULL 1LKREGMONDUMP JVM System Monitor Dump (registered monitors): 2LKREGMON Thread global lock (0x00007FF4F0004FE8): <unowned> 2LKREGMON &(PPG_mem_mem32_subAllocHeapMem32.monitor) lock (0x00007FF4F0005098): <unowned> 2LKREGMON NLS hash table lock (0x00007FF4F0005148): <unowned> ... NULL THREADS The THREADS section of a Java dump file provides summary information about the VM thread pool and detailed information about Java threads, native threads, and stack traces. Understanding the content of this section can help you diagnose problems that are caused by blocked or waiting threads. A Java thread runs on a native thread. Several lines are recorded for each Java thread in the Thread Details subsection, which include the following key pieces of information: 3XMTHREADINFO : The thread name, address information for the VM thread structures and Java thread object, the thread state, and thread priority. 3XMJAVALTHREAD : The Java thread ID and daemon status from the thread object. 3XMTHREADINFO1 : The native operating system thread ID, priority, scheduling policy, internal VM thread state, and VM thread flags. 3XMTHREADINFO2 : The native stack address range. 3XMTHREADINFO3 : Java callstack information ( 4XESTACKTRACE ) or Native call stack information ( 4XENATIVESTACK ). 5XESTACKTRACE : This line indicates whether locks were taken by a specific method. Java thread priorities are mapped to operating system priority values. Thread states are shown in the following table: Thread state value Status Description R Runnable The thread is able to run CW Condition Wait The thread is waiting S Suspended The thread is suspended by another thread Z Zombie The thread is destroyed P Parked The thread is parked by java.util.concurrent B Blocked The thread is waiting to obtain a lock For threads that are parked (P), blocked (B), or waiting (CW), an additional line ( 3XMTHREADBLOCK ) is included in the output that shows what the thread is parked on, blocked on, or waiting for. For clarity, the following example shows a shortened version of a typical THREADS section, where ... indicates that lines are removed: NULL ------------------------------------------------------------------------ 0SECTION THREADS subcomponent dump routine NULL ================================= NULL 1XMPOOLINFO JVM Thread pool info: 2XMPOOLTOTAL Current total number of pooled threads: 18 2XMPOOLLIVE Current total number of live threads: 16 2XMPOOLDAEMON Current total number of live daemon threads: 15 NULL 1XMTHDINFO Thread Details NULL 3XMTHREADINFO \"JIT Diagnostic Compilation Thread-7 Suspended\" J9VMThread:0x0000000000EFC500, omrthread_t:0x00007FF4F00A77E8, java/lang/Thread:0x00000000FFE97480, state:R, prio=10 3XMJAVALTHREAD (java/lang/Thread getId:0xA, isDaemon:true) 3XMTHREADINFO1 (native thread ID:0x7657, native priority:0xB, native policy:UNKNOWN, vmstate:CW, vm thread flags:0x00000081) 3XMTHREADINFO2 (native stack address range from:0x00007FF4CCC36000, to:0x00007FF4CCD36000, size:0x100000) 3XMCPUTIME CPU usage total: 0.000037663 secs, current category=\"JIT\" 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) 3XMTHREADINFO3 No Java callstack associated with this thread 3XMTHREADINFO3 No native callstack available for this thread NULL ... 3XMTHREADINFO \"Common-Cleaner\" J9VMThread:0x0000000000FD0100, omrthread_t:0x00007FF4F022A520, java/lang/Thread:0x00000000FFE26F40, state:CW, prio=8 3XMJAVALTHREAD (java/lang/Thread getId:0x2, isDaemon:true) 3XMTHREADINFO1 (native thread ID:0x765A, native priority:0x8, native policy:UNKNOWN, vmstate:CW, vm thread flags:0x00080181) 3XMTHREADINFO2 (native stack address range from:0x00007FF4CC0B8000, to:0x00007FF4CC0F8000, size:0x40000) 3XMCPUTIME CPU usage total: 0.000150926 secs, current category=\"Application\" 3XMTHREADBLOCK Waiting on: java/lang/ref/ReferenceQueue@0x00000000FFE26A10 Owned by: <unowned> 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at java/lang/Object.wait(Native Method) 4XESTACKTRACE at java/lang/Object.wait(Object.java:221) 4XESTACKTRACE at java/lang/ref/ReferenceQueue.remove(ReferenceQueue.java:138) 5XESTACKTRACE (entered lock: java/lang/ref/ReferenceQueue@0x00000000FFE26A10, entry count: 1) 4XESTACKTRACE at jdk/internal/ref/CleanerImpl.run(CleanerImpl.java:148) 4XESTACKTRACE at java/lang/Thread.run(Thread.java:835) 4XESTACKTRACE at jdk/internal/misc/InnocuousThread.run(InnocuousThread.java:122) 3XMTHREADINFO3 No native callstack available for this thread NULL NULL 3XMTHREADINFO \"IProfiler\" J9VMThread:0x0000000000F03D00, omrthread_t:0x00007FF4F00B06F8, java/lang/Thread:0x00000000FFE97B60, state:R, prio=5 3XMJAVALTHREAD (java/lang/Thread getId:0xC, isDaemon:true) 3XMTHREADINFO1 (native thread ID:0x7659, native priority:0x5, native policy:UNKNOWN, vmstate:CW, vm thread flags:0x00000081) 3XMTHREADINFO2 (native stack address range from:0x00007FF4F8940000, to:0x00007FF4F8960000, size:0x20000) 3XMCPUTIME CPU usage total: 0.004753103 secs, current category=\"JIT\" 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) 3XMTHREADINFO3 No Java callstack associated with this thread 3XMTHREADINFO3 No native callstack available for this thread NULL ... 1XMWLKTHDERR The following was reported while collecting native stacks: 2XMWLKTHDERR unable to count threads(3, -2) NULL 1XMTHDSUMMARY Threads CPU Usage Summary NULL ========================= NULL 1XMTHDCATINFO Warning: to get more accurate CPU times for the GC, the option -XX:-ReduceCPUMonitorOverhead can be used. See the user guide for more information. NULL 1XMTHDCATEGORY All JVM attached threads: 0.280083000 secs 1XMTHDCATEGORY | 2XMTHDCATEGORY +--System-JVM: 0.270814000 secs 2XMTHDCATEGORY | | 3XMTHDCATEGORY | +--GC: 0.000599000 secs 2XMTHDCATEGORY | | 3XMTHDCATEGORY | +--JIT: 0.071904000 secs 1XMTHDCATEGORY | 2XMTHDCATEGORY +--Application: 0.009269000 secs NULL HOOKS This section shows internal VM event callbacks, which are used for diagnosing performance problems in the VM. Multiple hook interfaces are listed, which include their individual hook events. The following example shows data for the J9VMHookInterface , including the total time for all previous events, the call site location (<source file>:<line number>), start time, and duration of the last callback and the longest callback (all times measured in microseconds). The hook data is reset after each Java dump. NULL ------------------------------------------------------------------------ SECTION HOOK subcomponent dump routine NULL ========================= 1NOTE These data are reset every time a javacore is taken 1HKINTERFACE MM_OMRHookInterface NULL ------------------------------------------------------------------------ 1HKINTERFACE MM_PrivateHookInterface NULL ------------------------------------------------------------------------ 1HKINTERFACE MM_HookInterface NULL ------------------------------------------------------------------------ 1HKINTERFACE J9VMHookInterface NULL ------------------------------------------------------------------------ 2HKEVENTID 1 3HKCALLCOUNT 1239 3HKTOTALTIME 219564us 3HKLAST Last Callback 4HKCALLSITE trcengine.c:395 4HKSTARTTIME Start Time: 2019-10-18T00:15:14.664 4HKDURATION Duration : 16us 3HKLONGST Longest Callback 4HKCALLSITE trcengine.c:395 4HKSTARTTIME Start Time: 2019-10-18T21:28:34.895 4HKDURATION Duration : 5012us NULL ... 1HKINTERFACE J9VMZipCachePoolHookInterface NULL ------------------------------------------------------------------------ 1HKINTERFACE J9JITHookInterface NULL ------------------------------------------------------------------------ 2HKEVENTID 3 3HKCALLCOUNT 3113 3HKTOTALTIME 4904us 3HKLAST Last Callback 4HKCALLSITE common/mgmtinit.c:193 4HKSTARTTIME Start Time: 2019-10-18T16:04:15.320 4HKDURATION Duration : 3us 3HKLONGST Longest Callback 4HKCALLSITE common/mgmtinit.c:193 4HKSTARTTIME Start Time: 2019-10-18T16:37:17.633 4HKDURATION Duration : 27us NULL ... SHARED CLASSES If the shared classes cache is enabled at run time, the information provided in a Java dump file describes settings that were used when creating the cache, together with summary information about the size and content of the cache. In the following example, the shared classes cache was created with a Class Debug Area ( -Xnolinenumbers=false ). Byte code instrumentation (BCI) is enabled, which is the default, and VMs sharing the cache are allowed to store classpaths, which is also the default. The Cache Summary shows a cache size ( 2SCLTEXTCSZ ) of 16776608 bytes, with a soft maximum size ( 2SCLTEXTSMB ) also of 16776608 bytes, which leaves 12691668 bytes of free space ( 2SCLTEXTFRB ). The size of the Class Debug Area ( 2SCLTEXTDAS ) is 1331200 bytes and only 11% of this space is used. In the Cache Memory Status subsection, the line 2SCLTEXTCMDT indicates the name and location of the shared cache and cr indicates that the cache is a 64-bit compressed references cache. NULL ------------------------------------------------------------------------ 0SECTION SHARED CLASSES subcomponent dump routine NULL ======================================== NULL 1SCLTEXTCRTW Cache Created With NULL ------------------ NULL 2SCLTEXTXNL -Xnolinenumbers = false 2SCLTEXTBCI BCI Enabled = true 2SCLTEXTBCI Restrict Classpaths = false NULL 1SCLTEXTCSUM Cache Summary NULL ------------------ NULL 2SCLTEXTNLC No line number content = false 2SCLTEXTLNC Line number content = true NULL 2SCLTEXTRCS ROMClass start address = 0x00007F423061C000 2SCLTEXTRCE ROMClass end address = 0x00007F42307B9A28 2SCLTEXTMSA Metadata start address = 0x00007F42313D42FC 2SCLTEXTCEA Cache end address = 0x00007F4231600000 2SCLTEXTRTF Runtime flags = 0x00102001ECA6028B 2SCLTEXTCGN Cache generation = 35 NULL 2SCLTEXTCSZ Cache size = 16776608 2SCLTEXTSMB Softmx bytes = 16776608 2SCLTEXTFRB Free bytes = 12691668 2SCLTEXTRCB ROMClass bytes = 1694248 2SCLTEXTAOB AOT code bytes = 0 2SCLTEXTADB AOT data bytes = 0 2SCLTEXTAHB AOT class hierarchy bytes = 32 2SCLTEXTATB AOT thunk bytes = 0 2SCLTEXTARB Reserved space for AOT bytes = -1 2SCLTEXTAMB Maximum space for AOT bytes = -1 2SCLTEXTJHB JIT hint bytes = 308 2SCLTEXTJPB JIT profile bytes = 2296 2SCLTEXTJRB Reserved space for JIT data bytes = -1 2SCLTEXTJMB Maximum space for JIT data bytes = -1 2SCLTEXTNOB Java Object bytes = 0 2SCLTEXTZCB Zip cache bytes = 919328 2SCLTEXTSHB Startup hint bytes = 0 2SCLTEXTRWB ReadWrite bytes = 114080 2SCLTEXTJCB JCL data bytes = 0 2SCLTEXTBDA Byte data bytes = 0 2SCLTEXTMDA Metadata bytes = 23448 2SCLTEXTDAS Class debug area size = 1331200 2SCLTEXTDAU Class debug area % used = 11% 2SCLTEXTDAN Class LineNumberTable bytes = 156240 2SCLTEXTDAV Class LocalVariableTable bytes = 0 NULL 2SCLTEXTNRC Number ROMClasses = 595 2SCLTEXTNAM Number AOT Methods = 0 2SCLTEXTNAD Number AOT Data Entries = 0 2SCLTEXTNAH Number AOT Class Hierarchy = 1 2SCLTEXTNAT Number AOT Thunks = 0 2SCLTEXTNJH Number JIT Hints = 14 2SCLTEXTNJP Number JIT Profiles = 20 2SCLTEXTNCP Number Classpaths = 1 2SCLTEXTNUR Number URLs = 0 2SCLTEXTNTK Number Tokens = 0 2SCLTEXTNOJ Number Java Objects = 0 2SCLTEXTNZC Number Zip Caches = 5 2SCLTEXTNSH Number Startup Hint Entries = 0 2SCLTEXTNJC Number JCL Entries = 0 2SCLTEXTNST Number Stale classes = 0 2SCLTEXTPST Percent Stale classes = 0% NULL 2SCLTEXTCPF Cache is 24% full NULL 1SCLTEXTCMST Cache Memory Status NULL ------------------ 1SCLTEXTCNTD Cache Name Feature Memory type Cache path NULL 2SCLTEXTCMDT sharedcc_doc-javacore CR Memory mapped file /tmp/javasharedresources/C290M4F1A64P_sharedcc_doc-javacore_G35 NULL 1SCLTEXTCMST Cache Lock Status NULL ------------------ 1SCLTEXTCNTD Lock Name Lock type TID owning lock NULL 2SCLTEXTCWRL Cache write lock File lock Unowned 2SCLTEXTCRWL Cache read/write lock File lock Unowned NULL The following example shows information for a layered cache: NULL ------------------------------------------------------------------------ 0SECTION SHARED CLASSES subcomponent dump routine NULL ======================================== NULL 1SCLTEXTCSTL Cache Statistics for Top Layer NULL 1SCLTEXTCRTW Cache Created With NULL ------------------ NULL 2SCLTEXTXNL -Xnolinenumbers = false 2SCLTEXTBCI BCI Enabled = true 2SCLTEXTBCI Restrict Classpaths = false NULL 1SCLTEXTCSUM Cache Summary NULL ------------------ NULL 2SCLTEXTNLC No line number content = false 2SCLTEXTLNC Line number content = false NULL 2SCLTEXTRCS ROMClass start address = 0x00007F0EDB567000 2SCLTEXTRCE ROMClass end address = 0x00007F0EDB567000 2SCLTEXTMSA Metadata start address = 0x00007F0EDC40241C 2SCLTEXTCEA Cache end address = 0x00007F0EDC54B000 2SCLTEXTRTF Runtime flags = 0x80102001ECA602BB 2SCLTEXTCGN Cache generation = 41 2SCLTEXTCLY Cache layer = 1 NULL 2SCLTEXTCSZ Cache size = 16776608 2SCLTEXTSMB Softmx bytes = 16776608 2SCLTEXTFRB Free bytes = 15315996 2SCLTEXTARB Reserved space for AOT bytes = -1 2SCLTEXTAMB Maximum space for AOT bytes = -1 2SCLTEXTJRB Reserved space for JIT data bytes = -1 2SCLTEXTJMB Maximum space for JIT data bytes = -1 2SCLTEXTRWB ReadWrite bytes = 114080 2SCLTEXTDAS Class debug area size = 1331200 2SCLTEXTDAU Class debug area % used = 0% 2SCLTEXTDAN Class LineNumberTable bytes = 0 2SCLTEXTDAV Class LocalVariableTable bytes = 0 NULL 2SCLTEXTCPF Cache is 8% full NULL 1SCLTEXTCMST Cache Memory Status NULL ------------------ 1SCLTEXTCNTD Cache Name Feature Memory type Cache path NULL 2SCLTEXTCMDT Cache1 CR Memory mapped file /tmp/javasharedresources/C290M4F1A64P_Cache1_G41L01 NULL 1SCLTEXTCMST Cache Lock Status NULL ------------------ 1SCLTEXTCNTD Lock Name Lock type TID owning lock NULL 2SCLTEXTCWRL Cache write lock File lock Unowned 2SCLTEXTCRWL Cache read/write lock File lock Unowned NULL 1SCLTEXTCSAL Cache Statistics for All Layers NULL 2SCLTEXTRCB ROMClass bytes = 1459040 2SCLTEXTAOB AOT code bytes = 57624 2SCLTEXTADB AOT data bytes = 272 2SCLTEXTAHB AOT class hierarchy bytes = 1840 2SCLTEXTATB AOT thunk bytes = 632 2SCLTEXTJHB JIT hint bytes = 484 2SCLTEXTJPB JIT profile bytes = 0 2SCLTEXTNOB Java Object bytes = 0 2SCLTEXTZCB Zip cache bytes = 1134016 2SCLTEXTSHB Startup hint bytes = 0 2SCLTEXTJCB JCL data bytes = 0 2SCLTEXTBDA Byte data bytes = 0 NULL 2SCLTEXTNRC Number ROMClasses = 503 2SCLTEXTNAM Number AOT Methods = 16 2SCLTEXTNAD Number AOT Data Entries = 1 2SCLTEXTNAH Number AOT Class Hierarchy = 28 2SCLTEXTNAT Number AOT Thunks = 11 2SCLTEXTNJH Number JIT Hints = 15 2SCLTEXTNJP Number JIT Profiles = 0 2SCLTEXTNCP Number Classpaths = 1 2SCLTEXTNUR Number URLs = 0 2SCLTEXTNTK Number Tokens = 0 2SCLTEXTNOJ Number Java Objects = 0 2SCLTEXTNZC Number Zip Caches = 21 2SCLTEXTNSH Number Startup Hint Entries = 0 2SCLTEXTNJC Number JCL Entries = 0 2SCLTEXTNST Number Stale classes = 0 2SCLTEXTPST Percent Stale classes = 0% CLASSES The classes section shows information about class loaders. The first part is a summary that records each available class loader ( 2CLTEXTCLLOADER ) followed by the number of libraries and classes that it loaded. This information is followed by a more detailed list of libraries ( 1CLTEXTCLLIB ) and classes ( 1CLTEXTCLLO ) that are loaded. In the example you can see that the java/lang/InternalAnonymousClassLoader loaded 2 classes, jdk/internal/loader/BuiltinClassLoader$$Lambda$2/00000000F03876A0(0x0000000001030F00) and jdk/internal/loader/BuiltinClassLoader$$Lambda$1/00000000F00D2460(0x0000000001018A00) . NULL ------------------------------------------------------------------------ 0SECTION CLASSES subcomponent dump routine NULL ================================= 1CLTEXTCLLOS Classloader summaries 1CLTEXTCLLSS 12345678: 1=primordial,2=extension,3=shareable,4=middleware,5=system,6=trusted,7=application,8=delegating 2CLTEXTCLLOADER p---st-- Loader *System*(0x00000000FFE1D258) 3CLNMBRLOADEDLIB Number of loaded libraries 5 3CLNMBRLOADEDCL Number of loaded classes 638 2CLTEXTCLLOADER -x--st-- Loader jdk/internal/loader/ClassLoaders$PlatformClassLoader(0x00000000FFE1D4F0), Parent *none*(0x0000000000000000) 3CLNMBRLOADEDLIB Number of loaded libraries 0 3CLNMBRLOADEDCL Number of loaded classes 0 2CLTEXTCLLOADER ----st-- Loader java/lang/InternalAnonymousClassLoader(0x00000000FFE1DFD0), Parent *none*(0x0000000000000000) 3CLNMBRLOADEDLIB Number of loaded libraries 0 3CLNMBRLOADEDCL Number of loaded classes 2 2CLTEXTCLLOADER -----ta- Loader jdk/internal/loader/ClassLoaders$AppClassLoader(0x00000000FFE1DAD0), Parent jdk/internal/loader/ClassLoaders$PlatformClassLoader(0x00000000FFE1D4F0) 3CLNMBRLOADEDLIB Number of loaded libraries 0 3CLNMBRLOADEDCL Number of loaded classes 0 1CLTEXTCLLIB ClassLoader loaded libraries 2CLTEXTCLLIB Loader *System*(0x00000000FFE1D258) 3CLTEXTLIB /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/compressedrefs/jclse9_29 3CLTEXTLIB /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/java 3CLTEXTLIB /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/compressedrefs/j9jit29 3CLTEXTLIB /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/zip 3CLTEXTLIB /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/nio 1CLTEXTCLLOD ClassLoader loaded classes 2CLTEXTCLLOAD Loader *System*(0x00000000FFE1D258) 3CLTEXTCLASS [Ljava/lang/Thread$State;(0x0000000001056400) ... 2CLTEXTCLLOAD Loader jdk/internal/loader/ClassLoaders$PlatformClassLoader(0x00000000FFE1D4F0) 2CLTEXTCLLOAD Loader java/lang/InternalAnonymousClassLoader(0x00000000FFE1DFD0) 3CLTEXTCLASS jdk/internal/loader/BuiltinClassLoader$$Lambda$2/00000000F03876A0(0x0000000001030F00) 3CLTEXTCLASS jdk/internal/loader/BuiltinClassLoader$$Lambda$1/00000000F00D2460(0x0000000001018A00) 2CLTEXTCLLOAD Loader jdk/internal/loader/ClassLoaders$AppClassLoader(0x00000000FFE1DAD0) Scenarios General Protection Fault In this scenario, a Java application has crashed due to a General Protection Fault (GPF), automatically generating a Java dump file. The first section of the file (TITLE) tells you that the GPF triggered the Java dump. 0SECTION TITLE subcomponent dump routine NULL =============================== 1TICHARSET UTF-8 1TISIGINFO Dump Event \"gpf\" (00002000) received 1TIDATETIMEUTC Date: 2021/04/23 at 18:02:44:017 (UTC) 1TIDATETIME Date: 2021/04/23 at 14:02:44:017 1TITIMEZONE Timezone: UTC-4 (EDT) 1TINANOTIME System nanotime: 379202644260787 1TIFILENAME Javacore filename: /home/test/JNICrasher/javacore.20210423.140244.29399.0002.txt 1TIREQFLAGS Request Flags: 0x81 (exclusive+preempt) 1TIPREPSTATE Prep State: 0x100 (trace_disabled) 1TIPREPINFO Exclusive VM access not taken: data may not be consistent across javacore sections To troubleshoot this problem, you need to know which thread caused the GPF to occur. The thread that was running at the time of the crash is reported as the current thread in the THREADS section of the Java dump. Here is an extract from the THREADS section: NULL ------------------------------------------------------------------------ 0SECTION THREADS subcomponent dump routine NULL ================================= NULL 1XMPOOLINFO JVM Thread pool info: 2XMPOOLTOTAL Current total number of pooled threads: 16 2XMPOOLLIVE Current total number of live threads: 15 2XMPOOLDAEMON Current total number of live daemon threads: 14 NULL 1XMCURTHDINFO Current thread 3XMTHREADINFO \"main\" J9VMThread:0xB6B60E00, omrthread_t:0xB6B049D8, java/lang/Thread:0xB55444D0, state:R, prio=5 3XMJAVALTHREAD (java/lang/Thread getId:0x1, isDaemon:false) 3XMTHREADINFO1 (native thread ID:0x72D8, native priority:0x5, native policy:UNKNOWN, vmstate:R, vm thread flags:0x00000000) 3XMTHREADINFO2 (native stack address range from:0xB6CE3000, to:0xB74E4000, size:0x801000) 3XMCPUTIME CPU usage total: 0.319865924 secs, current category=\"Application\" 3XMHEAPALLOC Heap bytes allocated since last GC cycle=778008 (0xBDF18) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at JNICrasher.doSomethingThatCrashes(Native Method) 4XESTACKTRACE at JNICrasher.main(JNICrasher.java:7) 3XMTHREADINFO3 Native callstack: 4XENATIVESTACK (0xB6C6F663 [libj9prt29.so+0x3b663]) 4XENATIVESTACK (0xB6C52F6E [libj9prt29.so+0x1ef6e]) 4XENATIVESTACK (0xB6C6F1CE [libj9prt29.so+0x3b1ce]) 4XENATIVESTACK (0xB6C6F2C6 [libj9prt29.so+0x3b2c6]) 4XENATIVESTACK (0xB6C6ED93 [libj9prt29.so+0x3ad93]) 4XENATIVESTACK (0xB6C52F6E [libj9prt29.so+0x1ef6e]) 4XENATIVESTACK (0xB6C6ED07 [libj9prt29.so+0x3ad07]) 4XENATIVESTACK (0xB6C6AA3D [libj9prt29.so+0x36a3d]) 4XENATIVESTACK (0xB6C6C3A4 [libj9prt29.so+0x383a4]) 4XENATIVESTACK (0xB667FA19 [libj9dmp29.so+0xfa19]) 4XENATIVESTACK (0xB6C52F6E [libj9prt29.so+0x1ef6e]) 4XENATIVESTACK (0xB66878CF [libj9dmp29.so+0x178cf]) 4XENATIVESTACK (0xB6688083 [libj9dmp29.so+0x18083]) 4XENATIVESTACK (0xB6C52F6E [libj9prt29.so+0x1ef6e]) 4XENATIVESTACK (0xB6680C0D [libj9dmp29.so+0x10c0d]) 4XENATIVESTACK (0xB667F9D7 [libj9dmp29.so+0xf9d7]) 4XENATIVESTACK (0xB6C52F6E [libj9prt29.so+0x1ef6e]) 4XENATIVESTACK (0xB668B02F [libj9dmp29.so+0x1b02f]) 4XENATIVESTACK (0xB668B4D3 [libj9dmp29.so+0x1b4d3]) 4XENATIVESTACK (0xB66740F1 [libj9dmp29.so+0x40f1]) 4XENATIVESTACK (0xB66726FA [libj9dmp29.so+0x26fa]) 4XENATIVESTACK (0xB6C52F6E [libj9prt29.so+0x1ef6e]) 4XENATIVESTACK (0xB66726A9 [libj9dmp29.so+0x26a9]) 4XENATIVESTACK (0xB6676AE4 [libj9dmp29.so+0x6ae4]) 4XENATIVESTACK (0xB668D75A [libj9dmp29.so+0x1d75a]) 4XENATIVESTACK (0xB6A28DD4 [libj9vm29.so+0x81dd4]) 4XENATIVESTACK (0xB6C52F6E [libj9prt29.so+0x1ef6e]) 4XENATIVESTACK (0xB6A289EE [libj9vm29.so+0x819ee]) 4XENATIVESTACK (0xB6A29A40 [libj9vm29.so+0x82a40]) 4XENATIVESTACK (0xB6C52B6A [libj9prt29.so+0x1eb6a]) 4XENATIVESTACK __kernel_rt_sigreturn+0x0 (0xB7747410) 4XENATIVESTACK (0xB75330B6 [libffi29.so+0x50b6]) 4XENATIVESTACK ffi_raw_call+0xad (0xB7531C53 [libffi29.so+0x3c53]) 4XENATIVESTACK (0xB69BE4AB [libj9vm29.so+0x174ab]) 4XENATIVESTACK (0xB6A665BC [libj9vm29.so+0xbf5bc]) 4XENATIVESTACK (0xB6A15552 [libj9vm29.so+0x6e552]) 4XENATIVESTACK (0xB6A30894 [libj9vm29.so+0x89894]) 4XENATIVESTACK (0xB6A6F169 [libj9vm29.so+0xc8169]) 4XENATIVESTACK (0xB6C52F6E [libj9prt29.so+0x1ef6e]) 4XENATIVESTACK (0xB6A6F1FA [libj9vm29.so+0xc81fa]) 4XENATIVESTACK (0xB6A30994 [libj9vm29.so+0x89994]) 4XENATIVESTACK (0xB6A2CE4C [libj9vm29.so+0x85e4c]) 4XENATIVESTACK (0xB770487D [libjli.so+0x787d]) 4XENATIVESTACK (0xB7719F72 [libpthread.so.0+0x6f72]) 4XENATIVESTACK clone+0x5e (0xB763543E [libc.so.6+0xee43e]) The extract tells you that the current thread was java/lang/Thread , and information is provided about the Java callstack and native callstack ( 3XMTHREADINFO3 ) at the point at which the crash occurred. To simulate a crash caused by a bug in an application, this example calls a JNI method whose native implementation causes a crash. The Java callstack shows the call to the JNI native method ( JNIcrasher ), and the native callstack shows the point of failure. In this example, the native call stack does not include any function names to help you isolate the error in the native code. You can get this information from a system dump, which is usually produced alongside the Java dump. Open the system dump with the Dump viewer and use the info thread command to print the Java and native stack for the current thread. Java OutOfMemoryError In this scenario, the Java heap runs out of memory, causing an OutOfMemoryError , which automatically generates a Java dump file. The first section of the file (TITLE) tells you that a systhrow event triggered the Java dump as a result of an OOM ( java/lang/OutOfMemoryError ) for Java heap space. 0SECTION TITLE subcomponent dump routine NULL =============================== 1TICHARSET UTF-8 1TISIGINFO Dump Event \"systhrow\" (00040000) Detail \"java/lang/OutOfMemoryError\" \"Java heap space\" received 1TIDATETIMEUTC Date: 2021/04/23 at 18:02:44:017 (UTC) 1TIDATETIME Date: 2021/04/23 at 14:02:44:017 1TITIMEZONE Timezone: UTC-4 (EDT) 1TINANOTIME System nanotime: 379202644260787 1TIFILENAME Javacore filename: /home/cheesemp/test/javacore.20210423.140244.18885.0003.txt 1TIREQFLAGS Request Flags: 0x81 (exclusive+preempt) 1TIPREPSTATE Prep State: 0x104 (exclusive_vm_access+trace_disabled) The MEMINFO section records how much memory is allocated to the Java heap ( 1STHEAPTYPE Object Memory ), how much is in use, and how much is free. Solving your problem might be as simple as setting a larger heap size when you start your application. If you don't know what size the Java heap was set to, you might find that information in the ENVINFO section, which records the command line options that were used when the application started. Look or search for the 1CIUSERARGS UserArgs: string and review the entries recorded for all lines that start 2CIUSERARG . The Java heap size is set by the -Xmx option. If the size has not been set on the command line by -Xmx , the default value applies, which you can find in Default Settings . In this scenario the solution to the problem is not an adjustment to the Java heap size. Here is the MEMINFO section: 0SECTION MEMINFO subcomponent dump routine NULL ================================= NULL 1STHEAPTYPE Object Memory NULL id start end size space/region 1STHEAPSPACE 0xB6B49D20 -- -- -- Generational 1STHEAPREGION 0xB6B4A078 0x95750000 0xB5470000 0x1FD20000 Generational/Tenured Region 1STHEAPREGION 0xB6B49F10 0xB5470000 0xB54C0000 0x00050000 Generational/Nursery Region 1STHEAPREGION 0xB6B49DA8 0xB54C0000 0xB5750000 0x00290000 Generational/Nursery Region NULL 1STHEAPTOTAL Total memory: 536870912 (0x20000000) 1STHEAPINUSE Total memory in use: 302603160 (0x12095B98) 1STHEAPFREE Total memory free: 234267752 (0x0DF6A468) The output shows that only 56% of the Java heap is in use, so this suggests that the application is trying to do something sub-optimal. To investigate further you need to work out which thread was the current thread when the OOM occurred to see what it was trying to do. As in the previous scenario, you can find the current thread in the THREADS section. Here is an extract from the output: 0SECTION THREADS subcomponent dump routine NULL ================================= NULL 1XMPOOLINFO JVM Thread pool info: 2XMPOOLTOTAL Current total number of pooled threads: 16 2XMPOOLLIVE Current total number of live threads: 16 2XMPOOLDAEMON Current total number of live daemon threads: 15 NULL 1XMCURTHDINFO Current thread 3XMTHREADINFO \"main\" J9VMThread:0xB6B60C00, omrthread_t:0xB6B049D8, java/lang/Thread:0x95764520, state:R, prio=5 3XMJAVALTHREAD (java/lang/Thread getId:0x1, isDaemon:false) 3XMTHREADINFO1 (native thread ID:0x49C6, native priority:0x5, native policy:UNKNOWN, vmstate:R, vm thread flags:0x00001020) 3XMTHREADINFO2 (native stack address range from:0xB6CB5000, to:0xB74B6000, size:0x801000) 3XMCPUTIME CPU usage total: 8.537823831 secs, current category=\"Application\" 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at java/lang/StringBuffer.ensureCapacityImpl(StringBuffer.java:696) 4XESTACKTRACE at java/lang/StringBuffer.append(StringBuffer.java:486(Compiled Code)) 5XESTACKTRACE (entered lock: java/lang/StringBuffer@0x957645B8, entry count: 1) 4XESTACKTRACE at java/lang/StringBuffer.append(StringBuffer.java:428(Compiled Code)) 4XESTACKTRACE at HeapBreaker.main(HeapBreaker.java:34(Compiled Code)) 3XMTHREADINFO3 Native callstack: 4XENATIVESTACK (0xB6C535B3 [libj9prt29.so+0x3b5b3]) 4XENATIVESTACK (0xB6C36F3E [libj9prt29.so+0x1ef3e]) 4XENATIVESTACK (0xB6C5311E [libj9prt29.so+0x3b11e]) 4XENATIVESTACK (0xB6C53216 [libj9prt29.so+0x3b216]) 4XENATIVESTACK (0xB6C52CE3 [libj9prt29.so+0x3ace3]) 4XENATIVESTACK (0xB6C36F3E [libj9prt29.so+0x1ef3e]) 4XENATIVESTACK (0xB6C52C57 [libj9prt29.so+0x3ac57]) 4XENATIVESTACK (0xB6C4E9CD [libj9prt29.so+0x369cd]) 4XENATIVESTACK (0xB6C502FA [libj9prt29.so+0x382fa]) To simulate a Java OutOfMemoryError , this example application repeatedly appends characters to a StringBuffer object in an infinite loop. The Java callstack shows the HeapBreaker.main method appending characters ( java/lang/StringGuffer.append ) until the method java/lang/StringBuffer.ensureCapacityImpl() throws the OutOfMemoryError . StringBuffer objects are wrappers for character arrays ( char[] ) and when the capacity of the underlying array is reached, the contents are automatically copied into a new, larger array. The new array is created in the StringBuffer.ensureCapacity() method, which more or less doubles the size of the old array. In this scenario, the array takes up all the remaining space in the Java heap. The MEMINFO section of the Java dump file can also tell you when an unexpectedly large allocation request causes an OOM. Look for the GC History ( 1STGCHTYPE ) section, which details allocation requests that trigger GC activity. In the sample output you can see that a large allocation request ( requestedbytes=603979784 ) triggered a global GC. When the GC could not free up sufficient space in the heap to satisfy the request, the allocation failure generated the OOM. 1STGCHTYPE GC History 3STHSTTYPE 14:29:29:580239000 GMT j9mm.101 - J9AllocateIndexableObject() returning NULL! 0 bytes requested for object of class B6BBC300 from memory space 'Generational' id=B6B49D20 3STHSTTYPE 14:29:29:579916000 GMT j9mm.134 - Allocation failure end: newspace=2686912/3014656 oldspace=231597224/533856256 loa=5338112/5338112 3STHSTTYPE 14:29:29:579905000 GMT j9mm.470 - Allocation failure cycle end: newspace=2686912/3014656 oldspace=231597224/533856256 loa=5338112/5338112 3STHSTTYPE 14:29:29:579859000 GMT j9mm.475 - GlobalGC end: workstackoverflow=0 overflowcount=0 memory=234284136/536870912 3STHSTTYPE 14:29:29:579807000 GMT j9mm.90 - GlobalGC collect complete 3STHSTTYPE 14:29:29:579776000 GMT j9mm.137 - Compact end: bytesmoved=301989896 3STHSTTYPE 14:29:29:313899000 GMT j9mm.136 - Compact start: reason=compact to meet allocation 3STHSTTYPE 14:29:29:313555000 GMT j9mm.57 - Sweep end 3STHSTTYPE 14:29:29:310772000 GMT j9mm.56 - Sweep start 3STHSTTYPE 14:29:29:310765000 GMT j9mm.94 - Class unloading end: classloadersunloaded=0 classesunloaded=0 3STHSTTYPE 14:29:29:310753000 GMT j9mm.60 - Class unloading start 3STHSTTYPE 14:29:29:310750000 GMT j9mm.55 - Mark end 3STHSTTYPE 14:29:29:306013000 GMT j9mm.54 - Mark start 3STHSTTYPE 14:29:29:305957000 GMT j9mm.474 - GlobalGC start: globalcount=9 3STHSTTYPE 14:29:29:305888000 GMT j9mm.475 - GlobalGC end: workstackoverflow=0 overflowcount=0 memory=234284136/536870912 3STHSTTYPE 14:29:29:305837000 GMT j9mm.90 - GlobalGC collect complete 3STHSTTYPE 14:29:29:305808000 GMT j9mm.137 - Compact end: bytesmoved=189784 3STHSTTYPE 14:29:29:298042000 GMT j9mm.136 - Compact start: reason=compact to meet allocation 3STHSTTYPE 14:29:29:297695000 GMT j9mm.57 - Sweep end 3STHSTTYPE 14:29:29:291696000 GMT j9mm.56 - Sweep start 3STHSTTYPE 14:29:29:291692000 GMT j9mm.55 - Mark end 3STHSTTYPE 14:29:29:284994000 GMT j9mm.54 - Mark start 3STHSTTYPE 14:29:29:284941000 GMT j9mm.474 - GlobalGC start: globalcount=8 3STHSTTYPE 14:29:29:284916000 GMT j9mm.135 - Exclusive access: exclusiveaccessms=0.016 meanexclusiveaccessms=0.016 threads=0 lastthreadtid=0xB6B61100 beatenbyotherthread=0 3STHSTTYPE 14:29:29:284914000 GMT j9mm.469 - Allocation failure cycle start: newspace=2678784/3014656 oldspace=80601248/533856256 loa=5338112/5338112 requestedbytes=603979784 3STHSTTYPE 14:29:29:284893000 GMT j9mm.470 - Allocation failure cycle end: newspace=2678784/3014656 oldspace=80601248/533856256 loa=5338112/5338112 3STHSTTYPE 14:29:29:284858000 GMT j9mm.560 - LocalGC end: rememberedsetoverflow=0 causedrememberedsetoverflow=0 scancacheoverflow=0 failedflipcount=0 failedflipbytes=0 failedtenurecount=0 failedtenurebytes=0 flipcount=2 flipbytes=64 newspace=2678784/3014656 oldspace=80601248/533856256 loa=5338112/5338112 tenureage=0 3STHSTTYPE 14:29:29:284140000 GMT j9mm.140 - Tilt ratio: 89 3STHSTTYPE 14:29:29:283160000 GMT j9mm.64 - LocalGC start: globalcount=8 scavengecount=335 weakrefs=0 soft=0 phantom=0 finalizers=0 3STHSTTYPE 14:29:29:283123000 GMT j9mm.135 - Exclusive access: exclusiveaccessms=0.016 meanexclusiveaccessms=0.016 threads=0 lastthreadtid=0xB6B61100 beatenbyotherthread=0 3STHSTTYPE 14:29:29:283120000 GMT j9mm.469 - Allocation failure cycle start: newspace=753616/3014656 oldspace=80601248/533856256 loa=5338112/5338112 requestedbytes=603979784 3STHSTTYPE 14:29:29:283117000 GMT j9mm.133 - Allocation failure start: newspace=753616/3014656 oldspace=80601248/533856256 loa=5338112/5338112 requestedbytes=603979784 3STHSTTYPE 14:29:29:269762000 GMT j9mm.134 - Allocation failure end: newspace=2686928/3014656 oldspace=80601248/533856256 loa=5338112/5338112 3STHSTTYPE 14:29:29:269751000 GMT j9mm.470 - Allocation failure cycle end: newspace=2686976/3014656 oldspace=80601248/533856256 loa=5338112/5338112 3STHSTTYPE 14:29:29:269718000 GMT j9mm.560 - LocalGC end: rememberedsetoverflow=0 causedrememberedsetoverflow=0 scancacheoverflow=0 failedflipcount=0 failedflipbytes=0 failedtenurecount=0 failedtenurebytes=0 flipcount=0 flipbytes=0 newspace=2686976/3014656 oldspace=80601248/533856256 loa=5338112/5338112 tenureage=0 3STHSTTYPE 14:29:29:268981000 GMT j9mm.140 - Tilt ratio: 89 3STHSTTYPE 14:29:29:268007000 GMT j9mm.64 - LocalGC start: globalcount=8 scavengecount=334 weakrefs=0 soft=0 phantom=0 finalizers=0 3STHSTTYPE 14:29:29:267969000 GMT j9mm.135 - Exclusive access: exclusiveaccessms=0.016 meanexclusiveaccessms=0.016 threads=0 lastthreadtid=0xB6B61100 beatenbyotherthread=0 3STHSTTYPE 14:29:29:267966000 GMT j9mm.469 - Allocation failure cycle start: newspace=0/3014656 oldspace=80601248/533856256 loa=5338112/5338112 requestedbytes=48 3STHSTTYPE 14:29:29:267963000 GMT j9mm.133 - Allocation failure start: newspace=0/3014656 oldspace=80601248/533856256 loa=5338112/5338112 requestedbytes=48 3STHSTTYPE 14:29:29:249015000 GMT j9mm.134 - Allocation failure end: newspace=2686928/3014656 oldspace=80601248/533856256 loa=5338112/5338112 3STHSTTYPE 14:29:29:249003000 GMT j9mm.470 - Allocation failure cycle end: newspace=2686976/3014656 oldspace=80601248/533856256 loa=5338112/5338112 3STHSTTYPE 14:29:29:248971000 GMT j9mm.560 - LocalGC end: rememberedsetoverflow=0 causedrememberedsetoverflow=0 scancacheoverflow=0 failedflipcount=0 failedflipbytes=0 failedtenurecount=0 failedtenurebytes=0 flipcount=0 flipbytes=0 newspace=2686976/3014656 oldspace=80601248/533856256 loa=5338112/5338112 tenureage=0 Although the Java code that was used in this scenario deliberately triggered an OutOfMemoryError in a pronounced way, similar allocation issues can and do occur when dealing with large data sets such as XML files. The next step in diagnosing the problem is to open the system dump that gets generated automatically when an OutOfMemoryError occurs. Open the dump with the Eclipse Memory Analyzer tool (MAT) and search for the StringBuffer object, which should provide further clues about what went wrong. A common example is seeing the same String duplicated over and over again, which might indicate that code is stuck in a loop. Note: If you want to use MAT to analyze your system dump, you must install the Diagnostic Tool Framework for Java (DTFJ) plugin in the Eclipse IDE. Select the following menu items: Help > Install New Software > Work with \"IBM Diagnostic Tool Framework for Java\" > If, unlike the previous scenario, you receive an OutOfMemoryError and the MEMINFO section shows that there is very little space left on the Java heap, the current thread information is typically not important. The current thread is simply the thread that happened to be current when the space ran out. In this situation you might want to increase your Java heap size. For help with this task, see How to do heap sizing . Native OutOfMemoryError In this scenario, the VM runs out of native memory. Native memory is memory that is used by the VM for storing all virtualized resources and data that it needs for VM operations. Native memory that is available to the VM process is limited by the operating system. The native memory available to the VM might also be subject to additional limits imposed by the operating system, for example Unix ulimits . When a NativeOutOfMemoryError occurs, a Java dump is generated by default. The first section of the file (TITLE) tells you that a systhrow event triggered the Java dump as a result of an OOM ( java/lang/OutOfMemoryError ) for native memory. 0SECTION TITLE subcomponent dump routine NULL =============================== 1TICHARSET UTF-8 1TISIGINFO Dump Event \"systhrow\" (00040000) Detail \"java/lang/OutOfMemoryError\" \"native memory exhausted\" received 1TIDATETIMEUTC Date: 2021/04/23 at 18:02:44:017 (UTC) 1TIDATETIME Date: 2021/04/23 at 14:02:44:017 1TITIMEZONE Timezone: UTC-4 (EDT) 1TINANOTIME System nanotime: 379202644260787 1TIFILENAME Javacore filename: /home/cheesemp/test/javacore.20210423.140244.19708.0003.txt 1TIREQFLAGS Request Flags: 0x81 (exclusive+preempt) 1TIPREPSTATE Prep State: 0x104 (exclusive_vm_access+trace_disabled) Sometimes, the current thread is responsible for causing the NativeOutOfMemoryError . Information about the current thread can be found in the THREADS section, as shown in the following output. 0SECTION THREADS subcomponent dump routine NULL ================================= NULL 1XMPOOLINFO JVM Thread pool info: 2XMPOOLTOTAL Current total number of pooled threads: 16 2XMPOOLLIVE Current total number of live threads: 16 2XMPOOLDAEMON Current total number of live daemon threads: 15 NULL 1XMCURTHDINFO Current thread 3XMTHREADINFO \"main\" J9VMThread:0xB6C60C00, omrthread_t:0xB6C049D8, java/lang/Thread:0xB55E3C10, state:R, prio=5 3XMJAVALTHREAD (java/lang/Thread getId:0x1, isDaemon:false) 3XMTHREADINFO1 (native thread ID:0x4CFD, native priority:0x5, native policy:UNKNOWN, vmstate:R, vm thread flags:0x00001020) 3XMTHREADINFO2 (native stack address range from:0xB6D4E000, to:0xB754F000, size:0x801000) 3XMCPUTIME CPU usage total: 3.654896026 secs, current category=\"Application\" 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at sun/misc/Unsafe.allocateDBBMemory(Native Method) 4XESTACKTRACE at java/nio/DirectByteBuffer.<init>(DirectByteBuffer.java:127(Compiled Code)) 4XESTACKTRACE at java/nio/ByteBuffer.allocateDirect(ByteBuffer.java:311) 4XESTACKTRACE at NativeHeapBreaker.main(NativeHeapBreaker.java:9) 3XMTHREADINFO3 Native callstack: 4XENATIVESTACK (0xB6A9F5B3 [libj9prt29.so+0x3b5b3]) ... 4XENATIVESTACK (0xB582CC9C [libjclse7b_29.so+0x40c9c]) 4XENATIVESTACK Java_sun_misc_Unsafe_allocateDBBMemory+0x88 (0xB5827F6B [libjclse7b_29.so+0x3bf6b]) 4XENATIVESTACK (0x94A2084A [<unknown>+0x0]) 4XENATIVESTACK (0xB6B2538B [libj9vm29.so+0x6c38b]) 4XENATIVESTACK (0xB6B4074C [libj9vm29.so+0x8774c]) 4XENATIVESTACK (0xB6B7F299 [libj9vm29.so+0xc6299]) 4XENATIVESTACK (0xB6A82F3E [libj9prt29.so+0x1ef3e]) 4XENATIVESTACK (0xB6B7F32A [libj9vm29.so+0xc632a]) 4XENATIVESTACK (0xB6B4084C [libj9vm29.so+0x8784c]) 4XENATIVESTACK (0xB6B3CD0C [libj9vm29.so+0x83d0c]) 4XENATIVESTACK (0xB776F87D [libjli.so+0x787d]) 4XENATIVESTACK (0xB7784F72 [libpthread.so.0+0x6f72]) 4XENATIVESTACK clone+0x5e (0xB76A043E [libc.so.6+0xee43e]) For clarity in the Native callstack output, ... indicates that some lines are removed. The Java callstack shows the transition from Java to native code ( sun/misc/Unsafe.allocateDBBMemory(Native Method) ), indicating a request for Direct Byte Buffer (DBB) storage. DBB storage is backed by native memory, with the Java heap containing only a reference to the native heap buffer. In this scenario, DBB storage is the likely culprit for this NativeOutOfMemoryError . The next step is to investigate the NATIVEMEMINFO section of the Java dump file, which reports the amount of memory used by the JRE process, broken down into component areas. 0SECTION NATIVEMEMINFO subcomponent dump routine NULL ================================= 0MEMUSER 1MEMUSER JRE: 3,166,386,688 bytes / 4388 allocations 1MEMUSER | 2MEMUSER +--VM: 563,176,824 bytes / 1518 allocations 2MEMUSER | | 3MEMUSER | +--Classes: 3,104,416 bytes / 120 allocations 2MEMUSER | | 3MEMUSER | +--Memory Manager (GC): 548,181,888 bytes / 398 allocations 3MEMUSER | | | 4MEMUSER | | +--Java Heap: 536,932,352 bytes / 1 allocation 3MEMUSER | | | 4MEMUSER | | +--Other: 11,249,536 bytes / 397 allocations 2MEMUSER | | 3MEMUSER | +--Threads: 10,817,120 bytes / 147 allocations 3MEMUSER | | | 4MEMUSER | | +--Java Stack: 115,584 bytes / 16 allocations 3MEMUSER | | | 4MEMUSER | | +--Native Stack: 10,616,832 bytes / 17 allocations 3MEMUSER | | | 4MEMUSER | | +--Other: 84,704 bytes / 114 allocations 2MEMUSER | | 3MEMUSER | +--Trace: 163,688 bytes / 268 allocations 2MEMUSER | | 3MEMUSER | +--JVMTI: 17,320 bytes / 13 allocations 2MEMUSER | | 3MEMUSER | +--JNI: 23,296 bytes / 55 allocations 2MEMUSER | | 3MEMUSER | +--Port Library: 8,576 bytes / 74 allocations 2MEMUSER | | 3MEMUSER | +--Other: 860,520 bytes / 443 allocations 1MEMUSER | 2MEMUSER +--JIT: 3,744,728 bytes / 122 allocations 2MEMUSER | | 3MEMUSER | +--JIT Code Cache: 2,097,152 bytes / 1 allocation 2MEMUSER | | 3MEMUSER | +--JIT Data Cache: 524,336 bytes / 1 allocation 2MEMUSER | | 3MEMUSER | +--Other: 1,123,240 bytes / 120 allocations 1MEMUSER | 2MEMUSER +--Class Libraries: 2,599,463,024 bytes / 2732 allocations 2MEMUSER | | 3MEMUSER | +--Harmony Class Libraries: 1,024 bytes / 1 allocation 2MEMUSER | | 3MEMUSER | +--VM Class Libraries: 2,599,462,000 bytes / 2731 allocations 3MEMUSER | | | 4MEMUSER | | +--sun.misc.Unsafe: 2,598,510,480 bytes / 2484 allocations 4MEMUSER | | | | 5MEMUSER | | | +--Direct Byte Buffers: 2,598,510,480 bytes / 2484 allocations 3MEMUSER | | | 4MEMUSER | | +--Other: 951,520 bytes / 247 allocations 1MEMUSER | 2MEMUSER +--Unknown: 2,112 bytes / 16 allocations NULL In the VM Class Libraries section, the amount of memory allocated for Direct Byte Buffers is shown. Because the NativeOutOfMemoryError was received on a small 32-bit system, a value of 2,598,510,480 bytes indicates that the operating system has run out of memory. On a larger UNIX system, the process might have run out of memory because of the ulimit setting. Increasing the value for ulimit might avoid the error, which you can do temporarily by setting ulimit -f unlimited in your current session. The theoretical maximum size for a 32-bit process is the size of the 32-bit address space, which is 4 GB. On most operating systems a portion of the address space for each process is used by the kernel, such that the real limit for 32-bit processes is actually significantly less than 4GB. As a result, running out of native memory with a 32-bit VM is quite common. The same 4 GB limit is also important if you are using a 64-bit VM with compressed references. In compressed references mode, all references to objects, classes, threads, and monitors are represented by 32-bit values for performance reasons, so these structures can be allocated only at 32-bit addresses. However, the operating system might place other allocations within this 4 GB of address space, and if this area becomes sufficiently full or fragmented, the VM throws a native NativeOutOfMemoryError error. These errors typically occur when the VM tries to create a new thread or load a class. The Current Thread History section should contain more information about what the thread was doing at the VM level when the NativeOutOfMemoryError error occurred. You can usually avoid this type of problem by using the -Xmcrs option to reserve a contiguous area of memory within the lowest 4GB of memory at VM startup. Another common cause of a NativeOutOfMemoryError is when an application loads duplicate classes. Classes are allocated outside of the Java heap in native memory. If the value reported for Classes in the NATIVEMEMINFO section is very large, duplicate classes might be the cause of your problem. The Eclipse Memory Analyzer Tool (MAT) can tell you if you have duplicate classes by using the Class Loader Explorer feature. Because a system dump is automatically generated as well as a Java dump in response to a NativeOutOfMemoryError , simply open the system dump in MAT to continue your diagnosis. Deadlock Deadlocks occur when two threads attempt to synchronize on an object and lock an instance of a class. When this happens, your application stops responding and hangs. Generating a Java dump file will quickly tell you whether you have a deadlock situation. Trigger the Java dump by sending a SIGQUIT signal ( kill -3 ) to the VM. The VM can detect the most common types of deadlock scenario involving Java monitors. If this type of deadlock is detected, information is provided in the LOCKS section. More complex deadlocks, including those that involve a mixture of native mutexes and Java monitors, are not detected. Here is the output from the code that was used to cause a common deadlock scenario: NULL 1LKDEADLOCK Deadlock detected !!! NULL --------------------- NULL 2LKDEADLOCKTHR Thread \"Worker Thread 2\" (0x94501D00) 3LKDEADLOCKWTR is waiting for: 4LKDEADLOCKMON sys_mon_t:0x08C2B344 infl_mon_t: 0x08C2B384: 4LKDEADLOCKOBJ java/lang/Object@0xB5666698 3LKDEADLOCKOWN which is owned by: 2LKDEADLOCKTHR Thread \"Worker Thread 3\" (0x94507500) 3LKDEADLOCKWTR which is waiting for: 4LKDEADLOCKMON sys_mon_t:0x08C2B3A0 infl_mon_t: 0x08C2B3E0: 4LKDEADLOCKOBJ java/lang/Object@0xB5666678 3LKDEADLOCKOWN which is owned by: 2LKDEADLOCKTHR Thread \"Worker Thread 1\" (0x92A3EC00) 3LKDEADLOCKWTR which is waiting for: 4LKDEADLOCKMON sys_mon_t:0x08C2B2E8 infl_mon_t: 0x08C2B328: 4LKDEADLOCKOBJ java/lang/Object@0xB5666688 3LKDEADLOCKOWN which is owned by: 2LKDEADLOCKTHR Thread \"Worker Thread 2\" (0x94501D00) This output tells you that Worker Thread 2 is waiting for Worker Thread 3 , which is waiting for Worker Thread 1 . Because Worker Thread 1 is also waiting for Worker Thread 2 , there is a deadlock. The next place to look is the output for Java and native stacks, in the THREADS section. By looking at the stack for each of these worker threads you can trace the problem back to specific lines in your application code. In this example, you can see from the following output that for all worker threads, the stack traces ( 4XESTACKTRACE / 5XESTACKTRACE ) indicate a problem in line 35 of the application DeadLockTest.java : 3XMTHREADINFO \"Worker Thread 1\" J9VMThread:0x92A3EC00, omrthread_t:0x92A3C2B0, java/lang/Thread:0xB5666778, state:B, prio=5 3XMJAVALTHREAD (java/lang/Thread getId:0x13, isDaemon:false) 3XMTHREADINFO1 (native thread ID:0x52CF, native priority:0x5, native policy:UNKNOWN, vmstate:B, vm thread flags:0x00000201) 3XMTHREADINFO2 (native stack address range from:0x9297E000, to:0x929BF000, size:0x41000) 3XMCPUTIME CPU usage total: 0.004365543 secs, current category=\"Application\" 3XMTHREADBLOCK Blocked on: java/lang/Object@0xB5666688 Owned by: \"Worker Thread 2\" (J9VMThread:0x94501D00, java/lang/Thread:0xB56668D0) 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at WorkerThread.run(DeadLockTest.java:35) 5XESTACKTRACE (entered lock: java/lang/Object@0xB5666678, entry count: 1) ... 3XMTHREADINFO \"Worker Thread 2\" J9VMThread:0x94501D00, omrthread_t:0x92A3C8F0, java/lang/Thread:0xB56668D0, state:B, prio=5 3XMJAVALTHREAD (java/lang/Thread getId:0x14, isDaemon:false) 3XMTHREADINFO1 (native thread ID:0x52D0, native priority:0x5, native policy:UNKNOWN, vmstate:B, vm thread flags:0x00000201) 3XMTHREADINFO2 (native stack address range from:0x946BF000, to:0x94700000, size:0x41000) 3XMCPUTIME CPU usage total: 0.004555580 secs, current category=\"Application\" 3XMTHREADBLOCK Blocked on: java/lang/Object@0xB5666698 Owned by: \"Worker Thread 3\" (J9VMThread:0x94507500, java/lang/Thread:0xB5666A18) 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at WorkerThread.run(DeadLockTest.java:35) 5XESTACKTRACE (entered lock: java/lang/Object@0xB5666688, entry count: 1) ... 3XMTHREADINFO \"Worker Thread 3\" J9VMThread:0x94507500, omrthread_t:0x92A3CC10, java/lang/Thread:0xB5666A18, state:B, prio=5 3XMJAVALTHREAD (java/lang/Thread getId:0x15, isDaemon:false) 3XMTHREADINFO1 (native thread ID:0x52D1, native priority:0x5, native policy:UNKNOWN, vmstate:B, vm thread flags:0x00000201) 3XMTHREADINFO2 (native stack address range from:0x9467E000, to:0x946BF000, size:0x41000) 3XMCPUTIME CPU usage total: 0.003657010 secs, current category=\"Application\" 3XMTHREADBLOCK Blocked on: java/lang/Object@0xB5666678 Owned by: \"Worker Thread 1\" (J9VMThread:0x92A3EC00, java/lang/Thread:0xB5666778) 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at WorkerThread.run(DeadLockTest.java:35) 5XESTACKTRACE (entered lock: java/lang/Object@0xB5666698, entry count: 1) Hang An application can hang for a number of reasons but the most common cause is excessive global garbage collection (GC) activity, where your application is repeatedly paused because your Java heap has almost run out of memory. You can identify this problem by looking at verbose GC output. Collect this output by specifying the -verbose:gc option. Deadlock situations can also manifest themselves as hangs. For more information on diagnosing this type of problem from a Java dump, see the deadlock scenario. If you have eliminated verbose GC activity and deadlocks, another common hang scenario involves threads that compete and wait for Java object locks. This type of problem can usually be diagnosed by examining a Java dump. The simplest hang scenario involving Java object locks is where a thread acquires a lock that other threads are waiting for, but it doesn't release the lock for some reason. The first place to look in the Java dump output is the LOCKS section. This section lists all the monitors and shows which threads have acquired a lock and which threads are waiting. If the hang is caused by a thread not releasing a lock that other threads need, you can see a list of waiting threads in the output. In this example scenario, the Java dump LOCKS section shows that Worker Thread 0 ( 3LKMONOBJECT ) has acquired a lock and there are 19 other worker threads waiting to obtain the lock. NULL ------------------------------------------------------------------------ 0SECTION LOCKS subcomponent dump routine NULL =============================== NULL 1LKPOOLINFO Monitor pool info: 2LKPOOLTOTAL Current total number of monitors: 1 NULL 1LKMONPOOLDUMP Monitor Pool Dump (flat & inflated object-monitors): 2LKMONINUSE sys_mon_t:0x92711200 infl_mon_t: 0x92711240: 3LKMONOBJECT java/lang/Object@0xB56658D8: Flat locked by \"Worker Thread 0\" (J9VMThread:0x92A3EC00), entry count 1 3LKWAITERQ Waiting to enter: 3LKWAITER \"Worker Thread 1\" (J9VMThread:0x92703F00) 3LKWAITER \"Worker Thread 2\" (J9VMThread:0x92709C00) 3LKWAITER \"Worker Thread 3\" (J9VMThread:0x92710A00) 3LKWAITER \"Worker Thread 4\" (J9VMThread:0x92717F00) 3LKWAITER \"Worker Thread 5\" (J9VMThread:0x9271DC00) 3LKWAITER \"Worker Thread 6\" (J9VMThread:0x92723A00) 3LKWAITER \"Worker Thread 7\" (J9VMThread:0x92729800) 3LKWAITER \"Worker Thread 8\" (J9VMThread:0x92733700) 3LKWAITER \"Worker Thread 9\" (J9VMThread:0x92739400) 3LKWAITER \"Worker Thread 10\" (J9VMThread:0x92740200) 3LKWAITER \"Worker Thread 11\" (J9VMThread:0x92748100) 3LKWAITER \"Worker Thread 12\" (J9VMThread:0x9274DF00) 3LKWAITER \"Worker Thread 13\" (J9VMThread:0x92754D00) 3LKWAITER \"Worker Thread 14\" (J9VMThread:0x9275AA00) 3LKWAITER \"Worker Thread 15\" (J9VMThread:0x92760800) 3LKWAITER \"Worker Thread 16\" (J9VMThread:0x92766600) 3LKWAITER \"Worker Thread 17\" (J9VMThread:0x9276C300) 3LKWAITER \"Worker Thread 18\" (J9VMThread:0x92773100) 3LKWAITER \"Worker Thread 19\" (J9VMThread:0x92778F00) NULL The next step is to determine why Worker Thread 0 is not releasing the lock. The best place to start is the stack trace for this thread, which you can find by searching on the thread name or J9VMThread ID in the THREADS section. The following extract shows the details for \"Worker Thread 0\" (J9VMThread:0x92A3EC00) : NULL 3XMTHREADINFO \"Worker Thread 0\" J9VMThread:0x92A3EC00, omrthread_t:0x92A3C280, java/lang/Thread:0xB56668B8, state:CW, prio=5 3XMJAVALTHREAD (java/lang/Thread getId:0x13, isDaemon:false) 3XMTHREADINFO1 (native thread ID:0x511F, native priority:0x5, native policy:UNKNOWN, vmstate:CW, vm thread flags:0x00000401) 3XMTHREADINFO2 (native stack address range from:0x9297E000, to:0x929BF000, size:0x41000) 3XMCPUTIME CPU usage total: 0.000211878 secs, current category=\"Application\" 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at java/lang/Thread.sleep(Native Method) 4XESTACKTRACE at java/lang/Thread.sleep(Thread.java:941) 4XESTACKTRACE at WorkerThread.doWork(HangTest.java:37) 4XESTACKTRACE at WorkerThread.run(HangTest.java:31) 5XESTACKTRACE (entered lock: java/lang/Object@0xB56658D8, entry count: 1) In the last line of this output you can see where the thread acquired the lock. Working up from this line, you can see that WorkerThread.run was called, which in turn called WorkerThread.doWork . The stack shows that the thread then entered a call to java/lang/Thread.sleep in HangTest.java on line 37, which is preventing the thread from completing its work and releasing the lock. In this example the sleep call was added to induce a hang, but in real-world scenarios the cause could be any blocking operation, such as reading from an input stream or socket. Another possibility is that the thread is waiting for another lock owned by yet another thread. It is important to remember that each Java dump represents a single snapshot in time. You should generate at least three Java dumps separated by a short pause, for example 30 seconds, and compare the output. This comparison tells you whether the threads involved are stuck in a fixed state or whether they are moving. In this example, the threads do not move and the investigation needs to focus on the logic in WorkerThread.doWork to understand why Worker Thread 0 entered the java/lang/Thread.sleep call. Another common scenario is where each Java dump shows a number of threads waiting for a lock owned by another thread, but the list of waiting threads and the lock-owning thread change over time. In this case the cause is likely to be a bottleneck caused by thread contention, where the threads are continually competing for the same lock. In severe cases, the lock is held only for a small amount of time but there are lots of threads trying to obtain it. Because more time is spent handling the lock and scheduling the thread than executing application code, the degradation in performance is manifested as a hang. Thread contention is usually caused by an application design problem. You can use a similar approach to the one used in this scenario to determime which lines of code are responsible for the contention.","title":"Java dump"},{"location":"dump_javadump/#java-dump","text":"Java dumps, sometimes referred to as Java cores , are produced when the VM ends unexpectedly because of an operating system signal, OutOfMemoryError , or a user-initiated keystroke combination. You can also generate a Java dump by calling the Dump API programmatically from your application or specifying the -Xdump:java option on the command line. If your Java application crashes or hangs, Java dumps can provide useful information to help you diagnose the root cause. If your application crashes, Java dumps are generated automatically for the following types of failure: the VM receives an unexpected signal or an assertion failure the VM runs out of memory If your application hangs, you can trigger the generation of a Java dump by sending a SIGQUIT signal ( kill -3 ) to the VM. Note: On Windows, if you started the VM in a console window you can force the VM to produce a Java dump in response to a SIGBREAK signal (Ctrl-Break keyboard combination). If you didn't start in a console window there is no equivalent to a Linux kill command on Windows for sending signals. The only option here is to trigger a full system dump by finding the VM process in the Processes tab of the Windows Task Manager and clicking Create dump file . To help you understand how a Java dump can help you with problem diagnosis, this topic includes a few scenarios to help you interpret the data: A crash caused by a general protection fault (gpf) A Java heap OutOfMemoryError (OOM) A native OutOfMemoryError (OOM) A deadlock situation A hang","title":"Java dump"},{"location":"dump_javadump/#java-dump-contents","text":"Java dumps summarize the state of the VM when the event occurs, with most of the information relating to components of the VM. The file is made up of a number of sections that provide different types of information.","title":"Java dump contents"},{"location":"dump_javadump/#title","text":"The first section of the Java dump file provides information about the event that triggered the production of the dump. In the following example you can see that a vmstop event triggered the dump at a specified date and time. 0SECTION TITLE subcomponent dump routine NULL =============================== 1TICHARSET UTF-8 1TISIGINFO Dump Event \"vmstop\" (00000002) Detail \"#0000000000000000\" received 1TIDATETIMEUTC Date: 2021/04/23 at 18:02:44:017 (UTC) 1TIDATETIME Date: 2021/04/23 at 14:02:44:017 1TITIMEZONE Timezone: UTC-4 (EDT) 1TINANOTIME System nanotime: 379202644260787 1TIFILENAME Javacore filename: /home/doc-javacore/javacore.20210423.140244.1175.0001.txt 1TIREQFLAGS Request Flags: 0x81 (exclusive+preempt) 1TIPREPSTATE Prep State: 0x106 (vm_access+exclusive_vm_access+trace_disabled)","title":"TITLE"},{"location":"dump_javadump/#gpinfo","text":"The GPINFO section provides general information about the system that the VM is running on. The following example is taken from a Java dump that was generated on a Linux system. NULL ------------------------------------------------------------------------ 0SECTION GPINFO subcomponent dump routine NULL ================================ 2XHOSLEVEL OS Level : Linux 3.10.0-862.11.6.el7.x86_64 2XHCPUS Processors - 3XHCPUARCH Architecture : amd64 3XHNUMCPUS How Many : 4 3XHNUMASUP NUMA is either not supported or has been disabled by user NULL 1XHERROR2 Register dump section only produced for SIGSEGV, SIGILL or SIGFPE. NULL The content of this section can vary, depending on the cause of the dump. For example, if the dump was caused by a general protection fault (gpf), the library in which the crash occurred is also recorded, together with a value shown as VM flags . This value can provide some clues about which component of the VM might have been involved. Look for the following line in the output: 1XHFLAGS VM flags:0000000000000000 The hexadecimal number recorded for VM flags ends in MSSSS, where M is the VM component and SSSS is component-specific code as shown in the following table: Component Code value INTERPRETER 0x10000 GC 0x20000 GROW_STACK 0x30000 JNI 0x40000 JIT_CODEGEN 0x50000 BCVERIFY 0x60000 RTVERIFY 0x70000 SHAREDCLASSES 0x80000 A value of 0000000000000000 (0x00000) indicates that a crash occurred outside of the VM.","title":"GPINFO"},{"location":"dump_javadump/#envinfo","text":"This section contains useful information about the environment in which the crash took place, including the following data: Java version ( 1CIJAVAVERSION ) OpenJ9 VM and subcomponent version information ( 1CIVMVERSION , 1CIJ9VMVERSION , 1CIJITVERSION , 1CIOMRVERSION , 1CIJCLVERSION ) VM start time ( 1CISTARTTIME ) and process information ( 1CIPROCESSID ) Java home ( 1CIJAVAHOMEDIR ) and DLL ( 1CIJAVADLLDIR ) directories User arguments passed on the command line ( 1CIUSERARG ) User limits imposed by the system ( 1CIUSERLIMITS ) Environment variables in place ( 1CIENVVARS ) System information ( 1CISYSINFO ) CPU information ( 1CICPUINFO ) Control group (Cgroup) information ( 1CICGRPINFO ) For clarity, the following example shows a shortened version of this section, where ... indicates that lines are removed: NULL ------------------------------------------------------------------------ 0SECTION ENVINFO subcomponent dump routine NULL ================================= 1CIJAVAVERSION JRE 9 Linux amd64-64 (build 9.0.4-internal+0-adhoc..openj9-openjdk-jdk9) 1CIVMVERSION 20180830_000000 1CIJ9VMVERSION 8e7c6ec 1CIJITVERSION 8e7c6ec 1CIOMRVERSION 553811b_CMPRSS 1CIJCLVERSION ec1d223 based on jdk-9.0.4+12 1CIJITMODES JIT enabled, AOT enabled, FSD disabled, HCR enabled 1CIRUNNINGAS Running as a standalone JVM 1CIVMIDLESTATE VM Idle State: ACTIVE 1CICONTINFO Running in container : FALSE 1CICGRPINFO JVM support for cgroups enabled : TRUE 1CISTARTTIME JVM start time: 2018/08/30 at 21:55:47:387 1CISTARTNANO JVM start nanotime: 22012135233549 1CIPROCESSID Process ID: 30285 (0x764D) 1CICMDLINE [not available] 1CIJAVAHOMEDIR Java Home Dir: /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk 1CIJAVADLLDIR Java DLL Dir: /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/bin 1CISYSCP Sys Classpath: 1CIUSERARGS UserArgs: 2CIUSERARG -Xoptionsfile=/home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/options.default ... NULL 1CIUSERLIMITS User Limits (in bytes except for NOFILE and NPROC) NULL ------------------------------------------------------------------------ NULL type soft limit hard limit 2CIUSERLIMIT RLIMIT_AS unlimited unlimited 2CIUSERLIMIT RLIMIT_CORE 0 unlimited 2CIUSERLIMIT RLIMIT_CPU unlimited unlimited 2CIUSERLIMIT RLIMIT_DATA unlimited unlimited 2CIUSERLIMIT RLIMIT_FSIZE unlimited unlimited 2CIUSERLIMIT RLIMIT_LOCKS unlimited unlimited 2CIUSERLIMIT RLIMIT_MEMLOCK 65536 65536 2CIUSERLIMIT RLIMIT_NOFILE 4096 4096 2CIUSERLIMIT RLIMIT_NPROC 4096 30592 2CIUSERLIMIT RLIMIT_RSS unlimited unlimited 2CIUSERLIMIT RLIMIT_STACK 8388608 unlimited 2CIUSERLIMIT RLIMIT_MSGQUEUE 819200 819200 2CIUSERLIMIT RLIMIT_NICE 0 0 2CIUSERLIMIT RLIMIT_RTPRIO 0 0 2CIUSERLIMIT RLIMIT_SIGPENDING 30592 30592 NULL 1CIENVVARS Environment Variables NULL ------------------------------------------------------------------------ 2CIENVVAR XDG_VTNR=1 2CIENVVAR SSH_AGENT_PID=2653 ... NULL 1CISYSINFO System Information NULL ------------------------------------------------------------------------ 2CISYSINFO /proc/sys/kernel/core_pattern = core 2CISYSINFO /proc/sys/kernel/core_uses_pid = 1 NULL 1CICPUINFO CPU Information NULL ------------------------------------------------------------------------ 2CIPHYSCPU Physical CPUs: 8 2CIONLNCPU Online CPUs: 8 2CIBOUNDCPU Bound CPUs: 8 2CIACTIVECPU Active CPUs: 0 2CITARGETCPU Target CPUs: 8 2CIJITFEATURE CPU features (JIT): fpu cx8 cmov mmx sse sse2 ssse3 fma sse4_1 popcnt aesni osxsave avx avx2 rdt_m 2CIAOTFEATURE CPU features (AOT): fpu cx8 cmov mmx sse sse2 ssse3 fma sse4_1 popcnt aesni osxsave avx avx2 rdt_m NULL 1CICGRPINFO Cgroup Information NULL ------------------------------------------------------------------------ 2CICGRPINFO subsystem : cpu 2CICGRPINFO cgroup name : / 3CICGRPINFO CPU Period : 100000 microseconds 3CICGRPINFO CPU Quota : Not Set 3CICGRPINFO CPU Shares : 1024 3CICGRPINFO Period intervals elapsed count : 0 3CICGRPINFO Throttled count : 0 3CICGRPINFO Total throttle time : 0 nanoseconds 2CICGRPINFO subsystem : cpuset 2CICGRPINFO cgroup name : / 3CICGRPINFO CPU exclusive : 1 3CICGRPINFO Mem exclusive : 1 3CICGRPINFO CPUs : 0-7 3CICGRPINFO Mems : 0 2CICGRPINFO subsystem : memory 2CICGRPINFO cgroup name : / 3CICGRPINFO Memory Limit : Not Set 3CICGRPINFO Memory + Swap Limit : Not Set 3CICGRPINFO Memory Usage : 5363396608 bytes 3CICGRPINFO Memory + Swap Usage : 5363396608 bytes 3CICGRPINFO Memory Max Usage : 0 bytes 3CICGRPINFO Memory + Swap Max Usage : 0 bytes 3CICGRPINFO Memory limit exceeded count : 0 3CICGRPINFO Memory + Swap limit exceeded count : 0 3CICGRPINFO OOM Killer Disabled : 0 3CICGRPINFO Under OOM : 0 NULL","title":"ENVINFO"},{"location":"dump_javadump/#nativememinfo","text":"This section records information about native memory that is requested by using library functions such as malloc() and mmap() . Values are provided as a breakdown, per component, indicating the total number of bytes allocated and the number of native memory allocations. In the following example, 4,682,840 bytes of native memory are allocated (but not yet freed) to VM Classes, which corresponds to 141 allocations. NULL ------------------------------------------------------------------------ 0SECTION NATIVEMEMINFO subcomponent dump routine NULL ================================= 0MEMUSER 1MEMUSER JRE: 2,569,088,312 bytes / 4653 allocations 1MEMUSER | 2MEMUSER +--VM: 2,280,088,336 bytes / 2423 allocations 2MEMUSER | | 3MEMUSER | +--Classes: 4,682,840 bytes / 141 allocations 2MEMUSER | | 3MEMUSER | +--Memory Manager (GC): 2,054,966,784 bytes / 433 allocations 3MEMUSER | | | 4MEMUSER | | +--Java Heap: 2,014,113,792 bytes / 1 allocation 3MEMUSER | | | 4MEMUSER | | +--Other: 40,852,992 bytes / 432 allocations 2MEMUSER | | 3MEMUSER | +--Threads: 10,970,016 bytes / 156 allocations 3MEMUSER | | | 4MEMUSER | | +--Java Stack: 197,760 bytes / 16 allocations 3MEMUSER | | | 4MEMUSER | | +--Native Stack: 10,616,832 bytes / 17 allocations 3MEMUSER | | | 4MEMUSER | | +--Other: 155,424 bytes / 123 allocations 2MEMUSER | | 3MEMUSER | +--Trace: 180,056 bytes / 263 allocations 2MEMUSER | | 3MEMUSER | +--JVMTI: 17,776 bytes / 13 allocations 2MEMUSER | | 3MEMUSER | +--JNI: 36,184 bytes / 52 allocations 2MEMUSER | | 3MEMUSER | +--Port Library: 208,179,632 bytes / 72 allocations 3MEMUSER | | | 4MEMUSER | | +--Unused <32bit allocation regions: 208,168,752 bytes / 1 allocation 3MEMUSER | | | 4MEMUSER | | +--Other: 10,880 bytes / 71 allocations 2MEMUSER | | 3MEMUSER | +--Other: 1,055,048 bytes / 1293 allocations 1MEMUSER | 2MEMUSER +--JIT: 288,472,816 bytes / 140 allocations 2MEMUSER | | 3MEMUSER | +--JIT Code Cache: 268,435,456 bytes / 1 allocation 2MEMUSER | | 3MEMUSER | +--JIT Data Cache: 2,097,216 bytes / 1 allocation 2MEMUSER | | 3MEMUSER | +--Other: 17,940,144 bytes / 138 allocations 1MEMUSER | 2MEMUSER +--Class Libraries: 13,432 bytes / 25 allocations 2MEMUSER | | 3MEMUSER | +--VM Class Libraries: 13,432 bytes / 25 allocations 3MEMUSER | | | 4MEMUSER | | +--sun.misc.Unsafe: 3,184 bytes / 13 allocations 4MEMUSER | | | | 5MEMUSER | | | +--Direct Byte Buffers: 1,056 bytes / 12 allocations 4MEMUSER | | | | 5MEMUSER | | | +--Other: 2,128 bytes / 1 allocation 3MEMUSER | | | 4MEMUSER | | +--Other: 10,248 bytes / 12 allocations 1MEMUSER | 2MEMUSER +--Unknown: 513,728 bytes / 2065 allocations NULL This section does not record memory that is allocated by application or JNI code and is typically a little less than the value recorded by operating system tools.","title":"NATIVEMEMINFO"},{"location":"dump_javadump/#meminfo","text":"This section relates to memory management, providing a breakdown of memory usage in the VM for the object heap, internal memory, memory used for classes, the JIT code cache, and JIT data cache in decimal and hexadecimal format. You can also find out which garbage collection policy is in use when the dump is produced. The object memory area ( 1STHEAPTYPE ) records each memory region in use, its start and end address, and region size. Further information is recorded about the memory segments used for internal memory, class memory, the JIT code cache and JIT data cache ( 1STSEGMENT ). This information includes the address of the segment control data structure, the start and end address of the native memory segment, as well as the segment size. For clarity, the following example shows a shortened version of this section, where ... indicates that lines are removed: NULL ------------------------------------------------------------------------ 0SECTION MEMINFO subcomponent dump routine NULL ================================= NULL 1STHEAPTYPE Object Memory NULL id start end size space/region 1STHEAPSPACE 0x00007FF4F00744A0 -- -- -- Generational 1STHEAPREGION 0x00007FF4F0074CE0 0x0000000087F40000 0x0000000088540000 0x0000000000600000 Generational/Tenured Region 1STHEAPREGION 0x00007FF4F0074930 0x00000000FFE00000 0x00000000FFF00000 0x0000000000100000 Generational/Nursery Region 1STHEAPREGION 0x00007FF4F0074580 0x00000000FFF00000 0x0000000100000000 0x0000000000100000 Generational/Nursery Region NULL 1STHEAPTOTAL Total memory: 8388608 (0x0000000000800000) 1STHEAPINUSE Total memory in use: 2030408 (0x00000000001EFB48) 1STHEAPFREE Total memory free: 6358200 (0x00000000006104B8) NULL 1STSEGTYPE Internal Memory NULL segment start alloc end type size 1STSEGMENT 0x00007FF4F004CBC8 0x00007FF4CD33C000 0x00007FF4CD33C000 0x00007FF4CE33C000 0x01000440 0x0000000001000000 1STSEGMENT 0x00007FF4F004CB08 0x00007FF4DE43D030 0x00007FF4DE517770 0x00007FF4DE53D030 0x00800040 0x0000000000100000 NULL 1STSEGTOTAL Total memory: 17825792 (0x0000000001100000) 1STSEGINUSE Total memory in use: 894784 (0x00000000000DA740) 1STSEGFREE Total memory free: 16931008 (0x00000000010258C0) NULL 1STSEGTYPE Class Memory NULL segment start alloc end type size 1STSEGMENT 0x00007FF4F03B5638 0x0000000001053D98 0x000000000105BD98 0x000000000105BD98 0x00010040 0x0000000000008000 1STSEGMENT 0x00007FF4F03B5578 0x0000000001048188 0x0000000001050188 0x0000000001050188 0x00010040 0x0000000000008000 ... NULL 1STSEGTOTAL Total memory: 3512520 (0x00000000003598C8) 1STSEGINUSE Total memory in use: 3433944 (0x00000000003465D8) 1STSEGFREE Total memory free: 78576 (0x00000000000132F0) NULL 1STSEGTYPE JIT Code Cache NULL segment start alloc end type size 1STSEGMENT 0x00007FF4F00961F8 0x00007FF4CE43D000 0x00007FF4CE445790 0x00007FF4DE43D000 0x00000068 0x0000000010000000 NULL 1STSEGTOTAL Total memory: 268435456 (0x0000000010000000) 1STSEGINUSE Total memory in use: 34704 (0x0000000000008790) 1STSEGFREE Total memory free: 268400752 (0x000000000FFF7870) 1STSEGLIMIT Allocation limit: 268435456 (0x0000000010000000) NULL 1STSEGTYPE JIT Data Cache NULL segment start alloc end type size 1STSEGMENT 0x00007FF4F0096668 0x00007FF4CC553030 0x00007FF4CC753030 0x00007FF4CC753030 0x00000048 0x0000000000200000 NULL 1STSEGTOTAL Total memory: 2097152 (0x0000000000200000) 1STSEGINUSE Total memory in use: 2097152 (0x0000000000200000) 1STSEGFREE Total memory free: 0 (0x0000000000000000) 1STSEGLIMIT Allocation limit: 402653184 (0x0000000018000000) NULL 1STGCHTYPE GC History NULL In the example, the GC History ( 1STGCHTYPE ) section is blank. This section is populated if a garbage collection cycle occurred in a VM that is being diagnosed with the trace facility.","title":"MEMINFO"},{"location":"dump_javadump/#locks","text":"This section of the Java dump provides information about locks, which protect shared resources from being accessed by more than one entity at a time. The information is essential in a deadlock situation, where two threads attempt to synchronize on an object and lock an instance of a class. Precise information is recorded about the threads that are causing the problem, which enables you to identify the root cause. The following example shows a typical LOCKS section, where no deadlocks existed at the time the dump was triggered. For clarity, the following example shows a shortened version of this section, where ... indicates that lines are removed: NULL ------------------------------------------------------------------------ 0SECTION LOCKS subcomponent dump routine NULL =============================== NULL 1LKPOOLINFO Monitor pool info: 2LKPOOLTOTAL Current total number of monitors: 3 NULL 1LKMONPOOLDUMP Monitor Pool Dump (flat & inflated object-monitors): 2LKMONINUSE sys_mon_t:0x00007FF4B0001D78 infl_mon_t: 0x00007FF4B0001DF8: 3LKMONOBJECT java/lang/ref/ReferenceQueue@0x00000000FFE26A10: <unowned> 3LKNOTIFYQ Waiting to be notified: 3LKWAITNOTIFY \"Common-Cleaner\" (J9VMThread:0x0000000000FD0100) NULL 1LKREGMONDUMP JVM System Monitor Dump (registered monitors): 2LKREGMON Thread global lock (0x00007FF4F0004FE8): <unowned> 2LKREGMON &(PPG_mem_mem32_subAllocHeapMem32.monitor) lock (0x00007FF4F0005098): <unowned> 2LKREGMON NLS hash table lock (0x00007FF4F0005148): <unowned> ... NULL","title":"LOCKS"},{"location":"dump_javadump/#threads","text":"The THREADS section of a Java dump file provides summary information about the VM thread pool and detailed information about Java threads, native threads, and stack traces. Understanding the content of this section can help you diagnose problems that are caused by blocked or waiting threads. A Java thread runs on a native thread. Several lines are recorded for each Java thread in the Thread Details subsection, which include the following key pieces of information: 3XMTHREADINFO : The thread name, address information for the VM thread structures and Java thread object, the thread state, and thread priority. 3XMJAVALTHREAD : The Java thread ID and daemon status from the thread object. 3XMTHREADINFO1 : The native operating system thread ID, priority, scheduling policy, internal VM thread state, and VM thread flags. 3XMTHREADINFO2 : The native stack address range. 3XMTHREADINFO3 : Java callstack information ( 4XESTACKTRACE ) or Native call stack information ( 4XENATIVESTACK ). 5XESTACKTRACE : This line indicates whether locks were taken by a specific method. Java thread priorities are mapped to operating system priority values. Thread states are shown in the following table: Thread state value Status Description R Runnable The thread is able to run CW Condition Wait The thread is waiting S Suspended The thread is suspended by another thread Z Zombie The thread is destroyed P Parked The thread is parked by java.util.concurrent B Blocked The thread is waiting to obtain a lock For threads that are parked (P), blocked (B), or waiting (CW), an additional line ( 3XMTHREADBLOCK ) is included in the output that shows what the thread is parked on, blocked on, or waiting for. For clarity, the following example shows a shortened version of a typical THREADS section, where ... indicates that lines are removed: NULL ------------------------------------------------------------------------ 0SECTION THREADS subcomponent dump routine NULL ================================= NULL 1XMPOOLINFO JVM Thread pool info: 2XMPOOLTOTAL Current total number of pooled threads: 18 2XMPOOLLIVE Current total number of live threads: 16 2XMPOOLDAEMON Current total number of live daemon threads: 15 NULL 1XMTHDINFO Thread Details NULL 3XMTHREADINFO \"JIT Diagnostic Compilation Thread-7 Suspended\" J9VMThread:0x0000000000EFC500, omrthread_t:0x00007FF4F00A77E8, java/lang/Thread:0x00000000FFE97480, state:R, prio=10 3XMJAVALTHREAD (java/lang/Thread getId:0xA, isDaemon:true) 3XMTHREADINFO1 (native thread ID:0x7657, native priority:0xB, native policy:UNKNOWN, vmstate:CW, vm thread flags:0x00000081) 3XMTHREADINFO2 (native stack address range from:0x00007FF4CCC36000, to:0x00007FF4CCD36000, size:0x100000) 3XMCPUTIME CPU usage total: 0.000037663 secs, current category=\"JIT\" 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) 3XMTHREADINFO3 No Java callstack associated with this thread 3XMTHREADINFO3 No native callstack available for this thread NULL ... 3XMTHREADINFO \"Common-Cleaner\" J9VMThread:0x0000000000FD0100, omrthread_t:0x00007FF4F022A520, java/lang/Thread:0x00000000FFE26F40, state:CW, prio=8 3XMJAVALTHREAD (java/lang/Thread getId:0x2, isDaemon:true) 3XMTHREADINFO1 (native thread ID:0x765A, native priority:0x8, native policy:UNKNOWN, vmstate:CW, vm thread flags:0x00080181) 3XMTHREADINFO2 (native stack address range from:0x00007FF4CC0B8000, to:0x00007FF4CC0F8000, size:0x40000) 3XMCPUTIME CPU usage total: 0.000150926 secs, current category=\"Application\" 3XMTHREADBLOCK Waiting on: java/lang/ref/ReferenceQueue@0x00000000FFE26A10 Owned by: <unowned> 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at java/lang/Object.wait(Native Method) 4XESTACKTRACE at java/lang/Object.wait(Object.java:221) 4XESTACKTRACE at java/lang/ref/ReferenceQueue.remove(ReferenceQueue.java:138) 5XESTACKTRACE (entered lock: java/lang/ref/ReferenceQueue@0x00000000FFE26A10, entry count: 1) 4XESTACKTRACE at jdk/internal/ref/CleanerImpl.run(CleanerImpl.java:148) 4XESTACKTRACE at java/lang/Thread.run(Thread.java:835) 4XESTACKTRACE at jdk/internal/misc/InnocuousThread.run(InnocuousThread.java:122) 3XMTHREADINFO3 No native callstack available for this thread NULL NULL 3XMTHREADINFO \"IProfiler\" J9VMThread:0x0000000000F03D00, omrthread_t:0x00007FF4F00B06F8, java/lang/Thread:0x00000000FFE97B60, state:R, prio=5 3XMJAVALTHREAD (java/lang/Thread getId:0xC, isDaemon:true) 3XMTHREADINFO1 (native thread ID:0x7659, native priority:0x5, native policy:UNKNOWN, vmstate:CW, vm thread flags:0x00000081) 3XMTHREADINFO2 (native stack address range from:0x00007FF4F8940000, to:0x00007FF4F8960000, size:0x20000) 3XMCPUTIME CPU usage total: 0.004753103 secs, current category=\"JIT\" 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) 3XMTHREADINFO3 No Java callstack associated with this thread 3XMTHREADINFO3 No native callstack available for this thread NULL ... 1XMWLKTHDERR The following was reported while collecting native stacks: 2XMWLKTHDERR unable to count threads(3, -2) NULL 1XMTHDSUMMARY Threads CPU Usage Summary NULL ========================= NULL 1XMTHDCATINFO Warning: to get more accurate CPU times for the GC, the option -XX:-ReduceCPUMonitorOverhead can be used. See the user guide for more information. NULL 1XMTHDCATEGORY All JVM attached threads: 0.280083000 secs 1XMTHDCATEGORY | 2XMTHDCATEGORY +--System-JVM: 0.270814000 secs 2XMTHDCATEGORY | | 3XMTHDCATEGORY | +--GC: 0.000599000 secs 2XMTHDCATEGORY | | 3XMTHDCATEGORY | +--JIT: 0.071904000 secs 1XMTHDCATEGORY | 2XMTHDCATEGORY +--Application: 0.009269000 secs NULL","title":"THREADS"},{"location":"dump_javadump/#hooks","text":"This section shows internal VM event callbacks, which are used for diagnosing performance problems in the VM. Multiple hook interfaces are listed, which include their individual hook events. The following example shows data for the J9VMHookInterface , including the total time for all previous events, the call site location (<source file>:<line number>), start time, and duration of the last callback and the longest callback (all times measured in microseconds). The hook data is reset after each Java dump. NULL ------------------------------------------------------------------------ SECTION HOOK subcomponent dump routine NULL ========================= 1NOTE These data are reset every time a javacore is taken 1HKINTERFACE MM_OMRHookInterface NULL ------------------------------------------------------------------------ 1HKINTERFACE MM_PrivateHookInterface NULL ------------------------------------------------------------------------ 1HKINTERFACE MM_HookInterface NULL ------------------------------------------------------------------------ 1HKINTERFACE J9VMHookInterface NULL ------------------------------------------------------------------------ 2HKEVENTID 1 3HKCALLCOUNT 1239 3HKTOTALTIME 219564us 3HKLAST Last Callback 4HKCALLSITE trcengine.c:395 4HKSTARTTIME Start Time: 2019-10-18T00:15:14.664 4HKDURATION Duration : 16us 3HKLONGST Longest Callback 4HKCALLSITE trcengine.c:395 4HKSTARTTIME Start Time: 2019-10-18T21:28:34.895 4HKDURATION Duration : 5012us NULL ... 1HKINTERFACE J9VMZipCachePoolHookInterface NULL ------------------------------------------------------------------------ 1HKINTERFACE J9JITHookInterface NULL ------------------------------------------------------------------------ 2HKEVENTID 3 3HKCALLCOUNT 3113 3HKTOTALTIME 4904us 3HKLAST Last Callback 4HKCALLSITE common/mgmtinit.c:193 4HKSTARTTIME Start Time: 2019-10-18T16:04:15.320 4HKDURATION Duration : 3us 3HKLONGST Longest Callback 4HKCALLSITE common/mgmtinit.c:193 4HKSTARTTIME Start Time: 2019-10-18T16:37:17.633 4HKDURATION Duration : 27us NULL ...","title":"HOOKS"},{"location":"dump_javadump/#shared-classes","text":"If the shared classes cache is enabled at run time, the information provided in a Java dump file describes settings that were used when creating the cache, together with summary information about the size and content of the cache. In the following example, the shared classes cache was created with a Class Debug Area ( -Xnolinenumbers=false ). Byte code instrumentation (BCI) is enabled, which is the default, and VMs sharing the cache are allowed to store classpaths, which is also the default. The Cache Summary shows a cache size ( 2SCLTEXTCSZ ) of 16776608 bytes, with a soft maximum size ( 2SCLTEXTSMB ) also of 16776608 bytes, which leaves 12691668 bytes of free space ( 2SCLTEXTFRB ). The size of the Class Debug Area ( 2SCLTEXTDAS ) is 1331200 bytes and only 11% of this space is used. In the Cache Memory Status subsection, the line 2SCLTEXTCMDT indicates the name and location of the shared cache and cr indicates that the cache is a 64-bit compressed references cache. NULL ------------------------------------------------------------------------ 0SECTION SHARED CLASSES subcomponent dump routine NULL ======================================== NULL 1SCLTEXTCRTW Cache Created With NULL ------------------ NULL 2SCLTEXTXNL -Xnolinenumbers = false 2SCLTEXTBCI BCI Enabled = true 2SCLTEXTBCI Restrict Classpaths = false NULL 1SCLTEXTCSUM Cache Summary NULL ------------------ NULL 2SCLTEXTNLC No line number content = false 2SCLTEXTLNC Line number content = true NULL 2SCLTEXTRCS ROMClass start address = 0x00007F423061C000 2SCLTEXTRCE ROMClass end address = 0x00007F42307B9A28 2SCLTEXTMSA Metadata start address = 0x00007F42313D42FC 2SCLTEXTCEA Cache end address = 0x00007F4231600000 2SCLTEXTRTF Runtime flags = 0x00102001ECA6028B 2SCLTEXTCGN Cache generation = 35 NULL 2SCLTEXTCSZ Cache size = 16776608 2SCLTEXTSMB Softmx bytes = 16776608 2SCLTEXTFRB Free bytes = 12691668 2SCLTEXTRCB ROMClass bytes = 1694248 2SCLTEXTAOB AOT code bytes = 0 2SCLTEXTADB AOT data bytes = 0 2SCLTEXTAHB AOT class hierarchy bytes = 32 2SCLTEXTATB AOT thunk bytes = 0 2SCLTEXTARB Reserved space for AOT bytes = -1 2SCLTEXTAMB Maximum space for AOT bytes = -1 2SCLTEXTJHB JIT hint bytes = 308 2SCLTEXTJPB JIT profile bytes = 2296 2SCLTEXTJRB Reserved space for JIT data bytes = -1 2SCLTEXTJMB Maximum space for JIT data bytes = -1 2SCLTEXTNOB Java Object bytes = 0 2SCLTEXTZCB Zip cache bytes = 919328 2SCLTEXTSHB Startup hint bytes = 0 2SCLTEXTRWB ReadWrite bytes = 114080 2SCLTEXTJCB JCL data bytes = 0 2SCLTEXTBDA Byte data bytes = 0 2SCLTEXTMDA Metadata bytes = 23448 2SCLTEXTDAS Class debug area size = 1331200 2SCLTEXTDAU Class debug area % used = 11% 2SCLTEXTDAN Class LineNumberTable bytes = 156240 2SCLTEXTDAV Class LocalVariableTable bytes = 0 NULL 2SCLTEXTNRC Number ROMClasses = 595 2SCLTEXTNAM Number AOT Methods = 0 2SCLTEXTNAD Number AOT Data Entries = 0 2SCLTEXTNAH Number AOT Class Hierarchy = 1 2SCLTEXTNAT Number AOT Thunks = 0 2SCLTEXTNJH Number JIT Hints = 14 2SCLTEXTNJP Number JIT Profiles = 20 2SCLTEXTNCP Number Classpaths = 1 2SCLTEXTNUR Number URLs = 0 2SCLTEXTNTK Number Tokens = 0 2SCLTEXTNOJ Number Java Objects = 0 2SCLTEXTNZC Number Zip Caches = 5 2SCLTEXTNSH Number Startup Hint Entries = 0 2SCLTEXTNJC Number JCL Entries = 0 2SCLTEXTNST Number Stale classes = 0 2SCLTEXTPST Percent Stale classes = 0% NULL 2SCLTEXTCPF Cache is 24% full NULL 1SCLTEXTCMST Cache Memory Status NULL ------------------ 1SCLTEXTCNTD Cache Name Feature Memory type Cache path NULL 2SCLTEXTCMDT sharedcc_doc-javacore CR Memory mapped file /tmp/javasharedresources/C290M4F1A64P_sharedcc_doc-javacore_G35 NULL 1SCLTEXTCMST Cache Lock Status NULL ------------------ 1SCLTEXTCNTD Lock Name Lock type TID owning lock NULL 2SCLTEXTCWRL Cache write lock File lock Unowned 2SCLTEXTCRWL Cache read/write lock File lock Unowned NULL The following example shows information for a layered cache: NULL ------------------------------------------------------------------------ 0SECTION SHARED CLASSES subcomponent dump routine NULL ======================================== NULL 1SCLTEXTCSTL Cache Statistics for Top Layer NULL 1SCLTEXTCRTW Cache Created With NULL ------------------ NULL 2SCLTEXTXNL -Xnolinenumbers = false 2SCLTEXTBCI BCI Enabled = true 2SCLTEXTBCI Restrict Classpaths = false NULL 1SCLTEXTCSUM Cache Summary NULL ------------------ NULL 2SCLTEXTNLC No line number content = false 2SCLTEXTLNC Line number content = false NULL 2SCLTEXTRCS ROMClass start address = 0x00007F0EDB567000 2SCLTEXTRCE ROMClass end address = 0x00007F0EDB567000 2SCLTEXTMSA Metadata start address = 0x00007F0EDC40241C 2SCLTEXTCEA Cache end address = 0x00007F0EDC54B000 2SCLTEXTRTF Runtime flags = 0x80102001ECA602BB 2SCLTEXTCGN Cache generation = 41 2SCLTEXTCLY Cache layer = 1 NULL 2SCLTEXTCSZ Cache size = 16776608 2SCLTEXTSMB Softmx bytes = 16776608 2SCLTEXTFRB Free bytes = 15315996 2SCLTEXTARB Reserved space for AOT bytes = -1 2SCLTEXTAMB Maximum space for AOT bytes = -1 2SCLTEXTJRB Reserved space for JIT data bytes = -1 2SCLTEXTJMB Maximum space for JIT data bytes = -1 2SCLTEXTRWB ReadWrite bytes = 114080 2SCLTEXTDAS Class debug area size = 1331200 2SCLTEXTDAU Class debug area % used = 0% 2SCLTEXTDAN Class LineNumberTable bytes = 0 2SCLTEXTDAV Class LocalVariableTable bytes = 0 NULL 2SCLTEXTCPF Cache is 8% full NULL 1SCLTEXTCMST Cache Memory Status NULL ------------------ 1SCLTEXTCNTD Cache Name Feature Memory type Cache path NULL 2SCLTEXTCMDT Cache1 CR Memory mapped file /tmp/javasharedresources/C290M4F1A64P_Cache1_G41L01 NULL 1SCLTEXTCMST Cache Lock Status NULL ------------------ 1SCLTEXTCNTD Lock Name Lock type TID owning lock NULL 2SCLTEXTCWRL Cache write lock File lock Unowned 2SCLTEXTCRWL Cache read/write lock File lock Unowned NULL 1SCLTEXTCSAL Cache Statistics for All Layers NULL 2SCLTEXTRCB ROMClass bytes = 1459040 2SCLTEXTAOB AOT code bytes = 57624 2SCLTEXTADB AOT data bytes = 272 2SCLTEXTAHB AOT class hierarchy bytes = 1840 2SCLTEXTATB AOT thunk bytes = 632 2SCLTEXTJHB JIT hint bytes = 484 2SCLTEXTJPB JIT profile bytes = 0 2SCLTEXTNOB Java Object bytes = 0 2SCLTEXTZCB Zip cache bytes = 1134016 2SCLTEXTSHB Startup hint bytes = 0 2SCLTEXTJCB JCL data bytes = 0 2SCLTEXTBDA Byte data bytes = 0 NULL 2SCLTEXTNRC Number ROMClasses = 503 2SCLTEXTNAM Number AOT Methods = 16 2SCLTEXTNAD Number AOT Data Entries = 1 2SCLTEXTNAH Number AOT Class Hierarchy = 28 2SCLTEXTNAT Number AOT Thunks = 11 2SCLTEXTNJH Number JIT Hints = 15 2SCLTEXTNJP Number JIT Profiles = 0 2SCLTEXTNCP Number Classpaths = 1 2SCLTEXTNUR Number URLs = 0 2SCLTEXTNTK Number Tokens = 0 2SCLTEXTNOJ Number Java Objects = 0 2SCLTEXTNZC Number Zip Caches = 21 2SCLTEXTNSH Number Startup Hint Entries = 0 2SCLTEXTNJC Number JCL Entries = 0 2SCLTEXTNST Number Stale classes = 0 2SCLTEXTPST Percent Stale classes = 0%","title":"SHARED CLASSES"},{"location":"dump_javadump/#classes","text":"The classes section shows information about class loaders. The first part is a summary that records each available class loader ( 2CLTEXTCLLOADER ) followed by the number of libraries and classes that it loaded. This information is followed by a more detailed list of libraries ( 1CLTEXTCLLIB ) and classes ( 1CLTEXTCLLO ) that are loaded. In the example you can see that the java/lang/InternalAnonymousClassLoader loaded 2 classes, jdk/internal/loader/BuiltinClassLoader$$Lambda$2/00000000F03876A0(0x0000000001030F00) and jdk/internal/loader/BuiltinClassLoader$$Lambda$1/00000000F00D2460(0x0000000001018A00) . NULL ------------------------------------------------------------------------ 0SECTION CLASSES subcomponent dump routine NULL ================================= 1CLTEXTCLLOS Classloader summaries 1CLTEXTCLLSS 12345678: 1=primordial,2=extension,3=shareable,4=middleware,5=system,6=trusted,7=application,8=delegating 2CLTEXTCLLOADER p---st-- Loader *System*(0x00000000FFE1D258) 3CLNMBRLOADEDLIB Number of loaded libraries 5 3CLNMBRLOADEDCL Number of loaded classes 638 2CLTEXTCLLOADER -x--st-- Loader jdk/internal/loader/ClassLoaders$PlatformClassLoader(0x00000000FFE1D4F0), Parent *none*(0x0000000000000000) 3CLNMBRLOADEDLIB Number of loaded libraries 0 3CLNMBRLOADEDCL Number of loaded classes 0 2CLTEXTCLLOADER ----st-- Loader java/lang/InternalAnonymousClassLoader(0x00000000FFE1DFD0), Parent *none*(0x0000000000000000) 3CLNMBRLOADEDLIB Number of loaded libraries 0 3CLNMBRLOADEDCL Number of loaded classes 2 2CLTEXTCLLOADER -----ta- Loader jdk/internal/loader/ClassLoaders$AppClassLoader(0x00000000FFE1DAD0), Parent jdk/internal/loader/ClassLoaders$PlatformClassLoader(0x00000000FFE1D4F0) 3CLNMBRLOADEDLIB Number of loaded libraries 0 3CLNMBRLOADEDCL Number of loaded classes 0 1CLTEXTCLLIB ClassLoader loaded libraries 2CLTEXTCLLIB Loader *System*(0x00000000FFE1D258) 3CLTEXTLIB /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/compressedrefs/jclse9_29 3CLTEXTLIB /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/java 3CLTEXTLIB /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/compressedrefs/j9jit29 3CLTEXTLIB /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/zip 3CLTEXTLIB /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/nio 1CLTEXTCLLOD ClassLoader loaded classes 2CLTEXTCLLOAD Loader *System*(0x00000000FFE1D258) 3CLTEXTCLASS [Ljava/lang/Thread$State;(0x0000000001056400) ... 2CLTEXTCLLOAD Loader jdk/internal/loader/ClassLoaders$PlatformClassLoader(0x00000000FFE1D4F0) 2CLTEXTCLLOAD Loader java/lang/InternalAnonymousClassLoader(0x00000000FFE1DFD0) 3CLTEXTCLASS jdk/internal/loader/BuiltinClassLoader$$Lambda$2/00000000F03876A0(0x0000000001030F00) 3CLTEXTCLASS jdk/internal/loader/BuiltinClassLoader$$Lambda$1/00000000F00D2460(0x0000000001018A00) 2CLTEXTCLLOAD Loader jdk/internal/loader/ClassLoaders$AppClassLoader(0x00000000FFE1DAD0)","title":"CLASSES"},{"location":"dump_javadump/#scenarios","text":"","title":"Scenarios"},{"location":"dump_javadump/#general-protection-fault","text":"In this scenario, a Java application has crashed due to a General Protection Fault (GPF), automatically generating a Java dump file. The first section of the file (TITLE) tells you that the GPF triggered the Java dump. 0SECTION TITLE subcomponent dump routine NULL =============================== 1TICHARSET UTF-8 1TISIGINFO Dump Event \"gpf\" (00002000) received 1TIDATETIMEUTC Date: 2021/04/23 at 18:02:44:017 (UTC) 1TIDATETIME Date: 2021/04/23 at 14:02:44:017 1TITIMEZONE Timezone: UTC-4 (EDT) 1TINANOTIME System nanotime: 379202644260787 1TIFILENAME Javacore filename: /home/test/JNICrasher/javacore.20210423.140244.29399.0002.txt 1TIREQFLAGS Request Flags: 0x81 (exclusive+preempt) 1TIPREPSTATE Prep State: 0x100 (trace_disabled) 1TIPREPINFO Exclusive VM access not taken: data may not be consistent across javacore sections To troubleshoot this problem, you need to know which thread caused the GPF to occur. The thread that was running at the time of the crash is reported as the current thread in the THREADS section of the Java dump. Here is an extract from the THREADS section: NULL ------------------------------------------------------------------------ 0SECTION THREADS subcomponent dump routine NULL ================================= NULL 1XMPOOLINFO JVM Thread pool info: 2XMPOOLTOTAL Current total number of pooled threads: 16 2XMPOOLLIVE Current total number of live threads: 15 2XMPOOLDAEMON Current total number of live daemon threads: 14 NULL 1XMCURTHDINFO Current thread 3XMTHREADINFO \"main\" J9VMThread:0xB6B60E00, omrthread_t:0xB6B049D8, java/lang/Thread:0xB55444D0, state:R, prio=5 3XMJAVALTHREAD (java/lang/Thread getId:0x1, isDaemon:false) 3XMTHREADINFO1 (native thread ID:0x72D8, native priority:0x5, native policy:UNKNOWN, vmstate:R, vm thread flags:0x00000000) 3XMTHREADINFO2 (native stack address range from:0xB6CE3000, to:0xB74E4000, size:0x801000) 3XMCPUTIME CPU usage total: 0.319865924 secs, current category=\"Application\" 3XMHEAPALLOC Heap bytes allocated since last GC cycle=778008 (0xBDF18) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at JNICrasher.doSomethingThatCrashes(Native Method) 4XESTACKTRACE at JNICrasher.main(JNICrasher.java:7) 3XMTHREADINFO3 Native callstack: 4XENATIVESTACK (0xB6C6F663 [libj9prt29.so+0x3b663]) 4XENATIVESTACK (0xB6C52F6E [libj9prt29.so+0x1ef6e]) 4XENATIVESTACK (0xB6C6F1CE [libj9prt29.so+0x3b1ce]) 4XENATIVESTACK (0xB6C6F2C6 [libj9prt29.so+0x3b2c6]) 4XENATIVESTACK (0xB6C6ED93 [libj9prt29.so+0x3ad93]) 4XENATIVESTACK (0xB6C52F6E [libj9prt29.so+0x1ef6e]) 4XENATIVESTACK (0xB6C6ED07 [libj9prt29.so+0x3ad07]) 4XENATIVESTACK (0xB6C6AA3D [libj9prt29.so+0x36a3d]) 4XENATIVESTACK (0xB6C6C3A4 [libj9prt29.so+0x383a4]) 4XENATIVESTACK (0xB667FA19 [libj9dmp29.so+0xfa19]) 4XENATIVESTACK (0xB6C52F6E [libj9prt29.so+0x1ef6e]) 4XENATIVESTACK (0xB66878CF [libj9dmp29.so+0x178cf]) 4XENATIVESTACK (0xB6688083 [libj9dmp29.so+0x18083]) 4XENATIVESTACK (0xB6C52F6E [libj9prt29.so+0x1ef6e]) 4XENATIVESTACK (0xB6680C0D [libj9dmp29.so+0x10c0d]) 4XENATIVESTACK (0xB667F9D7 [libj9dmp29.so+0xf9d7]) 4XENATIVESTACK (0xB6C52F6E [libj9prt29.so+0x1ef6e]) 4XENATIVESTACK (0xB668B02F [libj9dmp29.so+0x1b02f]) 4XENATIVESTACK (0xB668B4D3 [libj9dmp29.so+0x1b4d3]) 4XENATIVESTACK (0xB66740F1 [libj9dmp29.so+0x40f1]) 4XENATIVESTACK (0xB66726FA [libj9dmp29.so+0x26fa]) 4XENATIVESTACK (0xB6C52F6E [libj9prt29.so+0x1ef6e]) 4XENATIVESTACK (0xB66726A9 [libj9dmp29.so+0x26a9]) 4XENATIVESTACK (0xB6676AE4 [libj9dmp29.so+0x6ae4]) 4XENATIVESTACK (0xB668D75A [libj9dmp29.so+0x1d75a]) 4XENATIVESTACK (0xB6A28DD4 [libj9vm29.so+0x81dd4]) 4XENATIVESTACK (0xB6C52F6E [libj9prt29.so+0x1ef6e]) 4XENATIVESTACK (0xB6A289EE [libj9vm29.so+0x819ee]) 4XENATIVESTACK (0xB6A29A40 [libj9vm29.so+0x82a40]) 4XENATIVESTACK (0xB6C52B6A [libj9prt29.so+0x1eb6a]) 4XENATIVESTACK __kernel_rt_sigreturn+0x0 (0xB7747410) 4XENATIVESTACK (0xB75330B6 [libffi29.so+0x50b6]) 4XENATIVESTACK ffi_raw_call+0xad (0xB7531C53 [libffi29.so+0x3c53]) 4XENATIVESTACK (0xB69BE4AB [libj9vm29.so+0x174ab]) 4XENATIVESTACK (0xB6A665BC [libj9vm29.so+0xbf5bc]) 4XENATIVESTACK (0xB6A15552 [libj9vm29.so+0x6e552]) 4XENATIVESTACK (0xB6A30894 [libj9vm29.so+0x89894]) 4XENATIVESTACK (0xB6A6F169 [libj9vm29.so+0xc8169]) 4XENATIVESTACK (0xB6C52F6E [libj9prt29.so+0x1ef6e]) 4XENATIVESTACK (0xB6A6F1FA [libj9vm29.so+0xc81fa]) 4XENATIVESTACK (0xB6A30994 [libj9vm29.so+0x89994]) 4XENATIVESTACK (0xB6A2CE4C [libj9vm29.so+0x85e4c]) 4XENATIVESTACK (0xB770487D [libjli.so+0x787d]) 4XENATIVESTACK (0xB7719F72 [libpthread.so.0+0x6f72]) 4XENATIVESTACK clone+0x5e (0xB763543E [libc.so.6+0xee43e]) The extract tells you that the current thread was java/lang/Thread , and information is provided about the Java callstack and native callstack ( 3XMTHREADINFO3 ) at the point at which the crash occurred. To simulate a crash caused by a bug in an application, this example calls a JNI method whose native implementation causes a crash. The Java callstack shows the call to the JNI native method ( JNIcrasher ), and the native callstack shows the point of failure. In this example, the native call stack does not include any function names to help you isolate the error in the native code. You can get this information from a system dump, which is usually produced alongside the Java dump. Open the system dump with the Dump viewer and use the info thread command to print the Java and native stack for the current thread.","title":"General Protection Fault"},{"location":"dump_javadump/#java-outofmemoryerror","text":"In this scenario, the Java heap runs out of memory, causing an OutOfMemoryError , which automatically generates a Java dump file. The first section of the file (TITLE) tells you that a systhrow event triggered the Java dump as a result of an OOM ( java/lang/OutOfMemoryError ) for Java heap space. 0SECTION TITLE subcomponent dump routine NULL =============================== 1TICHARSET UTF-8 1TISIGINFO Dump Event \"systhrow\" (00040000) Detail \"java/lang/OutOfMemoryError\" \"Java heap space\" received 1TIDATETIMEUTC Date: 2021/04/23 at 18:02:44:017 (UTC) 1TIDATETIME Date: 2021/04/23 at 14:02:44:017 1TITIMEZONE Timezone: UTC-4 (EDT) 1TINANOTIME System nanotime: 379202644260787 1TIFILENAME Javacore filename: /home/cheesemp/test/javacore.20210423.140244.18885.0003.txt 1TIREQFLAGS Request Flags: 0x81 (exclusive+preempt) 1TIPREPSTATE Prep State: 0x104 (exclusive_vm_access+trace_disabled) The MEMINFO section records how much memory is allocated to the Java heap ( 1STHEAPTYPE Object Memory ), how much is in use, and how much is free. Solving your problem might be as simple as setting a larger heap size when you start your application. If you don't know what size the Java heap was set to, you might find that information in the ENVINFO section, which records the command line options that were used when the application started. Look or search for the 1CIUSERARGS UserArgs: string and review the entries recorded for all lines that start 2CIUSERARG . The Java heap size is set by the -Xmx option. If the size has not been set on the command line by -Xmx , the default value applies, which you can find in Default Settings . In this scenario the solution to the problem is not an adjustment to the Java heap size. Here is the MEMINFO section: 0SECTION MEMINFO subcomponent dump routine NULL ================================= NULL 1STHEAPTYPE Object Memory NULL id start end size space/region 1STHEAPSPACE 0xB6B49D20 -- -- -- Generational 1STHEAPREGION 0xB6B4A078 0x95750000 0xB5470000 0x1FD20000 Generational/Tenured Region 1STHEAPREGION 0xB6B49F10 0xB5470000 0xB54C0000 0x00050000 Generational/Nursery Region 1STHEAPREGION 0xB6B49DA8 0xB54C0000 0xB5750000 0x00290000 Generational/Nursery Region NULL 1STHEAPTOTAL Total memory: 536870912 (0x20000000) 1STHEAPINUSE Total memory in use: 302603160 (0x12095B98) 1STHEAPFREE Total memory free: 234267752 (0x0DF6A468) The output shows that only 56% of the Java heap is in use, so this suggests that the application is trying to do something sub-optimal. To investigate further you need to work out which thread was the current thread when the OOM occurred to see what it was trying to do. As in the previous scenario, you can find the current thread in the THREADS section. Here is an extract from the output: 0SECTION THREADS subcomponent dump routine NULL ================================= NULL 1XMPOOLINFO JVM Thread pool info: 2XMPOOLTOTAL Current total number of pooled threads: 16 2XMPOOLLIVE Current total number of live threads: 16 2XMPOOLDAEMON Current total number of live daemon threads: 15 NULL 1XMCURTHDINFO Current thread 3XMTHREADINFO \"main\" J9VMThread:0xB6B60C00, omrthread_t:0xB6B049D8, java/lang/Thread:0x95764520, state:R, prio=5 3XMJAVALTHREAD (java/lang/Thread getId:0x1, isDaemon:false) 3XMTHREADINFO1 (native thread ID:0x49C6, native priority:0x5, native policy:UNKNOWN, vmstate:R, vm thread flags:0x00001020) 3XMTHREADINFO2 (native stack address range from:0xB6CB5000, to:0xB74B6000, size:0x801000) 3XMCPUTIME CPU usage total: 8.537823831 secs, current category=\"Application\" 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at java/lang/StringBuffer.ensureCapacityImpl(StringBuffer.java:696) 4XESTACKTRACE at java/lang/StringBuffer.append(StringBuffer.java:486(Compiled Code)) 5XESTACKTRACE (entered lock: java/lang/StringBuffer@0x957645B8, entry count: 1) 4XESTACKTRACE at java/lang/StringBuffer.append(StringBuffer.java:428(Compiled Code)) 4XESTACKTRACE at HeapBreaker.main(HeapBreaker.java:34(Compiled Code)) 3XMTHREADINFO3 Native callstack: 4XENATIVESTACK (0xB6C535B3 [libj9prt29.so+0x3b5b3]) 4XENATIVESTACK (0xB6C36F3E [libj9prt29.so+0x1ef3e]) 4XENATIVESTACK (0xB6C5311E [libj9prt29.so+0x3b11e]) 4XENATIVESTACK (0xB6C53216 [libj9prt29.so+0x3b216]) 4XENATIVESTACK (0xB6C52CE3 [libj9prt29.so+0x3ace3]) 4XENATIVESTACK (0xB6C36F3E [libj9prt29.so+0x1ef3e]) 4XENATIVESTACK (0xB6C52C57 [libj9prt29.so+0x3ac57]) 4XENATIVESTACK (0xB6C4E9CD [libj9prt29.so+0x369cd]) 4XENATIVESTACK (0xB6C502FA [libj9prt29.so+0x382fa]) To simulate a Java OutOfMemoryError , this example application repeatedly appends characters to a StringBuffer object in an infinite loop. The Java callstack shows the HeapBreaker.main method appending characters ( java/lang/StringGuffer.append ) until the method java/lang/StringBuffer.ensureCapacityImpl() throws the OutOfMemoryError . StringBuffer objects are wrappers for character arrays ( char[] ) and when the capacity of the underlying array is reached, the contents are automatically copied into a new, larger array. The new array is created in the StringBuffer.ensureCapacity() method, which more or less doubles the size of the old array. In this scenario, the array takes up all the remaining space in the Java heap. The MEMINFO section of the Java dump file can also tell you when an unexpectedly large allocation request causes an OOM. Look for the GC History ( 1STGCHTYPE ) section, which details allocation requests that trigger GC activity. In the sample output you can see that a large allocation request ( requestedbytes=603979784 ) triggered a global GC. When the GC could not free up sufficient space in the heap to satisfy the request, the allocation failure generated the OOM. 1STGCHTYPE GC History 3STHSTTYPE 14:29:29:580239000 GMT j9mm.101 - J9AllocateIndexableObject() returning NULL! 0 bytes requested for object of class B6BBC300 from memory space 'Generational' id=B6B49D20 3STHSTTYPE 14:29:29:579916000 GMT j9mm.134 - Allocation failure end: newspace=2686912/3014656 oldspace=231597224/533856256 loa=5338112/5338112 3STHSTTYPE 14:29:29:579905000 GMT j9mm.470 - Allocation failure cycle end: newspace=2686912/3014656 oldspace=231597224/533856256 loa=5338112/5338112 3STHSTTYPE 14:29:29:579859000 GMT j9mm.475 - GlobalGC end: workstackoverflow=0 overflowcount=0 memory=234284136/536870912 3STHSTTYPE 14:29:29:579807000 GMT j9mm.90 - GlobalGC collect complete 3STHSTTYPE 14:29:29:579776000 GMT j9mm.137 - Compact end: bytesmoved=301989896 3STHSTTYPE 14:29:29:313899000 GMT j9mm.136 - Compact start: reason=compact to meet allocation 3STHSTTYPE 14:29:29:313555000 GMT j9mm.57 - Sweep end 3STHSTTYPE 14:29:29:310772000 GMT j9mm.56 - Sweep start 3STHSTTYPE 14:29:29:310765000 GMT j9mm.94 - Class unloading end: classloadersunloaded=0 classesunloaded=0 3STHSTTYPE 14:29:29:310753000 GMT j9mm.60 - Class unloading start 3STHSTTYPE 14:29:29:310750000 GMT j9mm.55 - Mark end 3STHSTTYPE 14:29:29:306013000 GMT j9mm.54 - Mark start 3STHSTTYPE 14:29:29:305957000 GMT j9mm.474 - GlobalGC start: globalcount=9 3STHSTTYPE 14:29:29:305888000 GMT j9mm.475 - GlobalGC end: workstackoverflow=0 overflowcount=0 memory=234284136/536870912 3STHSTTYPE 14:29:29:305837000 GMT j9mm.90 - GlobalGC collect complete 3STHSTTYPE 14:29:29:305808000 GMT j9mm.137 - Compact end: bytesmoved=189784 3STHSTTYPE 14:29:29:298042000 GMT j9mm.136 - Compact start: reason=compact to meet allocation 3STHSTTYPE 14:29:29:297695000 GMT j9mm.57 - Sweep end 3STHSTTYPE 14:29:29:291696000 GMT j9mm.56 - Sweep start 3STHSTTYPE 14:29:29:291692000 GMT j9mm.55 - Mark end 3STHSTTYPE 14:29:29:284994000 GMT j9mm.54 - Mark start 3STHSTTYPE 14:29:29:284941000 GMT j9mm.474 - GlobalGC start: globalcount=8 3STHSTTYPE 14:29:29:284916000 GMT j9mm.135 - Exclusive access: exclusiveaccessms=0.016 meanexclusiveaccessms=0.016 threads=0 lastthreadtid=0xB6B61100 beatenbyotherthread=0 3STHSTTYPE 14:29:29:284914000 GMT j9mm.469 - Allocation failure cycle start: newspace=2678784/3014656 oldspace=80601248/533856256 loa=5338112/5338112 requestedbytes=603979784 3STHSTTYPE 14:29:29:284893000 GMT j9mm.470 - Allocation failure cycle end: newspace=2678784/3014656 oldspace=80601248/533856256 loa=5338112/5338112 3STHSTTYPE 14:29:29:284858000 GMT j9mm.560 - LocalGC end: rememberedsetoverflow=0 causedrememberedsetoverflow=0 scancacheoverflow=0 failedflipcount=0 failedflipbytes=0 failedtenurecount=0 failedtenurebytes=0 flipcount=2 flipbytes=64 newspace=2678784/3014656 oldspace=80601248/533856256 loa=5338112/5338112 tenureage=0 3STHSTTYPE 14:29:29:284140000 GMT j9mm.140 - Tilt ratio: 89 3STHSTTYPE 14:29:29:283160000 GMT j9mm.64 - LocalGC start: globalcount=8 scavengecount=335 weakrefs=0 soft=0 phantom=0 finalizers=0 3STHSTTYPE 14:29:29:283123000 GMT j9mm.135 - Exclusive access: exclusiveaccessms=0.016 meanexclusiveaccessms=0.016 threads=0 lastthreadtid=0xB6B61100 beatenbyotherthread=0 3STHSTTYPE 14:29:29:283120000 GMT j9mm.469 - Allocation failure cycle start: newspace=753616/3014656 oldspace=80601248/533856256 loa=5338112/5338112 requestedbytes=603979784 3STHSTTYPE 14:29:29:283117000 GMT j9mm.133 - Allocation failure start: newspace=753616/3014656 oldspace=80601248/533856256 loa=5338112/5338112 requestedbytes=603979784 3STHSTTYPE 14:29:29:269762000 GMT j9mm.134 - Allocation failure end: newspace=2686928/3014656 oldspace=80601248/533856256 loa=5338112/5338112 3STHSTTYPE 14:29:29:269751000 GMT j9mm.470 - Allocation failure cycle end: newspace=2686976/3014656 oldspace=80601248/533856256 loa=5338112/5338112 3STHSTTYPE 14:29:29:269718000 GMT j9mm.560 - LocalGC end: rememberedsetoverflow=0 causedrememberedsetoverflow=0 scancacheoverflow=0 failedflipcount=0 failedflipbytes=0 failedtenurecount=0 failedtenurebytes=0 flipcount=0 flipbytes=0 newspace=2686976/3014656 oldspace=80601248/533856256 loa=5338112/5338112 tenureage=0 3STHSTTYPE 14:29:29:268981000 GMT j9mm.140 - Tilt ratio: 89 3STHSTTYPE 14:29:29:268007000 GMT j9mm.64 - LocalGC start: globalcount=8 scavengecount=334 weakrefs=0 soft=0 phantom=0 finalizers=0 3STHSTTYPE 14:29:29:267969000 GMT j9mm.135 - Exclusive access: exclusiveaccessms=0.016 meanexclusiveaccessms=0.016 threads=0 lastthreadtid=0xB6B61100 beatenbyotherthread=0 3STHSTTYPE 14:29:29:267966000 GMT j9mm.469 - Allocation failure cycle start: newspace=0/3014656 oldspace=80601248/533856256 loa=5338112/5338112 requestedbytes=48 3STHSTTYPE 14:29:29:267963000 GMT j9mm.133 - Allocation failure start: newspace=0/3014656 oldspace=80601248/533856256 loa=5338112/5338112 requestedbytes=48 3STHSTTYPE 14:29:29:249015000 GMT j9mm.134 - Allocation failure end: newspace=2686928/3014656 oldspace=80601248/533856256 loa=5338112/5338112 3STHSTTYPE 14:29:29:249003000 GMT j9mm.470 - Allocation failure cycle end: newspace=2686976/3014656 oldspace=80601248/533856256 loa=5338112/5338112 3STHSTTYPE 14:29:29:248971000 GMT j9mm.560 - LocalGC end: rememberedsetoverflow=0 causedrememberedsetoverflow=0 scancacheoverflow=0 failedflipcount=0 failedflipbytes=0 failedtenurecount=0 failedtenurebytes=0 flipcount=0 flipbytes=0 newspace=2686976/3014656 oldspace=80601248/533856256 loa=5338112/5338112 tenureage=0 Although the Java code that was used in this scenario deliberately triggered an OutOfMemoryError in a pronounced way, similar allocation issues can and do occur when dealing with large data sets such as XML files. The next step in diagnosing the problem is to open the system dump that gets generated automatically when an OutOfMemoryError occurs. Open the dump with the Eclipse Memory Analyzer tool (MAT) and search for the StringBuffer object, which should provide further clues about what went wrong. A common example is seeing the same String duplicated over and over again, which might indicate that code is stuck in a loop. Note: If you want to use MAT to analyze your system dump, you must install the Diagnostic Tool Framework for Java (DTFJ) plugin in the Eclipse IDE. Select the following menu items: Help > Install New Software > Work with \"IBM Diagnostic Tool Framework for Java\" > If, unlike the previous scenario, you receive an OutOfMemoryError and the MEMINFO section shows that there is very little space left on the Java heap, the current thread information is typically not important. The current thread is simply the thread that happened to be current when the space ran out. In this situation you might want to increase your Java heap size. For help with this task, see How to do heap sizing .","title":"Java OutOfMemoryError"},{"location":"dump_javadump/#native-outofmemoryerror","text":"In this scenario, the VM runs out of native memory. Native memory is memory that is used by the VM for storing all virtualized resources and data that it needs for VM operations. Native memory that is available to the VM process is limited by the operating system. The native memory available to the VM might also be subject to additional limits imposed by the operating system, for example Unix ulimits . When a NativeOutOfMemoryError occurs, a Java dump is generated by default. The first section of the file (TITLE) tells you that a systhrow event triggered the Java dump as a result of an OOM ( java/lang/OutOfMemoryError ) for native memory. 0SECTION TITLE subcomponent dump routine NULL =============================== 1TICHARSET UTF-8 1TISIGINFO Dump Event \"systhrow\" (00040000) Detail \"java/lang/OutOfMemoryError\" \"native memory exhausted\" received 1TIDATETIMEUTC Date: 2021/04/23 at 18:02:44:017 (UTC) 1TIDATETIME Date: 2021/04/23 at 14:02:44:017 1TITIMEZONE Timezone: UTC-4 (EDT) 1TINANOTIME System nanotime: 379202644260787 1TIFILENAME Javacore filename: /home/cheesemp/test/javacore.20210423.140244.19708.0003.txt 1TIREQFLAGS Request Flags: 0x81 (exclusive+preempt) 1TIPREPSTATE Prep State: 0x104 (exclusive_vm_access+trace_disabled) Sometimes, the current thread is responsible for causing the NativeOutOfMemoryError . Information about the current thread can be found in the THREADS section, as shown in the following output. 0SECTION THREADS subcomponent dump routine NULL ================================= NULL 1XMPOOLINFO JVM Thread pool info: 2XMPOOLTOTAL Current total number of pooled threads: 16 2XMPOOLLIVE Current total number of live threads: 16 2XMPOOLDAEMON Current total number of live daemon threads: 15 NULL 1XMCURTHDINFO Current thread 3XMTHREADINFO \"main\" J9VMThread:0xB6C60C00, omrthread_t:0xB6C049D8, java/lang/Thread:0xB55E3C10, state:R, prio=5 3XMJAVALTHREAD (java/lang/Thread getId:0x1, isDaemon:false) 3XMTHREADINFO1 (native thread ID:0x4CFD, native priority:0x5, native policy:UNKNOWN, vmstate:R, vm thread flags:0x00001020) 3XMTHREADINFO2 (native stack address range from:0xB6D4E000, to:0xB754F000, size:0x801000) 3XMCPUTIME CPU usage total: 3.654896026 secs, current category=\"Application\" 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at sun/misc/Unsafe.allocateDBBMemory(Native Method) 4XESTACKTRACE at java/nio/DirectByteBuffer.<init>(DirectByteBuffer.java:127(Compiled Code)) 4XESTACKTRACE at java/nio/ByteBuffer.allocateDirect(ByteBuffer.java:311) 4XESTACKTRACE at NativeHeapBreaker.main(NativeHeapBreaker.java:9) 3XMTHREADINFO3 Native callstack: 4XENATIVESTACK (0xB6A9F5B3 [libj9prt29.so+0x3b5b3]) ... 4XENATIVESTACK (0xB582CC9C [libjclse7b_29.so+0x40c9c]) 4XENATIVESTACK Java_sun_misc_Unsafe_allocateDBBMemory+0x88 (0xB5827F6B [libjclse7b_29.so+0x3bf6b]) 4XENATIVESTACK (0x94A2084A [<unknown>+0x0]) 4XENATIVESTACK (0xB6B2538B [libj9vm29.so+0x6c38b]) 4XENATIVESTACK (0xB6B4074C [libj9vm29.so+0x8774c]) 4XENATIVESTACK (0xB6B7F299 [libj9vm29.so+0xc6299]) 4XENATIVESTACK (0xB6A82F3E [libj9prt29.so+0x1ef3e]) 4XENATIVESTACK (0xB6B7F32A [libj9vm29.so+0xc632a]) 4XENATIVESTACK (0xB6B4084C [libj9vm29.so+0x8784c]) 4XENATIVESTACK (0xB6B3CD0C [libj9vm29.so+0x83d0c]) 4XENATIVESTACK (0xB776F87D [libjli.so+0x787d]) 4XENATIVESTACK (0xB7784F72 [libpthread.so.0+0x6f72]) 4XENATIVESTACK clone+0x5e (0xB76A043E [libc.so.6+0xee43e]) For clarity in the Native callstack output, ... indicates that some lines are removed. The Java callstack shows the transition from Java to native code ( sun/misc/Unsafe.allocateDBBMemory(Native Method) ), indicating a request for Direct Byte Buffer (DBB) storage. DBB storage is backed by native memory, with the Java heap containing only a reference to the native heap buffer. In this scenario, DBB storage is the likely culprit for this NativeOutOfMemoryError . The next step is to investigate the NATIVEMEMINFO section of the Java dump file, which reports the amount of memory used by the JRE process, broken down into component areas. 0SECTION NATIVEMEMINFO subcomponent dump routine NULL ================================= 0MEMUSER 1MEMUSER JRE: 3,166,386,688 bytes / 4388 allocations 1MEMUSER | 2MEMUSER +--VM: 563,176,824 bytes / 1518 allocations 2MEMUSER | | 3MEMUSER | +--Classes: 3,104,416 bytes / 120 allocations 2MEMUSER | | 3MEMUSER | +--Memory Manager (GC): 548,181,888 bytes / 398 allocations 3MEMUSER | | | 4MEMUSER | | +--Java Heap: 536,932,352 bytes / 1 allocation 3MEMUSER | | | 4MEMUSER | | +--Other: 11,249,536 bytes / 397 allocations 2MEMUSER | | 3MEMUSER | +--Threads: 10,817,120 bytes / 147 allocations 3MEMUSER | | | 4MEMUSER | | +--Java Stack: 115,584 bytes / 16 allocations 3MEMUSER | | | 4MEMUSER | | +--Native Stack: 10,616,832 bytes / 17 allocations 3MEMUSER | | | 4MEMUSER | | +--Other: 84,704 bytes / 114 allocations 2MEMUSER | | 3MEMUSER | +--Trace: 163,688 bytes / 268 allocations 2MEMUSER | | 3MEMUSER | +--JVMTI: 17,320 bytes / 13 allocations 2MEMUSER | | 3MEMUSER | +--JNI: 23,296 bytes / 55 allocations 2MEMUSER | | 3MEMUSER | +--Port Library: 8,576 bytes / 74 allocations 2MEMUSER | | 3MEMUSER | +--Other: 860,520 bytes / 443 allocations 1MEMUSER | 2MEMUSER +--JIT: 3,744,728 bytes / 122 allocations 2MEMUSER | | 3MEMUSER | +--JIT Code Cache: 2,097,152 bytes / 1 allocation 2MEMUSER | | 3MEMUSER | +--JIT Data Cache: 524,336 bytes / 1 allocation 2MEMUSER | | 3MEMUSER | +--Other: 1,123,240 bytes / 120 allocations 1MEMUSER | 2MEMUSER +--Class Libraries: 2,599,463,024 bytes / 2732 allocations 2MEMUSER | | 3MEMUSER | +--Harmony Class Libraries: 1,024 bytes / 1 allocation 2MEMUSER | | 3MEMUSER | +--VM Class Libraries: 2,599,462,000 bytes / 2731 allocations 3MEMUSER | | | 4MEMUSER | | +--sun.misc.Unsafe: 2,598,510,480 bytes / 2484 allocations 4MEMUSER | | | | 5MEMUSER | | | +--Direct Byte Buffers: 2,598,510,480 bytes / 2484 allocations 3MEMUSER | | | 4MEMUSER | | +--Other: 951,520 bytes / 247 allocations 1MEMUSER | 2MEMUSER +--Unknown: 2,112 bytes / 16 allocations NULL In the VM Class Libraries section, the amount of memory allocated for Direct Byte Buffers is shown. Because the NativeOutOfMemoryError was received on a small 32-bit system, a value of 2,598,510,480 bytes indicates that the operating system has run out of memory. On a larger UNIX system, the process might have run out of memory because of the ulimit setting. Increasing the value for ulimit might avoid the error, which you can do temporarily by setting ulimit -f unlimited in your current session. The theoretical maximum size for a 32-bit process is the size of the 32-bit address space, which is 4 GB. On most operating systems a portion of the address space for each process is used by the kernel, such that the real limit for 32-bit processes is actually significantly less than 4GB. As a result, running out of native memory with a 32-bit VM is quite common. The same 4 GB limit is also important if you are using a 64-bit VM with compressed references. In compressed references mode, all references to objects, classes, threads, and monitors are represented by 32-bit values for performance reasons, so these structures can be allocated only at 32-bit addresses. However, the operating system might place other allocations within this 4 GB of address space, and if this area becomes sufficiently full or fragmented, the VM throws a native NativeOutOfMemoryError error. These errors typically occur when the VM tries to create a new thread or load a class. The Current Thread History section should contain more information about what the thread was doing at the VM level when the NativeOutOfMemoryError error occurred. You can usually avoid this type of problem by using the -Xmcrs option to reserve a contiguous area of memory within the lowest 4GB of memory at VM startup. Another common cause of a NativeOutOfMemoryError is when an application loads duplicate classes. Classes are allocated outside of the Java heap in native memory. If the value reported for Classes in the NATIVEMEMINFO section is very large, duplicate classes might be the cause of your problem. The Eclipse Memory Analyzer Tool (MAT) can tell you if you have duplicate classes by using the Class Loader Explorer feature. Because a system dump is automatically generated as well as a Java dump in response to a NativeOutOfMemoryError , simply open the system dump in MAT to continue your diagnosis.","title":"Native OutOfMemoryError"},{"location":"dump_javadump/#deadlock","text":"Deadlocks occur when two threads attempt to synchronize on an object and lock an instance of a class. When this happens, your application stops responding and hangs. Generating a Java dump file will quickly tell you whether you have a deadlock situation. Trigger the Java dump by sending a SIGQUIT signal ( kill -3 ) to the VM. The VM can detect the most common types of deadlock scenario involving Java monitors. If this type of deadlock is detected, information is provided in the LOCKS section. More complex deadlocks, including those that involve a mixture of native mutexes and Java monitors, are not detected. Here is the output from the code that was used to cause a common deadlock scenario: NULL 1LKDEADLOCK Deadlock detected !!! NULL --------------------- NULL 2LKDEADLOCKTHR Thread \"Worker Thread 2\" (0x94501D00) 3LKDEADLOCKWTR is waiting for: 4LKDEADLOCKMON sys_mon_t:0x08C2B344 infl_mon_t: 0x08C2B384: 4LKDEADLOCKOBJ java/lang/Object@0xB5666698 3LKDEADLOCKOWN which is owned by: 2LKDEADLOCKTHR Thread \"Worker Thread 3\" (0x94507500) 3LKDEADLOCKWTR which is waiting for: 4LKDEADLOCKMON sys_mon_t:0x08C2B3A0 infl_mon_t: 0x08C2B3E0: 4LKDEADLOCKOBJ java/lang/Object@0xB5666678 3LKDEADLOCKOWN which is owned by: 2LKDEADLOCKTHR Thread \"Worker Thread 1\" (0x92A3EC00) 3LKDEADLOCKWTR which is waiting for: 4LKDEADLOCKMON sys_mon_t:0x08C2B2E8 infl_mon_t: 0x08C2B328: 4LKDEADLOCKOBJ java/lang/Object@0xB5666688 3LKDEADLOCKOWN which is owned by: 2LKDEADLOCKTHR Thread \"Worker Thread 2\" (0x94501D00) This output tells you that Worker Thread 2 is waiting for Worker Thread 3 , which is waiting for Worker Thread 1 . Because Worker Thread 1 is also waiting for Worker Thread 2 , there is a deadlock. The next place to look is the output for Java and native stacks, in the THREADS section. By looking at the stack for each of these worker threads you can trace the problem back to specific lines in your application code. In this example, you can see from the following output that for all worker threads, the stack traces ( 4XESTACKTRACE / 5XESTACKTRACE ) indicate a problem in line 35 of the application DeadLockTest.java : 3XMTHREADINFO \"Worker Thread 1\" J9VMThread:0x92A3EC00, omrthread_t:0x92A3C2B0, java/lang/Thread:0xB5666778, state:B, prio=5 3XMJAVALTHREAD (java/lang/Thread getId:0x13, isDaemon:false) 3XMTHREADINFO1 (native thread ID:0x52CF, native priority:0x5, native policy:UNKNOWN, vmstate:B, vm thread flags:0x00000201) 3XMTHREADINFO2 (native stack address range from:0x9297E000, to:0x929BF000, size:0x41000) 3XMCPUTIME CPU usage total: 0.004365543 secs, current category=\"Application\" 3XMTHREADBLOCK Blocked on: java/lang/Object@0xB5666688 Owned by: \"Worker Thread 2\" (J9VMThread:0x94501D00, java/lang/Thread:0xB56668D0) 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at WorkerThread.run(DeadLockTest.java:35) 5XESTACKTRACE (entered lock: java/lang/Object@0xB5666678, entry count: 1) ... 3XMTHREADINFO \"Worker Thread 2\" J9VMThread:0x94501D00, omrthread_t:0x92A3C8F0, java/lang/Thread:0xB56668D0, state:B, prio=5 3XMJAVALTHREAD (java/lang/Thread getId:0x14, isDaemon:false) 3XMTHREADINFO1 (native thread ID:0x52D0, native priority:0x5, native policy:UNKNOWN, vmstate:B, vm thread flags:0x00000201) 3XMTHREADINFO2 (native stack address range from:0x946BF000, to:0x94700000, size:0x41000) 3XMCPUTIME CPU usage total: 0.004555580 secs, current category=\"Application\" 3XMTHREADBLOCK Blocked on: java/lang/Object@0xB5666698 Owned by: \"Worker Thread 3\" (J9VMThread:0x94507500, java/lang/Thread:0xB5666A18) 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at WorkerThread.run(DeadLockTest.java:35) 5XESTACKTRACE (entered lock: java/lang/Object@0xB5666688, entry count: 1) ... 3XMTHREADINFO \"Worker Thread 3\" J9VMThread:0x94507500, omrthread_t:0x92A3CC10, java/lang/Thread:0xB5666A18, state:B, prio=5 3XMJAVALTHREAD (java/lang/Thread getId:0x15, isDaemon:false) 3XMTHREADINFO1 (native thread ID:0x52D1, native priority:0x5, native policy:UNKNOWN, vmstate:B, vm thread flags:0x00000201) 3XMTHREADINFO2 (native stack address range from:0x9467E000, to:0x946BF000, size:0x41000) 3XMCPUTIME CPU usage total: 0.003657010 secs, current category=\"Application\" 3XMTHREADBLOCK Blocked on: java/lang/Object@0xB5666678 Owned by: \"Worker Thread 1\" (J9VMThread:0x92A3EC00, java/lang/Thread:0xB5666778) 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at WorkerThread.run(DeadLockTest.java:35) 5XESTACKTRACE (entered lock: java/lang/Object@0xB5666698, entry count: 1)","title":"Deadlock"},{"location":"dump_javadump/#hang","text":"An application can hang for a number of reasons but the most common cause is excessive global garbage collection (GC) activity, where your application is repeatedly paused because your Java heap has almost run out of memory. You can identify this problem by looking at verbose GC output. Collect this output by specifying the -verbose:gc option. Deadlock situations can also manifest themselves as hangs. For more information on diagnosing this type of problem from a Java dump, see the deadlock scenario. If you have eliminated verbose GC activity and deadlocks, another common hang scenario involves threads that compete and wait for Java object locks. This type of problem can usually be diagnosed by examining a Java dump. The simplest hang scenario involving Java object locks is where a thread acquires a lock that other threads are waiting for, but it doesn't release the lock for some reason. The first place to look in the Java dump output is the LOCKS section. This section lists all the monitors and shows which threads have acquired a lock and which threads are waiting. If the hang is caused by a thread not releasing a lock that other threads need, you can see a list of waiting threads in the output. In this example scenario, the Java dump LOCKS section shows that Worker Thread 0 ( 3LKMONOBJECT ) has acquired a lock and there are 19 other worker threads waiting to obtain the lock. NULL ------------------------------------------------------------------------ 0SECTION LOCKS subcomponent dump routine NULL =============================== NULL 1LKPOOLINFO Monitor pool info: 2LKPOOLTOTAL Current total number of monitors: 1 NULL 1LKMONPOOLDUMP Monitor Pool Dump (flat & inflated object-monitors): 2LKMONINUSE sys_mon_t:0x92711200 infl_mon_t: 0x92711240: 3LKMONOBJECT java/lang/Object@0xB56658D8: Flat locked by \"Worker Thread 0\" (J9VMThread:0x92A3EC00), entry count 1 3LKWAITERQ Waiting to enter: 3LKWAITER \"Worker Thread 1\" (J9VMThread:0x92703F00) 3LKWAITER \"Worker Thread 2\" (J9VMThread:0x92709C00) 3LKWAITER \"Worker Thread 3\" (J9VMThread:0x92710A00) 3LKWAITER \"Worker Thread 4\" (J9VMThread:0x92717F00) 3LKWAITER \"Worker Thread 5\" (J9VMThread:0x9271DC00) 3LKWAITER \"Worker Thread 6\" (J9VMThread:0x92723A00) 3LKWAITER \"Worker Thread 7\" (J9VMThread:0x92729800) 3LKWAITER \"Worker Thread 8\" (J9VMThread:0x92733700) 3LKWAITER \"Worker Thread 9\" (J9VMThread:0x92739400) 3LKWAITER \"Worker Thread 10\" (J9VMThread:0x92740200) 3LKWAITER \"Worker Thread 11\" (J9VMThread:0x92748100) 3LKWAITER \"Worker Thread 12\" (J9VMThread:0x9274DF00) 3LKWAITER \"Worker Thread 13\" (J9VMThread:0x92754D00) 3LKWAITER \"Worker Thread 14\" (J9VMThread:0x9275AA00) 3LKWAITER \"Worker Thread 15\" (J9VMThread:0x92760800) 3LKWAITER \"Worker Thread 16\" (J9VMThread:0x92766600) 3LKWAITER \"Worker Thread 17\" (J9VMThread:0x9276C300) 3LKWAITER \"Worker Thread 18\" (J9VMThread:0x92773100) 3LKWAITER \"Worker Thread 19\" (J9VMThread:0x92778F00) NULL The next step is to determine why Worker Thread 0 is not releasing the lock. The best place to start is the stack trace for this thread, which you can find by searching on the thread name or J9VMThread ID in the THREADS section. The following extract shows the details for \"Worker Thread 0\" (J9VMThread:0x92A3EC00) : NULL 3XMTHREADINFO \"Worker Thread 0\" J9VMThread:0x92A3EC00, omrthread_t:0x92A3C280, java/lang/Thread:0xB56668B8, state:CW, prio=5 3XMJAVALTHREAD (java/lang/Thread getId:0x13, isDaemon:false) 3XMTHREADINFO1 (native thread ID:0x511F, native priority:0x5, native policy:UNKNOWN, vmstate:CW, vm thread flags:0x00000401) 3XMTHREADINFO2 (native stack address range from:0x9297E000, to:0x929BF000, size:0x41000) 3XMCPUTIME CPU usage total: 0.000211878 secs, current category=\"Application\" 3XMHEAPALLOC Heap bytes allocated since last GC cycle=0 (0x0) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at java/lang/Thread.sleep(Native Method) 4XESTACKTRACE at java/lang/Thread.sleep(Thread.java:941) 4XESTACKTRACE at WorkerThread.doWork(HangTest.java:37) 4XESTACKTRACE at WorkerThread.run(HangTest.java:31) 5XESTACKTRACE (entered lock: java/lang/Object@0xB56658D8, entry count: 1) In the last line of this output you can see where the thread acquired the lock. Working up from this line, you can see that WorkerThread.run was called, which in turn called WorkerThread.doWork . The stack shows that the thread then entered a call to java/lang/Thread.sleep in HangTest.java on line 37, which is preventing the thread from completing its work and releasing the lock. In this example the sleep call was added to induce a hang, but in real-world scenarios the cause could be any blocking operation, such as reading from an input stream or socket. Another possibility is that the thread is waiting for another lock owned by yet another thread. It is important to remember that each Java dump represents a single snapshot in time. You should generate at least three Java dumps separated by a short pause, for example 30 seconds, and compare the output. This comparison tells you whether the threads involved are stuck in a fixed state or whether they are moving. In this example, the threads do not move and the investigation needs to focus on the logic in WorkerThread.doWork to understand why Worker Thread 0 entered the java/lang/Thread.sleep call. Another common scenario is where each Java dump shows a number of threads waiting for a lock owned by another thread, but the list of waiting threads and the lock-owning thread change over time. In this case the cause is likely to be a bottleneck caused by thread contention, where the threads are continually competing for the same lock. In severe cases, the lock is held only for a small amount of time but there are lots of threads trying to obtain it. Because more time is spent handling the lock and scheduling the thread than executing application code, the degradation in performance is manifested as a hang. Thread contention is usually caused by an application design problem. You can use a similar approach to the one used in this scenario to determime which lines of code are responsible for the contention.","title":"Hang"},{"location":"dump_systemdump/","text":"System dump System dumps, often known as core dumps , are platform-specific and contain a raw binary dump of the process memory. This type of dump has a complete copy of the Java heap, including the contents of all Java objects in the application. Obtaining system dumps System dumps are produced in response to specific events. To discover which events generate a dump, run the -Xdump:what command. The following output captures the information shown for a system dump: -Xdump:system: events=gpf+abort+traceassert+corruptcache, label=/home/user/core.%Y%m%d.%H%M%S.%pid.%seq.dmp, range=1..0, priority=999, request=serial This output shows that events such as a general protection fault (gpf) or native abort() call can trigger a system dump. For more information about controlling the behavior of dump agents, see Dump agents . Enabling a full system dump (AIX, Linux, and macOS) If you require a system dump that contains details of all the native threads that are running, you must change the resource limits for your operating system. Otherwise, the native thread details that are stored in the dump are only for the native thread that was running when the VM ended. Set the system resource limits by running the following commands: ulimit -c unlimited ulimit -n unlimited ulimit -d unlimited ulimit -f unlimited Where: -c sets core files -n sets the number of open files -d sets the data limit -f sets the file limit For AIX systems, use the system management interface tool (SMIT) to enable a full CORE dump that is not a pre-430 style CORE dump . You can also set this configuration with the following command line option: chdev -l sys0 -a fullcore='true' -a pre430core='false' Analyzing a system dump To examine a system dump you can use the OpenJ9 dump viewer ( jdmpview ), a platform-specific debugging tool, or the Eclipse Memory Analyzer tool (MAT) . If you want to use MAT to analyze your system dump, you must install the Diagnostic Tool Framework for Java (DTFJ) plugin in the Eclipse IDE. Select the following menu items: Help > Install New Software > Work with \"IBM Diagnostic Tool Framework for Java\" > IBM Monitoring and Diagnostic Tools > Diagnostic Tool Framework for Java","title":"System dump"},{"location":"dump_systemdump/#system-dump","text":"System dumps, often known as core dumps , are platform-specific and contain a raw binary dump of the process memory. This type of dump has a complete copy of the Java heap, including the contents of all Java objects in the application.","title":"System dump"},{"location":"dump_systemdump/#obtaining-system-dumps","text":"System dumps are produced in response to specific events. To discover which events generate a dump, run the -Xdump:what command. The following output captures the information shown for a system dump: -Xdump:system: events=gpf+abort+traceassert+corruptcache, label=/home/user/core.%Y%m%d.%H%M%S.%pid.%seq.dmp, range=1..0, priority=999, request=serial This output shows that events such as a general protection fault (gpf) or native abort() call can trigger a system dump. For more information about controlling the behavior of dump agents, see Dump agents .","title":"Obtaining system dumps"},{"location":"dump_systemdump/#enabling-a-full-system-dump-aix-linux-and-macos","text":"If you require a system dump that contains details of all the native threads that are running, you must change the resource limits for your operating system. Otherwise, the native thread details that are stored in the dump are only for the native thread that was running when the VM ended. Set the system resource limits by running the following commands: ulimit -c unlimited ulimit -n unlimited ulimit -d unlimited ulimit -f unlimited Where: -c sets core files -n sets the number of open files -d sets the data limit -f sets the file limit For AIX systems, use the system management interface tool (SMIT) to enable a full CORE dump that is not a pre-430 style CORE dump . You can also set this configuration with the following command line option: chdev -l sys0 -a fullcore='true' -a pre430core='false'","title":"Enabling a full system dump (AIX, Linux, and macOS)"},{"location":"dump_systemdump/#analyzing-a-system-dump","text":"To examine a system dump you can use the OpenJ9 dump viewer ( jdmpview ), a platform-specific debugging tool, or the Eclipse Memory Analyzer tool (MAT) . If you want to use MAT to analyze your system dump, you must install the Diagnostic Tool Framework for Java (DTFJ) plugin in the Eclipse IDE. Select the following menu items: Help > Install New Software > Work with \"IBM Diagnostic Tool Framework for Java\" > IBM Monitoring and Diagnostic Tools > Diagnostic Tool Framework for Java","title":"Analyzing a system dump"},{"location":"env_var/","text":"Environment variables Although the OpenJ9 virtual machine (VM) recognizes many environment variables, most are superseded by command-line arguments. Use command-line arguments rather than environment variables, which are retained only for compatibility. Note: Environment variables are overridden by command-line arguments. Finding and setting environment variables To show the current environment, run: set (Windows\u2122) env (AIX\u00ae, Linux\u00ae, and macOS\u00ae) set (z/OS\u00ae) To show a particular environment variable, run: echo %ENVNAME% (Windows) echo $ENVNAME (AIX, Linux, macOS, and z/OS) Use values exactly as shown in the documentation. The names of environment variables are case-sensitive in AIX, Linux, macOS, and z/OS. To set the environment variable LOGIN_NAME to Fred , run: set LOGIN_NAME=Fred (Windows) export LOGIN_NAME=Fred (AIX/Linux/macOS: ksh or bash shells) setenv LOGIN_NAME Fred (csh shells) These variables are set only for the current shell or command-line session. If you are setting multiple values for an environment variable in a list: On AIX, Linux, macOS, and z/OS the separator is typically a colon (:). On Windows the separator is typically a semicolon (;). General options General VM environment variables are shown in the following table: Environment variable Usage information IBM_JAVA_COMMAND_LINE This variable is set by the VM after it starts. Using this variable, you can find the command-line parameters set when the VM started. This setting is not available if the VM is invoked by using JNI. OPENJ9_JAVA_OPTIONS=<option> Set this variable to store default Java options, including -X , -D , or -verbose:gc style options. For example, -Xms256m -Djava.compiler . Any options set are overridden by equivalent options that are specified when Java is started. This variable does not support certain options, see the list in -Xoptionsfile . If you specify the name of a trace output file either directly, or indirectly, by using a properties file, the output file might be accidentally overwritten if you run utilities such as the trace formatter, dump extractor, or dump viewer. To avoid this problem, add %d, %p or %t to the trace file names. See -Xtrace:output . Note: The equivalent to OPENJ9_JAVA_OPTIONS , IBM_JAVA_OPTIONS is deprecated and will be removed in a future release. JAVA_FONTS=<list of directories> Set this environment variable to specify the font directory. Setting this variable is equivalent to setting the property java.awt.fonts on Windows operating systems, and sun.java2d.fontpath on other operating systems. _JAVA_OPTIONS=<option> Set this variable to add Java options to the end of the command line. Supported options and trace file issues are the same as for OPENJ9_JAVA_OPTIONS . Dump agent options The preferred mechanism for controlling the production of dumps is by using the -Xdump option. However, these legacy environment variables are preserved and can still be used. The following table describes dump agent options: Environment Variable Usage Information JAVA_DUMP_OPTS Used to control the conditions under which dumps are produced. If you set agents for a condition by using the JAVA_DUMP_OPTS environment variable, default dump agents for that condition are disabled; however, any -Xdump options that are specified on the command line are used. The JAVA_DUMP_OPTS environment variable uses the following syntax: JAVA_DUMP_OPTS=\"ON<condition>(<agent>[<count>],<agent>[<count>]), ON<condition>(<agent>[<count>],...),...)\" Where: <condition> is one of the following values: ANYSIGNAL DUMP ERROR INTERRUPT EXCEPTION OUTOFMEMORY <agent> is one of the following values: ALL NONE JAVADUMP SYSDUMP HEAPDUMP CEEDUMP (z/OS specific) <count> is the number of times to run the specified agent for the specified condition. This value is optional. By default, the agent runs every time that the condition occurs. JAVA_DUMP_OPTS is parsed by taking the leftmost occurrence of each condition, so duplicates are ignored. The following setting produces a system dump for the first error condition only: ONERROR(SYSDUMP[1]),ONERROR(JAVADUMP) Also, the ONANYSIGNAL condition is parsed before all others, so ONINTERRUPT(NONE),ONANYSIGNAL(SYSDUMP) has the same effect as ONANYSIGNAL(SYSDUMP),ONINTERRUPT(NONE) If the JAVA_DUMP_TOOL environment variable is set, that variable is assumed to specify a valid executable name and is parsed for replaceable fields, such as %pid . If %pid is detected in the string, the string is replaced with the VM's own process ID. The tool that is specified by JAVA_DUMP_TOOL is run after any system dump or heap dump is taken, before anything else. The dump settings are applied in the following order. Settings later in the list take precedence: Default VM dump behavior. -Xdump command-line options that specify -Xdump:<type>:defaults , see OpenJ9 default options . DISABLE_JAVADUMP , IBM_HEAPDUMP , and IBM_HEAP_DUMP environment variables. IBM_JAVADUMP_OUTOFMEMORY and IBM_HEAPDUMP_OUTOFMEMORY environment variables. JAVA_DUMP_OPTS environment variable. Remaining -Xdump command-line options. Setting JAVA_DUMP_OPTS affects only those conditions that you specify. Actions on other conditions are unchanged. Signal mapping When setting the JAVA_DUMP_OPTS environment variable, the mapping of operating system signals to the \"condition\" is shown in the following table: Condition z/OS Windows Linux, macOS, and AIX EXCEPTION SIGTRAP, SIGILL, SIGSEGV, SIGFPE, SIGBUS, SIGSYS, SIGXFSV SIGILL, SIGSEGV, SIGFPE SIGTRAP, SIGILL, SIGSEGV, SIGFPE, SIGBUS, SIGXFSV INTERRUPT SIGINT, SIGTERM, SIGHUP SIGINT, SIGTERM SIGINT, SIGTERM, SIGHUP ERROR SIGABRT SIGABRT SIGABRT DUMP SIGQUIT SIGBREAK SIGQUIT Java dump options The preferred mechanism for controlling the production of Java dumps is by using the -Xdump:java option. However, these legacy environment variables are preserved and can still be used. Environment Variable Usage Information DISABLE_JAVADUMP=[TRUE|FALSE] Setting DISABLE_JAVADUMP to TRUE is the equivalent of using -Xdump:java:none and stops the default production of Java dumps. IBM_JAVACOREDIR=<directory> The default location into which the Java dump is written. On z/OS, the _CEE_DMPTARG environment variable is used instead. IBM_JAVADUMP_OUTOFMEMORY=[TRUE|FALSE] By setting this environment variable to FALSE , you disable Java dumps for an out-of-memory exception. When not set, a Java dump is generated when an out-of-memory exception is thrown but not caught and handled by the application. Set to TRUE to generate a dump when an out-of-memory exception is thrown, even if it is handled by the application. Set to FALSE to disable Java dumps for an out-of-memory exception. TMPDIR=<directory> This variable specifies an alternative temporary directory. This directory is used only when Java dumps and Heap dumps cannot be written to their target directories, or the current working directory. The default is /tmp ( C:\\temp for Windows). Note: You can use the dump agent JAVA_DUMP_OPTS variable to control the conditions under which Java dumps are produced. Heap dump options The preferred mechanism for controlling the production of Java dumps is by using the -Xdump:heap option. However, these legacy environment variables are preserved and can still be used. Environment Variable Usage Information IBM_HEAPDUMP=[TRUE|FALSE] Setting this option to TRUE enables heap dump production by using signals. IBM_HEAP_DUMP=[TRUE|FALSE] Setting this option to TRUE enables heap dump production by using signals. IBM_HEAPDUMPDIR=<directory> The default location into which the heap dump is written. On z/OS, the _CEE_DMPTARG environment variable is used instead. IBM_HEAPDUMP_OUTOFMEMORY=[TRUE|FALSE] Controls the generation of a heap dump when an out-of-memory exception is thrown. When not set, a heap dump is generated when an out-of-memory exception is thrown but not caught and handled by the application. Set to TRUE to generate a dump when an out-of-memory exception is thrown, even if it is handled by the application. Set to FALSE to disable heap dump for an out-of-memory exception. IBM_JAVA_HEAPDUMP_TEST Use this environment variable to cause the VM to generate both PHD and text versions of heap dumps. Equivalent to opts=PHD+CLASSIC on the -Xdump:heap option. IBM_JAVA_HEAPDUMP_TEXT Use this environment variable to cause the VM to generate a text (human readable) Heap dump. Equivalent to opts=CLASSIC on the -Xdump:heap option. TMPDIR=<directory> This variable specifies an alternative temporary directory. This directory is used only when Java dumps and heap dumps cannot be written to their target directories, or the current working directory. The default is /tmp ( C:\\temp for Windows). Note: You can use the dump agent JAVA_DUMP_OPTS variable to control the conditions under which Heap dumps are produced. Other diagnostic options The following table lists other environment variables that can be set for diagnostic purposes: Environment variable Usage Instructions IBM_COREDIR=<directory> Set this variable to specify an alternative location for system dumps, JIT dumps, and snap trace. On z/OS, _CEE_DMPTARG is used instead for snap trace, and transaction dumps are written to TSO according to JAVA_DUMP_TDUMP_PATTERN . On Linux and macOS, the dump is written to the directory that is specified directory by the operating system before being moved to the specified location. IBM_JAVA_ABEND_ON_FAILURE=Y (z/OS only) This setting tells the Java launcher to mark the Task Control Block (TCB) with an abend code if the OpenJ9 VM fails to load or is terminated by an uncaught exception. By default, the Java launcher does not mark the TCB. JAVA_DUMP_TDUMP_PATTERN=<string> (z/OS only) The specified <string> is passed to IEATDUMP to use as the data/set name for the Transaction Dump. The default <string> is %uid.JVM.TDUMP.%job.D%y%m%d.T%H%M%S (31-bit) or %uid.JVM.%job.D%y%m%d.T%H%M%S.X&amp;DS (64-bit), where %uid is found from the C code fragment shown in Notes . JAVA_THREAD_MODEL=<string> <string> can be defined as one of the following values: NATIVE (all threads are created as _MEDIUM_WEIGHT ), HEAVY (all threads are created as _HEAVY_WEIGHT ), MEDIUM (same as NATIVE ), or NULL . The default is NATIVE . IBM_XE_COE_NAME=<value> Set this variable to generate a system dump when the specified exception occurs. The value that is supplied is the package description of the exception; for example, java/lang/InternalError . A Signal 11 is followed by a JVMXE message and then the VM ends. JAVA_PLUGIN_TRACE=TRUE When this variable is set to TRUE or 1, a Java plug-in trace is produced for the session when an application runs. Traces are produced from both the Java and Native layer. By default, this variable is set to FALSE , so that a Java plug-in trace is not produced. Notes: C code fragment to discover %uid for JAVA_DUMP_TDUMP_PATTERN=<string> : pwd = getpwuid(getuid()); pwd->pw_name; Deprecated JIT options The following table describes deprecated environment variables for the JIT compiler: Environment Variable Usage Information IBM_MIXED_MODE_THRESHOLD Use -Xjit:count=<value> instead of this variable. JAVA_COMPILER Use -Djava.compiler=<value> instead of this variable.","title":"Environment variables"},{"location":"env_var/#environment-variables","text":"Although the OpenJ9 virtual machine (VM) recognizes many environment variables, most are superseded by command-line arguments. Use command-line arguments rather than environment variables, which are retained only for compatibility. Note: Environment variables are overridden by command-line arguments.","title":"Environment variables"},{"location":"env_var/#finding-and-setting-environment-variables","text":"To show the current environment, run: set (Windows\u2122) env (AIX\u00ae, Linux\u00ae, and macOS\u00ae) set (z/OS\u00ae) To show a particular environment variable, run: echo %ENVNAME% (Windows) echo $ENVNAME (AIX, Linux, macOS, and z/OS) Use values exactly as shown in the documentation. The names of environment variables are case-sensitive in AIX, Linux, macOS, and z/OS. To set the environment variable LOGIN_NAME to Fred , run: set LOGIN_NAME=Fred (Windows) export LOGIN_NAME=Fred (AIX/Linux/macOS: ksh or bash shells) setenv LOGIN_NAME Fred (csh shells) These variables are set only for the current shell or command-line session. If you are setting multiple values for an environment variable in a list: On AIX, Linux, macOS, and z/OS the separator is typically a colon (:). On Windows the separator is typically a semicolon (;).","title":"Finding and setting environment variables"},{"location":"env_var/#general-options","text":"General VM environment variables are shown in the following table: Environment variable Usage information IBM_JAVA_COMMAND_LINE This variable is set by the VM after it starts. Using this variable, you can find the command-line parameters set when the VM started. This setting is not available if the VM is invoked by using JNI. OPENJ9_JAVA_OPTIONS=<option> Set this variable to store default Java options, including -X , -D , or -verbose:gc style options. For example, -Xms256m -Djava.compiler . Any options set are overridden by equivalent options that are specified when Java is started. This variable does not support certain options, see the list in -Xoptionsfile . If you specify the name of a trace output file either directly, or indirectly, by using a properties file, the output file might be accidentally overwritten if you run utilities such as the trace formatter, dump extractor, or dump viewer. To avoid this problem, add %d, %p or %t to the trace file names. See -Xtrace:output . Note: The equivalent to OPENJ9_JAVA_OPTIONS , IBM_JAVA_OPTIONS is deprecated and will be removed in a future release. JAVA_FONTS=<list of directories> Set this environment variable to specify the font directory. Setting this variable is equivalent to setting the property java.awt.fonts on Windows operating systems, and sun.java2d.fontpath on other operating systems. _JAVA_OPTIONS=<option> Set this variable to add Java options to the end of the command line. Supported options and trace file issues are the same as for OPENJ9_JAVA_OPTIONS .","title":"General options"},{"location":"env_var/#dump-agent-options","text":"The preferred mechanism for controlling the production of dumps is by using the -Xdump option. However, these legacy environment variables are preserved and can still be used. The following table describes dump agent options: Environment Variable Usage Information JAVA_DUMP_OPTS Used to control the conditions under which dumps are produced. If you set agents for a condition by using the JAVA_DUMP_OPTS environment variable, default dump agents for that condition are disabled; however, any -Xdump options that are specified on the command line are used. The JAVA_DUMP_OPTS environment variable uses the following syntax: JAVA_DUMP_OPTS=\"ON<condition>(<agent>[<count>],<agent>[<count>]), ON<condition>(<agent>[<count>],...),...)\" Where: <condition> is one of the following values: ANYSIGNAL DUMP ERROR INTERRUPT EXCEPTION OUTOFMEMORY <agent> is one of the following values: ALL NONE JAVADUMP SYSDUMP HEAPDUMP CEEDUMP (z/OS specific) <count> is the number of times to run the specified agent for the specified condition. This value is optional. By default, the agent runs every time that the condition occurs. JAVA_DUMP_OPTS is parsed by taking the leftmost occurrence of each condition, so duplicates are ignored. The following setting produces a system dump for the first error condition only: ONERROR(SYSDUMP[1]),ONERROR(JAVADUMP) Also, the ONANYSIGNAL condition is parsed before all others, so ONINTERRUPT(NONE),ONANYSIGNAL(SYSDUMP) has the same effect as ONANYSIGNAL(SYSDUMP),ONINTERRUPT(NONE) If the JAVA_DUMP_TOOL environment variable is set, that variable is assumed to specify a valid executable name and is parsed for replaceable fields, such as %pid . If %pid is detected in the string, the string is replaced with the VM's own process ID. The tool that is specified by JAVA_DUMP_TOOL is run after any system dump or heap dump is taken, before anything else. The dump settings are applied in the following order. Settings later in the list take precedence: Default VM dump behavior. -Xdump command-line options that specify -Xdump:<type>:defaults , see OpenJ9 default options . DISABLE_JAVADUMP , IBM_HEAPDUMP , and IBM_HEAP_DUMP environment variables. IBM_JAVADUMP_OUTOFMEMORY and IBM_HEAPDUMP_OUTOFMEMORY environment variables. JAVA_DUMP_OPTS environment variable. Remaining -Xdump command-line options. Setting JAVA_DUMP_OPTS affects only those conditions that you specify. Actions on other conditions are unchanged.","title":"Dump agent options"},{"location":"env_var/#signal-mapping","text":"When setting the JAVA_DUMP_OPTS environment variable, the mapping of operating system signals to the \"condition\" is shown in the following table: Condition z/OS Windows Linux, macOS, and AIX EXCEPTION SIGTRAP, SIGILL, SIGSEGV, SIGFPE, SIGBUS, SIGSYS, SIGXFSV SIGILL, SIGSEGV, SIGFPE SIGTRAP, SIGILL, SIGSEGV, SIGFPE, SIGBUS, SIGXFSV INTERRUPT SIGINT, SIGTERM, SIGHUP SIGINT, SIGTERM SIGINT, SIGTERM, SIGHUP ERROR SIGABRT SIGABRT SIGABRT DUMP SIGQUIT SIGBREAK SIGQUIT","title":"Signal mapping"},{"location":"env_var/#java-dump-options","text":"The preferred mechanism for controlling the production of Java dumps is by using the -Xdump:java option. However, these legacy environment variables are preserved and can still be used. Environment Variable Usage Information DISABLE_JAVADUMP=[TRUE|FALSE] Setting DISABLE_JAVADUMP to TRUE is the equivalent of using -Xdump:java:none and stops the default production of Java dumps. IBM_JAVACOREDIR=<directory> The default location into which the Java dump is written. On z/OS, the _CEE_DMPTARG environment variable is used instead. IBM_JAVADUMP_OUTOFMEMORY=[TRUE|FALSE] By setting this environment variable to FALSE , you disable Java dumps for an out-of-memory exception. When not set, a Java dump is generated when an out-of-memory exception is thrown but not caught and handled by the application. Set to TRUE to generate a dump when an out-of-memory exception is thrown, even if it is handled by the application. Set to FALSE to disable Java dumps for an out-of-memory exception. TMPDIR=<directory> This variable specifies an alternative temporary directory. This directory is used only when Java dumps and Heap dumps cannot be written to their target directories, or the current working directory. The default is /tmp ( C:\\temp for Windows). Note: You can use the dump agent JAVA_DUMP_OPTS variable to control the conditions under which Java dumps are produced.","title":"Java dump options"},{"location":"env_var/#heap-dump-options","text":"The preferred mechanism for controlling the production of Java dumps is by using the -Xdump:heap option. However, these legacy environment variables are preserved and can still be used. Environment Variable Usage Information IBM_HEAPDUMP=[TRUE|FALSE] Setting this option to TRUE enables heap dump production by using signals. IBM_HEAP_DUMP=[TRUE|FALSE] Setting this option to TRUE enables heap dump production by using signals. IBM_HEAPDUMPDIR=<directory> The default location into which the heap dump is written. On z/OS, the _CEE_DMPTARG environment variable is used instead. IBM_HEAPDUMP_OUTOFMEMORY=[TRUE|FALSE] Controls the generation of a heap dump when an out-of-memory exception is thrown. When not set, a heap dump is generated when an out-of-memory exception is thrown but not caught and handled by the application. Set to TRUE to generate a dump when an out-of-memory exception is thrown, even if it is handled by the application. Set to FALSE to disable heap dump for an out-of-memory exception. IBM_JAVA_HEAPDUMP_TEST Use this environment variable to cause the VM to generate both PHD and text versions of heap dumps. Equivalent to opts=PHD+CLASSIC on the -Xdump:heap option. IBM_JAVA_HEAPDUMP_TEXT Use this environment variable to cause the VM to generate a text (human readable) Heap dump. Equivalent to opts=CLASSIC on the -Xdump:heap option. TMPDIR=<directory> This variable specifies an alternative temporary directory. This directory is used only when Java dumps and heap dumps cannot be written to their target directories, or the current working directory. The default is /tmp ( C:\\temp for Windows). Note: You can use the dump agent JAVA_DUMP_OPTS variable to control the conditions under which Heap dumps are produced.","title":"Heap dump options"},{"location":"env_var/#other-diagnostic-options","text":"The following table lists other environment variables that can be set for diagnostic purposes: Environment variable Usage Instructions IBM_COREDIR=<directory> Set this variable to specify an alternative location for system dumps, JIT dumps, and snap trace. On z/OS, _CEE_DMPTARG is used instead for snap trace, and transaction dumps are written to TSO according to JAVA_DUMP_TDUMP_PATTERN . On Linux and macOS, the dump is written to the directory that is specified directory by the operating system before being moved to the specified location. IBM_JAVA_ABEND_ON_FAILURE=Y (z/OS only) This setting tells the Java launcher to mark the Task Control Block (TCB) with an abend code if the OpenJ9 VM fails to load or is terminated by an uncaught exception. By default, the Java launcher does not mark the TCB. JAVA_DUMP_TDUMP_PATTERN=<string> (z/OS only) The specified <string> is passed to IEATDUMP to use as the data/set name for the Transaction Dump. The default <string> is %uid.JVM.TDUMP.%job.D%y%m%d.T%H%M%S (31-bit) or %uid.JVM.%job.D%y%m%d.T%H%M%S.X&amp;DS (64-bit), where %uid is found from the C code fragment shown in Notes . JAVA_THREAD_MODEL=<string> <string> can be defined as one of the following values: NATIVE (all threads are created as _MEDIUM_WEIGHT ), HEAVY (all threads are created as _HEAVY_WEIGHT ), MEDIUM (same as NATIVE ), or NULL . The default is NATIVE . IBM_XE_COE_NAME=<value> Set this variable to generate a system dump when the specified exception occurs. The value that is supplied is the package description of the exception; for example, java/lang/InternalError . A Signal 11 is followed by a JVMXE message and then the VM ends. JAVA_PLUGIN_TRACE=TRUE When this variable is set to TRUE or 1, a Java plug-in trace is produced for the session when an application runs. Traces are produced from both the Java and Native layer. By default, this variable is set to FALSE , so that a Java plug-in trace is not produced. Notes: C code fragment to discover %uid for JAVA_DUMP_TDUMP_PATTERN=<string> : pwd = getpwuid(getuid()); pwd->pw_name;","title":"Other diagnostic options"},{"location":"env_var/#deprecated-jit-options","text":"The following table describes deprecated environment variables for the JIT compiler: Environment Variable Usage Information IBM_MIXED_MODE_THRESHOLD Use -Xjit:count=<value> instead of this variable. JAVA_COMPILER Use -Djava.compiler=<value> instead of this variable.","title":"Deprecated JIT options"},{"location":"gc/","text":"Garbage collection policies OpenJ9 provides several garbage collection (GC) policies that are designed around different application workloads and service level agreements. Each GC policy consists of a set of characteristics and features that aim to optimize one or more performance aspects of a running application. These performance aspects include application throughput, memory footprint, average pause times, worst-case pause times, and startup time. Different policies require a Java heap that is configured in different ways in order to achieve different goals. The simplest configuration consists of a single area of memory, often referred to as a flat heap. Other configurations divide the heap into different areas or regions, which might contain objects of different ages ( generations ) or sizes. A GC cycle is a repeatable process that involves a set of GC operations. These operations process all or parts of the Java heap to complete a discrete function and are discussed in more detail in GC operations . GC policies use different GC cycles to manage different aspects of the heap. For example, the gencon policy runs a partial GC cycle on the nursery area of the heap to complete a scavenge operation. At other times, gencon also runs a global GC cycle on the entire Java heap to complete mark and sweep (and optionally compact ) operations. GC cycles might be divided into increments that run over a period of time to reduce maximum pause times. These increments might involve stop-the-world (STW) pauses that must halt application threads to give certain GC operations exclusive access to the Java heap. Alternatively, increments might include GC operations that can run concurrently with application processing. The following table shows the heap configuration and the GC cycles and operations used by different policies: Policy Heap configuration GC cycles / operations gencon Two areas: nursery and tenure Two generation groups: new/older Global GC cycle: concurrent mark-sweep operations, optionally followed by a compact operation Partial GC cycle: STW scavenge operation or concurrent scavenge operation (if optionally enabled) balanced Multiple regions of equal size Multiple generations Global GC mark cycle: incremental concurrent mark operation ( global mark phase ) Partial GC cycle: STW copy forward operation and optional mark, sweep, or compact operations optavgpause One area: flat One generation Global GC cycle: concurrent mark-sweep operations, optionally followed by a compact operation optthruput One area: flat One generation Global GC cycle: STW mark-sweep operations, optionally followed by a compact operation metronome Multiple regions by size class One generation Global GC cycle: incremental STW mark-sweep operation in small interruptible steps nogc One area: flat No GC cycles Note: All OpenJ9 GC policies support compressed references on 64-bit platforms, which compresses heap pointers to 32 bits if the total heap size does not exceed the theoretical upper bound of 64 GB. Applications that require more heap space can select any heap size within the bounds imposed by the operating system and available system RAM, without using compressed references. For more information, see compressed references . Policy selection and tuning The default policy is the Generational Concurrent ( gencon ) GC policy, which suits a broad spectrum of applications. Choosing a different GC policy should be guided by the application dynamics and an observation of how the application interacts with the heap during startup and at steady state. To help with this analysis, all OpenJ9 GC policies are instrumented to collect a wide range of GC-related metric data for reporting in a GC log file . To enable GC logging for the OpenJ9 Java runtime, include the -verbose:gc option on the command line. By default, this option prints output to stderr but you can send the output to a log file by using -Xverbosegclog . You can then visualize the output by loading the GC log into the Garbage Collector and Memory Visualizer (GCMV) plugin for the Eclipse IDE. OpenJ9 Java GC logs can also be analyzed by some online services, such as GCEasy . The following sections provide more information about each policy and when you might choose it for your application. To select a GC policy other than gencon , specify the -Xgcpolicy option on the command line. To adjust the initial and maximum size of the Java heap, use the -Xms and -Xmx command line options. For generational GC policies, you can also set the -Xmn , -Xmns , and -Xmnx options. gencon policy (default) The Generational Concurrent GC policy ( -Xgcpolicy:gencon ) is probably best suited if you have a transactional application, with many short-lived objects. This policy aims to minimize GC pause times without compromising throughput. This is the default policy employed by the VM, so if you want to use it you don't need to specify it on the command line when you start your application. If your application requires the allocation of objects of very different sizes and liveness on the Java heap, you might experience heap fragmentation, which in turn might lead to global heap compaction. In these circumstances, the Balanced GC policy might be more appropriate. GC processing With the gencon policy, the Java heap is divided into two main areas, the nursery area, where new objects are created and the tenure area, where objects are moved if they have reached tenure age . The nursery area is subdivided into two further areas, the allocate space and the survivor space. A partial GC cycle that involves a GC scavenge operation is used to reclaim memory from the nursery area. This process is illustrated in the following diagram, which shows a sequence of four main events: Objects are created in the allocate space. The allocate space is full. A local GC scavenge process runs and reachable objects are either evacuated (copied) into the survivor space or into the tenure area if they have reached tenure age. Any objects that can't be reached are left untouched and subsequently cleared. The allocate and survivor spaces swap roles. The original survivor space becomes the allocate space where new objects are created, and the original allocate space becomes the survivor space ready for the next local GC scavenge process. The relative sizes of the allocate and survivor spaces are dynamically adjusted by a technique called tilting . When the nursery area is first created, it is evenly divided between the allocate and survivor spaces. If, after a GC scavenge operation runs, the amount of space required for the survivor area is comparatively small, the boundary between the two spaces is adjusted by tilting. For example, if the survivor space requires only 10% of the nursery area, the tilt ratio is adjusted to give 90% of the nursery area to the allocate space. With more space available for new objects, the frequency of scavenge cycles is reduced. The tenure age of an object is determined by the VM and reflects the number of times that an object has been copied between the allocate space and the survivor space. The age is in the range 1 - 14 and is adjusted dynamically by the VM depending on the object survival rate at particular ages. For example, if an object has a tenure age of 5 , it has been copied backwards and forwards between allocate and survivor spaces five times. If the VM sets a tenure age of 5 based on the percentage of space remaining in the nursery area, the next scavenge moves the object from the nursery to the tenure area. You can set an initial tenure age with the -Xgc:scvTenureAge option. You can also prevent the VM dynamically adjusting the tenure age by setting the Xgc:scvNoAdaptiveTenure option so that the initial age is maintained throughout the run time of the VM. Within the tenure area, new objects are allocated into the small object area (SOA), which is illustrated in the earlier diagram (see item 3). A large object area (LOA) is set aside for objects greater than 64 KB that cannot be allocated into the SOA to minimize fragmentation. The LOA is allocated by default but is reduced and removed after a few GC cycles if it isn't populated. To prevent the creation of an LOA, you can specify the -Xnoloa option on the command line when you start your application. When the tenure area is close to full a global GC cycle is triggered. The partial GC cycle (scavenge) reduces pause times by frequently reclaiming memory in the nursery area which, for a transactional application with many short-lived objects, has the most recyclable space. While most of the objects stay in the nursery area after the scavenge operation is complete, a small fraction are moved to the tenure area. Over time the tenure area might become full. So, whilst a partial GC cycle is operating on the nursery area, a concurrent global GC cycle also runs alongside normal program execution to mark and remove unreachable objects from the tenure area. These two GC approaches combine to provide a good trade-off between shorter pause times and consistent throughput. Concurrent Scavenge A special mode of the gencon policy is known as Concurrent Scavenge . This mode aims to further reduce the average time spent in STW pauses by collecting garbage from the nursery area in parallel with running application threads. Whilst aiming to reduce the average time, this mode does not improve the worst case pause time when compared to running gencon without Concurrent Scavenge enabled. To enable Concurrent Scavenge, see -Xgc:concurrentScavenge . This mode can be enabled with hardware-based support and software-based support: Hardware-based support: (Linux on IBM Z\u00ae and z/OS\u00ae) This mode works on the IBM z14\u2122 and later mainframe system with the Guarded Storage (GS) Facility. The GS Facility provides hardware-based support to detect when potentially stale references to objects are accessed by an application. This means that the garbage collector can start processing objects in parts of the heap without halting an application because the GS Facility is on hand to spot accesses to an object and send a notification. The object that was ready to be swept away can be moved, and references to it can be reset. Software-based support: (64-bit: Linux on (x86-64, POWER, IBM Z\u00ae), AIX\u00ae, macOS\u00ae, and z/OS\u00ae) With software-based support, Concurrent Scavenge can be enabled without any pre-requisite hardware although the performance throughput is not as good as hardware-based support. More information about Concurrent Scavenge mode can be found in the blog post Concurrent Scavenge Garbage Collection Policy . balanced policy (64-bit only) The Balanced GC policy ( -Xgcpolicy:balanced ) evens out pause times and reduces the overhead of some of the costlier operations that are typically associated with garbage collection, such as compaction and class unloading. The Java heap is divided into a large number of regions (1,000 - 2,000), which are managed individually by an incremental generational collector to reduce the maximum pause time on large heaps and increase the efficiency of garbage collection. The aim of the policy is to avoid global garbage collections by matching object allocation and survival rates. When to use The Balanced policy suits applications that require large heaps (>64 MB) on 64-bit platforms. This policy might be a good alternative for applications that experience unacceptable pause times with gencon . If you have problems with application pause times that are caused by global garbage collections, particularly compactions, this policy might improve application performance. If you are using large systems that have Non-Uniform Memory Architecture (NUMA) characteristics (x86 and POWER\u2122 platforms only), the Balanced policy might further improve application throughput. However, even though pause times are typically evened out across GC operations, actual pause times are affected by object allocation rates, object survival rates, and fragmentation levels within the heap, and cannot therefore be bound to a certain maximum nor can a certain utilization level be guaranteed. GC processing During VM startup, the GC divides the heap memory into regions of equal size. These regions remain static for the lifetime of the VM and are the basic unit of garbage collection and allocation operations. For example, when the heap is expanded or contracted, the memory committed or released corresponds to a certain number of regions. Although the Java heap is a contiguous range of memory addresses, any region within that range can be committed or released from a pool as required. This enables the Balanced GC to contract the heap more dynamically and aggressively than other garbage collectors, which typically require the committed portion of the heap to be contiguous. Regions impose a maximum object size. Objects are always allocated within the bounds of a single region and are never permitted to span regions. The region size is always a power of two; for example, 512 KB, 1 MB, and so on (where KB is 2 10 bytes and MB is 2 20 bytes). The region size is selected at startup based on the maximum heap size. The collector chooses the smallest power of two which will result in less than 2048 regions, with a minimum region size of 512 KB. Except for small heaps (less than about 512 MB) the VM aims to have between 1024 and 2047 regions. Object ages are tracked for each region with a maximum of 24 possible generations. The following diagram illustrates the structure of the object heap: The eden space is a set of regions of age 0, which contain the newest objects allocated. The size of the eden space is determined by the number of regions that it contains. When the region count for the eden space reaches a predetermined threshold ( taxation threshold), a partial GC cycle runs to reduce the number of used regions, typically by using a copy forward operation. Empty regions can then be assigned to the eden space from the pool. In specific cases, mark and compact operations might be used, for example, when there are not enough free survivor regions available. The partial GC cycle is a STW operation that always includes the eden space, but might include older regions. Objects from collectible regions of age N are moved into another region of the same age N or to an empty region that is assigned an age of N. Then, the ages of all regions across the heap are incremented by 1, except for the maximum age 24 regions. Regions of age 24 are included in partial GC collection sets in order to defragment them. Partial GC cycles work to reclaim free regions in the heap for allocating new objects. Because some objects from eden regions always survive, a partial GC cycle can reclaim only about 90% of this memory. To keep up with object allocation, partial GC cycles also reclaim free regions by defragmenting older regions. For example, a partial GC cycle that moves objects from 5 fragmented older regions into 2 empty regions, reclaims 3 regions for new object allocation. However, over time the overall amount of fragmented memory decreases and records about object liveness in older regions become less accurate. Eventually, the work done by partial GC cycles to reclaim memory cannot keep pace with memory consumption. Free regions become so scarce that a global mark operation (GMP), which is triggered by another taxation threshold, is required to build a new record of object liveness across the heap. A sweep operation uses this record to measure the amount of free memory in fragmented older regions, which later partial GC cycles can act upon to move objects and reclaim free regions. A global sweep operation also runs to reclaim memory so that it can create empty regions. The global sweep operation, while logically associated with the global mark operation, runs in the same STW increment as the first partial GC cycle after the mark operation completes. Because the GC cycle responsible for the global mark operation runs concurrently, it might overlap and interleave with a few partial GC cycles. With the balanced policy, a global GC cycle is sometimes required in addition to the global mark operations and partial GC cycle. This global GC cycle is rare, occurring only in very tight memory conditions when other GC cycles cannot free enough memory on the heap. Most objects are easily contained within the minimum region size of 512 KB. However, to support large arrays, which cannot be contained in a region, the balanced GC policy uses an arraylet representation in the heap. For more information about structure and layout, see Arraylets . Note: With arraylets, JNI access to array data might involve reconstituting arraylets as contiguous arrays, which can significantly slow down processing. To learn about the default heap size and the tuning options that can be used with the balanced policy, see -Xgcpolicy:balanced . optavgpause policy The optimize for pause time policy ( -Xgcpolicy:optavgpause ) uses a global GC to manage a flat heap comprised of a single area and to compact the heap if the heap becomes fragmented. The global GC cycle starts preemptively so that the cycle finishes before the heap is exhausted. By anticipating global collections and initiating some mark operations ahead of collection, the optavgpause policy reduces GC pause times when compared to optthruput . However, the reduction in pause time comes at the expense of some performance throughput. When to use Consider using this policy if you have a large heap size (available on 64-bit platforms), because this policy limits the effect of increasing heap size on the length of the GC pause. Although optavgpause uses a write barrier to support concurrent mark operations, it does not use a generational write barrier. For some application workloads, such as those that frequently change large and old reference arrays, this strategy might be of greater benefit. However, in many situations, the default gencon policy offers better performance. By using a flat heap, optavgpause avoids potential issues with very large objects. With gencon , the heap is divided into areas (nursery and tenure) in order to manage generations of objects. Although there might be sufficient free space on the overall Java heap for a very large object, it might not fit into the nursery area. If the allocator does succeed in allocating a very large object, further GC cycles might be required to create enough contiguous free space. Overall, optavgpause , along with optthruput , is best suited to short-lived applications and to long-running services that involve concurrent sessions with short lifespans. Short-lived applications with adequate heap sizes usually complete without compaction. The flat heap fragments more slowly when session-bound objects are allocated and drop out of the live set in short overlapping clusters. GC processing The optavgpause policy requires a flat Java heap. A global GC cycle runs concurrent mark-sweep operations, optionally followed by compact operations. By running most operations concurrently with application threads, this strategy aims to reduce GC pause times as much as possible. optthruput policy The optimize for throughput policy ( -Xgcpolicy:optthruput ) uses a global GC cycle to manage a flat heap that is comprised of a single area and to compact the heap if the heap becomes fragmented. The global collector runs mark and sweep operations that are triggered by an allocation failure when the heap is exhausted. As a result, applications stop for long pauses while garbage collection takes place. When to use You might consider using this policy when a large heap application can tolerate longer GC pauses to obtain better overall throughput. Unlike gencon , the optthruput policy does not use object access barriers. In some workloads, the cost of these barriers might be high enough to make optthruput preferable. However, in many situations, the default gencon policy offers better performance. By using a flat heap, optthruput avoids potential issues with very large objects. With gencon , the heap is divided into areas (nursery and tenure) in order to manage generations of objects. Although there might be sufficient free space on the overall Java heap for a very large object, it might not fit into the nursery area. If the allocator does succeed in allocating a very large object, further GC cycles might be required to create enough contiguous free space. Overall, optthruput , along with optavgpause , is best suited to short-lived applications and to long-running services that involve concurrent sessions with short lifespans. Short-lived applications with adequate heap sizes usually complete without compaction. The flat heap fragments more slowly when session-bound objects are allocated and drop out of the live set in short overlapping clusters. GC processing The optthruput policy requires a flat Java heap. A global GC cycle runs mark-sweep operations, optionally followed by compact operations. The cycle requires exclusive access to the heap, causing application threads to halt while operations take place. As such, long pauses can occur. metronome policy (Linux on x86-64 and AIX platforms only) The metronome policy ( -Xgcpolicy:metronome ) is an incremental, deterministic garbage collector with short pause times. Applications that are dependent on precise response times can take advantage of this technology by avoiding potentially long delays from GC activity. When to use metronome is designed for applications that require a precise upper bound on collection pause times as well as specified application utilization: the proportion of time that the application is permitted to use, with the remainder being devoted to GC. The metronome GC runs in short interruptible bursts to avoid long STW pauses. GC processing The Java heap is allocated as a contiguous range of memory, partitioned into small regions of equal size (~64 KB). The metronome policy does not dynamically resize the heap; the heap is always fully expanded, even if -Xms is not set to -Xmx . Each region of the heap is either empty, or contains only objects in one of 16 size classes. The heap also supports Arraylets for dealing with large arrays. This organization improves the use of available heap space, reducing the need for heap compaction and defragmentation, and providing more precise control over the incremental sweep operation. Note: With arraylets, JNI access to array data might involve reconstituting arraylets as contiguous arrays, which can significantly slow down processing. Although high application utilization is desirable for optimal throughput, the GC must be able to keep up with the application's memory allocation rate. A higher utilization typically requires a larger heap because the GC isn't allowed to run as much as a lower utilization would permit. The relationship between utilization and heap size is highly application dependent, and striking an appropriate balance requires iterative experimentation with the application and VM parameters. You might need to adjust heap size or pause time or target utilization to achieve an acceptable runtime configuration. To learn about default options and tuning options that can be used with the metronome policy, see -Xgcpolicy:metronome . nogc policy -Xgcpolicy:nogc handles only memory allocation and heap expansion, but doesn't reclaim any memory. The GC impact on runtime performance is therefore minimized, but if the available Java heap becomes exhausted, an OutOfMemoryError exception is triggered and the VM stops. When to use This policy is not suited to the majority of Java applications. However, the following use cases apply: Testing during development GC performance: Use nogc as a baseline when testing the performance of other GC policies, including the provision of a low-latency baseline. Application memory: Use nogc to test your settings for allocated memory. If you use -Xmx to set the heap size that should not be exceeded, your application terminates with a heap dump if it tries to exceed your memory limit. Running applications with minimal or no GC requirements You might use nogc when an application is so short-lived that allocated memory is never exhausted and running a full GC cycle is therefore a waste of resources. Similarly, when memory application is well understood or where there is rarely memory to be reclaimed, you might prefer to avoid unnecessary GC cycles and rely on a failover mechanism to occasionally restart the VM. Note: You should be especially careful when using any of the following techniques with nogc because memory is never released under this policy: Finalization Direct memory access Weak, soft, and phantom references Troubleshooting You can diagnose problems with garbage collection operations by turning on verbose GC logging. By default, the information is printed to STDERR but can be redirected to a file by specifying the -Xverbosegclog option. The log files contain detailed information about all operations, including initialization, STW processing, finalization, reference processing, and allocation failures. For more information, see Verbose GC logs . If verbose logs do not provide enough information to help you diagnose GC problems, you can use GC trace to analyze operations at a more granular level. For more information, see -Xtgc .","title":"GC policies"},{"location":"gc/#garbage-collection-policies","text":"OpenJ9 provides several garbage collection (GC) policies that are designed around different application workloads and service level agreements. Each GC policy consists of a set of characteristics and features that aim to optimize one or more performance aspects of a running application. These performance aspects include application throughput, memory footprint, average pause times, worst-case pause times, and startup time. Different policies require a Java heap that is configured in different ways in order to achieve different goals. The simplest configuration consists of a single area of memory, often referred to as a flat heap. Other configurations divide the heap into different areas or regions, which might contain objects of different ages ( generations ) or sizes. A GC cycle is a repeatable process that involves a set of GC operations. These operations process all or parts of the Java heap to complete a discrete function and are discussed in more detail in GC operations . GC policies use different GC cycles to manage different aspects of the heap. For example, the gencon policy runs a partial GC cycle on the nursery area of the heap to complete a scavenge operation. At other times, gencon also runs a global GC cycle on the entire Java heap to complete mark and sweep (and optionally compact ) operations. GC cycles might be divided into increments that run over a period of time to reduce maximum pause times. These increments might involve stop-the-world (STW) pauses that must halt application threads to give certain GC operations exclusive access to the Java heap. Alternatively, increments might include GC operations that can run concurrently with application processing. The following table shows the heap configuration and the GC cycles and operations used by different policies: Policy Heap configuration GC cycles / operations gencon Two areas: nursery and tenure Two generation groups: new/older Global GC cycle: concurrent mark-sweep operations, optionally followed by a compact operation Partial GC cycle: STW scavenge operation or concurrent scavenge operation (if optionally enabled) balanced Multiple regions of equal size Multiple generations Global GC mark cycle: incremental concurrent mark operation ( global mark phase ) Partial GC cycle: STW copy forward operation and optional mark, sweep, or compact operations optavgpause One area: flat One generation Global GC cycle: concurrent mark-sweep operations, optionally followed by a compact operation optthruput One area: flat One generation Global GC cycle: STW mark-sweep operations, optionally followed by a compact operation metronome Multiple regions by size class One generation Global GC cycle: incremental STW mark-sweep operation in small interruptible steps nogc One area: flat No GC cycles Note: All OpenJ9 GC policies support compressed references on 64-bit platforms, which compresses heap pointers to 32 bits if the total heap size does not exceed the theoretical upper bound of 64 GB. Applications that require more heap space can select any heap size within the bounds imposed by the operating system and available system RAM, without using compressed references. For more information, see compressed references .","title":"Garbage collection policies"},{"location":"gc/#policy-selection-and-tuning","text":"The default policy is the Generational Concurrent ( gencon ) GC policy, which suits a broad spectrum of applications. Choosing a different GC policy should be guided by the application dynamics and an observation of how the application interacts with the heap during startup and at steady state. To help with this analysis, all OpenJ9 GC policies are instrumented to collect a wide range of GC-related metric data for reporting in a GC log file . To enable GC logging for the OpenJ9 Java runtime, include the -verbose:gc option on the command line. By default, this option prints output to stderr but you can send the output to a log file by using -Xverbosegclog . You can then visualize the output by loading the GC log into the Garbage Collector and Memory Visualizer (GCMV) plugin for the Eclipse IDE. OpenJ9 Java GC logs can also be analyzed by some online services, such as GCEasy . The following sections provide more information about each policy and when you might choose it for your application. To select a GC policy other than gencon , specify the -Xgcpolicy option on the command line. To adjust the initial and maximum size of the Java heap, use the -Xms and -Xmx command line options. For generational GC policies, you can also set the -Xmn , -Xmns , and -Xmnx options.","title":"Policy selection and tuning"},{"location":"gc/#gencon-policy-default","text":"The Generational Concurrent GC policy ( -Xgcpolicy:gencon ) is probably best suited if you have a transactional application, with many short-lived objects. This policy aims to minimize GC pause times without compromising throughput. This is the default policy employed by the VM, so if you want to use it you don't need to specify it on the command line when you start your application. If your application requires the allocation of objects of very different sizes and liveness on the Java heap, you might experience heap fragmentation, which in turn might lead to global heap compaction. In these circumstances, the Balanced GC policy might be more appropriate.","title":"gencon policy (default)"},{"location":"gc/#gc-processing","text":"With the gencon policy, the Java heap is divided into two main areas, the nursery area, where new objects are created and the tenure area, where objects are moved if they have reached tenure age . The nursery area is subdivided into two further areas, the allocate space and the survivor space. A partial GC cycle that involves a GC scavenge operation is used to reclaim memory from the nursery area. This process is illustrated in the following diagram, which shows a sequence of four main events: Objects are created in the allocate space. The allocate space is full. A local GC scavenge process runs and reachable objects are either evacuated (copied) into the survivor space or into the tenure area if they have reached tenure age. Any objects that can't be reached are left untouched and subsequently cleared. The allocate and survivor spaces swap roles. The original survivor space becomes the allocate space where new objects are created, and the original allocate space becomes the survivor space ready for the next local GC scavenge process. The relative sizes of the allocate and survivor spaces are dynamically adjusted by a technique called tilting . When the nursery area is first created, it is evenly divided between the allocate and survivor spaces. If, after a GC scavenge operation runs, the amount of space required for the survivor area is comparatively small, the boundary between the two spaces is adjusted by tilting. For example, if the survivor space requires only 10% of the nursery area, the tilt ratio is adjusted to give 90% of the nursery area to the allocate space. With more space available for new objects, the frequency of scavenge cycles is reduced. The tenure age of an object is determined by the VM and reflects the number of times that an object has been copied between the allocate space and the survivor space. The age is in the range 1 - 14 and is adjusted dynamically by the VM depending on the object survival rate at particular ages. For example, if an object has a tenure age of 5 , it has been copied backwards and forwards between allocate and survivor spaces five times. If the VM sets a tenure age of 5 based on the percentage of space remaining in the nursery area, the next scavenge moves the object from the nursery to the tenure area. You can set an initial tenure age with the -Xgc:scvTenureAge option. You can also prevent the VM dynamically adjusting the tenure age by setting the Xgc:scvNoAdaptiveTenure option so that the initial age is maintained throughout the run time of the VM. Within the tenure area, new objects are allocated into the small object area (SOA), which is illustrated in the earlier diagram (see item 3). A large object area (LOA) is set aside for objects greater than 64 KB that cannot be allocated into the SOA to minimize fragmentation. The LOA is allocated by default but is reduced and removed after a few GC cycles if it isn't populated. To prevent the creation of an LOA, you can specify the -Xnoloa option on the command line when you start your application. When the tenure area is close to full a global GC cycle is triggered. The partial GC cycle (scavenge) reduces pause times by frequently reclaiming memory in the nursery area which, for a transactional application with many short-lived objects, has the most recyclable space. While most of the objects stay in the nursery area after the scavenge operation is complete, a small fraction are moved to the tenure area. Over time the tenure area might become full. So, whilst a partial GC cycle is operating on the nursery area, a concurrent global GC cycle also runs alongside normal program execution to mark and remove unreachable objects from the tenure area. These two GC approaches combine to provide a good trade-off between shorter pause times and consistent throughput.","title":"GC processing"},{"location":"gc/#concurrent-scavenge","text":"A special mode of the gencon policy is known as Concurrent Scavenge . This mode aims to further reduce the average time spent in STW pauses by collecting garbage from the nursery area in parallel with running application threads. Whilst aiming to reduce the average time, this mode does not improve the worst case pause time when compared to running gencon without Concurrent Scavenge enabled. To enable Concurrent Scavenge, see -Xgc:concurrentScavenge . This mode can be enabled with hardware-based support and software-based support: Hardware-based support: (Linux on IBM Z\u00ae and z/OS\u00ae) This mode works on the IBM z14\u2122 and later mainframe system with the Guarded Storage (GS) Facility. The GS Facility provides hardware-based support to detect when potentially stale references to objects are accessed by an application. This means that the garbage collector can start processing objects in parts of the heap without halting an application because the GS Facility is on hand to spot accesses to an object and send a notification. The object that was ready to be swept away can be moved, and references to it can be reset. Software-based support: (64-bit: Linux on (x86-64, POWER, IBM Z\u00ae), AIX\u00ae, macOS\u00ae, and z/OS\u00ae) With software-based support, Concurrent Scavenge can be enabled without any pre-requisite hardware although the performance throughput is not as good as hardware-based support. More information about Concurrent Scavenge mode can be found in the blog post Concurrent Scavenge Garbage Collection Policy .","title":"Concurrent Scavenge"},{"location":"gc/#balanced-policy","text":"(64-bit only) The Balanced GC policy ( -Xgcpolicy:balanced ) evens out pause times and reduces the overhead of some of the costlier operations that are typically associated with garbage collection, such as compaction and class unloading. The Java heap is divided into a large number of regions (1,000 - 2,000), which are managed individually by an incremental generational collector to reduce the maximum pause time on large heaps and increase the efficiency of garbage collection. The aim of the policy is to avoid global garbage collections by matching object allocation and survival rates.","title":"balanced policy"},{"location":"gc/#when-to-use","text":"The Balanced policy suits applications that require large heaps (>64 MB) on 64-bit platforms. This policy might be a good alternative for applications that experience unacceptable pause times with gencon . If you have problems with application pause times that are caused by global garbage collections, particularly compactions, this policy might improve application performance. If you are using large systems that have Non-Uniform Memory Architecture (NUMA) characteristics (x86 and POWER\u2122 platforms only), the Balanced policy might further improve application throughput. However, even though pause times are typically evened out across GC operations, actual pause times are affected by object allocation rates, object survival rates, and fragmentation levels within the heap, and cannot therefore be bound to a certain maximum nor can a certain utilization level be guaranteed.","title":"When to use"},{"location":"gc/#gc-processing_1","text":"During VM startup, the GC divides the heap memory into regions of equal size. These regions remain static for the lifetime of the VM and are the basic unit of garbage collection and allocation operations. For example, when the heap is expanded or contracted, the memory committed or released corresponds to a certain number of regions. Although the Java heap is a contiguous range of memory addresses, any region within that range can be committed or released from a pool as required. This enables the Balanced GC to contract the heap more dynamically and aggressively than other garbage collectors, which typically require the committed portion of the heap to be contiguous. Regions impose a maximum object size. Objects are always allocated within the bounds of a single region and are never permitted to span regions. The region size is always a power of two; for example, 512 KB, 1 MB, and so on (where KB is 2 10 bytes and MB is 2 20 bytes). The region size is selected at startup based on the maximum heap size. The collector chooses the smallest power of two which will result in less than 2048 regions, with a minimum region size of 512 KB. Except for small heaps (less than about 512 MB) the VM aims to have between 1024 and 2047 regions. Object ages are tracked for each region with a maximum of 24 possible generations. The following diagram illustrates the structure of the object heap: The eden space is a set of regions of age 0, which contain the newest objects allocated. The size of the eden space is determined by the number of regions that it contains. When the region count for the eden space reaches a predetermined threshold ( taxation threshold), a partial GC cycle runs to reduce the number of used regions, typically by using a copy forward operation. Empty regions can then be assigned to the eden space from the pool. In specific cases, mark and compact operations might be used, for example, when there are not enough free survivor regions available. The partial GC cycle is a STW operation that always includes the eden space, but might include older regions. Objects from collectible regions of age N are moved into another region of the same age N or to an empty region that is assigned an age of N. Then, the ages of all regions across the heap are incremented by 1, except for the maximum age 24 regions. Regions of age 24 are included in partial GC collection sets in order to defragment them. Partial GC cycles work to reclaim free regions in the heap for allocating new objects. Because some objects from eden regions always survive, a partial GC cycle can reclaim only about 90% of this memory. To keep up with object allocation, partial GC cycles also reclaim free regions by defragmenting older regions. For example, a partial GC cycle that moves objects from 5 fragmented older regions into 2 empty regions, reclaims 3 regions for new object allocation. However, over time the overall amount of fragmented memory decreases and records about object liveness in older regions become less accurate. Eventually, the work done by partial GC cycles to reclaim memory cannot keep pace with memory consumption. Free regions become so scarce that a global mark operation (GMP), which is triggered by another taxation threshold, is required to build a new record of object liveness across the heap. A sweep operation uses this record to measure the amount of free memory in fragmented older regions, which later partial GC cycles can act upon to move objects and reclaim free regions. A global sweep operation also runs to reclaim memory so that it can create empty regions. The global sweep operation, while logically associated with the global mark operation, runs in the same STW increment as the first partial GC cycle after the mark operation completes. Because the GC cycle responsible for the global mark operation runs concurrently, it might overlap and interleave with a few partial GC cycles. With the balanced policy, a global GC cycle is sometimes required in addition to the global mark operations and partial GC cycle. This global GC cycle is rare, occurring only in very tight memory conditions when other GC cycles cannot free enough memory on the heap. Most objects are easily contained within the minimum region size of 512 KB. However, to support large arrays, which cannot be contained in a region, the balanced GC policy uses an arraylet representation in the heap. For more information about structure and layout, see Arraylets . Note: With arraylets, JNI access to array data might involve reconstituting arraylets as contiguous arrays, which can significantly slow down processing. To learn about the default heap size and the tuning options that can be used with the balanced policy, see -Xgcpolicy:balanced .","title":"GC processing"},{"location":"gc/#optavgpause-policy","text":"The optimize for pause time policy ( -Xgcpolicy:optavgpause ) uses a global GC to manage a flat heap comprised of a single area and to compact the heap if the heap becomes fragmented. The global GC cycle starts preemptively so that the cycle finishes before the heap is exhausted. By anticipating global collections and initiating some mark operations ahead of collection, the optavgpause policy reduces GC pause times when compared to optthruput . However, the reduction in pause time comes at the expense of some performance throughput.","title":"optavgpause policy"},{"location":"gc/#when-to-use_1","text":"Consider using this policy if you have a large heap size (available on 64-bit platforms), because this policy limits the effect of increasing heap size on the length of the GC pause. Although optavgpause uses a write barrier to support concurrent mark operations, it does not use a generational write barrier. For some application workloads, such as those that frequently change large and old reference arrays, this strategy might be of greater benefit. However, in many situations, the default gencon policy offers better performance. By using a flat heap, optavgpause avoids potential issues with very large objects. With gencon , the heap is divided into areas (nursery and tenure) in order to manage generations of objects. Although there might be sufficient free space on the overall Java heap for a very large object, it might not fit into the nursery area. If the allocator does succeed in allocating a very large object, further GC cycles might be required to create enough contiguous free space. Overall, optavgpause , along with optthruput , is best suited to short-lived applications and to long-running services that involve concurrent sessions with short lifespans. Short-lived applications with adequate heap sizes usually complete without compaction. The flat heap fragments more slowly when session-bound objects are allocated and drop out of the live set in short overlapping clusters.","title":"When to use"},{"location":"gc/#gc-processing_2","text":"The optavgpause policy requires a flat Java heap. A global GC cycle runs concurrent mark-sweep operations, optionally followed by compact operations. By running most operations concurrently with application threads, this strategy aims to reduce GC pause times as much as possible.","title":"GC processing"},{"location":"gc/#optthruput-policy","text":"The optimize for throughput policy ( -Xgcpolicy:optthruput ) uses a global GC cycle to manage a flat heap that is comprised of a single area and to compact the heap if the heap becomes fragmented. The global collector runs mark and sweep operations that are triggered by an allocation failure when the heap is exhausted. As a result, applications stop for long pauses while garbage collection takes place.","title":"optthruput policy"},{"location":"gc/#when-to-use_2","text":"You might consider using this policy when a large heap application can tolerate longer GC pauses to obtain better overall throughput. Unlike gencon , the optthruput policy does not use object access barriers. In some workloads, the cost of these barriers might be high enough to make optthruput preferable. However, in many situations, the default gencon policy offers better performance. By using a flat heap, optthruput avoids potential issues with very large objects. With gencon , the heap is divided into areas (nursery and tenure) in order to manage generations of objects. Although there might be sufficient free space on the overall Java heap for a very large object, it might not fit into the nursery area. If the allocator does succeed in allocating a very large object, further GC cycles might be required to create enough contiguous free space. Overall, optthruput , along with optavgpause , is best suited to short-lived applications and to long-running services that involve concurrent sessions with short lifespans. Short-lived applications with adequate heap sizes usually complete without compaction. The flat heap fragments more slowly when session-bound objects are allocated and drop out of the live set in short overlapping clusters.","title":"When to use"},{"location":"gc/#gc-processing_3","text":"The optthruput policy requires a flat Java heap. A global GC cycle runs mark-sweep operations, optionally followed by compact operations. The cycle requires exclusive access to the heap, causing application threads to halt while operations take place. As such, long pauses can occur.","title":"GC processing"},{"location":"gc/#metronome-policy","text":"(Linux on x86-64 and AIX platforms only) The metronome policy ( -Xgcpolicy:metronome ) is an incremental, deterministic garbage collector with short pause times. Applications that are dependent on precise response times can take advantage of this technology by avoiding potentially long delays from GC activity.","title":"metronome policy"},{"location":"gc/#when-to-use_3","text":"metronome is designed for applications that require a precise upper bound on collection pause times as well as specified application utilization: the proportion of time that the application is permitted to use, with the remainder being devoted to GC. The metronome GC runs in short interruptible bursts to avoid long STW pauses.","title":"When to use"},{"location":"gc/#gc-processing_4","text":"The Java heap is allocated as a contiguous range of memory, partitioned into small regions of equal size (~64 KB). The metronome policy does not dynamically resize the heap; the heap is always fully expanded, even if -Xms is not set to -Xmx . Each region of the heap is either empty, or contains only objects in one of 16 size classes. The heap also supports Arraylets for dealing with large arrays. This organization improves the use of available heap space, reducing the need for heap compaction and defragmentation, and providing more precise control over the incremental sweep operation. Note: With arraylets, JNI access to array data might involve reconstituting arraylets as contiguous arrays, which can significantly slow down processing. Although high application utilization is desirable for optimal throughput, the GC must be able to keep up with the application's memory allocation rate. A higher utilization typically requires a larger heap because the GC isn't allowed to run as much as a lower utilization would permit. The relationship between utilization and heap size is highly application dependent, and striking an appropriate balance requires iterative experimentation with the application and VM parameters. You might need to adjust heap size or pause time or target utilization to achieve an acceptable runtime configuration. To learn about default options and tuning options that can be used with the metronome policy, see -Xgcpolicy:metronome .","title":"GC processing"},{"location":"gc/#nogc-policy","text":"-Xgcpolicy:nogc handles only memory allocation and heap expansion, but doesn't reclaim any memory. The GC impact on runtime performance is therefore minimized, but if the available Java heap becomes exhausted, an OutOfMemoryError exception is triggered and the VM stops.","title":"nogc policy"},{"location":"gc/#when-to-use_4","text":"This policy is not suited to the majority of Java applications. However, the following use cases apply: Testing during development GC performance: Use nogc as a baseline when testing the performance of other GC policies, including the provision of a low-latency baseline. Application memory: Use nogc to test your settings for allocated memory. If you use -Xmx to set the heap size that should not be exceeded, your application terminates with a heap dump if it tries to exceed your memory limit. Running applications with minimal or no GC requirements You might use nogc when an application is so short-lived that allocated memory is never exhausted and running a full GC cycle is therefore a waste of resources. Similarly, when memory application is well understood or where there is rarely memory to be reclaimed, you might prefer to avoid unnecessary GC cycles and rely on a failover mechanism to occasionally restart the VM. Note: You should be especially careful when using any of the following techniques with nogc because memory is never released under this policy: Finalization Direct memory access Weak, soft, and phantom references","title":"When to use"},{"location":"gc/#troubleshooting","text":"You can diagnose problems with garbage collection operations by turning on verbose GC logging. By default, the information is printed to STDERR but can be redirected to a file by specifying the -Xverbosegclog option. The log files contain detailed information about all operations, including initialization, STW processing, finalization, reference processing, and allocation failures. For more information, see Verbose GC logs . If verbose logs do not provide enough information to help you diagnose GC problems, you can use GC trace to analyze operations at a more granular level. For more information, see -Xtgc .","title":"Troubleshooting"},{"location":"gc_overview/","text":"Garbage collection To prevent applications running out of memory, objects in the Java heap that are no longer required must be reclaimed. This process is known as garbage collection (GC). When garbage is collected, the garbage collector must obtain exclusive access to the heap, which causes an application to pause while the cleanup is done. This pause is often referred to as a stop-the-world (STW) pause because an application must halt until the process completes. In general, the first step in the GC process is to mark the objects that are reachable, which means they are still in use. The next step is to sweep away the unmarked objects to reclaim memory. The final step is to compact the heap if the heap is badly fragmented. A GC cycle is a repeatable process that involves a set of GC operations. These operations process all or parts of the Java heap. When operating on the whole of the Java heap, the cycle is referred to as a global GC cycle ; When operating on part of the heap, the cycle is referred to as a partial GC cycle . A global GC cycle can be triggered explicitly or implicitly according to the following rules: A global GC cycle is triggered implicitly if it occurs because of internal mechanisms, such as an allocation failure or a taxation threshold being reached. A global GC cycle is triggered explicitly if it is started directly by an application calling System.gc() or indirectly, for example when requesting a heap dump. Partial GC cycles are triggered only implicitly under the control of a particular GC policy. For more information about the GC policies available with OpenJ9, see Garbage collection policies . The GC process is designed to operate without intervention from an application. Developers should not attempt to predict GC behavior, for example, by making calls to System.gc() to trigger a cycle or by using finalizers to clean up objects in memory. Such actions might degrade the performance of an application. GC operations GC operations run discrete functions on the Java heap. For example, a mark operation traces all objects in the heap to determine which ones are reachable. A sweep operation runs to clear away unreachable objects. Together, a mark and sweep operation are capable of reclaiming used memory as part of a GC cycle. Not all GC cycles include operations to reclaim memory. For example, the balanced GC policy involves a global cycle that includes only a mark operation; reclaiming the memory with a sweep operation occurs as part of a separate partial GC cycle that evacuates younger regions and defragments older regions. A GC operation might complete in one step, or it might involve multiple steps. For example, a mark operation consists of three steps, as described in the following section. GC mark operation A mark operation identifies which objects on the Java heap are reachable from outside of the heap and which objects are unreachable. Reachable objects are in use and must be retained, whereas unreachable objects are not in use and can be cleared away as garbage. The process of marking involves a bit array called a mark map that is allocated by the VM at startup, based on the maximum heap size setting. Each bit in the mark map corresponds to 8 bytes of heap space. When an object is marked , its location in the heap is recorded by setting the appropriate bit in the mark map. A mark operation can be broken down into the following steps: Initial A root object is an object that is accessible from outside of the heap such as a stack, class static field, or JNI reference. For other objects in the heap to be reachable, they must retain a connection from a root object. In the initial step, tracing identifies all root objects by running a root scan. Root objects are pushed onto a work stack for processing in the next step. Main The list of reachable root objects in the work stack is recursively traced for references to other objects in the heap. Objects that are not marked are new objects and these are added to the work stack. If an object is reachable, the appropriate bit is set in the mark map. Final The final step processes weakly reachable roots such as finalizable objects, weak references, monitor sets, and string sets. For more information about the processing of soft , weak , and phantom references, see Weak reference processing . In general, helper threads are used in parallel to speed up mark operations on the heap. The helper threads share the work stack with the application thread and are involved in identifying root objects, tracing objects in the heap, and updating the mark map. By default, the number of helper threads is based on the number of CPUs reported by the operating system. You can control the number of helper threads available by specifying the -Xgcthreads command line option when starting your application. In a verbose GC log, this operation is shown by the <gc-op type=\"mark\"> XML element. For more information, see Verbose GC logs . Concurrent mark processing A mark operation can run with exclusive access to the heap, which requires application threads to pause while processing takes place. Alternatively, it can run concurrently with application threads to avoid pauses in application processing. With concurrent mark, the process of root scanning is handed over to application stack threads, which populate the work stack with root objects in their stack. The root objects in the work stack are then traced by a background thread and by each application thread during a heap lock allocation to find reachable objects and update the mark map. Because the mark operation runs concurrently with application threads, any changes to objects that are already traced must be updated. This process works by using a write barrier that can flag the update and trigger a further scan of part of the heap. To track updates to objects, concurrent mark operations use single-byte cards in a card table . Each card corresponds to a 512-byte section of the Java heap. When an object is updated, the start address for the object in the heap is marked on the appropriate card. These cards are used to determine what must be retraced later in the GC cycle. A GC cycle that includes concurrent mark operations aims to trace all reachable objects and complete processing at the same time as the heap is exhausted. Continuous adjustments are made to the start time of each cycle to get as close to heap exhaustion as possible. When the heap is exhausted a sweep operation is able to reclaim memory. This operation requires a STW pause. Before sweep operations start, the root objects are rescanned and the cards are checked to determine which areas of memory must be retraced. An advantage of concurrent mark operations over STW mark operations is reduced pause times, because the garbage collector is able to identify garbage without halting application threads. Pause times are also more consistent because the collector is able to tune start times to maximize heap usage. Disadvantages of concurrent mark operations include the additional CPU for operating the write barrier and additional work for application threads to trace objects when requesting a heap lock. Concurrent mark operations are used by the gencon GC policy and the optavgpause GC policy . Incremental concurrent mark processing Incremental concurrent mark processing evens out pause times by avoiding global STW garbage collections. This type of marking is also known as the global mark phase , whereby mark operations take place incrementally across the entire heap. The global mark operations are interleaved with a partial GC cycle that is responsible for moving objects and clearing unreachable objects in the heap. These operations also use mark map in a card table to manage updates to objects that occur whilst mark operations are in progress. However, unlike the concurrent mark operations used by other policies, application threads are not involved in tracing objects; only background threads are used to trace objects and update the mark map. Incremental concurrent mark operations are used by the balanced GC policy . GC sweep operation The purpose of a sweep operation is to identify memory that can be reclaimed for object allocation and update a central record, known as the freelist . sweep operations occur in 2 steps: Initial This step analyzes the mark map for free memory. Final Based on the analysis, the sections of the heap are connected to the freelist. As with mark operations, multiple helper threads can be used to sweep the Java heap in parallel to speed up processing times. Because these helper threads are the same ones that are used for parallel mark operations, the number of threads can be controlled by using the -Xgcthreads option. Parallel sweep operations run on 256 KB sections of the heap. Each helper thread scans a section at a time. The results are stored and used to generate a freelist of empty regions. In a verbose GC log, this operation is shown by the <gc-op type=\"sweep\"> XML element. For more information, see Verbose GC logs . Concurrent sweep processing Concurrent sweep processing works in tandem with concurrent mark processing and uses the same mark map. Concurrent sweep operations start after a STW collection and complete a section of the heap before concurrent mark operations continue. Concurrent sweep is used by the optavgpause GC policy. GC scavenge operation A GC scavenge operation is triggered by an allocation failure in the nursery area of the heap. The operation occurs in the following 3 steps: Initial A root object is an object that is accessible from outside of the heap such as a stack, class static field, or JNI reference. For other objects in the heap to be reachable, they must retain a connection from a root object. In the initial step, tracing identifies all root objects by running a root scan. Root objects are pushed onto a work stack for processing in the next step. Main The list of reachable root objects in the work stack is recursively traced for references to other objects in the heap by using the hierarchical scan ordering mode ( -Xgc:hierarchicalScanOrdering ). If new objects are found, they are added to the work stack. If an object is reachable, it is copied from the allocate space to the survivor space in the nursery area or to the tenure area if the object has reached a particular age. Final The final step processes weakly reachable roots such as finalizable objects, weak references, monitor sets, and string sets. For more information about the processing of soft, weak, and phantom references, see Weak reference processing . In a verbose GC log, this operation is shown by the <gc-op type=\"scavenge\"> XML element. For more information, see Verbose GC logs . The scavenge operation is used by the gencon GC policy . GC copy forward operation A GC copy forward operation is similar to a scavenge operation but is triggered by a taxation threshold being reached. The operation occurs in the following 3 steps: Initial A root object is an object that is accessible from outside of the heap such as a stack, class static field, or JNI reference. For other objects in the heap to be reachable, they must retain a connection from a root object. In the initial step, tracing identifies all root objects by running a root scan. Root objects are pushed onto a work stack for processing in the next step. Main The list of reachable root objects in the work stack is recursively traced for references to other objects in the heap by using dynamic breadth first scan ordering mode ( -Xgc:dynamicBreadthFirstScanOrdering ). If new objects are found, they are added to the work stack. If an object is reachable, it is moved to another region of the same age or to an empty region of the same age in the heap. The age of all regions in the heap is then incremented by 1, except for the oldest region (age 24). Final The final step processes weakly reachable roots such as finalizable objects, weak references, monitor sets, and string sets. For more information about the processing of soft, weak, and phantom references, see Weak reference processing . The operation aims to empty or evacuate fragmented regions that can then be reclaimed for new object allocation. In a verbose GC log, this operation is shown by the <gc-op type=\"copy forward\"> XML element. For more information, see Verbose GC logs . The copy forward operation is used by the balanced GC policy . GC classunloading operation The classunloading operation is single threaded, not parallel threaded. In a verbose GC log, this operation is shown by the <gc-op type=\"classunload\"> XML element. For more information, see Verbose GC logs . GC compact operation Compaction of the heap is an expensive operation because when objects are moved to defragment the heap, the references to each object change. Therefore, compact operations do not occur by default but only when the following triggers occur: The -Xcompactgc option is specified on the command line. After sweeping the heap, there is not enough free space available to satisfy an allocation request. A System.gc() is requested and the last allocation failure that triggered a global GC cycle did not compact or -Xcompactexplicitgc is specified. At least half the previously available memory has been consumed by TLH allocations (ensuring an accurate sample) and the average TLH size falls to less than 1024 bytes. The largest object that the gencon GC policy failed to move to the tenure area in the most recent scavenge operation is bigger than the largest free slot in the tenure area. The heap is fully expanded and less than 4% of the tenure area is free. Less than 128 KB of the heap is free. The following two options can be used to control compaction: -Xcompactgc forces compaction of the heap. -Xnocompactgc avoids compaction of the heap as a result of all the triggers shown in the preceding list. However a compaction can still occur in rare circumstances. In a verbose GC log, this operation is shown by the <gc-op type=\"compact\"> XML element. For more information, see Verbose GC logs . Weak reference processing Weak reference processing includes soft references, weak references, and phantom references. These references are created by the user for specific use cases and allow some level of interaction with the garbage collector. For example, a soft reference to an object allows that object to persist in memory for a longer period of time before being cleared. For example, a software cache. The garbage collector handles the reference types in the order shown and with the behavior detailed in the following table: Reference type Class Garbage collector behavior soft java.lang.ref.SoftReference A soft reference is cleared only when its referent is not marked for a number of GC cycles or if space on the heap is likely to cause an out of memory error. Use the -Xsoftrefthreshold option to control the collection of soft reference objects. weak java.lang.ref.WeakReference A weak reference is cleared as soon as its referent is not marked by a GC cycle. phantom java.lang.ref.PhantomReference A phantom reference is added to a reference queue and cleared after any objects that require finalization. If your application uses the Java Native Interface (JNI) to interact with other application types, you can also create weak JNI object references. These references have a similar life cycle to a weak Java reference. The garbage collector processes weak JNI references after all other Java reference types.","title":"Garbage Collection (GC)"},{"location":"gc_overview/#garbage-collection","text":"To prevent applications running out of memory, objects in the Java heap that are no longer required must be reclaimed. This process is known as garbage collection (GC). When garbage is collected, the garbage collector must obtain exclusive access to the heap, which causes an application to pause while the cleanup is done. This pause is often referred to as a stop-the-world (STW) pause because an application must halt until the process completes. In general, the first step in the GC process is to mark the objects that are reachable, which means they are still in use. The next step is to sweep away the unmarked objects to reclaim memory. The final step is to compact the heap if the heap is badly fragmented. A GC cycle is a repeatable process that involves a set of GC operations. These operations process all or parts of the Java heap. When operating on the whole of the Java heap, the cycle is referred to as a global GC cycle ; When operating on part of the heap, the cycle is referred to as a partial GC cycle . A global GC cycle can be triggered explicitly or implicitly according to the following rules: A global GC cycle is triggered implicitly if it occurs because of internal mechanisms, such as an allocation failure or a taxation threshold being reached. A global GC cycle is triggered explicitly if it is started directly by an application calling System.gc() or indirectly, for example when requesting a heap dump. Partial GC cycles are triggered only implicitly under the control of a particular GC policy. For more information about the GC policies available with OpenJ9, see Garbage collection policies . The GC process is designed to operate without intervention from an application. Developers should not attempt to predict GC behavior, for example, by making calls to System.gc() to trigger a cycle or by using finalizers to clean up objects in memory. Such actions might degrade the performance of an application.","title":"Garbage collection"},{"location":"gc_overview/#gc-operations","text":"GC operations run discrete functions on the Java heap. For example, a mark operation traces all objects in the heap to determine which ones are reachable. A sweep operation runs to clear away unreachable objects. Together, a mark and sweep operation are capable of reclaiming used memory as part of a GC cycle. Not all GC cycles include operations to reclaim memory. For example, the balanced GC policy involves a global cycle that includes only a mark operation; reclaiming the memory with a sweep operation occurs as part of a separate partial GC cycle that evacuates younger regions and defragments older regions. A GC operation might complete in one step, or it might involve multiple steps. For example, a mark operation consists of three steps, as described in the following section.","title":"GC operations"},{"location":"gc_overview/#gc-mark-operation","text":"A mark operation identifies which objects on the Java heap are reachable from outside of the heap and which objects are unreachable. Reachable objects are in use and must be retained, whereas unreachable objects are not in use and can be cleared away as garbage. The process of marking involves a bit array called a mark map that is allocated by the VM at startup, based on the maximum heap size setting. Each bit in the mark map corresponds to 8 bytes of heap space. When an object is marked , its location in the heap is recorded by setting the appropriate bit in the mark map. A mark operation can be broken down into the following steps: Initial A root object is an object that is accessible from outside of the heap such as a stack, class static field, or JNI reference. For other objects in the heap to be reachable, they must retain a connection from a root object. In the initial step, tracing identifies all root objects by running a root scan. Root objects are pushed onto a work stack for processing in the next step. Main The list of reachable root objects in the work stack is recursively traced for references to other objects in the heap. Objects that are not marked are new objects and these are added to the work stack. If an object is reachable, the appropriate bit is set in the mark map. Final The final step processes weakly reachable roots such as finalizable objects, weak references, monitor sets, and string sets. For more information about the processing of soft , weak , and phantom references, see Weak reference processing . In general, helper threads are used in parallel to speed up mark operations on the heap. The helper threads share the work stack with the application thread and are involved in identifying root objects, tracing objects in the heap, and updating the mark map. By default, the number of helper threads is based on the number of CPUs reported by the operating system. You can control the number of helper threads available by specifying the -Xgcthreads command line option when starting your application. In a verbose GC log, this operation is shown by the <gc-op type=\"mark\"> XML element. For more information, see Verbose GC logs .","title":"GC mark operation"},{"location":"gc_overview/#concurrent-mark-processing","text":"A mark operation can run with exclusive access to the heap, which requires application threads to pause while processing takes place. Alternatively, it can run concurrently with application threads to avoid pauses in application processing. With concurrent mark, the process of root scanning is handed over to application stack threads, which populate the work stack with root objects in their stack. The root objects in the work stack are then traced by a background thread and by each application thread during a heap lock allocation to find reachable objects and update the mark map. Because the mark operation runs concurrently with application threads, any changes to objects that are already traced must be updated. This process works by using a write barrier that can flag the update and trigger a further scan of part of the heap. To track updates to objects, concurrent mark operations use single-byte cards in a card table . Each card corresponds to a 512-byte section of the Java heap. When an object is updated, the start address for the object in the heap is marked on the appropriate card. These cards are used to determine what must be retraced later in the GC cycle. A GC cycle that includes concurrent mark operations aims to trace all reachable objects and complete processing at the same time as the heap is exhausted. Continuous adjustments are made to the start time of each cycle to get as close to heap exhaustion as possible. When the heap is exhausted a sweep operation is able to reclaim memory. This operation requires a STW pause. Before sweep operations start, the root objects are rescanned and the cards are checked to determine which areas of memory must be retraced. An advantage of concurrent mark operations over STW mark operations is reduced pause times, because the garbage collector is able to identify garbage without halting application threads. Pause times are also more consistent because the collector is able to tune start times to maximize heap usage. Disadvantages of concurrent mark operations include the additional CPU for operating the write barrier and additional work for application threads to trace objects when requesting a heap lock. Concurrent mark operations are used by the gencon GC policy and the optavgpause GC policy .","title":"Concurrent mark processing"},{"location":"gc_overview/#incremental-concurrent-mark-processing","text":"Incremental concurrent mark processing evens out pause times by avoiding global STW garbage collections. This type of marking is also known as the global mark phase , whereby mark operations take place incrementally across the entire heap. The global mark operations are interleaved with a partial GC cycle that is responsible for moving objects and clearing unreachable objects in the heap. These operations also use mark map in a card table to manage updates to objects that occur whilst mark operations are in progress. However, unlike the concurrent mark operations used by other policies, application threads are not involved in tracing objects; only background threads are used to trace objects and update the mark map. Incremental concurrent mark operations are used by the balanced GC policy .","title":"Incremental concurrent mark processing"},{"location":"gc_overview/#gc-sweep-operation","text":"The purpose of a sweep operation is to identify memory that can be reclaimed for object allocation and update a central record, known as the freelist . sweep operations occur in 2 steps: Initial This step analyzes the mark map for free memory. Final Based on the analysis, the sections of the heap are connected to the freelist. As with mark operations, multiple helper threads can be used to sweep the Java heap in parallel to speed up processing times. Because these helper threads are the same ones that are used for parallel mark operations, the number of threads can be controlled by using the -Xgcthreads option. Parallel sweep operations run on 256 KB sections of the heap. Each helper thread scans a section at a time. The results are stored and used to generate a freelist of empty regions. In a verbose GC log, this operation is shown by the <gc-op type=\"sweep\"> XML element. For more information, see Verbose GC logs .","title":"GC sweep operation"},{"location":"gc_overview/#concurrent-sweep-processing","text":"Concurrent sweep processing works in tandem with concurrent mark processing and uses the same mark map. Concurrent sweep operations start after a STW collection and complete a section of the heap before concurrent mark operations continue. Concurrent sweep is used by the optavgpause GC policy.","title":"Concurrent sweep processing"},{"location":"gc_overview/#gc-scavenge-operation","text":"A GC scavenge operation is triggered by an allocation failure in the nursery area of the heap. The operation occurs in the following 3 steps: Initial A root object is an object that is accessible from outside of the heap such as a stack, class static field, or JNI reference. For other objects in the heap to be reachable, they must retain a connection from a root object. In the initial step, tracing identifies all root objects by running a root scan. Root objects are pushed onto a work stack for processing in the next step. Main The list of reachable root objects in the work stack is recursively traced for references to other objects in the heap by using the hierarchical scan ordering mode ( -Xgc:hierarchicalScanOrdering ). If new objects are found, they are added to the work stack. If an object is reachable, it is copied from the allocate space to the survivor space in the nursery area or to the tenure area if the object has reached a particular age. Final The final step processes weakly reachable roots such as finalizable objects, weak references, monitor sets, and string sets. For more information about the processing of soft, weak, and phantom references, see Weak reference processing . In a verbose GC log, this operation is shown by the <gc-op type=\"scavenge\"> XML element. For more information, see Verbose GC logs . The scavenge operation is used by the gencon GC policy .","title":"GC scavenge operation"},{"location":"gc_overview/#gc-copy-forward-operation","text":"A GC copy forward operation is similar to a scavenge operation but is triggered by a taxation threshold being reached. The operation occurs in the following 3 steps: Initial A root object is an object that is accessible from outside of the heap such as a stack, class static field, or JNI reference. For other objects in the heap to be reachable, they must retain a connection from a root object. In the initial step, tracing identifies all root objects by running a root scan. Root objects are pushed onto a work stack for processing in the next step. Main The list of reachable root objects in the work stack is recursively traced for references to other objects in the heap by using dynamic breadth first scan ordering mode ( -Xgc:dynamicBreadthFirstScanOrdering ). If new objects are found, they are added to the work stack. If an object is reachable, it is moved to another region of the same age or to an empty region of the same age in the heap. The age of all regions in the heap is then incremented by 1, except for the oldest region (age 24). Final The final step processes weakly reachable roots such as finalizable objects, weak references, monitor sets, and string sets. For more information about the processing of soft, weak, and phantom references, see Weak reference processing . The operation aims to empty or evacuate fragmented regions that can then be reclaimed for new object allocation. In a verbose GC log, this operation is shown by the <gc-op type=\"copy forward\"> XML element. For more information, see Verbose GC logs . The copy forward operation is used by the balanced GC policy .","title":"GC copy forward operation"},{"location":"gc_overview/#gc-classunloading-operation","text":"The classunloading operation is single threaded, not parallel threaded. In a verbose GC log, this operation is shown by the <gc-op type=\"classunload\"> XML element. For more information, see Verbose GC logs .","title":"GC classunloading operation"},{"location":"gc_overview/#gc-compact-operation","text":"Compaction of the heap is an expensive operation because when objects are moved to defragment the heap, the references to each object change. Therefore, compact operations do not occur by default but only when the following triggers occur: The -Xcompactgc option is specified on the command line. After sweeping the heap, there is not enough free space available to satisfy an allocation request. A System.gc() is requested and the last allocation failure that triggered a global GC cycle did not compact or -Xcompactexplicitgc is specified. At least half the previously available memory has been consumed by TLH allocations (ensuring an accurate sample) and the average TLH size falls to less than 1024 bytes. The largest object that the gencon GC policy failed to move to the tenure area in the most recent scavenge operation is bigger than the largest free slot in the tenure area. The heap is fully expanded and less than 4% of the tenure area is free. Less than 128 KB of the heap is free. The following two options can be used to control compaction: -Xcompactgc forces compaction of the heap. -Xnocompactgc avoids compaction of the heap as a result of all the triggers shown in the preceding list. However a compaction can still occur in rare circumstances. In a verbose GC log, this operation is shown by the <gc-op type=\"compact\"> XML element. For more information, see Verbose GC logs .","title":"GC compact operation"},{"location":"gc_overview/#weak-reference-processing","text":"Weak reference processing includes soft references, weak references, and phantom references. These references are created by the user for specific use cases and allow some level of interaction with the garbage collector. For example, a soft reference to an object allows that object to persist in memory for a longer period of time before being cleared. For example, a software cache. The garbage collector handles the reference types in the order shown and with the behavior detailed in the following table: Reference type Class Garbage collector behavior soft java.lang.ref.SoftReference A soft reference is cleared only when its referent is not marked for a number of GC cycles or if space on the heap is likely to cause an out of memory error. Use the -Xsoftrefthreshold option to control the collection of soft reference objects. weak java.lang.ref.WeakReference A weak reference is cleared as soon as its referent is not marked by a GC cycle. phantom java.lang.ref.PhantomReference A phantom reference is added to a reference queue and cleared after any objects that require finalization. If your application uses the Java Native Interface (JNI) to interact with other application types, you can also create weak JNI object references. These references have a similar life cycle to a weak Java reference. The garbage collector processes weak JNI references after all other Java reference types.","title":"Weak reference processing"},{"location":"interface_dtfj/","text":"Diagnostic Tool Framework for Java The Diagnostic Tool Framework for Java\u2122 (DTFJ) is a Java application programming interface (API) that is used to support the building of Java diagnostic tools. DTFJ works with data from a system dump or a Java dump. On Linux and AIX\u00ae operating systems, you can get more information from a system dump if you also have copies of executable files and libraries. You can run the jpackcore utility to collect these files into a single archive for use in subsequent problem diagnosis. For more information, see Dump extractor . The DTFJ API helps diagnostic tools access the following information: Memory locations stored in the dump (System dumps only) Relationships between memory locations and Java internals (System dumps only) Java threads running in the VM Native threads held in the dump (System dumps only) Java classes and their class loaders that were present Java objects that were present in the heap (System dumps only) Java monitors and the objects and threads they are associated with Details of the workstation on which the dump was produced (System dumps only) Details of the Java version that was being used The command line that launched the VM If your DTFJ application requests information that is not available in the Java dump, the API will return null or throw a DataUnavailable exception. You might need to adapt DTFJ applications written to process system dumps to make them work with Java dumps. DTFJ is implemented in pure Java and tools written using DTFJ can be cross-platform. Therefore, you can analyze a dump taken from one workstation on another (remote and more convenient) machine. For example, a dump produced on an AIX\u00ae Power\u00ae system can be analyzed on a Windows laptop. See the DTFJ API documentation . Note: If the code that loads DTFJ is in a module, the module must require the openj9.dtfj module. For example: module MyModule { requires openj9.dtfj; } Using the DTFJ interface To create applications that use DTFJ, you must use the DTFJ interface. Implementations of this interface have been written that work with system dumps and Java dumps. The diagram that follows illustrates the DTFJ interface. The starting point for working with a dump is to obtain an Image instance by using the ImageFactory class supplied with the concrete implementation of the API. Working with a system dump The following example shows how to work with a system dump. In this example, the only section of code that ties the dump to a particular implementation of DTFJ is the generation of the factory class. Change the factory if you want to use a different implementation. If there is a problem with the file that is passed to the getImage() method, an IOException is thrown and an appropriate message is issued. If a missing file is passed to the example shown, the following output is produced: Could not find/use required file(s) java.io.FileNotFoundException: core_file.xml (The system cannot find the file specified.) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(FileInputStream.java:135) at com.ibm.dtfj.image.j9.ImageFactory.getImage(ImageFactory.java:47) at com.ibm.dtfj.image.j9.ImageFactory.getImage(ImageFactory.java:35) at DTFJEX1.main(DTFJEX1.java:23)Copy In this case, the DTFJ implementation is expecting a dump file to exist. Different errors are caught if the file existed but was not recognized as a valid dump file. Example of working with a system dump import java.io.File; import java.util.Iterator; import java.io.IOException; import com.ibm.dtfj.image.CorruptData; import com.ibm.dtfj.image.Image; import com.ibm.dtfj.image.ImageFactory; public class DTFJEX1 { public static void main(String[] args) { Image image = null; if (args.length > 0) { File f = new File(args[0]); try { Class factoryClass = Class.forName(\"com.ibm.dtfj.image.j9.ImageFactory\"); ImageFactory factory = (ImageFactory) factoryClass.newInstance(); image = factory.getImage(f); } catch (ClassNotFoundException e) { System.err.println(\"Could not find DTFJ factory class\"); e.printStackTrace(System.err); } catch (IllegalAccessException e) { System.err.println(\"IllegalAccessException for DTFJ factory class\"); e.printStackTrace(System.err); } catch (InstantiationException e) { System.err.println(\"Could not instantiate DTFJ factory class\"); e.printStackTrace(System.err); } catch (IOException e) { System.err.println(\"Could not find/use required file(s)\"); e.printStackTrace(System.err); } } else { System.err.println(\"No filename specified\"); } if (image == null) { return; } Iterator asIt = image.getAddressSpaces(); int count = 0; while (asIt.hasNext()) { Object tempObj = asIt.next(); if (tempObj instanceof CorruptData) { System.err.println(\"Address Space object is corrupt: \" + (CorruptData) tempObj); } else { count++; } } System.out.println(\"The number of address spaces is: \" + count); } } Working with a Java dump To work with a Java dump, change the factory class to com.ibm.dtfj.image.javacore.JCImageFactory and pass the Java dump file to the getImage() method. Example of working with a Java dump import java.io.File; import java.util.Iterator; import java.io.IOException; import com.ibm.dtfj.image.CorruptData; import com.ibm.dtfj.image.Image; import com.ibm.dtfj.image.ImageFactory; public class DTFJEX2 { public static void main(String[] args) { Image image=null; if (args.length > 0) { File javacoreFile = new File(args[0]); try { Class factoryClass = Class.forName(\"com.ibm.dtfj.image.javacore.JCImageFactory\"); ImageFactory factory = (ImageFactory) factoryClass.newInstance(); image = factory.getImage(javacoreFile); } catch (ClassNotFoundException e) { System.err.println(\"Could not find DTFJ factory class\"); e.printStackTrace(System.err); } catch (IllegalAccessException e) { System.err.println(\"IllegalAccessException for DTFJ factory class\"); e.printStackTrace(System.err); } catch (InstantiationException e) { System.err.println(\"Could not instantiate DTFJ factory class\"); e.printStackTrace(System.err); } catch (IOException e) { System.err.println(\"Could not find/use required file(s)\"); e.printStackTrace(System.err); } } else { System.err.println(\"No filename specified\"); } if (image == null) { return; } Iterator asIt = image.getAddressSpaces(); int count = 0; while (asIt.hasNext()) { Object tempObj = asIt.next(); if (tempObj instanceof CorruptData) { System.err.println(\"Address Space object is corrupt: \" + (CorruptData) tempObj); } else { count++; } } System.out.println(\"The number of address spaces is: \" + count); } } Analyze the dump After you have obtained an Image instance, you can begin analyzing the dump. The Image instance is the second instance in the class hierarchy for DTFJ illustrated by the following diagram: Some things to note from the diagram: The DTFJ interface is separated into two parts: classes with names that start with Image (the dump, a sequence of bytes with different contents on different platforms) and classes with names that start with Java (the Java internal knowledge). Image and Java classes are linked using a ManagedRuntime class (which is extended by JavaRuntime ). An Image object contains one ImageAddressSpace object (or, on z/OS\u00ae, possibly more). An ImageAddressSpace object contains one ImageProcess object (or, on z/OS, possibly more). Conceptually, you can apply the Image model to any program running with the ImageProcess . For the purposes of this document discussion is limited to the OpenJ9 virtual machine implementations. There is a link from a JavaThread object to its corresponding ImageThread object. Use this link to find out about native code associated with a Java thread, for example JNI functions that have been called from Java. If a JavaThread was not running Java code when the dump was taken, the JavaThread object has no JavaStackFrame objects. In these cases, use the link to the corresponding ImageThread object to find out what native code was running in that thread. This situation is typically the case with the JIT compilation thread and Garbage Collection threads. The DTFJ interface enables you to obtain information about native memory. Native memory is memory requested from the operating system using library functions such as malloc() and mmap() . When the Java runtime allocates native memory, the memory is associated with a high-level memory category. For more information about native memory detailed in a Java dump, see Java dump: NATIVEMEMINFO DTFJ example application This example is a fully working DTFJ application. Many DTFJ applications will follow a similar model. Sample DTFJ application import java.io.File; import java.util.Iterator; import com.ibm.dtfj.image.CorruptData; import com.ibm.dtfj.image.CorruptDataException; import com.ibm.dtfj.image.DataUnavailable; import com.ibm.dtfj.image.Image; import com.ibm.dtfj.image.ImageAddressSpace; import com.ibm.dtfj.image.ImageFactory; import com.ibm.dtfj.image.ImageProcess; import com.ibm.dtfj.java.JavaRuntime; import com.ibm.dtfj.java.JavaThread; import com.ibm.dtfj.image.ImageThread; public class DTFJEX2 { public static void main( String[] args ) { Image image = null; if ( args.length > 0 ) { File f = new File( args[0] ); try { Class factoryClass = Class .forName( \"com.ibm.dtfj.image.j9.ImageFactory\" ); ImageFactory factory = (ImageFactory) factoryClass.newInstance( ); image = factory.getImage( f ); } catch ( Exception ex ) { /* * Should use the error handling as shown in DTFJEX1. */ System.err.println( \"Error in DTFJEX2\" ); ex.printStackTrace( System.err ); } } else { System.err.println( \"No filename specified\" ); } if ( null == image ) { return; } MatchingThreads( image ); } public static void MatchingThreads( Image image ) { ImageThread imgThread = null; Iterator asIt = image.getAddressSpaces( ); while ( asIt.hasNext( ) ) { System.out.println( \"Found ImageAddressSpace...\" ); ImageAddressSpace as = (ImageAddressSpace) asIt.next( ); Iterator prIt = as.getProcesses( ); while ( prIt.hasNext( ) ) { System.out.println( \"Found ImageProcess...\" ); ImageProcess process = (ImageProcess) prIt.next( ); Iterator runTimesIt = process.getRuntimes( ); while ( runTimesIt.hasNext( ) ) { System.out.println( \"Found Runtime...\" ); JavaRuntime javaRT = (JavaRuntime) runTimesIt.next( ); Iterator javaThreadIt = javaRT.getThreads( ); while ( javaThreadIt.hasNext( ) ) { Object tempObj = javaThreadIt.next( ); /* * Should use CorruptData handling for all iterators */ if ( tempObj instanceof CorruptData ) { System.out.println( \"We have some corrupt data\" ); } else { JavaThread javaThread = (JavaThread) tempObj; System.out.println( \"Found JavaThread...\" ); try { imgThread = (ImageThread) javaThread.getImageThread( ); // Now we have a Java thread we can iterator // through the image threads Iterator imgThreadIt = process.getThreads( ); while ( imgThreadIt.hasNext( ) ) { ImageThread imgThread2 = (ImageThread) imgThreadIt .next( ); if ( imgThread.equals( imgThread2 ) ) { System.out.println( \"Found a match:\" ); System.out.println( \"\\tjavaThread \" + javaThread.getName( ) + \" is the same as \" + imgThread2.getID( ) ); } } } catch ( CorruptDataException e ) { System.err.println( \"ImageThread was corrupt: \" + e.getMessage( ) ); } catch ( DataUnavailable e ) { System.out.println( \"DataUnavailable: \" + e.getMessage( ) ); } } } } } } } } For clarity, the example does not perform full error checking when constructing the main Image object and does not perform CorruptData handling in all of the iterators. In a production environment, you use the techniques illustrated in the previous examples under Working with a system dump and Working with a Java dump . In the example, the program iterates through every available Java thread and checks whether it is equal to any of the available image threads. When they are found to be equal, the program displays the following message: \"Found a match\". The example demonstrates: How to iterate down through the class hierarchy. How to handle CorruptData objects from the iterators. The use of the .equals method for testing equality between objects.","title":"DTFJ"},{"location":"interface_dtfj/#diagnostic-tool-framework-for-java","text":"The Diagnostic Tool Framework for Java\u2122 (DTFJ) is a Java application programming interface (API) that is used to support the building of Java diagnostic tools. DTFJ works with data from a system dump or a Java dump. On Linux and AIX\u00ae operating systems, you can get more information from a system dump if you also have copies of executable files and libraries. You can run the jpackcore utility to collect these files into a single archive for use in subsequent problem diagnosis. For more information, see Dump extractor . The DTFJ API helps diagnostic tools access the following information: Memory locations stored in the dump (System dumps only) Relationships between memory locations and Java internals (System dumps only) Java threads running in the VM Native threads held in the dump (System dumps only) Java classes and their class loaders that were present Java objects that were present in the heap (System dumps only) Java monitors and the objects and threads they are associated with Details of the workstation on which the dump was produced (System dumps only) Details of the Java version that was being used The command line that launched the VM If your DTFJ application requests information that is not available in the Java dump, the API will return null or throw a DataUnavailable exception. You might need to adapt DTFJ applications written to process system dumps to make them work with Java dumps. DTFJ is implemented in pure Java and tools written using DTFJ can be cross-platform. Therefore, you can analyze a dump taken from one workstation on another (remote and more convenient) machine. For example, a dump produced on an AIX\u00ae Power\u00ae system can be analyzed on a Windows laptop. See the DTFJ API documentation . Note: If the code that loads DTFJ is in a module, the module must require the openj9.dtfj module. For example: module MyModule { requires openj9.dtfj; }","title":"Diagnostic Tool Framework for Java"},{"location":"interface_dtfj/#using-the-dtfj-interface","text":"To create applications that use DTFJ, you must use the DTFJ interface. Implementations of this interface have been written that work with system dumps and Java dumps. The diagram that follows illustrates the DTFJ interface. The starting point for working with a dump is to obtain an Image instance by using the ImageFactory class supplied with the concrete implementation of the API.","title":"Using the DTFJ interface"},{"location":"interface_dtfj/#working-with-a-system-dump","text":"The following example shows how to work with a system dump. In this example, the only section of code that ties the dump to a particular implementation of DTFJ is the generation of the factory class. Change the factory if you want to use a different implementation. If there is a problem with the file that is passed to the getImage() method, an IOException is thrown and an appropriate message is issued. If a missing file is passed to the example shown, the following output is produced: Could not find/use required file(s) java.io.FileNotFoundException: core_file.xml (The system cannot find the file specified.) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(FileInputStream.java:135) at com.ibm.dtfj.image.j9.ImageFactory.getImage(ImageFactory.java:47) at com.ibm.dtfj.image.j9.ImageFactory.getImage(ImageFactory.java:35) at DTFJEX1.main(DTFJEX1.java:23)Copy In this case, the DTFJ implementation is expecting a dump file to exist. Different errors are caught if the file existed but was not recognized as a valid dump file. Example of working with a system dump import java.io.File; import java.util.Iterator; import java.io.IOException; import com.ibm.dtfj.image.CorruptData; import com.ibm.dtfj.image.Image; import com.ibm.dtfj.image.ImageFactory; public class DTFJEX1 { public static void main(String[] args) { Image image = null; if (args.length > 0) { File f = new File(args[0]); try { Class factoryClass = Class.forName(\"com.ibm.dtfj.image.j9.ImageFactory\"); ImageFactory factory = (ImageFactory) factoryClass.newInstance(); image = factory.getImage(f); } catch (ClassNotFoundException e) { System.err.println(\"Could not find DTFJ factory class\"); e.printStackTrace(System.err); } catch (IllegalAccessException e) { System.err.println(\"IllegalAccessException for DTFJ factory class\"); e.printStackTrace(System.err); } catch (InstantiationException e) { System.err.println(\"Could not instantiate DTFJ factory class\"); e.printStackTrace(System.err); } catch (IOException e) { System.err.println(\"Could not find/use required file(s)\"); e.printStackTrace(System.err); } } else { System.err.println(\"No filename specified\"); } if (image == null) { return; } Iterator asIt = image.getAddressSpaces(); int count = 0; while (asIt.hasNext()) { Object tempObj = asIt.next(); if (tempObj instanceof CorruptData) { System.err.println(\"Address Space object is corrupt: \" + (CorruptData) tempObj); } else { count++; } } System.out.println(\"The number of address spaces is: \" + count); } }","title":"Working with a system dump"},{"location":"interface_dtfj/#working-with-a-java-dump","text":"To work with a Java dump, change the factory class to com.ibm.dtfj.image.javacore.JCImageFactory and pass the Java dump file to the getImage() method. Example of working with a Java dump import java.io.File; import java.util.Iterator; import java.io.IOException; import com.ibm.dtfj.image.CorruptData; import com.ibm.dtfj.image.Image; import com.ibm.dtfj.image.ImageFactory; public class DTFJEX2 { public static void main(String[] args) { Image image=null; if (args.length > 0) { File javacoreFile = new File(args[0]); try { Class factoryClass = Class.forName(\"com.ibm.dtfj.image.javacore.JCImageFactory\"); ImageFactory factory = (ImageFactory) factoryClass.newInstance(); image = factory.getImage(javacoreFile); } catch (ClassNotFoundException e) { System.err.println(\"Could not find DTFJ factory class\"); e.printStackTrace(System.err); } catch (IllegalAccessException e) { System.err.println(\"IllegalAccessException for DTFJ factory class\"); e.printStackTrace(System.err); } catch (InstantiationException e) { System.err.println(\"Could not instantiate DTFJ factory class\"); e.printStackTrace(System.err); } catch (IOException e) { System.err.println(\"Could not find/use required file(s)\"); e.printStackTrace(System.err); } } else { System.err.println(\"No filename specified\"); } if (image == null) { return; } Iterator asIt = image.getAddressSpaces(); int count = 0; while (asIt.hasNext()) { Object tempObj = asIt.next(); if (tempObj instanceof CorruptData) { System.err.println(\"Address Space object is corrupt: \" + (CorruptData) tempObj); } else { count++; } } System.out.println(\"The number of address spaces is: \" + count); } }","title":"Working with a Java dump"},{"location":"interface_dtfj/#analyze-the-dump","text":"After you have obtained an Image instance, you can begin analyzing the dump. The Image instance is the second instance in the class hierarchy for DTFJ illustrated by the following diagram: Some things to note from the diagram: The DTFJ interface is separated into two parts: classes with names that start with Image (the dump, a sequence of bytes with different contents on different platforms) and classes with names that start with Java (the Java internal knowledge). Image and Java classes are linked using a ManagedRuntime class (which is extended by JavaRuntime ). An Image object contains one ImageAddressSpace object (or, on z/OS\u00ae, possibly more). An ImageAddressSpace object contains one ImageProcess object (or, on z/OS, possibly more). Conceptually, you can apply the Image model to any program running with the ImageProcess . For the purposes of this document discussion is limited to the OpenJ9 virtual machine implementations. There is a link from a JavaThread object to its corresponding ImageThread object. Use this link to find out about native code associated with a Java thread, for example JNI functions that have been called from Java. If a JavaThread was not running Java code when the dump was taken, the JavaThread object has no JavaStackFrame objects. In these cases, use the link to the corresponding ImageThread object to find out what native code was running in that thread. This situation is typically the case with the JIT compilation thread and Garbage Collection threads. The DTFJ interface enables you to obtain information about native memory. Native memory is memory requested from the operating system using library functions such as malloc() and mmap() . When the Java runtime allocates native memory, the memory is associated with a high-level memory category. For more information about native memory detailed in a Java dump, see Java dump: NATIVEMEMINFO","title":"Analyze the dump"},{"location":"interface_dtfj/#dtfj-example-application","text":"This example is a fully working DTFJ application. Many DTFJ applications will follow a similar model. Sample DTFJ application import java.io.File; import java.util.Iterator; import com.ibm.dtfj.image.CorruptData; import com.ibm.dtfj.image.CorruptDataException; import com.ibm.dtfj.image.DataUnavailable; import com.ibm.dtfj.image.Image; import com.ibm.dtfj.image.ImageAddressSpace; import com.ibm.dtfj.image.ImageFactory; import com.ibm.dtfj.image.ImageProcess; import com.ibm.dtfj.java.JavaRuntime; import com.ibm.dtfj.java.JavaThread; import com.ibm.dtfj.image.ImageThread; public class DTFJEX2 { public static void main( String[] args ) { Image image = null; if ( args.length > 0 ) { File f = new File( args[0] ); try { Class factoryClass = Class .forName( \"com.ibm.dtfj.image.j9.ImageFactory\" ); ImageFactory factory = (ImageFactory) factoryClass.newInstance( ); image = factory.getImage( f ); } catch ( Exception ex ) { /* * Should use the error handling as shown in DTFJEX1. */ System.err.println( \"Error in DTFJEX2\" ); ex.printStackTrace( System.err ); } } else { System.err.println( \"No filename specified\" ); } if ( null == image ) { return; } MatchingThreads( image ); } public static void MatchingThreads( Image image ) { ImageThread imgThread = null; Iterator asIt = image.getAddressSpaces( ); while ( asIt.hasNext( ) ) { System.out.println( \"Found ImageAddressSpace...\" ); ImageAddressSpace as = (ImageAddressSpace) asIt.next( ); Iterator prIt = as.getProcesses( ); while ( prIt.hasNext( ) ) { System.out.println( \"Found ImageProcess...\" ); ImageProcess process = (ImageProcess) prIt.next( ); Iterator runTimesIt = process.getRuntimes( ); while ( runTimesIt.hasNext( ) ) { System.out.println( \"Found Runtime...\" ); JavaRuntime javaRT = (JavaRuntime) runTimesIt.next( ); Iterator javaThreadIt = javaRT.getThreads( ); while ( javaThreadIt.hasNext( ) ) { Object tempObj = javaThreadIt.next( ); /* * Should use CorruptData handling for all iterators */ if ( tempObj instanceof CorruptData ) { System.out.println( \"We have some corrupt data\" ); } else { JavaThread javaThread = (JavaThread) tempObj; System.out.println( \"Found JavaThread...\" ); try { imgThread = (ImageThread) javaThread.getImageThread( ); // Now we have a Java thread we can iterator // through the image threads Iterator imgThreadIt = process.getThreads( ); while ( imgThreadIt.hasNext( ) ) { ImageThread imgThread2 = (ImageThread) imgThreadIt .next( ); if ( imgThread.equals( imgThread2 ) ) { System.out.println( \"Found a match:\" ); System.out.println( \"\\tjavaThread \" + javaThread.getName( ) + \" is the same as \" + imgThread2.getID( ) ); } } } catch ( CorruptDataException e ) { System.err.println( \"ImageThread was corrupt: \" + e.getMessage( ) ); } catch ( DataUnavailable e ) { System.out.println( \"DataUnavailable: \" + e.getMessage( ) ); } } } } } } } } For clarity, the example does not perform full error checking when constructing the main Image object and does not perform CorruptData handling in all of the iterators. In a production environment, you use the techniques illustrated in the previous examples under Working with a system dump and Working with a Java dump . In the example, the program iterates through every available Java thread and checks whether it is equal to any of the available image threads. When they are found to be equal, the program displays the following message: \"Found a match\". The example demonstrates: How to iterate down through the class hierarchy. How to handle CorruptData objects from the iterators. The use of the .equals method for testing equality between objects.","title":"DTFJ example application"},{"location":"interface_jvmti/","text":"Java Virtual Machine Tool Interface The Java\u2122 Virtual Machine Tool Interface (JVMTI) is a two-way interface that allows communication between the VM and a native agent. It replaces both the Java Virtual Machine Debug Interface (JVMDI) and Java Virtual Machine Profiler Interface (JVMPI). Overview The JVMTI allows third parties to develop debugging, profiling, and monitoring tools for the VM. The interface contains mechanisms for the agent to notify the VM about the kinds of information it requires, and also provides a means of receiving relevant notifications. Several agents can be attached to a VM at any one time. JVMTI agents can be loaded at startup using short or long forms of the command-line option: -agentlib:<agent-lib-name>=<options> or -agentpath:<path-to-agent>=<options> In the example that follows (see Sample JVMTI agent ), the directory containing the jdwp library is assumed to be on the library path. If you require a specific library, such as jdwp , with your JVMTI agent, you can specify the path at startup, for example: -agentlib:jdwp=<options> For more information about JVMTI, see https://docs.oracle.com/javase/8/docs/technotes/guides/management/index.html . For a guide about writing a JVMTI agent, see http://www.oracle.com/technetwork/articles/javase/jvmti-136367.html . OpenJ9 extensions OpenJ9 extensions to the JVMTI allow a JVMTI agent to query or automatically trigger operations in the VM, including the following tasks: Task OpenJ9 extensions Get the OS thread ID GetOSThreadID Query, set, and reset the VM dump options QueryVmDump , SetVmDump , ResetVmDump Trigger a VM dump, and monitor JVMTI event functions when VM dumps start and end TriggerVmDump , VMDumpStart , VMDumpEnd Set VM trace options SetVmTrace Subscribe to and unsubscribe from VM tracepoints RegisterTracePointSubscriber , DeregisterTracePointSubscriber Query runtime environment native memory categories GetMemoryCategories Query and set VM log options QueryVmLogOptions , SetVmLogOptions Search for and remove a shared classes cache IterateSharedCaches , DestroySharedCache Subscribe to and unsubscribe from verbose garbage collection (GC) data logging RegisterVerboseGCSubscriber , DeregisterVerboseGCSubscriber The definitions that you need when you write a JVMTI agent are provided in the header files jvmti.h and ibmjvmti.h , in the include directory. Sample JVMTI agent The following sample shows you how to write a simple JVMTI agent that uses OpenJ9 extensions to the JVMTI. Sample JVMTI agent written in C/C++, which uses the OpenJ9 extensions /* * tiSample.c * * Sample JVMTI agent to demonstrate the OpenJ9 JVMTI dump extensions */ #include \"jvmti.h\" #include \"ibmjvmti.h\" /* Forward declarations for JVMTI callback functions */ void JNICALL VMInitCallback(jvmtiEnv *jvmti_env, JNIEnv* jni_env, jthread thread); void JNICALL DumpStartCallback(jvmtiEnv *jvmti_env, char* label, char* event, char* detail, ...); /* * Agent_Onload() * * JVMTI agent initialisation function, invoked as agent is loaded by the VM */ JNIEXPORT jint JNICALL Agent_OnLoad(JavaVM *jvm, char *options, void *reserved) { jvmtiEnv *jvmti = NULL; jvmtiError rc; jint extensionEventCount = 0; jvmtiExtensionEventInfo *extensionEvents = NULL; jint extensionFunctionCount = 0; jvmtiExtensionFunctionInfo *extensionFunctions = NULL; int i = 0, j = 0; printf(\"tiSample: Loading JVMTI sample agent\\n\"); /* Get access to JVMTI */ (*jvm)->GetEnv(jvm, (void **)&jvmti, JVMTI_VERSION_1_0); /* Look up all the JVMTI extension events and functions */ (*jvmti)->GetExtensionEvents(jvmti, &extensionEventCount, &extensionEvents); (*jvmti)->GetExtensionFunctions(jvmti, &extensionFunctionCount, &extensionFunctions); printf(\"tiSample: Found %i JVMTI extension events, %i extension functions\\n\", extensionEventCount, extensionFunctionCount); /* Find the JVMTI extension event we want */ while (i++ < extensionEventCount) { if (strcmp(extensionEvents->id, COM_IBM_VM_DUMP_START) == 0) { /* Found the dump start extension event, now set up a callback for it */ rc = (*jvmti)->SetExtensionEventCallback(jvmti, extensionEvents->extension_event_index, &DumpStartCallback); printf(\"tiSample: Setting JVMTI event callback %s, rc=%i\\n\", COM_IBM_VM_DUMP_START, rc); break; } extensionEvents++; /* move on to the next extension event */ } /* Find the JVMTI extension function we want */ while (j++ < extensionFunctionCount) { jvmtiExtensionFunction function = extensionFunctions->func; if (strcmp(extensionFunctions->id, COM_IBM_SET_VM_DUMP) == 0) { /* Found the set dump extension function, now set a dump option to generate javadumps on thread starts */ rc = function(jvmti, \"java:events=thrstart\"); printf(\"tiSample: Calling JVMTI extension %s, rc=%i\\n\", COM_IBM_SET_VM_DUMP, rc); break; } extensionFunctions++; /* move on to the next extension function */ } return JNI_OK; } /* * DumpStartCallback() * JVMTI callback for dump start event (IBM JVMTI extension) */ void JNICALL DumpStartCallback(jvmtiEnv *jvmti_env, char* label, char* event, char* detail, ...) { printf(\"tiSample: Received JVMTI event callback, for event %s\\n\", event); } The sample JVMTI agent consists of two functions, Agent_OnLoad() and DumpStartCallback() : Agent_OnLoad() This function is called by the VM when the agent is loaded at VM startup, which allows the JVMTI agent to modify VM behavior before initialization is complete. The sample agent obtains access to the JVMTI interface by using the JNI Invocation API function GetEnv() . The agent calls the APIs GetExtensionEvents() and GetExtensionFunctions() to find the JVMTI extensions that are supported by the VM. These APIs provide access to the list of extensions available in the jvmtiExtensionEventInfo and jvmtiExtensionFunctionInfo structures. The sample uses an extension event and an extension function in the following way: Extension event: The sample JVMTI agent searches for the extension event VmDumpStart in the list of jvmtiExtensionEventInfo structures, by using the identifier COM_IBM_VM_DUMP_START provided in ibmjvmti.h . When the event is found, the JVMTI agent calls the JVMTI interface SetExtensionEventCallback() to enable the event, providing a function DumpStartCallback() that is called when the event is triggered. Extension function: Next, the sample JVMTI agent searches for the extension function SetVMDump in the list of jvmtiExtensionFunctionInfo structures, by using the identifier COM_IBM_SET_VM_DUMP provided in ibmjvmti.h . The JVMTI agent calls the function by using the jvmtiExtensionFunction pointer to set a VM dump option java:events=thrstart . This option requests the VM to trigger a Java dump every time a VM thread is started. DumpStartCallback() This callback function issues a message when the associated extension event is called. In the sample code, DumpStartCallback() is used when the VmDumpStart event is triggered. Using the sample JVMTI agent Build the sample JVMTI agent: Windows: cl /I<jre_path>\\include /MD /FetiSample.dll tiSample.c /link /DLL Linux, AIX\u00ae, and z/OS\u00ae: gcc -I<jre_path>/include -o libtiSample.so -shared tiSample.c where <jre_path> is the path to your Java runtime environment installation. To run the sample JVMTI agent, use the command: java -agentlib:tiSample -version When the sample JVMTI agent loads, messages are generated. When the JVMTI agent initiates a Java dump, the message JVMDUMP010 is issued. API reference The following sections provide reference information for the OpenJ9 extensions to the JVMTI. GetOSThreadID You can get the OS thread ID by using the GetOSThreadID() API: jvmtiError GetOSThreadID(jvmtiEnv* jvmti_env, jthread thread, jlong * threadid_ptr); Parameters jvmti_env : A pointer to the JVMTI environment. thread : The thread for which the ID is required. threadid_ptr : A pointer to a variable, used to return the thread ID that corresponds to the thread specified by the thread parameter. Returns JVMTI_ERROR_NONE : Success JVMTI_ERROR_NULL_POINTER : The threadid_ptr parameter is null. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is invalid. JVMTI_ERROR_INVALID_THREAD : The thread is not valid. JVMTI_ERROR_THREAD_NOT_ALIVE : The VM state of the thread is not started or has died. JVMTI_ERROR_UNATTACHED_THREAD : The current thread is not attached to the VM. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI start or live phase. Identifiers JVMTI Extension Function identifier: com.ibm.GetOSThreadID Macro declaration in the ibmjvmti.h file: COM_IBM_GET_OS_THREAD_ID QueryVmDump You can query the VM dump options that are set for a VM by using the QueryVmDump() API: jvmtiError QueryVmDump(jvmtiEnv* jvmti_env, jint buffer_size, void* options_buffer, jint* data_size_ptr) This extension returns a set of dump option specifications as ASCII strings. The syntax of the option string is the same as the -Xdump command-line option, with the initial -Xdump: omitted. See -Xdump . The option strings are separated by newline characters. If the memory buffer is too small to contain the current VM dump option strings, you can expect the following results: The error message JVMTI_ERROR_ILLEGAL_ARGUMENT is returned. The variable for data_size_ptr is set to the required buffer size. Parameters jvmti_env : A pointer to the JVMTI environment. buffer_size : The size of the supplied memory buffer in bytes. options_buffer : A pointer to the supplied memory buffer. data_size_ptr : A pointer to a variable, used to return the total size of the option strings. Returns JVMTI_ERROR_NONE : Success JVMTI_ERROR_NULL_POINTER : The options_buffer or data_size_ptr parameters are null. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is invalid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_NOT_AVAILABLE : The dump configuration is locked because a dump is in progress. JVMTI_ERROR_ILLEGAL_ARGUMENT : The supplied memory buffer in options_buffer is too small. Identifiers JVMTI Extension Function identifier: com.ibm.QueryVmDump Macro declaration in the ibmjvmti.h file: COM_IBM_QUERY_VM_DUMP SetVmDump You can set VM dump options by using the SetVmDump() API: jvmtiError SetVmDump(jvmtiEnv* jvmti_env, char* option) The dump option is passed in as an ASCII character string. Use the same syntax as the -Xdump command-line option, with the initial -Xdump: omitted. See -Xdump . When dumps are in progress, the dump configuration is locked, and calls to SetVmDump() fail with a return value of JVMTI_ERROR_NOT_AVAILABLE . Parameters jvmti_env : A pointer to the JVMTI environment. option : The VM dump option string. Note: On z/OS, you might need to convert the option string from EBCDIC to ASCII before using this JVMTI extension function. Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_NULL_POINTER : The parameter option is null. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is invalid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_NOT_AVAILABLE : The dump configuration is locked because a dump is in progress. JVMTI_ERROR_ILLEGAL_ARGUMENT : The parameter option contains an invalid -Xdump string. Identifiers JVMTI Extension Function identifier: com.ibm.SetVmDump Macro declaration in the ibmjvmti.h file: COM_IBM_SET_VM_DUMP TriggerVmDump You can trigger a VM dump and specify the type of dump you want by using the TriggerVmDump() API: jvmtiError TriggerVmDump(jvmtiEnv* jvmti_env, char* option) Choose the type of dump required by specifying an ASCII string that contains one of the supported dump agent types. See -Xdump . JVMTI events are provided at the start and end of the dump. Parameters jvmti_env : A pointer to the JVMTI environment. option : A pointer to the dump type string, which can be one of the following types: stack java system console tool heap snap ceedump (z/OS only) Note: On z/OS, you might need to convert the option string from EBCDIC to ASCII before using this JVMTI extension function. Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_NULL_POINTER : The option parameter is null. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is invalid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_NOT_AVAILABLE : The dump configuration is locked because a dump is in progress. Identifiers JVMTI Extension Function identifier: com.ibm.TriggerVmDump Macro declaration in the ibmjvmti.h file: COM_IBM_TRIGGER_VM_DUMP ResetVmDump You can reset VM dump options to the values at VM initialization by using the ResetVmDump() API: jvmtiError ResetVmDump(jvmtiEnv* jvmti_env) Parameters jvmti_env : The JVMTI environment pointer. Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is invalid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_NOT_AVAILABLE : The dump configuration is locked because a dump is in progress. Identifiers JVMTI Extension Function identifier: com.ibm.ResetVmDump Macro declaration in the ibmjvmti.h file: COM_IBM_RESET_VM_DUMP VMDumpStart The following JVMTI event function is called when a VM dump starts: void JNICALL VMDumpStart(jvmtiEnv *jvmti_env, JNIEnv* jni_env, char* label, char* event, char* detail) The event function provides the dump file name, the name of the JVMTI event, and the detail string from the dump event. The detail string provides additional information about the event that triggered the dump. This information is the same as the information detailed in the JVMDUMP039I message. For example: JVMDUMP039I Processing dump event \"systhrow\", detail \"java/lang/OutOfMemoryError\" at 2014/10/17 13:31:03 - please wait.\" Parameters jvmti_env : JVMTI environment pointer. jni_env : JNI environment pointer for the thread on which the event occurred. label : The dump file name, including directory path. event : The extension event name, such as com.ibm.VmDumpStart . detail : The dump event detail string. The string can be empty. Returns None VMDumpEnd The following JVMTI event function is called when a VM dump ends: void JNICALL VMDumpEnd(jvmtiEnv *jvmti_env, JNIEnv* jni_env, char* label, char* event, char* detail) The event function provides the dump file name, the name of the JVMTI event, and the detail string from the dump event. The detail string provides additional information about the event that triggered the dump. This information is the same as the information detailed in the JVMDUMP039I message. For example: JVMDUMP039I Processing dump event \"systhrow\", detail \"java/lang/OutOfMemoryError\" at 2014/10/17 13:31:03 - please wait. Parameters jvmti_env : JVMTI environment pointer. jni_env : JNI environment pointer for the thread on which the event occurred. label : The dump file name, including directory path. event : The extension event name com.ibm.VmDumpEnd . detail : The dump event detail string. The string can be empty. Returns None SetVmTrace You can set VM trace options by using the SetVmTrace() API: jvmtiError SetVmTrace(jvmtiEnv* jvmti_env, char* option) The trace option is passed in as an ASCII character string. Use the same syntax as the -Xtrace command-line option, with the initial -Xtrace: omitted. See -Xtrace . Parameters jvmti_env : JVMTI environment pointer. option : Enter the VM trace option string. Note: On z/OS, you might need to convert the option string from EBCDIC to ASCII before using this JVMTI extension function. Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_NULL_POINTER : The option parameter is null. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is invalid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_ILLEGAL_ARGUMENT : The option parameter contains an invalid -Xtrace string. Identifiers JVMTI Extension Function identifier: com.ibm.SetVmTrace Macro declaration in the ibmjvmti.h file: COM_IBM_SET_VM_TRACE RegisterTracePointSubscriber You can subscribe to VM tracepoints by using the RegisterTracePointSubscriber() API: jvmtiError RegisterTracePointSubscriber(jvmtiEnv* jvmti_env, char *description, jvmtiTraceSubscriber subscriber, jvmtiTraceAlarm alarm, void *userData, void **subscriptionID) Parameters jvmti_env : A pointer to the JVMTI environment. description : An ASCII character string that describes the subscriber. subscriber : A function of type jvmtiTraceSubscriber . alarm : A function pointer of type jvmtiTraceAlarm . user_data : A pointer to user data. This pointer is passed to the subscriber and alarm functions each time these functions are called. This pointer can be a null value. subscription_id : A pointer to a subscription identifier. This pointer is returned by the RegisterTracePointSubscriber call if successful. The value must be supplied to a future call to the DeregisterTracePointSubscriber API, which is used to unsubscribe from the VM tracepoint. Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_NULL_POINTER : One of the supplied parameters is null. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is not valid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_NOT_AVAILABLE : VM trace is not available. JVMTI_ERROR_INTERNAL : An internal error occurred. Identifiers JVMTI Extension Function identifier: com.ibm.RegisterTracePointSubscriber Macro declaration in the ibmjvmti.h file: COM_IBM_REGISTER_TRACEPOINT_SUBSCRIBER jvmtiTraceSubscriber function The subscriber function type is defined as follows: typedef jvmtiError (*jvmtiTraceSubscriber)(jvmtiEnv *jvmti_env, void *record, jlong length, void *user_data); The subscriber function must be of type jvmtiTraceSubscriber , which is declared in ibmjvmti.h . This function is called with each tracepoint record that is selected through the -Xtrace:external option. The tracepoint record that is supplied to the subscriber function is valid only for the duration of the function. If the subscriber wants to save the data, the data must be copied elsewhere. If the subscriber function returns an error, the alarm function is called, the subscription is disconnected, and no further tracepoints are sent to the subscriber. Subscriber function parameters jvmti_env : A pointer to the JVMTI environment. record : A UTF-8 string that contains a tracepoint record. length : The number of UTF-8 characters in the tracepoint record. user_data : User data that is supplied when the subscriber is registered. jvmtiTraceAlarm function The alarm function type is defined as follows: typedef jvmtiError (*jvmtiTraceAlarm)(jvmtiEnv *jvmti_env, void *subscription_id, void *user_data); The alarm function must be of type jvmtiTraceAlarm , which is declared in ibmjvmti.h . This function is called if the subscriber function returns an error. Alarm function parameters jvmti_env : A pointer to the JVMTI environment. subscription_id : The subscription identifier. user_data : User data that is supplied when the subscriber is registered. DeregisterTracePointSubscriber You can unsubscribe from VM tracepoints by using the DeregisterTracePointSubscriber() API: jvmtiError DeregisterTracePointSubscriber(jvmtiEnv* jvmti_env, void *userData, void *subscription_id) After the DeregisterTracePointSubscriber() API is called, no further calls are made to the subscriber function. Parameters jvmti_env : A pointer to the JVMTI environment. subscription_id : The subscription identifier that is returned by the call to the RegisterTracePointSubscriber API. Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_NULL_POINTER : The subscription_id parameter is null. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is not valid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. Identifiers JVMTI Extension Function identifier: com.ibm.DeregisterTracePointSubscriber Macro declaration in the ibmjvmti.h file: COM_IBM_DEREGISTER_TRACEPOINT_SUBSCRIBER GetMemoryCategories You can query runtime environment native memory categories by using the GetMemoryCategories() API: jvmtiError GetMemoryCategories(jvmtiEnv* env, jint version, jint max_categories, jvmtiMemoryCategory * categories_buffer, jint * written_count_ptr, jint * total_categories_ptr); You can query the total native memory consumption of the runtime environment for each memory category by using this API. Native memory is memory requested from the operating system using library functions such as malloc() and mmap() . Runtime environment native memory use is grouped under high-level memory categories, as described in the NATIVEMEMINFO section of the Java dump topic. The data returned by the GetMemoryCategories() API is consistent with this format. See Java dump: NATIVEMEMINFO . The extension writes native memory information to a memory buffer specified by the user. Each memory category is recorded as a jvmtiMemoryCategory structure, whose format is defined in ibmjvmti.h . You can use the GetMemoryCategories() API to work out the buffer size you must allocate to hold all memory categories defined inside the VM. To calculate the size, call the API with a null categories_buffer argument and a non-null total_categories_ptr argument. Parameters env : A pointer to the JVMTI environment. version : The version of the jvmtiMemoryCategory structure that you are using. Use COM_IBM_GET_MEMORY_CATEGORIES_VERSION_1 for this argument, unless you must work with an obsolete version of the jvmtiMemoryCategory structure. max_categories : The number of jvmtiMemoryCategory structures that can fit in the categories_buffer memory buffer. categories_buffer : A pointer to the memory buffer for holding the result of the GetMemoryCategories() call. The number of jvmtiMemoryCategory slots available in the categories_buffer memory buffer must be accurately specified with max_categories , otherwise GetMemoryCategories() can overflow the memory buffer. The value can be null. written_count_ptr : A pointer to jint to store the number of jvmtiMemoryCategory structures to be written to the categories_buffer memory buffer. The value can be null. total_categories_ptr : A pointer to jint to store the total number of memory categories declared in the VM. The value can be null. Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_UNSUPPORTED_VERSION : Unrecognized value passed for version. JVMTI_ERROR_ILLEGAL_ARGUMENT : Illegal argument; categories_buffer , count_ptr , and total_categories_ptr all have null values. JVMTI_ERROR_INVALID_ENVIRONMENT : The env parameter is invalid. JVMTI_ERROR_OUT_OF_MEMORY : Memory category data is truncated because max_categories is not large enough. Identifiers JVMTI Extension Function identifier: com.ibm.GetMemoryCategories Macro declaration in the ibmjvmti.h file: COM_IBM_GET_MEMORY_CATEGORIES QueryVmLogOptions You can query VM log options by using the QueryVmLogOptions() API: jvmtiError QueryVmLogOptions(jvmtiEnv* jvmti_env, jint buffer_size, void* options, jint* data_size_ptr) This extension returns the current log options as an ASCII string. The syntax of the string is the same as the -Xsyslog command-line option, with the initial -Xsyslog: omitted. For example, the string \"error,warn\" indicates that the VM is set to log error and warning messages only. For more information, see -Xsyslog . Parameters jvmti_env : A pointer to the JVMTI environment. buffer_size : The size of the supplied memory buffer in bytes. If the memory buffer is too small to contain the current VM log option string, the JVMTI_ERROR_ILLEGAL_ARGUMENT error message is returned. options_buffer : A pointer to the supplied memory buffer. data_size_ptr : A pointer to a variable, used to return the total size of the option string. Returns JVMTI_ERROR_NONE : Success JVMTI_ERROR_NULL_POINTER : The options or data_size_ptr parameters are null. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is invalid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_ILLEGAL_ARGUMENT : The supplied memory buffer is too small. Identifiers JVMTI Extension Function identifier: com.ibm.QueryVmLogOptions Macro declaration in the ibmjvmti.h file: COM_IBM_QUERY_VM_LOG_OPTIONS SetVmLogOptions You can set VM log options by using the SetVmLogOptions() API: jvmtiError SetVmLogOptions(jvmtiEnv* jvmti_env, char* options_buffer) The log option is passed in as an ASCII character string. Use the same syntax as the -Xsyslog command-line option, with the initial -Xsyslog: omitted. For example, to set the VM to log error and warning messages, pass in a string containing \"error,warn\". For more information, see -Xsyslog . Parameters jvmti_env : A pointer to the JVMTI environment. options_buffer : A pointer to memory containing the log option. Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_NULL_POINTER : The parameter option is null. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is invalid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_ILLEGAL_ARGUMENT : The parameter option contains an invalid -Xsyslog string. Identifiers JVMTI Extension Function identifier: com.ibm.SetVmLogOptions Macro declaration in the ibmjvmti.h file: COM_IBM_SET_VM_LOG_OPTIONS IterateSharedCaches You can search for shared classes caches that exist in a specified cache directory by using the IterateSharedCaches() API: jvmtiError IterateSharedCaches(jvmtiEnv* env, jint version, const char *cacheDir, jint flags, jboolean useCommandLineValues, jvmtiIterateSharedCachesCallback callback, void *user_data); Information about the caches is returned in a structure that is populated by a user-specified callback function. You can specify the search directory in two ways: Set the value of useCommandLineValues to true and specify the directory on the command line. If the directory is not specified on the command line, the default location for the platform is used. Set the value of useCommandLineValues to false and use the cacheDir parameter. To accept the default location for the platform, specify cacheDir with a null value. Parameters env : A pointer to the JVMTI environment. version : Version information for IterateSharedCaches , which describes the jvmtiSharedCacheInfo structure passed to the jvmtiIterateSharedCachesCallback function. The values allowed are: COM_IBM_ITERATE_SHARED_CACHES_VERSION_1 COM_IBM_ITERATE_SHARED_CACHES_VERSION_2 COM_IBM_ITERATE_SHARED_CACHES_VERSION_3 COM_IBM_ITERATE_SHARED_CACHES_VERSION_4 COM_IBM_ITERATE_SHARED_CACHES_VERSION_5 cacheDir : When the value of useCommandLineValues is false , specify the absolute path of the directory for the shared classes cache. If the value is null , the platform-dependent default is used. flags : Reserved for future use. The only value allowed is COM_IBM_ITERATE_SHARED_CACHES_NO_FLAGS . useCommandLineValues : Set this value to true when you want to specify the cache directory on the command line. Set this value to false when you want to use the cacheDir parameter. callback : A function pointer to a user provided callback routine jvmtiIterateSharedCachesCallback . user_data : User supplied data, passed as an argument to the callback function. jint (JNICALL *jvmtiIterateSharedCachesCallback)(jvmtiEnv *env,jvmtiSharedCacheInfo *cache_info, void *user_data); Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The env parameter is not valid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_UNSUPPORTED_VERSION : The version parameter is not valid. JVMTI_ERROR_NULL_POINTER : The callback parameter is null. JVMTI_ERROR_NOT_AVAILABLE : The shared classes feature is not enabled in the VM. JVMTI_ERROR_ILLEGAL_ARGUMENT : The flags parameter is not valid. JVMTI_ERROR_INTERNAL : This error is returned when the jvmtiIterateSharedCachesCallback returns JNI_ERR . Identifiers JVMTI Extension Function identifier: com.ibm.IterateSharedCaches Macro declaration in the ibmjvmti.h file: COM_IBM_ITERATE_SHARED_CACHES jvmtiIterateSharedCachesCallback function Callback function parameters env : A pointer to the JVMTI environment when calling COM_IBM_ITERATE_SHARED_CACHES . cache_info : A jvmtiSharedCacheInfo structure containing information about a shared cache. user_data : User-supplied data, passed as an argument to IterateSharedCaches . Callback function returns JNI_OK : Continue iterating. JNI_ERR : Stop iterating, which causes IterateSharedCaches to return JVMTI_ERROR_INTERNAL jvmtiSharedCacheInfo structure The structure of jvmtiSharedCacheInfo typedef struct jvmtiSharedCacheInfo { const char *name; // the name of the shared cache jboolean isCompatible; // if the shared cache is compatible with this VM jboolean isPersistent; // true if the shared cache is persistent, false if its non-persistent jint os_shmid; // the OS shared memory ID associated with a non-persistent cache, -1 otherwise jint os_semid; // the OS shared semaphore ID associated with a non-persistent cache, -1 otherwise jint modLevel; // one of: // COM_IBM_SHARED_CACHE_MODLEVEL_JAVA5 // COM_IBM_SHARED_CACHE_MODLEVEL_JAVA6 // COM_IBM_SHARED_CACHE_MODLEVEL_JAVA7 // COM_IBM_SHARED_CACHE_MODLEVEL_JAVA8 // COM_IBM_SHARED_CACHE_MODLEVEL_JAVA9 // from Java 10: the version number of the Java level on which the shared cache is created jint addrMode; // the address mode of the VM creating the shared cache: includes additional // information on whether it is a 64-bit compressedRefs cache when // COM_IBM_ITERATE_SHARED_CACHES_VERSION_3 or later is specified. jboolean isCorrupt; // if the cache is corrupted jlong cacheSize; // the total usable shared classes cache size, or -1 when isCompatible is false jlong freeBytes; // the number of free bytes in the shared classes cache, or -1 when isCompatible is false jlong lastDetach; // the last detach time specified in milliseconds since 00:00:00 on 1 January 1970 UTC, // or -1 when the last detach time is not available jint cacheType; // the type of the cache jlong softMaxBytes; // the soft limit for the available space in the cache jint layer; // the shared cache layer number } jvmtiSharedCacheInfo; Notes: The field cacheType is included when COM_IBM_ITERATE_SHARED_CACHES_VERSION_2 or later is specified. jvmtiSharedCacheInfo.addrMode encodes both address mode and the compressed reference mode when COM_IBM_ITERATE_SHARED_CACHES_VERSION_3 or later is specified. In this case, use the following set of macros to access the address mode and compressed reference mode: To get the address mode, use: COM_IBM_ITERATE_SHARED_CACHES_GET_ADDR_MODE(jvmtiSharedCacheInfo.addrMode) This macro returns one of the following values: COM_IBM_SHARED_CACHE_ADDRMODE_32 COM_IBM_SHARED_CACHE_ADDRMODE_64 To get the compressed references mode, use: COM_IBM_ITERATE_SHARED_CACHES_GET_CMPRSSREF_MODE(jvmtiSharedCacheInfo.addrMode) This macro returns one of the following values: COM_IBM_ITERATE_SHARED_CACHES_UNKNOWN_COMPRESSED_POINTERS_MODE COM_IBM_ITERATE_SHARED_CACHES_COMPRESSED_POINTERS_MODE COM_IBM_ITERATE_SHARED_CACHES_NON_COMPRESSED_POINTERS_MODE The field softMaxBytes is included when COM_IBM_ITERATE_SHARED_CACHES_VERSION_4 or later is specified. The field layer is included when COM_IBM_ITERATE_SHARED_CACHES_VERSION_5 or later is specified. If the shared cache does not have a layer number, the value for layer is -1 . DestroySharedCache You can remove a shared classes cache by using the DestroySharedCache() API: jvmtiError DestroySharedCache(jvmtiEnv *env, const char *cacheDir, const char *name, jint persistence, jboolean useCommandLineValues, jint *internalErrorCode); This extension removes a named shared classes cache of a given persistence type, in a given directory. You can specify the cache name, persistence type, and directory in one of these ways: Set useCommandLineValues to true and specify the values on the command line. If a value is not available, the default values for the platform are used. Set useCommandLineValues to false and use the cacheDir , persistence and cacheName parameters to identify the cache to be removed. To accept the default value for cacheDir or cacheName , specify the parameter with a null value. Parameters env : A pointer to the JVMTI environment. cacheDir : When the value of useCommandLineValues is false , specify the absolute path of the directory for the shared classes cache. If the value is null , the platform-dependent default is used. cacheName : When the value of useCommandLineValues is false , specify the name of the cache to be removed. If the value is null , the platform-dependent default is used. persistence : When the value of useCommandLineValues is false, specify the type of cache to remove. This parameter must have one of the following values: PERSISTENCE_DEFAULT (The default value for the platform). PERSISTENT NONPERSISTENT useCommandLineValues : Set this value to true when you want to specify the shared classes cache name, persistence type, and directory on the command line. Set this value to false when you want to use the cacheDir , persistence , and cacheName parameters instead. internalErrorCode : If not null , this value is set to one of the following constants when JVMTI_ERROR_INTERNAL is returned: COM_IBM_DESTROYED_ALL_CACHE : Set when JVMTI_ERROR_NONE is returned. COM_IBM_DESTROYED_NONE : Set when the function fails to remove any caches. COM_IBM_DESTROY_FAILED_CURRENT_GEN_CACHE : Set when the function fails to remove the existing current generation cache, irrespective of the state of older generation caches. COM_IBM_DESTROY_FAILED_OLDER_GEN_CACHE : Set when the function fails to remove any older generation caches. The current generation cache does not exist or is successfully removed. Returns JVMTI_ERROR_NONE : Success. No cache exists or all existing caches of all generations are removed. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The env parameter is not valid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_NOT_AVAILABLE : The shared classes feature is not enabled in the VM. JVMTI_ERROR_ILLEGAL_ARGUMENT : The persistence parameter is not valid. JVMTI_ERROR_INTERNAL : Failed to remove any existing cache with the given name. See the value of the internalErrorCode parameter for more information about the failure. Identifiers JVMTI Extension Function identifier: com.ibm.DestroySharedCache Macro declaration in the ibmjvmti.h file: COM_IBM_DESTROY_SHARED_CACHE RegisterVerboseGCSubscriber You can subscribe to verbose garbage collection (GC) data logging by using the RegisterVerboseGCSubscriber() API: jvmtiError RegisterVerboseGCSubscriber(jvmtiEnv* jvmti_env, char *description, jvmtiVerboseGCSubscriber subscriber, jvmtiVerboseGCAlarm alarm, void *user_data, void **subscription_id) Parameters jvmti_env : A pointer to the JVMTI environment. description : An ASCII character string that describes the subscriber. subscriber : A function of type jvmtiVerboseGCSubscriber . alarm : A function pointer of type jvmtiVerboseGCAlarm . user_data : A pointer to user data. This pointer is passed to the subscriber and alarm functions each time these functions are called. This pointer can be a null value. subscription_id : A pointer to a subscription identifier. This pointer is returned by the RegisterVerboseGCSubscriber call if successful. The value must be supplied to a future call to DeregisterVerboseGCSubscriber API, which is used to unsubscribe from verbose GC data logging. Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_NULL_POINTER : One of the supplied parameters is null. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is not valid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_NOT_AVAILABLE : GC verbose logging is not available. JVMTI_ERROR_INTERNAL : An internal error has occurred. Identifiers JVMTI Extension Function identifier: com.ibm.RegisterVerboseGCSubscriber Macro declaration in the ibmjvmti.h file: COM_IBM_REGISTER_VERBOSEGC_SUBSCRIBER jvmtiVerboseGCSubscriber function The subscriber function type is defined as follows: typedef jvmtiError (*jvmtiVerboseGCSubscriber)(jvmtiEnv *jvmti_env, const char *record, jlong length, void *user_data); The subscriber function must be of type jvmtiVerboseGCSubscriber , which is declared in ibmjvmti.h . This function is called with each record of verbose logging data produced by the VM. The verbose logging record supplied to the subscriber function is valid only for the duration of the function. If the subscriber wants to save the data, the data must be copied elsewhere. If the subscriber function returns an error, the alarm function is called, and the subscription is deregistered. Subscriber function parameters jvmti_env : A pointer to the JVMTI environment. record : An ASCII string that contains a verbose log record. length : The number of ASCII characters in the verbose log record. user_data : User data supplied when the subscriber is registered. jvmtiVerboseGCAlarm function The alarm function type is defined as follows: typedef jvmtiError (*jvmtiVerboseGCAlarm)(jvmtiEnv *jvmti_env, void *subscription_id, void *user_data); The alarm function must be of type jvmtiVerboseGCAlarm , which is declared in ibmjvmti.h . This function is called if the subscriber function returns an error. Alarm function parameters jvmti_env : A pointer to the JVMTI environment. user_data : User data supplied when the subscriber is registered. subscription_id : The subscription identifier. DeregisterVerboseGCSubscriber You can unsubscribe from verbose Garbage Collection (GC) data logging by using the DeregisterVerboseGCSubscriber() API: jvmtiError DeregisterVerboseGCSubscriber(jvmtiEnv* jvmti_env, void *userData, void *subscription_id) After the DeregisterVerboseGCSubscriber() API is called, no further calls are made to the previously registered subscriber function. Parameters jvmti_env : A pointer to the JVMTI environment. subscription_id : The subscription identifier that is returned by the call to the RegisterVerboseGCSubscriber() API. Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_NULL_POINTER : The subscription_id parameter is null. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is not valid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. Identifiers JVMTI Extension Function identifier: com.ibm.DeregisterVerboseGCSubscriber Macro declaration in the ibmjvmti.h file: COM_IBM_DEREGISTER_VERBOSEGC_SUBSCRIBER","title":"JVMTI"},{"location":"interface_jvmti/#java-virtual-machine-tool-interface","text":"The Java\u2122 Virtual Machine Tool Interface (JVMTI) is a two-way interface that allows communication between the VM and a native agent. It replaces both the Java Virtual Machine Debug Interface (JVMDI) and Java Virtual Machine Profiler Interface (JVMPI).","title":"Java Virtual Machine Tool Interface"},{"location":"interface_jvmti/#overview","text":"The JVMTI allows third parties to develop debugging, profiling, and monitoring tools for the VM. The interface contains mechanisms for the agent to notify the VM about the kinds of information it requires, and also provides a means of receiving relevant notifications. Several agents can be attached to a VM at any one time. JVMTI agents can be loaded at startup using short or long forms of the command-line option: -agentlib:<agent-lib-name>=<options> or -agentpath:<path-to-agent>=<options> In the example that follows (see Sample JVMTI agent ), the directory containing the jdwp library is assumed to be on the library path. If you require a specific library, such as jdwp , with your JVMTI agent, you can specify the path at startup, for example: -agentlib:jdwp=<options> For more information about JVMTI, see https://docs.oracle.com/javase/8/docs/technotes/guides/management/index.html . For a guide about writing a JVMTI agent, see http://www.oracle.com/technetwork/articles/javase/jvmti-136367.html .","title":"Overview"},{"location":"interface_jvmti/#openj9-extensions","text":"OpenJ9 extensions to the JVMTI allow a JVMTI agent to query or automatically trigger operations in the VM, including the following tasks: Task OpenJ9 extensions Get the OS thread ID GetOSThreadID Query, set, and reset the VM dump options QueryVmDump , SetVmDump , ResetVmDump Trigger a VM dump, and monitor JVMTI event functions when VM dumps start and end TriggerVmDump , VMDumpStart , VMDumpEnd Set VM trace options SetVmTrace Subscribe to and unsubscribe from VM tracepoints RegisterTracePointSubscriber , DeregisterTracePointSubscriber Query runtime environment native memory categories GetMemoryCategories Query and set VM log options QueryVmLogOptions , SetVmLogOptions Search for and remove a shared classes cache IterateSharedCaches , DestroySharedCache Subscribe to and unsubscribe from verbose garbage collection (GC) data logging RegisterVerboseGCSubscriber , DeregisterVerboseGCSubscriber The definitions that you need when you write a JVMTI agent are provided in the header files jvmti.h and ibmjvmti.h , in the include directory.","title":"OpenJ9 extensions"},{"location":"interface_jvmti/#sample-jvmti-agent","text":"The following sample shows you how to write a simple JVMTI agent that uses OpenJ9 extensions to the JVMTI. Sample JVMTI agent written in C/C++, which uses the OpenJ9 extensions /* * tiSample.c * * Sample JVMTI agent to demonstrate the OpenJ9 JVMTI dump extensions */ #include \"jvmti.h\" #include \"ibmjvmti.h\" /* Forward declarations for JVMTI callback functions */ void JNICALL VMInitCallback(jvmtiEnv *jvmti_env, JNIEnv* jni_env, jthread thread); void JNICALL DumpStartCallback(jvmtiEnv *jvmti_env, char* label, char* event, char* detail, ...); /* * Agent_Onload() * * JVMTI agent initialisation function, invoked as agent is loaded by the VM */ JNIEXPORT jint JNICALL Agent_OnLoad(JavaVM *jvm, char *options, void *reserved) { jvmtiEnv *jvmti = NULL; jvmtiError rc; jint extensionEventCount = 0; jvmtiExtensionEventInfo *extensionEvents = NULL; jint extensionFunctionCount = 0; jvmtiExtensionFunctionInfo *extensionFunctions = NULL; int i = 0, j = 0; printf(\"tiSample: Loading JVMTI sample agent\\n\"); /* Get access to JVMTI */ (*jvm)->GetEnv(jvm, (void **)&jvmti, JVMTI_VERSION_1_0); /* Look up all the JVMTI extension events and functions */ (*jvmti)->GetExtensionEvents(jvmti, &extensionEventCount, &extensionEvents); (*jvmti)->GetExtensionFunctions(jvmti, &extensionFunctionCount, &extensionFunctions); printf(\"tiSample: Found %i JVMTI extension events, %i extension functions\\n\", extensionEventCount, extensionFunctionCount); /* Find the JVMTI extension event we want */ while (i++ < extensionEventCount) { if (strcmp(extensionEvents->id, COM_IBM_VM_DUMP_START) == 0) { /* Found the dump start extension event, now set up a callback for it */ rc = (*jvmti)->SetExtensionEventCallback(jvmti, extensionEvents->extension_event_index, &DumpStartCallback); printf(\"tiSample: Setting JVMTI event callback %s, rc=%i\\n\", COM_IBM_VM_DUMP_START, rc); break; } extensionEvents++; /* move on to the next extension event */ } /* Find the JVMTI extension function we want */ while (j++ < extensionFunctionCount) { jvmtiExtensionFunction function = extensionFunctions->func; if (strcmp(extensionFunctions->id, COM_IBM_SET_VM_DUMP) == 0) { /* Found the set dump extension function, now set a dump option to generate javadumps on thread starts */ rc = function(jvmti, \"java:events=thrstart\"); printf(\"tiSample: Calling JVMTI extension %s, rc=%i\\n\", COM_IBM_SET_VM_DUMP, rc); break; } extensionFunctions++; /* move on to the next extension function */ } return JNI_OK; } /* * DumpStartCallback() * JVMTI callback for dump start event (IBM JVMTI extension) */ void JNICALL DumpStartCallback(jvmtiEnv *jvmti_env, char* label, char* event, char* detail, ...) { printf(\"tiSample: Received JVMTI event callback, for event %s\\n\", event); } The sample JVMTI agent consists of two functions, Agent_OnLoad() and DumpStartCallback() :","title":"Sample JVMTI agent"},{"location":"interface_jvmti/#agent_onload","text":"This function is called by the VM when the agent is loaded at VM startup, which allows the JVMTI agent to modify VM behavior before initialization is complete. The sample agent obtains access to the JVMTI interface by using the JNI Invocation API function GetEnv() . The agent calls the APIs GetExtensionEvents() and GetExtensionFunctions() to find the JVMTI extensions that are supported by the VM. These APIs provide access to the list of extensions available in the jvmtiExtensionEventInfo and jvmtiExtensionFunctionInfo structures. The sample uses an extension event and an extension function in the following way: Extension event: The sample JVMTI agent searches for the extension event VmDumpStart in the list of jvmtiExtensionEventInfo structures, by using the identifier COM_IBM_VM_DUMP_START provided in ibmjvmti.h . When the event is found, the JVMTI agent calls the JVMTI interface SetExtensionEventCallback() to enable the event, providing a function DumpStartCallback() that is called when the event is triggered. Extension function: Next, the sample JVMTI agent searches for the extension function SetVMDump in the list of jvmtiExtensionFunctionInfo structures, by using the identifier COM_IBM_SET_VM_DUMP provided in ibmjvmti.h . The JVMTI agent calls the function by using the jvmtiExtensionFunction pointer to set a VM dump option java:events=thrstart . This option requests the VM to trigger a Java dump every time a VM thread is started.","title":"Agent_OnLoad()"},{"location":"interface_jvmti/#dumpstartcallback","text":"This callback function issues a message when the associated extension event is called. In the sample code, DumpStartCallback() is used when the VmDumpStart event is triggered.","title":"DumpStartCallback()"},{"location":"interface_jvmti/#using-the-sample-jvmti-agent","text":"Build the sample JVMTI agent: Windows: cl /I<jre_path>\\include /MD /FetiSample.dll tiSample.c /link /DLL Linux, AIX\u00ae, and z/OS\u00ae: gcc -I<jre_path>/include -o libtiSample.so -shared tiSample.c where <jre_path> is the path to your Java runtime environment installation. To run the sample JVMTI agent, use the command: java -agentlib:tiSample -version When the sample JVMTI agent loads, messages are generated. When the JVMTI agent initiates a Java dump, the message JVMDUMP010 is issued.","title":"Using the sample JVMTI agent"},{"location":"interface_jvmti/#api-reference","text":"The following sections provide reference information for the OpenJ9 extensions to the JVMTI.","title":"API reference"},{"location":"interface_jvmti/#getosthreadid","text":"You can get the OS thread ID by using the GetOSThreadID() API: jvmtiError GetOSThreadID(jvmtiEnv* jvmti_env, jthread thread, jlong * threadid_ptr); Parameters jvmti_env : A pointer to the JVMTI environment. thread : The thread for which the ID is required. threadid_ptr : A pointer to a variable, used to return the thread ID that corresponds to the thread specified by the thread parameter. Returns JVMTI_ERROR_NONE : Success JVMTI_ERROR_NULL_POINTER : The threadid_ptr parameter is null. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is invalid. JVMTI_ERROR_INVALID_THREAD : The thread is not valid. JVMTI_ERROR_THREAD_NOT_ALIVE : The VM state of the thread is not started or has died. JVMTI_ERROR_UNATTACHED_THREAD : The current thread is not attached to the VM. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI start or live phase. Identifiers JVMTI Extension Function identifier: com.ibm.GetOSThreadID Macro declaration in the ibmjvmti.h file: COM_IBM_GET_OS_THREAD_ID","title":"GetOSThreadID"},{"location":"interface_jvmti/#queryvmdump","text":"You can query the VM dump options that are set for a VM by using the QueryVmDump() API: jvmtiError QueryVmDump(jvmtiEnv* jvmti_env, jint buffer_size, void* options_buffer, jint* data_size_ptr) This extension returns a set of dump option specifications as ASCII strings. The syntax of the option string is the same as the -Xdump command-line option, with the initial -Xdump: omitted. See -Xdump . The option strings are separated by newline characters. If the memory buffer is too small to contain the current VM dump option strings, you can expect the following results: The error message JVMTI_ERROR_ILLEGAL_ARGUMENT is returned. The variable for data_size_ptr is set to the required buffer size. Parameters jvmti_env : A pointer to the JVMTI environment. buffer_size : The size of the supplied memory buffer in bytes. options_buffer : A pointer to the supplied memory buffer. data_size_ptr : A pointer to a variable, used to return the total size of the option strings. Returns JVMTI_ERROR_NONE : Success JVMTI_ERROR_NULL_POINTER : The options_buffer or data_size_ptr parameters are null. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is invalid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_NOT_AVAILABLE : The dump configuration is locked because a dump is in progress. JVMTI_ERROR_ILLEGAL_ARGUMENT : The supplied memory buffer in options_buffer is too small. Identifiers JVMTI Extension Function identifier: com.ibm.QueryVmDump Macro declaration in the ibmjvmti.h file: COM_IBM_QUERY_VM_DUMP","title":"QueryVmDump"},{"location":"interface_jvmti/#setvmdump","text":"You can set VM dump options by using the SetVmDump() API: jvmtiError SetVmDump(jvmtiEnv* jvmti_env, char* option) The dump option is passed in as an ASCII character string. Use the same syntax as the -Xdump command-line option, with the initial -Xdump: omitted. See -Xdump . When dumps are in progress, the dump configuration is locked, and calls to SetVmDump() fail with a return value of JVMTI_ERROR_NOT_AVAILABLE . Parameters jvmti_env : A pointer to the JVMTI environment. option : The VM dump option string. Note: On z/OS, you might need to convert the option string from EBCDIC to ASCII before using this JVMTI extension function. Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_NULL_POINTER : The parameter option is null. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is invalid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_NOT_AVAILABLE : The dump configuration is locked because a dump is in progress. JVMTI_ERROR_ILLEGAL_ARGUMENT : The parameter option contains an invalid -Xdump string. Identifiers JVMTI Extension Function identifier: com.ibm.SetVmDump Macro declaration in the ibmjvmti.h file: COM_IBM_SET_VM_DUMP","title":"SetVmDump"},{"location":"interface_jvmti/#triggervmdump","text":"You can trigger a VM dump and specify the type of dump you want by using the TriggerVmDump() API: jvmtiError TriggerVmDump(jvmtiEnv* jvmti_env, char* option) Choose the type of dump required by specifying an ASCII string that contains one of the supported dump agent types. See -Xdump . JVMTI events are provided at the start and end of the dump. Parameters jvmti_env : A pointer to the JVMTI environment. option : A pointer to the dump type string, which can be one of the following types: stack java system console tool heap snap ceedump (z/OS only) Note: On z/OS, you might need to convert the option string from EBCDIC to ASCII before using this JVMTI extension function. Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_NULL_POINTER : The option parameter is null. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is invalid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_NOT_AVAILABLE : The dump configuration is locked because a dump is in progress. Identifiers JVMTI Extension Function identifier: com.ibm.TriggerVmDump Macro declaration in the ibmjvmti.h file: COM_IBM_TRIGGER_VM_DUMP","title":"TriggerVmDump"},{"location":"interface_jvmti/#resetvmdump","text":"You can reset VM dump options to the values at VM initialization by using the ResetVmDump() API: jvmtiError ResetVmDump(jvmtiEnv* jvmti_env) Parameters jvmti_env : The JVMTI environment pointer. Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is invalid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_NOT_AVAILABLE : The dump configuration is locked because a dump is in progress. Identifiers JVMTI Extension Function identifier: com.ibm.ResetVmDump Macro declaration in the ibmjvmti.h file: COM_IBM_RESET_VM_DUMP","title":"ResetVmDump"},{"location":"interface_jvmti/#vmdumpstart","text":"The following JVMTI event function is called when a VM dump starts: void JNICALL VMDumpStart(jvmtiEnv *jvmti_env, JNIEnv* jni_env, char* label, char* event, char* detail) The event function provides the dump file name, the name of the JVMTI event, and the detail string from the dump event. The detail string provides additional information about the event that triggered the dump. This information is the same as the information detailed in the JVMDUMP039I message. For example: JVMDUMP039I Processing dump event \"systhrow\", detail \"java/lang/OutOfMemoryError\" at 2014/10/17 13:31:03 - please wait.\" Parameters jvmti_env : JVMTI environment pointer. jni_env : JNI environment pointer for the thread on which the event occurred. label : The dump file name, including directory path. event : The extension event name, such as com.ibm.VmDumpStart . detail : The dump event detail string. The string can be empty. Returns None","title":"VMDumpStart"},{"location":"interface_jvmti/#vmdumpend","text":"The following JVMTI event function is called when a VM dump ends: void JNICALL VMDumpEnd(jvmtiEnv *jvmti_env, JNIEnv* jni_env, char* label, char* event, char* detail) The event function provides the dump file name, the name of the JVMTI event, and the detail string from the dump event. The detail string provides additional information about the event that triggered the dump. This information is the same as the information detailed in the JVMDUMP039I message. For example: JVMDUMP039I Processing dump event \"systhrow\", detail \"java/lang/OutOfMemoryError\" at 2014/10/17 13:31:03 - please wait. Parameters jvmti_env : JVMTI environment pointer. jni_env : JNI environment pointer for the thread on which the event occurred. label : The dump file name, including directory path. event : The extension event name com.ibm.VmDumpEnd . detail : The dump event detail string. The string can be empty. Returns None","title":"VMDumpEnd"},{"location":"interface_jvmti/#setvmtrace","text":"You can set VM trace options by using the SetVmTrace() API: jvmtiError SetVmTrace(jvmtiEnv* jvmti_env, char* option) The trace option is passed in as an ASCII character string. Use the same syntax as the -Xtrace command-line option, with the initial -Xtrace: omitted. See -Xtrace . Parameters jvmti_env : JVMTI environment pointer. option : Enter the VM trace option string. Note: On z/OS, you might need to convert the option string from EBCDIC to ASCII before using this JVMTI extension function. Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_NULL_POINTER : The option parameter is null. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is invalid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_ILLEGAL_ARGUMENT : The option parameter contains an invalid -Xtrace string. Identifiers JVMTI Extension Function identifier: com.ibm.SetVmTrace Macro declaration in the ibmjvmti.h file: COM_IBM_SET_VM_TRACE","title":"SetVmTrace"},{"location":"interface_jvmti/#registertracepointsubscriber","text":"You can subscribe to VM tracepoints by using the RegisterTracePointSubscriber() API: jvmtiError RegisterTracePointSubscriber(jvmtiEnv* jvmti_env, char *description, jvmtiTraceSubscriber subscriber, jvmtiTraceAlarm alarm, void *userData, void **subscriptionID) Parameters jvmti_env : A pointer to the JVMTI environment. description : An ASCII character string that describes the subscriber. subscriber : A function of type jvmtiTraceSubscriber . alarm : A function pointer of type jvmtiTraceAlarm . user_data : A pointer to user data. This pointer is passed to the subscriber and alarm functions each time these functions are called. This pointer can be a null value. subscription_id : A pointer to a subscription identifier. This pointer is returned by the RegisterTracePointSubscriber call if successful. The value must be supplied to a future call to the DeregisterTracePointSubscriber API, which is used to unsubscribe from the VM tracepoint. Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_NULL_POINTER : One of the supplied parameters is null. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is not valid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_NOT_AVAILABLE : VM trace is not available. JVMTI_ERROR_INTERNAL : An internal error occurred. Identifiers JVMTI Extension Function identifier: com.ibm.RegisterTracePointSubscriber Macro declaration in the ibmjvmti.h file: COM_IBM_REGISTER_TRACEPOINT_SUBSCRIBER","title":"RegisterTracePointSubscriber"},{"location":"interface_jvmti/#jvmtitracesubscriber-function","text":"The subscriber function type is defined as follows: typedef jvmtiError (*jvmtiTraceSubscriber)(jvmtiEnv *jvmti_env, void *record, jlong length, void *user_data); The subscriber function must be of type jvmtiTraceSubscriber , which is declared in ibmjvmti.h . This function is called with each tracepoint record that is selected through the -Xtrace:external option. The tracepoint record that is supplied to the subscriber function is valid only for the duration of the function. If the subscriber wants to save the data, the data must be copied elsewhere. If the subscriber function returns an error, the alarm function is called, the subscription is disconnected, and no further tracepoints are sent to the subscriber. Subscriber function parameters jvmti_env : A pointer to the JVMTI environment. record : A UTF-8 string that contains a tracepoint record. length : The number of UTF-8 characters in the tracepoint record. user_data : User data that is supplied when the subscriber is registered.","title":"jvmtiTraceSubscriber function"},{"location":"interface_jvmti/#jvmtitracealarm-function","text":"The alarm function type is defined as follows: typedef jvmtiError (*jvmtiTraceAlarm)(jvmtiEnv *jvmti_env, void *subscription_id, void *user_data); The alarm function must be of type jvmtiTraceAlarm , which is declared in ibmjvmti.h . This function is called if the subscriber function returns an error. Alarm function parameters jvmti_env : A pointer to the JVMTI environment. subscription_id : The subscription identifier. user_data : User data that is supplied when the subscriber is registered.","title":"jvmtiTraceAlarm function"},{"location":"interface_jvmti/#deregistertracepointsubscriber","text":"You can unsubscribe from VM tracepoints by using the DeregisterTracePointSubscriber() API: jvmtiError DeregisterTracePointSubscriber(jvmtiEnv* jvmti_env, void *userData, void *subscription_id) After the DeregisterTracePointSubscriber() API is called, no further calls are made to the subscriber function. Parameters jvmti_env : A pointer to the JVMTI environment. subscription_id : The subscription identifier that is returned by the call to the RegisterTracePointSubscriber API. Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_NULL_POINTER : The subscription_id parameter is null. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is not valid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. Identifiers JVMTI Extension Function identifier: com.ibm.DeregisterTracePointSubscriber Macro declaration in the ibmjvmti.h file: COM_IBM_DEREGISTER_TRACEPOINT_SUBSCRIBER","title":"DeregisterTracePointSubscriber"},{"location":"interface_jvmti/#getmemorycategories","text":"You can query runtime environment native memory categories by using the GetMemoryCategories() API: jvmtiError GetMemoryCategories(jvmtiEnv* env, jint version, jint max_categories, jvmtiMemoryCategory * categories_buffer, jint * written_count_ptr, jint * total_categories_ptr); You can query the total native memory consumption of the runtime environment for each memory category by using this API. Native memory is memory requested from the operating system using library functions such as malloc() and mmap() . Runtime environment native memory use is grouped under high-level memory categories, as described in the NATIVEMEMINFO section of the Java dump topic. The data returned by the GetMemoryCategories() API is consistent with this format. See Java dump: NATIVEMEMINFO . The extension writes native memory information to a memory buffer specified by the user. Each memory category is recorded as a jvmtiMemoryCategory structure, whose format is defined in ibmjvmti.h . You can use the GetMemoryCategories() API to work out the buffer size you must allocate to hold all memory categories defined inside the VM. To calculate the size, call the API with a null categories_buffer argument and a non-null total_categories_ptr argument. Parameters env : A pointer to the JVMTI environment. version : The version of the jvmtiMemoryCategory structure that you are using. Use COM_IBM_GET_MEMORY_CATEGORIES_VERSION_1 for this argument, unless you must work with an obsolete version of the jvmtiMemoryCategory structure. max_categories : The number of jvmtiMemoryCategory structures that can fit in the categories_buffer memory buffer. categories_buffer : A pointer to the memory buffer for holding the result of the GetMemoryCategories() call. The number of jvmtiMemoryCategory slots available in the categories_buffer memory buffer must be accurately specified with max_categories , otherwise GetMemoryCategories() can overflow the memory buffer. The value can be null. written_count_ptr : A pointer to jint to store the number of jvmtiMemoryCategory structures to be written to the categories_buffer memory buffer. The value can be null. total_categories_ptr : A pointer to jint to store the total number of memory categories declared in the VM. The value can be null. Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_UNSUPPORTED_VERSION : Unrecognized value passed for version. JVMTI_ERROR_ILLEGAL_ARGUMENT : Illegal argument; categories_buffer , count_ptr , and total_categories_ptr all have null values. JVMTI_ERROR_INVALID_ENVIRONMENT : The env parameter is invalid. JVMTI_ERROR_OUT_OF_MEMORY : Memory category data is truncated because max_categories is not large enough. Identifiers JVMTI Extension Function identifier: com.ibm.GetMemoryCategories Macro declaration in the ibmjvmti.h file: COM_IBM_GET_MEMORY_CATEGORIES","title":"GetMemoryCategories"},{"location":"interface_jvmti/#queryvmlogoptions","text":"You can query VM log options by using the QueryVmLogOptions() API: jvmtiError QueryVmLogOptions(jvmtiEnv* jvmti_env, jint buffer_size, void* options, jint* data_size_ptr) This extension returns the current log options as an ASCII string. The syntax of the string is the same as the -Xsyslog command-line option, with the initial -Xsyslog: omitted. For example, the string \"error,warn\" indicates that the VM is set to log error and warning messages only. For more information, see -Xsyslog . Parameters jvmti_env : A pointer to the JVMTI environment. buffer_size : The size of the supplied memory buffer in bytes. If the memory buffer is too small to contain the current VM log option string, the JVMTI_ERROR_ILLEGAL_ARGUMENT error message is returned. options_buffer : A pointer to the supplied memory buffer. data_size_ptr : A pointer to a variable, used to return the total size of the option string. Returns JVMTI_ERROR_NONE : Success JVMTI_ERROR_NULL_POINTER : The options or data_size_ptr parameters are null. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is invalid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_ILLEGAL_ARGUMENT : The supplied memory buffer is too small. Identifiers JVMTI Extension Function identifier: com.ibm.QueryVmLogOptions Macro declaration in the ibmjvmti.h file: COM_IBM_QUERY_VM_LOG_OPTIONS","title":"QueryVmLogOptions"},{"location":"interface_jvmti/#setvmlogoptions","text":"You can set VM log options by using the SetVmLogOptions() API: jvmtiError SetVmLogOptions(jvmtiEnv* jvmti_env, char* options_buffer) The log option is passed in as an ASCII character string. Use the same syntax as the -Xsyslog command-line option, with the initial -Xsyslog: omitted. For example, to set the VM to log error and warning messages, pass in a string containing \"error,warn\". For more information, see -Xsyslog . Parameters jvmti_env : A pointer to the JVMTI environment. options_buffer : A pointer to memory containing the log option. Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_NULL_POINTER : The parameter option is null. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is invalid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_ILLEGAL_ARGUMENT : The parameter option contains an invalid -Xsyslog string. Identifiers JVMTI Extension Function identifier: com.ibm.SetVmLogOptions Macro declaration in the ibmjvmti.h file: COM_IBM_SET_VM_LOG_OPTIONS","title":"SetVmLogOptions"},{"location":"interface_jvmti/#iteratesharedcaches","text":"You can search for shared classes caches that exist in a specified cache directory by using the IterateSharedCaches() API: jvmtiError IterateSharedCaches(jvmtiEnv* env, jint version, const char *cacheDir, jint flags, jboolean useCommandLineValues, jvmtiIterateSharedCachesCallback callback, void *user_data); Information about the caches is returned in a structure that is populated by a user-specified callback function. You can specify the search directory in two ways: Set the value of useCommandLineValues to true and specify the directory on the command line. If the directory is not specified on the command line, the default location for the platform is used. Set the value of useCommandLineValues to false and use the cacheDir parameter. To accept the default location for the platform, specify cacheDir with a null value. Parameters env : A pointer to the JVMTI environment. version : Version information for IterateSharedCaches , which describes the jvmtiSharedCacheInfo structure passed to the jvmtiIterateSharedCachesCallback function. The values allowed are: COM_IBM_ITERATE_SHARED_CACHES_VERSION_1 COM_IBM_ITERATE_SHARED_CACHES_VERSION_2 COM_IBM_ITERATE_SHARED_CACHES_VERSION_3 COM_IBM_ITERATE_SHARED_CACHES_VERSION_4 COM_IBM_ITERATE_SHARED_CACHES_VERSION_5 cacheDir : When the value of useCommandLineValues is false , specify the absolute path of the directory for the shared classes cache. If the value is null , the platform-dependent default is used. flags : Reserved for future use. The only value allowed is COM_IBM_ITERATE_SHARED_CACHES_NO_FLAGS . useCommandLineValues : Set this value to true when you want to specify the cache directory on the command line. Set this value to false when you want to use the cacheDir parameter. callback : A function pointer to a user provided callback routine jvmtiIterateSharedCachesCallback . user_data : User supplied data, passed as an argument to the callback function. jint (JNICALL *jvmtiIterateSharedCachesCallback)(jvmtiEnv *env,jvmtiSharedCacheInfo *cache_info, void *user_data); Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The env parameter is not valid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_UNSUPPORTED_VERSION : The version parameter is not valid. JVMTI_ERROR_NULL_POINTER : The callback parameter is null. JVMTI_ERROR_NOT_AVAILABLE : The shared classes feature is not enabled in the VM. JVMTI_ERROR_ILLEGAL_ARGUMENT : The flags parameter is not valid. JVMTI_ERROR_INTERNAL : This error is returned when the jvmtiIterateSharedCachesCallback returns JNI_ERR . Identifiers JVMTI Extension Function identifier: com.ibm.IterateSharedCaches Macro declaration in the ibmjvmti.h file: COM_IBM_ITERATE_SHARED_CACHES","title":"IterateSharedCaches"},{"location":"interface_jvmti/#jvmtiiteratesharedcachescallback-function","text":"Callback function parameters env : A pointer to the JVMTI environment when calling COM_IBM_ITERATE_SHARED_CACHES . cache_info : A jvmtiSharedCacheInfo structure containing information about a shared cache. user_data : User-supplied data, passed as an argument to IterateSharedCaches . Callback function returns JNI_OK : Continue iterating. JNI_ERR : Stop iterating, which causes IterateSharedCaches to return JVMTI_ERROR_INTERNAL","title":"jvmtiIterateSharedCachesCallback function"},{"location":"interface_jvmti/#jvmtisharedcacheinfo-structure","text":"The structure of jvmtiSharedCacheInfo typedef struct jvmtiSharedCacheInfo { const char *name; // the name of the shared cache jboolean isCompatible; // if the shared cache is compatible with this VM jboolean isPersistent; // true if the shared cache is persistent, false if its non-persistent jint os_shmid; // the OS shared memory ID associated with a non-persistent cache, -1 otherwise jint os_semid; // the OS shared semaphore ID associated with a non-persistent cache, -1 otherwise jint modLevel; // one of: // COM_IBM_SHARED_CACHE_MODLEVEL_JAVA5 // COM_IBM_SHARED_CACHE_MODLEVEL_JAVA6 // COM_IBM_SHARED_CACHE_MODLEVEL_JAVA7 // COM_IBM_SHARED_CACHE_MODLEVEL_JAVA8 // COM_IBM_SHARED_CACHE_MODLEVEL_JAVA9 // from Java 10: the version number of the Java level on which the shared cache is created jint addrMode; // the address mode of the VM creating the shared cache: includes additional // information on whether it is a 64-bit compressedRefs cache when // COM_IBM_ITERATE_SHARED_CACHES_VERSION_3 or later is specified. jboolean isCorrupt; // if the cache is corrupted jlong cacheSize; // the total usable shared classes cache size, or -1 when isCompatible is false jlong freeBytes; // the number of free bytes in the shared classes cache, or -1 when isCompatible is false jlong lastDetach; // the last detach time specified in milliseconds since 00:00:00 on 1 January 1970 UTC, // or -1 when the last detach time is not available jint cacheType; // the type of the cache jlong softMaxBytes; // the soft limit for the available space in the cache jint layer; // the shared cache layer number } jvmtiSharedCacheInfo; Notes: The field cacheType is included when COM_IBM_ITERATE_SHARED_CACHES_VERSION_2 or later is specified. jvmtiSharedCacheInfo.addrMode encodes both address mode and the compressed reference mode when COM_IBM_ITERATE_SHARED_CACHES_VERSION_3 or later is specified. In this case, use the following set of macros to access the address mode and compressed reference mode: To get the address mode, use: COM_IBM_ITERATE_SHARED_CACHES_GET_ADDR_MODE(jvmtiSharedCacheInfo.addrMode) This macro returns one of the following values: COM_IBM_SHARED_CACHE_ADDRMODE_32 COM_IBM_SHARED_CACHE_ADDRMODE_64 To get the compressed references mode, use: COM_IBM_ITERATE_SHARED_CACHES_GET_CMPRSSREF_MODE(jvmtiSharedCacheInfo.addrMode) This macro returns one of the following values: COM_IBM_ITERATE_SHARED_CACHES_UNKNOWN_COMPRESSED_POINTERS_MODE COM_IBM_ITERATE_SHARED_CACHES_COMPRESSED_POINTERS_MODE COM_IBM_ITERATE_SHARED_CACHES_NON_COMPRESSED_POINTERS_MODE The field softMaxBytes is included when COM_IBM_ITERATE_SHARED_CACHES_VERSION_4 or later is specified. The field layer is included when COM_IBM_ITERATE_SHARED_CACHES_VERSION_5 or later is specified. If the shared cache does not have a layer number, the value for layer is -1 .","title":"jvmtiSharedCacheInfo structure"},{"location":"interface_jvmti/#destroysharedcache","text":"You can remove a shared classes cache by using the DestroySharedCache() API: jvmtiError DestroySharedCache(jvmtiEnv *env, const char *cacheDir, const char *name, jint persistence, jboolean useCommandLineValues, jint *internalErrorCode); This extension removes a named shared classes cache of a given persistence type, in a given directory. You can specify the cache name, persistence type, and directory in one of these ways: Set useCommandLineValues to true and specify the values on the command line. If a value is not available, the default values for the platform are used. Set useCommandLineValues to false and use the cacheDir , persistence and cacheName parameters to identify the cache to be removed. To accept the default value for cacheDir or cacheName , specify the parameter with a null value. Parameters env : A pointer to the JVMTI environment. cacheDir : When the value of useCommandLineValues is false , specify the absolute path of the directory for the shared classes cache. If the value is null , the platform-dependent default is used. cacheName : When the value of useCommandLineValues is false , specify the name of the cache to be removed. If the value is null , the platform-dependent default is used. persistence : When the value of useCommandLineValues is false, specify the type of cache to remove. This parameter must have one of the following values: PERSISTENCE_DEFAULT (The default value for the platform). PERSISTENT NONPERSISTENT useCommandLineValues : Set this value to true when you want to specify the shared classes cache name, persistence type, and directory on the command line. Set this value to false when you want to use the cacheDir , persistence , and cacheName parameters instead. internalErrorCode : If not null , this value is set to one of the following constants when JVMTI_ERROR_INTERNAL is returned: COM_IBM_DESTROYED_ALL_CACHE : Set when JVMTI_ERROR_NONE is returned. COM_IBM_DESTROYED_NONE : Set when the function fails to remove any caches. COM_IBM_DESTROY_FAILED_CURRENT_GEN_CACHE : Set when the function fails to remove the existing current generation cache, irrespective of the state of older generation caches. COM_IBM_DESTROY_FAILED_OLDER_GEN_CACHE : Set when the function fails to remove any older generation caches. The current generation cache does not exist or is successfully removed. Returns JVMTI_ERROR_NONE : Success. No cache exists or all existing caches of all generations are removed. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The env parameter is not valid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_NOT_AVAILABLE : The shared classes feature is not enabled in the VM. JVMTI_ERROR_ILLEGAL_ARGUMENT : The persistence parameter is not valid. JVMTI_ERROR_INTERNAL : Failed to remove any existing cache with the given name. See the value of the internalErrorCode parameter for more information about the failure. Identifiers JVMTI Extension Function identifier: com.ibm.DestroySharedCache Macro declaration in the ibmjvmti.h file: COM_IBM_DESTROY_SHARED_CACHE","title":"DestroySharedCache"},{"location":"interface_jvmti/#registerverbosegcsubscriber","text":"You can subscribe to verbose garbage collection (GC) data logging by using the RegisterVerboseGCSubscriber() API: jvmtiError RegisterVerboseGCSubscriber(jvmtiEnv* jvmti_env, char *description, jvmtiVerboseGCSubscriber subscriber, jvmtiVerboseGCAlarm alarm, void *user_data, void **subscription_id) Parameters jvmti_env : A pointer to the JVMTI environment. description : An ASCII character string that describes the subscriber. subscriber : A function of type jvmtiVerboseGCSubscriber . alarm : A function pointer of type jvmtiVerboseGCAlarm . user_data : A pointer to user data. This pointer is passed to the subscriber and alarm functions each time these functions are called. This pointer can be a null value. subscription_id : A pointer to a subscription identifier. This pointer is returned by the RegisterVerboseGCSubscriber call if successful. The value must be supplied to a future call to DeregisterVerboseGCSubscriber API, which is used to unsubscribe from verbose GC data logging. Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_NULL_POINTER : One of the supplied parameters is null. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is not valid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. JVMTI_ERROR_NOT_AVAILABLE : GC verbose logging is not available. JVMTI_ERROR_INTERNAL : An internal error has occurred. Identifiers JVMTI Extension Function identifier: com.ibm.RegisterVerboseGCSubscriber Macro declaration in the ibmjvmti.h file: COM_IBM_REGISTER_VERBOSEGC_SUBSCRIBER","title":"RegisterVerboseGCSubscriber"},{"location":"interface_jvmti/#jvmtiverbosegcsubscriber-function","text":"The subscriber function type is defined as follows: typedef jvmtiError (*jvmtiVerboseGCSubscriber)(jvmtiEnv *jvmti_env, const char *record, jlong length, void *user_data); The subscriber function must be of type jvmtiVerboseGCSubscriber , which is declared in ibmjvmti.h . This function is called with each record of verbose logging data produced by the VM. The verbose logging record supplied to the subscriber function is valid only for the duration of the function. If the subscriber wants to save the data, the data must be copied elsewhere. If the subscriber function returns an error, the alarm function is called, and the subscription is deregistered. Subscriber function parameters jvmti_env : A pointer to the JVMTI environment. record : An ASCII string that contains a verbose log record. length : The number of ASCII characters in the verbose log record. user_data : User data supplied when the subscriber is registered.","title":"jvmtiVerboseGCSubscriber function"},{"location":"interface_jvmti/#jvmtiverbosegcalarm-function","text":"The alarm function type is defined as follows: typedef jvmtiError (*jvmtiVerboseGCAlarm)(jvmtiEnv *jvmti_env, void *subscription_id, void *user_data); The alarm function must be of type jvmtiVerboseGCAlarm , which is declared in ibmjvmti.h . This function is called if the subscriber function returns an error. Alarm function parameters jvmti_env : A pointer to the JVMTI environment. user_data : User data supplied when the subscriber is registered. subscription_id : The subscription identifier.","title":"jvmtiVerboseGCAlarm function"},{"location":"interface_jvmti/#deregisterverbosegcsubscriber","text":"You can unsubscribe from verbose Garbage Collection (GC) data logging by using the DeregisterVerboseGCSubscriber() API: jvmtiError DeregisterVerboseGCSubscriber(jvmtiEnv* jvmti_env, void *userData, void *subscription_id) After the DeregisterVerboseGCSubscriber() API is called, no further calls are made to the previously registered subscriber function. Parameters jvmti_env : A pointer to the JVMTI environment. subscription_id : The subscription identifier that is returned by the call to the RegisterVerboseGCSubscriber() API. Returns JVMTI_ERROR_NONE : Success. JVMTI_ERROR_NULL_POINTER : The subscription_id parameter is null. JVMTI_ERROR_OUT_OF_MEMORY : There is insufficient system memory to process the request. JVMTI_ERROR_INVALID_ENVIRONMENT : The jvmti_env parameter is not valid. JVMTI_ERROR_WRONG_PHASE : The extension has been called outside the JVMTI live phase. Identifiers JVMTI Extension Function identifier: com.ibm.DeregisterVerboseGCSubscriber Macro declaration in the ibmjvmti.h file: COM_IBM_DEREGISTER_VERBOSEGC_SUBSCRIBER","title":"DeregisterVerboseGCSubscriber"},{"location":"interface_lang_management/","text":"Language management interface Eclipse OpenJ9 provides MXBean extensions to the standard java.lang.management API, which can be used to monitor and manage the Java\u2122 virtual machine. These extensions provide access to information about the state of the OpenJ9 VM and the environment in which it is running. The following tables list the MXBeans by package and describe the monitoring or management capabilities. Package: com.ibm.lang.management MXBean Description GarbageCollectorMXBean Discovers Garbage Collection (GC) operations (collection times, compactions, heap memory usage, and freed memory). JvmCpuMonitorMXBean Discovers CPU consumption by category (GC, JIT, or other threads). MemoryMXBean Discovers memory usage (minimum and maximum heap sizes, and shared classes cache sizes). MemoryPoolMXBean Discovers memory pool usage for specific GC policies. OperatingSystemMXBean Discovers information about the operating system (memory, CPU capacity/utilization). RuntimeMXBean Discovers information about the runtime environment (CPU load, Java process ID, and VM state) ThreadMXBean Discovers information about native thread IDs. UnixOperatingSystemMXBean Discovers information for Unix operating systems (memory, file descriptors, processors, processor usage, and hardware) Package: com.ibm.virtualization.management MXBean Description GuestOSMXBean Discovers CPU and memory statistics of a virtual machine or logical partition as seen by the Hypervisor. HypervisorMXBean Discovers whether the operating system is running on a hypervisor and provides information about the hypervisor. Package: openj9.lang.management MXBean Description OpenJ9DiagnosticsMXBean Configures and dynamically triggers dump agents. For more information about using these MXBeans, read the API documentation. For Java 8, see the OpenJ9 Language Management API documentation .","title":"Language Management"},{"location":"interface_lang_management/#language-management-interface","text":"Eclipse OpenJ9 provides MXBean extensions to the standard java.lang.management API, which can be used to monitor and manage the Java\u2122 virtual machine. These extensions provide access to information about the state of the OpenJ9 VM and the environment in which it is running. The following tables list the MXBeans by package and describe the monitoring or management capabilities. Package: com.ibm.lang.management MXBean Description GarbageCollectorMXBean Discovers Garbage Collection (GC) operations (collection times, compactions, heap memory usage, and freed memory). JvmCpuMonitorMXBean Discovers CPU consumption by category (GC, JIT, or other threads). MemoryMXBean Discovers memory usage (minimum and maximum heap sizes, and shared classes cache sizes). MemoryPoolMXBean Discovers memory pool usage for specific GC policies. OperatingSystemMXBean Discovers information about the operating system (memory, CPU capacity/utilization). RuntimeMXBean Discovers information about the runtime environment (CPU load, Java process ID, and VM state) ThreadMXBean Discovers information about native thread IDs. UnixOperatingSystemMXBean Discovers information for Unix operating systems (memory, file descriptors, processors, processor usage, and hardware) Package: com.ibm.virtualization.management MXBean Description GuestOSMXBean Discovers CPU and memory statistics of a virtual machine or logical partition as seen by the Hypervisor. HypervisorMXBean Discovers whether the operating system is running on a hypervisor and provides information about the hypervisor. Package: openj9.lang.management MXBean Description OpenJ9DiagnosticsMXBean Configures and dynamically triggers dump agents. For more information about using these MXBeans, read the API documentation. For Java 8, see the OpenJ9 Language Management API documentation .","title":"Language management interface"},{"location":"introduction/","text":"Getting started with OpenJ9 OpenJ9 is a high performance, scalable, Java\u2122 virtual machine (VM) implementation that is fully compliant with the Java Virtual Machine Specification . At run time, the VM interprets the Java bytecode that is compiled by the Java compiler. The VM acts as a translator between the language and the underlying operating system and hardware. A Java program requires a specific VM to run on a particular platform, such as Linux\u00ae, z/OS\u00ae, or Windows\u2122. This material provides information about the VM configuration and tuning options, together with the default settings. Follow the links provided for more detailed information. Configuring your system Most Java applications should run on an OpenJDK that contains the OpenJ9 VM without changing anything on the underlying system. However, to get the most out of your system you might want to consider some configuration options. Read Configuring your system to learn more about the following options: Setting operating system environment variables, such as PATH and CLASSPATH . Increasing resource limits for running Java applications. Configuring large page memory allocation. Configuring Dynamic LPAR support on AIX\u00ae systems. Performance tunin