diff --git a/gc/index.html b/gc/index.html
index 8b92f91..f95de6f 100644
--- a/gc/index.html
+++ b/gc/index.html
@@ -2957,7 +2957,7 @@
 <li><a href="https://developer.ibm.com/javasdk/2017/09/18/reducing-garbage-collection-pause-times-concurrent-scavenge-guarded-storage-facility/">Reducing Garbage Collection pause times with Concurrent Scavenge and the Guarded Storage Facility</a></li>
 <li><a href="https://developer.ibm.com/javasdk/2017/09/25/concurrent-scavenge-using-guarded-storage-facility-works/">How Concurrent Scavenge using the Guarded Storage Facility Works</a></li>
 </ul>
-<p><i class="fa fa-pencil-square-o" aria-hidden="true"></i> <strong>Note:</strong> Concurrent scavenge mode is available on Linux on IBM Z&reg; and the z/OS&reg; platform.</p>
+<p><i class="fa fa-pencil-square-o" aria-hidden="true"></i> <strong>Note:</strong> Concurrent scavenge mode is available on Linux on x86-64, Linux on IBM Z&reg; and the z/OS&reg; platform.</p>
 <h2 id="other-policies">Other policies</h2>
 <p>OpenJ9 has the following alternative GC policies:</p>
 <ul>
diff --git a/search/search_index.json b/search/search_index.json
index da847a4..973b599 100644
--- a/search/search_index.json
+++ b/search/search_index.json
@@ -82,12 +82,12 @@
         },
         {
             "location": "/version0.11/",
-            "text": "What's new in version 0.11.0\n\n\nThe following new features and notable changes since v.0.10.0 are included in this release:\n\n\n\n\nNew binaries and changes to supported environments.\n\n\n \nOpenSSL is now supported for improved native cryptographic performance\n\n\n \nChanges to the location of the default shared cache and cache snapshot directory\n\n\nNew class data sharing suboptions\n\n\nContainer awareness in the OpenJ9 VM is now enabled by default\n\n\nPause-less garbage collection mode is now available on x86 platforms\n\n\nYou can now restrict identity hash codes to non-negative values\n\n\nSupport for OpenJDK HotSpot options\n\n\n\n\nBinaries and supported environments\n\n\nOpenJ9 release 0.11.0 provides limited support for the macOS\u00ae platform on OpenJDK 11. Early builds of OpenJDK 11 with OpenJ9 on macOS are available at\nthe AdoptOpenJDK project at the following link:  \n\n\n\n\nOpenJDK version 11\n\n\n\n\nSupport for macOS on OpenJDK 8 is coming soon.\n\n\nTo learn more about support for OpenJ9 releases, including OpenJDK levels and platform support, see \nSupported environments\n\n\nOpenSSL is now supported for improved native cryptographic performance\n\n\n\n\nOpenSSL is a native open source cryptographic toolkit for Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols, which provides improved cryptographic performance compared to the in-built OpenJDK Java cryptographic implementation. The OpenSSL V1.1.x implementation is enabled by default and  supported for the Digest, CBC, and GCM algorithms. Binaries obtained from AdoptOpenJDK include OpenSSL v1.1.x (see Note). For more information about tuning the OpenSSL implementation, see \nPerformance tuning\n.\n\n\n \nNote:\n Currently, OpenSSL is not bundled as part of the AdoptOpenJDK AIX binary due to an unresolved problem.\n\n\n\n\nChanges to the location of the default shared cache and cache snapshot directory\n\n\n\n\nTo increase security, the default shared classes cache directory is changed on non-Windows platforms from \n/tmp/javasharedresources/\n to the user's home directory, unless you specify \n-Xshareclasses:groupAccess\n. If you use the \ngroupAccess\n suboption, the default directory is unchanged because some members of the group might not have access to the user home directory.\n\n\n \nNote:\n For persistent caches, the shared classes cache directory cannot be on an NFS mount. If your user home directory is on an NFS mount, either move it or use the \n-Xshareclasses:cacheDir=<directory>\n suboption to specify a different directory for the cache.\n\n\nIn general, caches cannot be shared across different Java releases, so you cannot re-use a cache that was created by a previous level of Java 11; if you use the name and cacheDir suboptions to specify an existing cache, the VM attempts to delete the cache and create a new one. However, on Windows, the cache cannot be deleted if it is in use, in which case the VM continues to use the existing cache.\n\n\nYou can find and remove old caches or snapshots by using the following command-line options:\n\n\nFor persistent caches:\n- \n-Xshareclasses:cacheDir=/tmp/javasharedresources/,listAllCaches\n to find the cache\n- \n-Xshareclasses:cacheDir=/tmp/javasharedresources/,name=<cacheName>,destroy\n to remove the cache\n\n\nFor nonpersistent caches or snapshots:\n- \n-Xshareclasses:cacheDir=/tmp,listAllCaches\n to find the item\n- \n-Xshareclasses:cacheDir=/tmp,name=<snapshotName>,destroySnapshot\n to remove the item\n\n\n\n\nNew class data sharing suboptions\n\n\n-Xshareclasses:bootClassesOnly\n: disables caching of classes that are loaded by non-bootstrap class loaders. This suboption also enables the \nnonfatal\n suboption, which allows the VM to start even if there was an error creating the shared classes cache.\n\n\n-Xshareclasses:fatal\n: prevents the VM from starting if there was an error creating the shared classes cache. You might want to enable this suboption when using the -Xshareclasses:bootClassesOnly suboption, to troubleshoot problems when creating the cache.\n\n\nContainer awareness in the OpenJ9 VM is now enabled by default\n\n\nWhen using container technology, applications are typically run on their own and do not need to compete for memory. If the VM detects that it is running in a container environment, and a memory limit for the container is set, the VM automatically adjusts the maximum default Java heap size.\n\n\nIn earlier releases, this behavior was enabled by setting the \n-XX:+UseContainerSupport\n option. This setting is now the default. For more information\nabout the Java heap size set for a container, see \n-XX:[+|-]UseContainerSupport\n.\n\n\nPause-less garbage collection mode is now available on x86 platforms\n\n\nPause-less garbage collection mode is aimed at large heap, response-time sensitive applications. When enabled, the VM attempts to reduce GC pause times. In earlier releases, pause-less garbage collection mode (\n-Xgc:concurrentScavenge\n) was available only on IBM z14 hardware. This mode is now available on 64-bit x86 Linux and Windows platforms.\n\n\n \nRestrictions:\n\n\n\n\nThe Generational Concurrent (\ngencon\n) garbage collection policy must be used. (This is the default policy.)\n\n\nCompressed references must be used. See \n-Xcompressedrefs\n. Compressed references are enabled by default when the maximum heap size (\n-Xmx\n) \u2264 57 GB. The concurrent scavenge option is ignored if the maximum heap size is > 57 GB.\n\n\n\n\nYou can now restrict identity hash codes to non-negative values\n\n\nOpenJ9 allows both positive and negative identity hashcodes, which can be problematic if your program (incorrectly) assumes hashcodes can only be positive. However, you can now use the \n-XX:[+|-]PositiveIdentityHash\n option to limit identity hash codes to non-negative values.\n\n\nSupport for OpenJDK HotSpot options\n\n\nFor compatibility, the following OpenJDK Hotspot options are now supported by OpenJ9:\n\n\n\n\n-XX:MaxHeapSize\n\n\n-XX:InitialHeapSize\n\n\n\n\nFull release information\n\n\nTo see a complete list of changes between Eclipse OpenJ9 V0.10.0 and V0.11.0 releases, see the \nRelease notes\n.",
+            "text": "What's new in version 0.11.0\n\n\nThe following new features and notable changes since v.0.10.0 are included in this release:\n\n\n\n\nNew binaries and changes to supported environments.\n\n\n \nOpenSSL is now supported for improved native cryptographic performance\n\n\n \nChanges to the location of the default shared cache and cache snapshot directory\n\n\nNew class data sharing suboptions\n\n\nContainer awareness in the OpenJ9 VM is now enabled by default\n\n\nPause-less garbage collection mode is now available on Linux x86 platforms\n\n\nYou can now restrict identity hash codes to non-negative values\n\n\nSupport for OpenJDK HotSpot options\n\n\n\n\nBinaries and supported environments\n\n\nOpenJ9 release 0.11.0 provides limited support for the macOS\u00ae platform on OpenJDK 11. Early builds of OpenJDK 11 with OpenJ9 on macOS are available at\nthe AdoptOpenJDK project at the following link:  \n\n\n\n\nOpenJDK version 11\n\n\n\n\nSupport for macOS on OpenJDK 8 is coming soon.\n\n\nTo learn more about support for OpenJ9 releases, including OpenJDK levels and platform support, see \nSupported environments\n\n\nOpenSSL is now supported for improved native cryptographic performance\n\n\n\n\nOpenSSL is a native open source cryptographic toolkit for Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols, which provides improved cryptographic performance compared to the in-built OpenJDK Java cryptographic implementation. The OpenSSL V1.1.x implementation is enabled by default and  supported for the Digest, CBC, and GCM algorithms. Binaries obtained from AdoptOpenJDK include OpenSSL v1.1.x (see Note). For more information about tuning the OpenSSL implementation, see \nPerformance tuning\n.\n\n\n \nNote:\n Currently, OpenSSL is not bundled as part of the AdoptOpenJDK AIX binary due to an unresolved problem.\n\n\n\n\nChanges to the location of the default shared cache and cache snapshot directory\n\n\n\n\nTo increase security, the default shared classes cache directory is changed on non-Windows platforms from \n/tmp/javasharedresources/\n to the user's home directory, unless you specify \n-Xshareclasses:groupAccess\n. If you use the \ngroupAccess\n suboption, the default directory is unchanged because some members of the group might not have access to the user home directory.\n\n\n \nNote:\n For persistent caches, the shared classes cache directory cannot be on an NFS mount. If your user home directory is on an NFS mount, either move it or use the \n-Xshareclasses:cacheDir=<directory>\n suboption to specify a different directory for the cache.\n\n\nIn general, caches cannot be shared across different Java releases, so you cannot re-use a cache that was created by a previous level of Java 11; if you use the name and cacheDir suboptions to specify an existing cache, the VM attempts to delete the cache and create a new one. However, on Windows, the cache cannot be deleted if it is in use, in which case the VM continues to use the existing cache.\n\n\nYou can find and remove old caches or snapshots by using the following command-line options:\n\n\nFor persistent caches:\n- \n-Xshareclasses:cacheDir=/tmp/javasharedresources/,listAllCaches\n to find the cache\n- \n-Xshareclasses:cacheDir=/tmp/javasharedresources/,name=<cacheName>,destroy\n to remove the cache\n\n\nFor nonpersistent caches or snapshots:\n- \n-Xshareclasses:cacheDir=/tmp,listAllCaches\n to find the item\n- \n-Xshareclasses:cacheDir=/tmp,name=<snapshotName>,destroySnapshot\n to remove the item\n\n\n\n\nNew class data sharing suboptions\n\n\n-Xshareclasses:bootClassesOnly\n: disables caching of classes that are loaded by non-bootstrap class loaders. This suboption also enables the \nnonfatal\n suboption, which allows the VM to start even if there was an error creating the shared classes cache.\n\n\n-Xshareclasses:fatal\n: prevents the VM from starting if there was an error creating the shared classes cache. You might want to enable this suboption when using the -Xshareclasses:bootClassesOnly suboption, to troubleshoot problems when creating the cache.\n\n\nContainer awareness in the OpenJ9 VM is now enabled by default\n\n\nWhen using container technology, applications are typically run on their own and do not need to compete for memory. If the VM detects that it is running in a container environment, and a memory limit for the container is set, the VM automatically adjusts the maximum default Java heap size.\n\n\nIn earlier releases, this behavior was enabled by setting the \n-XX:+UseContainerSupport\n option. This setting is now the default. For more information\nabout the Java heap size set for a container, see \n-XX:[+|-]UseContainerSupport\n.\n\n\nPause-less garbage collection mode is now available on Linux x86 platforms\n\n\nPause-less garbage collection mode is aimed at large heap, response-time sensitive applications. When enabled, the VM attempts to reduce GC pause times. In earlier releases, pause-less garbage collection mode (\n-Xgc:concurrentScavenge\n) was available only on IBM z14 hardware. This mode is now available on 64-bit x86 Linux platforms.\n\n\n \nRestrictions:\n\n\n\n\nThe Generational Concurrent (\ngencon\n) garbage collection policy must be used. (This is the default policy.)\n\n\nCompressed references must be used. See \n-Xcompressedrefs\n. Compressed references are enabled by default when the maximum heap size (\n-Xmx\n) \u2264 57 GB. The concurrent scavenge option is ignored if the maximum heap size is > 57 GB.\n\n\n\n\nYou can now restrict identity hash codes to non-negative values\n\n\nOpenJ9 allows both positive and negative identity hashcodes, which can be problematic if your program (incorrectly) assumes hashcodes can only be positive. However, you can now use the \n-XX:[+|-]PositiveIdentityHash\n option to limit identity hash codes to non-negative values.\n\n\nSupport for OpenJDK HotSpot options\n\n\nFor compatibility, the following OpenJDK Hotspot options are now supported by OpenJ9:\n\n\n\n\n-XX:MaxHeapSize\n\n\n-XX:InitialHeapSize\n\n\n\n\nFull release information\n\n\nTo see a complete list of changes between Eclipse OpenJ9 V0.10.0 and V0.11.0 releases, see the \nRelease notes\n.",
             "title": "Version 0.11.0"
         },
         {
             "location": "/version0.11/#whats-new-in-version-0110",
-            "text": "The following new features and notable changes since v.0.10.0 are included in this release:   New binaries and changes to supported environments.    OpenSSL is now supported for improved native cryptographic performance    Changes to the location of the default shared cache and cache snapshot directory  New class data sharing suboptions  Container awareness in the OpenJ9 VM is now enabled by default  Pause-less garbage collection mode is now available on x86 platforms  You can now restrict identity hash codes to non-negative values  Support for OpenJDK HotSpot options",
+            "text": "The following new features and notable changes since v.0.10.0 are included in this release:   New binaries and changes to supported environments.    OpenSSL is now supported for improved native cryptographic performance    Changes to the location of the default shared cache and cache snapshot directory  New class data sharing suboptions  Container awareness in the OpenJ9 VM is now enabled by default  Pause-less garbage collection mode is now available on Linux x86 platforms  You can now restrict identity hash codes to non-negative values  Support for OpenJDK HotSpot options",
             "title": "What's new in version 0.11.0"
         },
         {
@@ -116,9 +116,9 @@
             "title": "Container awareness in the OpenJ9 VM is now enabled by default"
         },
         {
-            "location": "/version0.11/#pause-less-garbage-collection-mode-is-now-available-on-x86-platforms",
-            "text": "Pause-less garbage collection mode is aimed at large heap, response-time sensitive applications. When enabled, the VM attempts to reduce GC pause times. In earlier releases, pause-less garbage collection mode ( -Xgc:concurrentScavenge ) was available only on IBM z14 hardware. This mode is now available on 64-bit x86 Linux and Windows platforms.    Restrictions:   The Generational Concurrent ( gencon ) garbage collection policy must be used. (This is the default policy.)  Compressed references must be used. See  -Xcompressedrefs . Compressed references are enabled by default when the maximum heap size ( -Xmx ) \u2264 57 GB. The concurrent scavenge option is ignored if the maximum heap size is > 57 GB.",
-            "title": "Pause-less garbage collection mode is now available on x86 platforms"
+            "location": "/version0.11/#pause-less-garbage-collection-mode-is-now-available-on-linux-x86-platforms",
+            "text": "Pause-less garbage collection mode is aimed at large heap, response-time sensitive applications. When enabled, the VM attempts to reduce GC pause times. In earlier releases, pause-less garbage collection mode ( -Xgc:concurrentScavenge ) was available only on IBM z14 hardware. This mode is now available on 64-bit x86 Linux platforms.    Restrictions:   The Generational Concurrent ( gencon ) garbage collection policy must be used. (This is the default policy.)  Compressed references must be used. See  -Xcompressedrefs . Compressed references are enabled by default when the maximum heap size ( -Xmx ) \u2264 57 GB. The concurrent scavenge option is ignored if the maximum heap size is > 57 GB.",
+            "title": "Pause-less garbage collection mode is now available on Linux x86 platforms"
         },
         {
             "location": "/version0.11/#you-can-now-restrict-identity-hash-codes-to-non-negative-values",
@@ -242,7 +242,7 @@
         },
         {
             "location": "/gc/",
-            "text": "Garbage collection\n\n\nTo 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 clean up is done. This pause is often referred to as a \nstop-the-world\n 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. Depending on the type of application you are running, you might want to choose when and how garbage collection is done.\n\n\nEclipse OpenJ9 has a number of GC policies designed around different types of applications and workloads. Picking the right policy very much depends on your usage and performance goals.\n\n\nGencon policy\n\n\nIf you have a transactional application, with many short lived objects, the Generational Concurrent (\n-Xgcpolicy:gencon\n) GC policy is probably best suited, which 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.\n\n\nA special mode of the \ngencon\n policy is known as \nConcurrent Scavenge\n (\n-Xgc:concurrentScavenge\n). This mode works with the Guarded Storage (GS) Facility, which is a feature of the IBM z14\u2122 mainframe system. The aim is to minimize the time spent in stop-the-world pauses by collecting garbage in parallel with running application threads. 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. You can read more about this mode in the following blog posts:\n\n\n\n\nReducing Garbage Collection pause times with Concurrent Scavenge and the Guarded Storage Facility\n\n\nHow Concurrent Scavenge using the Guarded Storage Facility Works\n\n\n\n\n \nNote:\n Concurrent scavenge mode is available on Linux on IBM Z\u00ae and the z/OS\u00ae platform.\n\n\nOther policies\n\n\nOpenJ9 has the following alternative GC policies:\n\n\n\n\n-Xgcpolicy:balanced\n divides the Java heap into regions, which are individually managed 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 collections by matching object allocation and survival rates. If you have problems with application pause times that are caused by global garbage collections, particularly compactions, this policy might improve application performance, particularly on large systems that have Non-Uniform Memory Architecture (NUMA) characteristics (x86 and POWER\u2122 platforms).\n\n\n-Xgcpolicy:metronome\n is designed for applications that require precise response times. Garbage collection occurs in small interruptible steps to avoid stop-the-world pauses. This policy is available only on x86 Linux and AIX\u00ae platforms.\n\n\n-Xgcpolicy:optavgpause\n uses concurrent mark and sweep phases, which means that pause times are reduced when compared to optthruput, but at the expense of some performance throughput.\n\n\n-Xgcpolicy:optthruput\n is optimized for throughput by disabling the concurrent mark phase, which means that applications will stop for long pauses while garbage collection takes place. You might consider using this policy when high application throughput, rather than short garbage collection pauses, is the main performance goal.\n\n\n\n\nFor more information about these garbage collection policies and options, see \n-Xgcpolicy\n.\n\n\nTroubleshooting\n\n\nYou can diagnose problems with garbage collection operations by turning on verbose garbage collection logging. By default, the information is printed to STDERR but can be redirected to a file by specifying the \n-Xverbosegclog\n option. The log files contain detailed information about all operations, including initialization, stop-the-world processing, finalization, reference processing, and allocation failures. For more information, see \nVerbose garbage collection\n\n\nIf 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 \n-Xtgc\n.",
+            "text": "Garbage collection\n\n\nTo 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 clean up is done. This pause is often referred to as a \nstop-the-world\n 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. Depending on the type of application you are running, you might want to choose when and how garbage collection is done.\n\n\nEclipse OpenJ9 has a number of GC policies designed around different types of applications and workloads. Picking the right policy very much depends on your usage and performance goals.\n\n\nGencon policy\n\n\nIf you have a transactional application, with many short lived objects, the Generational Concurrent (\n-Xgcpolicy:gencon\n) GC policy is probably best suited, which 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.\n\n\nA special mode of the \ngencon\n policy is known as \nConcurrent Scavenge\n (\n-Xgc:concurrentScavenge\n). This mode works with the Guarded Storage (GS) Facility, which is a feature of the IBM z14\u2122 mainframe system. The aim is to minimize the time spent in stop-the-world pauses by collecting garbage in parallel with running application threads. 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. You can read more about this mode in the following blog posts:\n\n\n\n\nReducing Garbage Collection pause times with Concurrent Scavenge and the Guarded Storage Facility\n\n\nHow Concurrent Scavenge using the Guarded Storage Facility Works\n\n\n\n\n \nNote:\n Concurrent scavenge mode is available on Linux on x86-64, Linux on IBM Z\u00ae and the z/OS\u00ae platform.\n\n\nOther policies\n\n\nOpenJ9 has the following alternative GC policies:\n\n\n\n\n-Xgcpolicy:balanced\n divides the Java heap into regions, which are individually managed 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 collections by matching object allocation and survival rates. If you have problems with application pause times that are caused by global garbage collections, particularly compactions, this policy might improve application performance, particularly on large systems that have Non-Uniform Memory Architecture (NUMA) characteristics (x86 and POWER\u2122 platforms).\n\n\n-Xgcpolicy:metronome\n is designed for applications that require precise response times. Garbage collection occurs in small interruptible steps to avoid stop-the-world pauses. This policy is available only on x86 Linux and AIX\u00ae platforms.\n\n\n-Xgcpolicy:optavgpause\n uses concurrent mark and sweep phases, which means that pause times are reduced when compared to optthruput, but at the expense of some performance throughput.\n\n\n-Xgcpolicy:optthruput\n is optimized for throughput by disabling the concurrent mark phase, which means that applications will stop for long pauses while garbage collection takes place. You might consider using this policy when high application throughput, rather than short garbage collection pauses, is the main performance goal.\n\n\n\n\nFor more information about these garbage collection policies and options, see \n-Xgcpolicy\n.\n\n\nTroubleshooting\n\n\nYou can diagnose problems with garbage collection operations by turning on verbose garbage collection logging. By default, the information is printed to STDERR but can be redirected to a file by specifying the \n-Xverbosegclog\n option. The log files contain detailed information about all operations, including initialization, stop-the-world processing, finalization, reference processing, and allocation failures. For more information, see \nVerbose garbage collection\n\n\nIf 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 \n-Xtgc\n.",
             "title": "Garbage Collection"
         },
         {
@@ -252,7 +252,7 @@
         },
         {
             "location": "/gc/#gencon-policy",
-            "text": "If you have a transactional application, with many short lived objects, the Generational Concurrent ( -Xgcpolicy:gencon ) GC policy is probably best suited, which 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.  A special mode of the  gencon  policy is known as  Concurrent Scavenge  ( -Xgc:concurrentScavenge ). This mode works with the Guarded Storage (GS) Facility, which is a feature of the IBM z14\u2122 mainframe system. The aim is to minimize the time spent in stop-the-world pauses by collecting garbage in parallel with running application threads. 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. You can read more about this mode in the following blog posts:   Reducing Garbage Collection pause times with Concurrent Scavenge and the Guarded Storage Facility  How Concurrent Scavenge using the Guarded Storage Facility Works     Note:  Concurrent scavenge mode is available on Linux on IBM Z\u00ae and the z/OS\u00ae platform.",
+            "text": "If you have a transactional application, with many short lived objects, the Generational Concurrent ( -Xgcpolicy:gencon ) GC policy is probably best suited, which 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.  A special mode of the  gencon  policy is known as  Concurrent Scavenge  ( -Xgc:concurrentScavenge ). This mode works with the Guarded Storage (GS) Facility, which is a feature of the IBM z14\u2122 mainframe system. The aim is to minimize the time spent in stop-the-world pauses by collecting garbage in parallel with running application threads. 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. You can read more about this mode in the following blog posts:   Reducing Garbage Collection pause times with Concurrent Scavenge and the Guarded Storage Facility  How Concurrent Scavenge using the Guarded Storage Facility Works     Note:  Concurrent scavenge mode is available on Linux on x86-64, Linux on IBM Z\u00ae and the z/OS\u00ae platform.",
             "title": "Gencon policy"
         },
         {
@@ -1767,7 +1767,7 @@
         },
         {
             "location": "/xgc/",
-            "text": "-Xgc\n\n\nOptions that change the behavior of the Garbage Collector (GC).\n\n\nSyntax\n\n\n    -Xgc:<parameter>\n\n\n\n\n\nParameters\n\n\n\n\n\n\n\n\nParameter\n\n\nEffect\n\n\n\n\n\n\n\n\n\n\nconcurrentScavenge\n          \n\n\nEnables a garbage collection (GC) mode with less pause times.\n\n\n\n\n\n\ndnssExpectedTimeRatioMaximum\n\n\nSets the maximum time to spend on GC of the nursery area.\n\n\n\n\n\n\ndnssExpectedTimeRatioMinimum\n\n\nSets the minimum time to spend on GC of the nursery area.\n\n\n\n\n\n\nexcessiveGCratio\n            \n\n\nSets a boundary value beyond which GC is deemed to be excessive.\n\n\n\n\n\n\nminContractPercent\n          \n\n\nSets the minimum percentage of the heap that can be contracted at any given time.\n\n\n\n\n\n\nmaxContractPercent\n          \n\n\nSets the maximum percentage of the heap that can be contracted at any given time.\n\n\n\n\n\n\noverrideHiresTimerCheck\n     \n\n\nOverrides GC operating system checks for timer resolution.\n\n\n\n\n\n\npreferredHeapBase\n           \n\n\nSets a memory range for the Java\u2122 heap. (AIX\u00ae, Linux\u2122, and Windows\u2122 only)\n\n\n\n\n\n\nscvNoAdaptiveTenure\n         \n\n\nTurns off the adaptive tenure age in the generational concurrent GC policy.\n\n\n\n\n\n\nscvTenureAge\n                \n\n\nSets the initial scavenger tenure age in the generational concurrent GC policy.\n\n\n\n\n\n\ntlhIncrementSize\n            \n\n\nSets the size of the thread local heap (TLH)  increment\n\n\n\n\n\n\ntlhInitialSize\n              \n\n\nSets the initial size of the thread local heap\n\n\n\n\n\n\ntlhMaximumSize\n              \n\n\nSets the maximum size of the thread local heap\n\n\n\n\n\n\nverboseFormat\n               \n\n\nSets the verbose GC format.\n\n\n\n\n\n\n\n\nconcurrentScavenge\n\n\n(64-bit: not AIX or Linux on IBM Power Systems)\n\n\n    -Xgc:concurrentScavenge\n\n\n\n\n\n\n\n\n\nThis option supports pause-less garbage collection mode. If you set this option, the VM attempts to reduce GC pause times for response-time sensitive, large-heap applications.\n\n\nThe following restrictions apply:\n\n\n\n\n\n\nThe Generational Concurrent (\ngencon\n) garbage collection policy must be used.\n(This is the default policy.)\n\n\n\n\n\n\nCompressed references must be used. See \n-Xcompressedrefs\n.\n(Compressed references are enabled by default when the maximum heap size (\n-Xmx\n) \u2264 57 GB. The concurrent scavenge option is ignored if the maximum heap size is > 57 GB.)\n\n\n\n\n\n\n \nNote: Linux on Z and z/OS\n\n\nThis option is supported on IBM z14\u2122 hardware running the following software:\n\n\nOperating systems:\n\n\n\n\nz/OS V2R3\n\n\nz/OS V2R2 and \nAPAR OA51643\n.\n\n\nRHEL 7.5 (minimum kernel level 4.14)\n\n\nUbuntu 18.04 (minimum kernel level 4.15)\n\n\n\n\nHypervisors:\n\n\n\n\nIBM z/VM 6.4 with \nAPAR VM65987\n\n\nKVM solutions with QEMU 2.10 or later and minimum host kernel level 4.12 (for example, RHEL 7.5 with kernel level 4.14)\n\n\n\n\nIf these requirements are not met, the option is ignored.\n\n\n \nNote:\n On z/OS, the virtual storage used might exceed the Java maximum heap size. Set the z/OS memory limit, specified by \nulimit -M\n, to a larger value than the maximum heap size.\n\n\n\n\n\n\ndnssExpectedTimeRatioMaximum\n\n\n    -Xgc:dnssExpectedTimeRatioMaximum=<value>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nValue\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n<value>\n\n\n[percentage]\n\n\n5\n\n\n\n\n\n\n\n\n\n\n\n\nThe maximum amount of time spent on garbage collection of the nursery area, expressed as a percentage of the overall time for the last three GC intervals.\n\n\n\n\n\n\ndnssExpectedTimeRatioMinimum\n\n\n    -Xgc:dnssExpectedTimeRatioMinimum=<value>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nValue\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n<value>\n\n\n[percentage]\n\n\n1\n\n\n\n\n\n\n\n\n\n\n\n\nThe minimum amount of time spent on garbage collection of the nursery area, expressed as a percentage of the overall time for the last three GC intervals.\n\n\n\n\n\n\nexcessiveGCratio\n\n\n    -Xgc:excessiveGCratio=<value>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nValue\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n<value>\n\n\n[percentage]\n\n\n95\n\n\n\n\n\n\n\n\n\n\n\n\nwhere \n<value>\n is a percentage of total application run time that is not spent in GC.\n\n\nThe default value is 95, which means that anything over 5% of total application run time spent on GC is deemed excessive. This option can be used only when \n-Xenableexcessivegc\n is set.\n\n\n\n\n\n\nminContractPercent\n\n\n    -Xgc:minContractPercent=<n>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nValue\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n<n>\n\n\n[percentage]\n\n\n-\n\n\n\n\n\n\n\n\n\n\n\n\nThe minimum percentage of the heap that can be contracted at any given time.\n\n\n\n\n\n\nmaxContractPercent\n\n\n    -Xgc:maxContractPercent=<n>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nValue\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n<n>\n\n\n[percentage]\n\n\n-\n\n\n\n\n\n\n\n\n\n\n\n\nThe maximum percentage of the heap that can be contracted at any given time. For example, \n-Xgc:maxContractPercent=20\n causes the heap to contract by as much as 20%.\n\n\n\n\n\n\noverrideHiresTimerCheck\n\n\n    -Xgc:overrideHiresTimerCheck\n\n\n\n\n\n\n\n\n\nWhen the VM starts, the GC checks that the operating system can meet the timer resolution requirements for the requested target pause time. Typically, this check correctly identifies operating systems that can deliver adequate time resolution. However, in some cases the operating system provides a more conservative answer than strictly necessary for GC pause time management, which prevents startup. Specifying this parameter causes the GC to ignore the answer returned by the operating system. The VM starts, but GC pause time management remains subject to operating system performance, which might not provide adequate timer resolution.\n\n\n \nNote:\n Use this option with caution, and only when you are unable to use a supported operating system.\n\n\n\n\n\n\npreferredHeapBase\n\n\n(AIX, Linux, Windows only)\n\n\n    -Xgc:preferredHeapBase=<address>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nValue\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n<value>\n\n\n[hexadecimal]\n\n\n-\n\n\n\n\n\n\n\n\n\n\n\n\nwhere, \n<address>\n is the base memory address for the heap. Use this option with the \n-Xcompressedrefs\n option to allocate the heap you specify with the \n-Xmx\n option, in a memory range of your choice. If \n-Xcompressedrefs\n is not specified, this option has no effect. In the following example, the heap is located at the 4 GB mark, leaving the lowest 4 GB of address space for use by other processes.\n\n\n-\nXgc\n:\npreferredHeapBase\n=\n0x100000000\n\n\n\n\n\n\nIf the heap cannot be allocated in a contiguous block at the \npreferredHeapBase\n address you specified, an error occurs detailing a Garbage Collection (GC) allocation failure startup. When the \npreferredHeapBase\n option is used with the \n-Xlp\n option, the \npreferredHeapBase\n address must be a multiple of the large page size. If you specify an inaccurate heap base address, the heap is allocated with the default page size.\n\n\n\n\n\n\nscvNoAdaptiveTenure\n\n\n    -Xgc:scvNoAdaptiveTenure\n\n\n\n\n\n\n\nTurns off the adaptive tenure age in the generational concurrent GC policy. The initial age that is set is maintained throughout the run time of the VM. See \nscvTenureAge\n.\n\n\n\n\nscvTenureAge\n\n\n    -Xgc:scvTenureAge=<n>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nValue\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n<n>\n\n\n[1 - 14]\n\n\n10\n\n\n\n\n\n\n\n\n\n\n\n\nSets the initial scavenger tenure age in the generational concurrent GC policy. For more information, see \nTenure age\n.\n\n\n\n\n\n\ntlhIncrementSize\n\n\n    -Xgc:tlhIncrementSize=<bytes>\n\n\n\n\n\n\n\nSets the increment size of the thread local heap (TLH), which plays a key role in cache allocation. Threads start creating TLHs with a predefined initial size (default 2 KB). On every TLH refresh, the requested size for that thread is increased by an increment (default 4 KB). Use this option to control the increment size.\n\n\n\n\ntlhInitialSize\n\n\n    -Xgc:tlhInitialSize=<bytes>\n\n\n\n\n\n\n\nSets the initial size of the TLH. The default size is 2 KB.\n\n\n\n\ntlhMaximumSize\n\n\n    -Xgc:tlhMaximumSize=<bytes>\n\n\n\n\n\n\n\nSets the maximum size of the TLH. The size of the TLH varies from 512 bytes (768 on 64-bit JVMs) to 128 KB, depending on the allocation rate of the thread.\nLarger TLHs can help reduce heap lock contention, but might also reduce heap utilisation and increase heap fragmentation. Typically, when the maximum TLH size is increased, you should also increase the increment size (\n-XtlhIncrementSize\n) proportionally, so that active threads can reach the maximum requested TLH size more quickly.\n\n\n\n\nverboseFormat\n\n\n    -Xgc:verboseFormat=<format>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nValue\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n<format>\n\n\ndefault\n\n\nyes\n\n\n\n\n\n\n\n\ndeprecated\n\n\n\n\n\n\n\n\n\n\n\n\ndefault\n: The default verbose garbage collection format for OpenJ9. For more information, see \nVerbose garbage collection logging\n.\n\n\ndeprecated\n: The verbose garbage collection format available in the IBM J9 VM V2.4 and earlier.",
+            "text": "-Xgc\n\n\nOptions that change the behavior of the Garbage Collector (GC).\n\n\nSyntax\n\n\n    -Xgc:<parameter>\n\n\n\n\n\nParameters\n\n\n\n\n\n\n\n\nParameter\n\n\nEffect\n\n\n\n\n\n\n\n\n\n\nconcurrentScavenge\n          \n\n\nEnables a garbage collection (GC) mode with less pause times.\n\n\n\n\n\n\ndnssExpectedTimeRatioMaximum\n\n\nSets the maximum time to spend on GC of the nursery area.\n\n\n\n\n\n\ndnssExpectedTimeRatioMinimum\n\n\nSets the minimum time to spend on GC of the nursery area.\n\n\n\n\n\n\nexcessiveGCratio\n            \n\n\nSets a boundary value beyond which GC is deemed to be excessive.\n\n\n\n\n\n\nminContractPercent\n          \n\n\nSets the minimum percentage of the heap that can be contracted at any given time.\n\n\n\n\n\n\nmaxContractPercent\n          \n\n\nSets the maximum percentage of the heap that can be contracted at any given time.\n\n\n\n\n\n\noverrideHiresTimerCheck\n     \n\n\nOverrides GC operating system checks for timer resolution.\n\n\n\n\n\n\npreferredHeapBase\n           \n\n\nSets a memory range for the Java\u2122 heap. (AIX\u00ae, Linux\u2122, and Windows\u2122 only)\n\n\n\n\n\n\nscvNoAdaptiveTenure\n         \n\n\nTurns off the adaptive tenure age in the generational concurrent GC policy.\n\n\n\n\n\n\nscvTenureAge\n                \n\n\nSets the initial scavenger tenure age in the generational concurrent GC policy.\n\n\n\n\n\n\ntlhIncrementSize\n            \n\n\nSets the size of the thread local heap (TLH)  increment\n\n\n\n\n\n\ntlhInitialSize\n              \n\n\nSets the initial size of the thread local heap\n\n\n\n\n\n\ntlhMaximumSize\n              \n\n\nSets the maximum size of the thread local heap\n\n\n\n\n\n\nverboseFormat\n               \n\n\nSets the verbose GC format.\n\n\n\n\n\n\n\n\nconcurrentScavenge\n\n\n(64-bit: Linux on x86, Linux on IBM Z\u00ae, or z/OS\u00ae only)\n\n\n    -Xgc:concurrentScavenge\n\n\n\n\n\n\n\n\n\nThis option supports pause-less garbage collection mode. If you set this option, the VM attempts to reduce GC pause times for response-time sensitive, large-heap applications.\n\n\nThe following restrictions apply:\n\n\n\n\n\n\nThe Generational Concurrent (\ngencon\n) garbage collection policy must be used.\n(This is the default policy.)\n\n\n\n\n\n\nCompressed references must be used. See \n-Xcompressedrefs\n.\n(Compressed references are enabled by default when the maximum heap size (\n-Xmx\n) \u2264 57 GB. The concurrent scavenge option is ignored if the maximum heap size is > 57 GB.)\n\n\n\n\n\n\n \nNote: Linux on Z and z/OS\n\n\nThis option is supported on IBM z14\u2122 hardware running the following software:\n\n\nOperating systems:\n\n\n\n\nz/OS V2R3\n\n\nz/OS V2R2 and \nAPAR OA51643\n.\n\n\nRHEL 7.5 (minimum kernel level 4.14)\n\n\nUbuntu 18.04 (minimum kernel level 4.15)\n\n\n\n\nHypervisors:\n\n\n\n\nIBM z/VM 6.4 with \nAPAR VM65987\n\n\nKVM solutions with QEMU 2.10 or later and minimum host kernel level 4.12 (for example, RHEL 7.5 with kernel level 4.14)\n\n\n\n\nIf these requirements are not met, the option is ignored.\n\n\n \nNote:\n On z/OS, the virtual storage used might exceed the Java maximum heap size. Set the z/OS memory limit, specified by \nulimit -M\n, to a larger value than the maximum heap size.\n\n\n\n\n\n\ndnssExpectedTimeRatioMaximum\n\n\n    -Xgc:dnssExpectedTimeRatioMaximum=<value>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nValue\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n<value>\n\n\n[percentage]\n\n\n5\n\n\n\n\n\n\n\n\n\n\n\n\nThe maximum amount of time spent on garbage collection of the nursery area, expressed as a percentage of the overall time for the last three GC intervals.\n\n\n\n\n\n\ndnssExpectedTimeRatioMinimum\n\n\n    -Xgc:dnssExpectedTimeRatioMinimum=<value>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nValue\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n<value>\n\n\n[percentage]\n\n\n1\n\n\n\n\n\n\n\n\n\n\n\n\nThe minimum amount of time spent on garbage collection of the nursery area, expressed as a percentage of the overall time for the last three GC intervals.\n\n\n\n\n\n\nexcessiveGCratio\n\n\n    -Xgc:excessiveGCratio=<value>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nValue\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n<value>\n\n\n[percentage]\n\n\n95\n\n\n\n\n\n\n\n\n\n\n\n\nwhere \n<value>\n is a percentage of total application run time that is not spent in GC.\n\n\nThe default value is 95, which means that anything over 5% of total application run time spent on GC is deemed excessive. This option can be used only when \n-Xenableexcessivegc\n is set.\n\n\n\n\n\n\nminContractPercent\n\n\n    -Xgc:minContractPercent=<n>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nValue\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n<n>\n\n\n[percentage]\n\n\n-\n\n\n\n\n\n\n\n\n\n\n\n\nThe minimum percentage of the heap that can be contracted at any given time.\n\n\n\n\n\n\nmaxContractPercent\n\n\n    -Xgc:maxContractPercent=<n>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nValue\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n<n>\n\n\n[percentage]\n\n\n-\n\n\n\n\n\n\n\n\n\n\n\n\nThe maximum percentage of the heap that can be contracted at any given time. For example, \n-Xgc:maxContractPercent=20\n causes the heap to contract by as much as 20%.\n\n\n\n\n\n\noverrideHiresTimerCheck\n\n\n    -Xgc:overrideHiresTimerCheck\n\n\n\n\n\n\n\n\n\nWhen the VM starts, the GC checks that the operating system can meet the timer resolution requirements for the requested target pause time. Typically, this check correctly identifies operating systems that can deliver adequate time resolution. However, in some cases the operating system provides a more conservative answer than strictly necessary for GC pause time management, which prevents startup. Specifying this parameter causes the GC to ignore the answer returned by the operating system. The VM starts, but GC pause time management remains subject to operating system performance, which might not provide adequate timer resolution.\n\n\n \nNote:\n Use this option with caution, and only when you are unable to use a supported operating system.\n\n\n\n\n\n\npreferredHeapBase\n\n\n(AIX, Linux, Windows only)\n\n\n    -Xgc:preferredHeapBase=<address>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nValue\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n<value>\n\n\n[hexadecimal]\n\n\n-\n\n\n\n\n\n\n\n\n\n\n\n\nwhere, \n<address>\n is the base memory address for the heap. Use this option with the \n-Xcompressedrefs\n option to allocate the heap you specify with the \n-Xmx\n option, in a memory range of your choice. If \n-Xcompressedrefs\n is not specified, this option has no effect. In the following example, the heap is located at the 4 GB mark, leaving the lowest 4 GB of address space for use by other processes.\n\n\n-\nXgc\n:\npreferredHeapBase\n=\n0x100000000\n\n\n\n\n\n\nIf the heap cannot be allocated in a contiguous block at the \npreferredHeapBase\n address you specified, an error occurs detailing a Garbage Collection (GC) allocation failure startup. When the \npreferredHeapBase\n option is used with the \n-Xlp\n option, the \npreferredHeapBase\n address must be a multiple of the large page size. If you specify an inaccurate heap base address, the heap is allocated with the default page size.\n\n\n\n\n\n\nscvNoAdaptiveTenure\n\n\n    -Xgc:scvNoAdaptiveTenure\n\n\n\n\n\n\n\nTurns off the adaptive tenure age in the generational concurrent GC policy. The initial age that is set is maintained throughout the run time of the VM. See \nscvTenureAge\n.\n\n\n\n\nscvTenureAge\n\n\n    -Xgc:scvTenureAge=<n>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nValue\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n<n>\n\n\n[1 - 14]\n\n\n10\n\n\n\n\n\n\n\n\n\n\n\n\nSets the initial scavenger tenure age in the generational concurrent GC policy. For more information, see \nTenure age\n.\n\n\n\n\n\n\ntlhIncrementSize\n\n\n    -Xgc:tlhIncrementSize=<bytes>\n\n\n\n\n\n\n\nSets the increment size of the thread local heap (TLH), which plays a key role in cache allocation. Threads start creating TLHs with a predefined initial size (default 2 KB). On every TLH refresh, the requested size for that thread is increased by an increment (default 4 KB). Use this option to control the increment size.\n\n\n\n\ntlhInitialSize\n\n\n    -Xgc:tlhInitialSize=<bytes>\n\n\n\n\n\n\n\nSets the initial size of the TLH. The default size is 2 KB.\n\n\n\n\ntlhMaximumSize\n\n\n    -Xgc:tlhMaximumSize=<bytes>\n\n\n\n\n\n\n\nSets the maximum size of the TLH. The size of the TLH varies from 512 bytes (768 on 64-bit JVMs) to 128 KB, depending on the allocation rate of the thread.\nLarger TLHs can help reduce heap lock contention, but might also reduce heap utilisation and increase heap fragmentation. Typically, when the maximum TLH size is increased, you should also increase the increment size (\n-XtlhIncrementSize\n) proportionally, so that active threads can reach the maximum requested TLH size more quickly.\n\n\n\n\nverboseFormat\n\n\n    -Xgc:verboseFormat=<format>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nValue\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n<format>\n\n\ndefault\n\n\nyes\n\n\n\n\n\n\n\n\ndeprecated\n\n\n\n\n\n\n\n\n\n\n\n\ndefault\n: The default verbose garbage collection format for OpenJ9. For more information, see \nVerbose garbage collection logging\n.\n\n\ndeprecated\n: The verbose garbage collection format available in the IBM J9 VM V2.4 and earlier.",
             "title": "-Xgc"
         },
         {
@@ -1787,7 +1787,7 @@
         },
         {
             "location": "/xgc/#concurrentscavenge",
-            "text": "(64-bit: not AIX or Linux on IBM Power Systems)      -Xgc:concurrentScavenge    This option supports pause-less garbage collection mode. If you set this option, the VM attempts to reduce GC pause times for response-time sensitive, large-heap applications.  The following restrictions apply:    The Generational Concurrent ( gencon ) garbage collection policy must be used. (This is the default policy.)    Compressed references must be used. See  -Xcompressedrefs . (Compressed references are enabled by default when the maximum heap size ( -Xmx ) \u2264 57 GB. The concurrent scavenge option is ignored if the maximum heap size is > 57 GB.)      Note: Linux on Z and z/OS  This option is supported on IBM z14\u2122 hardware running the following software:  Operating systems:   z/OS V2R3  z/OS V2R2 and  APAR OA51643 .  RHEL 7.5 (minimum kernel level 4.14)  Ubuntu 18.04 (minimum kernel level 4.15)   Hypervisors:   IBM z/VM 6.4 with  APAR VM65987  KVM solutions with QEMU 2.10 or later and minimum host kernel level 4.12 (for example, RHEL 7.5 with kernel level 4.14)   If these requirements are not met, the option is ignored.    Note:  On z/OS, the virtual storage used might exceed the Java maximum heap size. Set the z/OS memory limit, specified by  ulimit -M , to a larger value than the maximum heap size.",
+            "text": "(64-bit: Linux on x86, Linux on IBM Z\u00ae, or z/OS\u00ae only)      -Xgc:concurrentScavenge    This option supports pause-less garbage collection mode. If you set this option, the VM attempts to reduce GC pause times for response-time sensitive, large-heap applications.  The following restrictions apply:    The Generational Concurrent ( gencon ) garbage collection policy must be used. (This is the default policy.)    Compressed references must be used. See  -Xcompressedrefs . (Compressed references are enabled by default when the maximum heap size ( -Xmx ) \u2264 57 GB. The concurrent scavenge option is ignored if the maximum heap size is > 57 GB.)      Note: Linux on Z and z/OS  This option is supported on IBM z14\u2122 hardware running the following software:  Operating systems:   z/OS V2R3  z/OS V2R2 and  APAR OA51643 .  RHEL 7.5 (minimum kernel level 4.14)  Ubuntu 18.04 (minimum kernel level 4.15)   Hypervisors:   IBM z/VM 6.4 with  APAR VM65987  KVM solutions with QEMU 2.10 or later and minimum host kernel level 4.12 (for example, RHEL 7.5 with kernel level 4.14)   If these requirements are not met, the option is ignored.    Note:  On z/OS, the virtual storage used might exceed the Java maximum heap size. Set the z/OS memory limit, specified by  ulimit -M , to a larger value than the maximum heap size.",
             "title": "concurrentScavenge"
         },
         {
diff --git a/sitemap.xml b/sitemap.xml
index b8888ee..b5fc7c9 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -4,7 +4,7 @@
     
     <url>
      <loc>https://www.eclipse.org/openj9/docs/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -12,7 +12,7 @@
     
     <url>
      <loc>https://www.eclipse.org/openj9/docs/introduction/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -21,25 +21,25 @@
         
     <url>
      <loc>https://www.eclipse.org/openj9/docs/version0.11/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://www.eclipse.org/openj9/docs/version0.10/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://www.eclipse.org/openj9/docs/version0.9/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://www.eclipse.org/openj9/docs/version0.8/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
@@ -48,7 +48,7 @@
     
     <url>
      <loc>https://www.eclipse.org/openj9/docs/gc/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -56,7 +56,7 @@
     
     <url>
      <loc>https://www.eclipse.org/openj9/docs/jit/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -64,7 +64,7 @@
     
     <url>
      <loc>https://www.eclipse.org/openj9/docs/aot/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -72,7 +72,7 @@
     
     <url>
      <loc>https://www.eclipse.org/openj9/docs/shrc/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
@@ -81,25 +81,25 @@
         
     <url>
      <loc>https://www.eclipse.org/openj9/docs/diag_overview/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://www.eclipse.org/openj9/docs/dump_javadump/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://www.eclipse.org/openj9/docs/dump_heapdump/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://www.eclipse.org/openj9/docs/dump_systemdump/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
@@ -109,19 +109,19 @@
         
     <url>
      <loc>https://www.eclipse.org/openj9/docs/cmdline_specifying/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://www.eclipse.org/openj9/docs/cmdline_general/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://www.eclipse.org/openj9/docs/cmdline_migration/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
@@ -149,19 +149,19 @@
         
     <url>
      <loc>https://www.eclipse.org/openj9/docs/tool_jdmpview/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://www.eclipse.org/openj9/docs/tool_traceformat/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://www.eclipse.org/openj9/docs/tool_builder/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
@@ -171,31 +171,31 @@
         
     <url>
      <loc>https://www.eclipse.org/openj9/docs/openj9_support/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://www.eclipse.org/openj9/docs/openj9_defaults/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://www.eclipse.org/openj9/docs/openj9_directories/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://www.eclipse.org/openj9/docs/messages_intro/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
     <url>
      <loc>https://www.eclipse.org/openj9/docs/env_var/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
         
@@ -204,7 +204,7 @@
     
     <url>
      <loc>https://www.eclipse.org/openj9/docs/legal/</loc>
-     <lastmod>2018-10-24</lastmod>
+     <lastmod>2018-10-26</lastmod>
      <changefreq>daily</changefreq>
     </url>
     
diff --git a/version0.11/index.html b/version0.11/index.html
index 88f0553..74f7d8f 100644
--- a/version0.11/index.html
+++ b/version0.11/index.html
@@ -390,8 +390,8 @@
 </li>
       
         <li class="md-nav__item">
-  <a href="#pause-less-garbage-collection-mode-is-now-available-on-x86-platforms" title="Pause-less garbage collection mode is now available on x86 platforms" class="md-nav__link">
-    Pause-less garbage collection mode is now available on x86 platforms
+  <a href="#pause-less-garbage-collection-mode-is-now-available-on-linux-x86-platforms" title="Pause-less garbage collection mode is now available on Linux x86 platforms" class="md-nav__link">
+    Pause-less garbage collection mode is now available on Linux x86 platforms
   </a>
   
 </li>
@@ -2961,8 +2961,8 @@
 </li>
       
         <li class="md-nav__item">
-  <a href="#pause-less-garbage-collection-mode-is-now-available-on-x86-platforms" title="Pause-less garbage collection mode is now available on x86 platforms" class="md-nav__link">
-    Pause-less garbage collection mode is now available on x86 platforms
+  <a href="#pause-less-garbage-collection-mode-is-now-available-on-linux-x86-platforms" title="Pause-less garbage collection mode is now available on Linux x86 platforms" class="md-nav__link">
+    Pause-less garbage collection mode is now available on Linux x86 platforms
   </a>
   
 </li>
@@ -3041,7 +3041,7 @@
 <li><img alt="Start of content that applies only to Java 11 (LTS)" src="../cr/java11.png" /> <a href="#changes-to-the-location-of-the-default-shared-cache-and-cache-snapshot-directory">Changes to the location of the default shared cache and cache snapshot directory</a></li>
 <li><a href="#new-class-data-sharing-suboptions">New class data sharing suboptions</a></li>
 <li><a href="#container-awareness-in-the-openj9-vm-is-now-enabled-by-default">Container awareness in the OpenJ9 VM is now enabled by default</a></li>
-<li><a href="#pause-less-garbage-collection-mode-is-now-available-on-x86-platforms">Pause-less garbage collection mode is now available on x86 platforms</a></li>
+<li><a href="#pause-less-garbage-collection-mode-is-now-available-on-x86-platforms">Pause-less garbage collection mode is now available on Linux x86 platforms</a></li>
 <li><a href="#you-can-now-restrict-identity-hash-codes-to-non-negative-values">You can now restrict identity hash codes to non-negative values</a></li>
 <li><a href="#support-for-openjdk-hotspot-options">Support for OpenJDK HotSpot options</a></li>
 </ul>
@@ -3077,9 +3077,9 @@
 <h2 id="container-awareness-in-the-openj9-vm-is-now-enabled-by-default">Container awareness in the OpenJ9 VM is now enabled by default</h2>
 <p>When using container technology, applications are typically run on their own and do not need to compete for memory. If the VM detects that it is running in a container environment, and a memory limit for the container is set, the VM automatically adjusts the maximum default Java heap size.</p>
 <p>In earlier releases, this behavior was enabled by setting the <code>-XX:+UseContainerSupport</code> option. This setting is now the default. For more information
-about the Java heap size set for a container, see <a href="xxusercontainersupport.md">-XX:[+|-]UseContainerSupport</a>.</p>
-<h2 id="pause-less-garbage-collection-mode-is-now-available-on-x86-platforms">Pause-less garbage collection mode is now available on x86 platforms</h2>
-<p>Pause-less garbage collection mode is aimed at large heap, response-time sensitive applications. When enabled, the VM attempts to reduce GC pause times. In earlier releases, pause-less garbage collection mode (<a href="../xgc/#concurrentscavenge"><code>-Xgc:concurrentScavenge</code></a>) was available only on IBM z14 hardware. This mode is now available on 64-bit x86 Linux and Windows platforms.</p>
+about the Java heap size set for a container, see <a href="../xxusecontainersupport/">-XX:[+|-]UseContainerSupport</a>.</p>
+<h2 id="pause-less-garbage-collection-mode-is-now-available-on-linux-x86-platforms">Pause-less garbage collection mode is now available on Linux x86 platforms</h2>
+<p>Pause-less garbage collection mode is aimed at large heap, response-time sensitive applications. When enabled, the VM attempts to reduce GC pause times. In earlier releases, pause-less garbage collection mode (<a href="../xgc/#concurrentscavenge"><code>-Xgc:concurrentScavenge</code></a>) was available only on IBM z14 hardware. This mode is now available on 64-bit x86 Linux platforms.</p>
 <p><i class="fa fa-exclamation-triangle" aria-hidden="true"></i> <strong>Restrictions:</strong></p>
 <ul>
 <li>The Generational Concurrent (<code>gencon</code>) garbage collection policy must be used. (This is the default policy.)</li>
diff --git a/xgc/index.html b/xgc/index.html
index 8a7e33b..25aab97 100644
--- a/xgc/index.html
+++ b/xgc/index.html
@@ -3220,7 +3220,7 @@
 </tbody>
 </table>
 <h3 id="concurrentscavenge"><code>concurrentScavenge</code></h3>
-<p><strong>(64-bit: not AIX or Linux on IBM Power Systems)</strong></p>
+<p><strong>(64-bit: Linux on x86, Linux on IBM Z&reg;, or z/OS&reg; only)</strong></p>
 <div class="codehilite"><pre><span></span>    -Xgc:concurrentScavenge
 </pre></div>