Google Git
Sign in
eclipse / www.eclipse.org / openj9 / docs / 9928a8f694bd49ebde48a7d520752862c99d9cb6 / . / search / search_index.json
blob: 6eda621a8e99f952eb5be7a388cb2c3bf3c877fd [file] [log] [blame]
{
"docs": [
{
"location": "/",
"text": "Eclipse OpenJ9\n\n\nWelcome to the user documentation for the Eclipse OpenJ9 virtual machine (VM).\n\n\nThis 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:\n\n\n This sentence applies only to Java 8 binaries that include the OpenJ9 VM. Icons for LTS releases are this colour. \n\n\n This sentence applies only to Java 10 or later binaries that include the OpenJ9 VM. Icons for feature releases are this colour. \n\n\nTo see which Java releases are LTS releases and which are feature releases, and for information about release cadence, supported platforms, and build environments, see \nSupported environments\n.\n\n\n \nNote:\n Documentation to support OpenJ9 is still under construction. The current content covers\nsome 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. We expect further content to be contributed over time. Because OpenJ9 was contributed to the Eclipse Foundation by IBM, this content contains some links to additional information that forms part of the \nIBM\u00ae SDK, Java\u2122 Technology Edition product documentation\n in IBM Knowledge Center. That content supplements the documentation here until a more complete set of user documentation is available.\n\n\nWe welcome contributions to the user documentation. If you would like to get involved, please read our \nContribution guidelines\n. If you spot any errors in the documentation, please raise an \nissue\n at our GitHub repository.\n\n\nSupported environments\n\n\nOpenJDK 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 \ncurrent list of supported environments\n for details.\n\n\n \nNote:\n This user guide contains information about configuring, tuning, and debugging OpenJ9 on the z/OS\u00ae platform. This content was contributed by IBM so that it is available when the work to create OpenJDK binaries for the z/OS platform is complete.\n\n\nUseful links\n\n\n\n\nEclipse OpenJ9 website home page\n\n\nEclipse OpenJ9 GitHub repository\n\n\nEclipse Foundation OpenJ9 project page\n\n\n\n\nYou can obtain pre-built OpenJDK binaries from the AdoptOpenJDK project:\n\n\n\n\nOpenJDK8 with OpenJ9\n\n\nOpenJDK10 with OpenJ9\n\n\nOpenJDK11 with OpenJ9",
"title": "About"
},
{
"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 8 binaries that include the OpenJ9 VM. Icons for LTS releases are this colour. This sentence applies only to Java 10 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\nsome 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. We expect further content to be contributed over time. 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 Knowledge Center. 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 contains information about configuring, tuning, and debugging OpenJ9 on the z/OS\u00ae platform. This content was contributed by IBM so that it is available when the work to create OpenJDK binaries for the z/OS platform is complete.",
"title": "Supported environments"
},
{
"location": "/#useful-links",
"text": "Eclipse OpenJ9 website home page Eclipse OpenJ9 GitHub repository Eclipse Foundation OpenJ9 project page You can obtain pre-built OpenJDK binaries from the AdoptOpenJDK project: OpenJDK8 with OpenJ9 OpenJDK10 with OpenJ9 OpenJDK11 with OpenJ9",
"title": "Useful links"
},
{
"location": "/introduction/",
"text": "Eclipse OpenJ9\n\n\nOpenJ9 is a high performance, scalable, Java\u2122 virtual machine (VM) implementation that is fully compliant with the \nJava Virtual Machine Specification\n.\n\n\nAt 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\u2122, z/OS\u00ae, or Windows\u2122.\n\n\nThis reference material provides information about the VM configuration and tuning options, together with the default settings.\n\n\nConfiguring your system\n\n\nFor normal operation, certain environment variables must be set at the operating system level. Depending on your system environment, you might also want to set other configuration options that allow the VM to exploit hardware and operating system features. Read \nCustomizing your system\n to learn more about the following options:\n\n\n\n\nSetting the PATH and CLASSPATH environment variable.\n\n\nSetting the LIBPATH or LD_LIBRARY_PATH environment variable (AIX\u00ae and Linux).\n\n\nSetting ulimits on AIX and Linux systems to ensure that the operating system allocates sufficient resources for your application.\n\n\nSetting region size, BPXPRM parameters, and Language Environment\u00ae runtime options on z/OS systems.\n\n\nIf your application allocates a large amount of memory and frequently accesses that memory, you might want to enable large page support on your system. See \nConfiguring large page memory allocation\n.\n\n\nConfiguring Dynamic LPAR support on AIX systems.\n\n\n\n\nPerformance tuning\n\n\nOpenJ9 is configured to start with a set of default options that provide the optimal runtime environment for Java applications with typical workloads. However, if your application is atypical, you can improve performance by tuning the OpenJ9 VM. You can also improve performance by enabling hardware features or using specific APIs in your application code.\n\n\nGarbage collection policies\n\n\nOpenJ9 includes several garbage collection policies. To learn more about these policies and the types of application workload that can benefit from them, see \nGarbage Collection\n.\n\n\nClass data sharing\n\n\nYou can share class data between running VMs, which can reduce the startup time for a VM once the cache has been created. For more information, see \nClass Data Sharing\n.\n\n\nNative data operations\n\n\nIf your Java application manipulates native data, consider writing your application to take advantage of methods in the Data Access Accelerator API.\n\n\nCloud optimizations\n\n\nTo improve the performance of applications that run in the cloud, try setting the following tuning options:\n\n\n\n\nUse a shared classes cache (\n-Xshareclasses -XX:SharedCacheHardLimit=200m -Xscmx60m\n) with Ahead-Of-Time (AOT) compilation to improve your startup time. For more information, see \nClass Data Sharing\n and \nAOT Compiler\n.\n\n\nUse the idle VM settings to maintain a smaller footprint, which can generate cost savings for cloud services that charge based on memory usage. The idle tuning mechanism detects when the VM is idle, releasing free memory pages to keep the footprint as small as possible and keep your running costs to a minimum. For more information, see \n-XX:IdleTuningMinIdleWaitTime\n.\n\n\nUse the \n-Xtune:virtualized\n option, which configures OpenJ9 for typical cloud deployments where VM guests are provisioned with a small number of virtual CPUs to maximize the number of applications that can be run. When enabled, OpenJ9 adapts its internal processes to reduce the amount of CPU consumed and trim down the memory footprint. These changes come at the expense of only a small loss in throughput.\n\n\n\n\nRuntime options\n\n\nRuntime options are specified on the command line and include system properties, standard options, nonstandard (\n-X\n) options, and \n-XX\n options. For a detailed list of runtime options, see \nOpenJ9 command-line options\n\n\nDefault settings\n\n\nIf you do not specify any options on the command line at run time, the OpenJ9 VM starts with default settings that define how it operates. For more information about these settings, see \nDefault settings for the OpenJ9 VM\n.\n\n\nTroubleshooting\n\n\nThe OpenJ9 diagnostic component contains extensive features to assist with problem determination. Diagnostic data is produced under default conditions, but can also be controlled by starting the VM with the \n-Xdump option\n or using the \ncom.ibm.jvm.Dump\n API. You can also trace Java applications, methods, and VM operations by using the \n-Xtrace option\n.\n\n\nTo get started, read \nDiagnostic tools and data\n.",
"title": "Introduction"
},
{
"location": "/introduction/#eclipse-openj9",
"text": "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\u2122, z/OS\u00ae, or Windows\u2122. This reference material provides information about the VM configuration and tuning options, together with the default settings.",
"title": "Eclipse OpenJ9"
},
{
"location": "/introduction/#configuring-your-system",
"text": "For normal operation, certain environment variables must be set at the operating system level. Depending on your system environment, you might also want to set other configuration options that allow the VM to exploit hardware and operating system features. Read Customizing your system to learn more about the following options: Setting the PATH and CLASSPATH environment variable. Setting the LIBPATH or LD_LIBRARY_PATH environment variable (AIX\u00ae and Linux). Setting ulimits on AIX and Linux systems to ensure that the operating system allocates sufficient resources for your application. Setting region size, BPXPRM parameters, and Language Environment\u00ae runtime options on z/OS systems. If your application allocates a large amount of memory and frequently accesses that memory, you might want to enable large page support on your system. See Configuring large page memory allocation . Configuring Dynamic LPAR support on AIX systems.",
"title": "Configuring your system"
},
{
"location": "/introduction/#performance-tuning",
"text": "OpenJ9 is configured to start with a set of default options that provide the optimal runtime environment for Java applications with typical workloads. However, if your application is atypical, you can improve performance by tuning the OpenJ9 VM. You can also improve performance by enabling hardware features or using specific APIs in your application code.",
"title": "Performance tuning"
},
{
"location": "/introduction/#garbage-collection-policies",
"text": "OpenJ9 includes several garbage collection policies. To learn more about these policies and the types of application workload that can benefit from them, see Garbage Collection .",
"title": "Garbage collection policies"
},
{
"location": "/introduction/#class-data-sharing",
"text": "You can share class data between running VMs, which can reduce the startup time for a VM once the cache has been created. For more information, see Class Data Sharing .",
"title": "Class data sharing"
},
{
"location": "/introduction/#native-data-operations",
"text": "If your Java application manipulates native data, consider writing your application to take advantage of methods in the Data Access Accelerator API.",
"title": "Native data operations"
},
{
"location": "/introduction/#cloud-optimizations",
"text": "To improve the performance of applications that run in the cloud, try setting the following tuning options: Use a shared classes cache ( -Xshareclasses -XX:SharedCacheHardLimit=200m -Xscmx60m ) with Ahead-Of-Time (AOT) compilation to improve your startup time. For more information, see Class Data Sharing and AOT Compiler . Use the idle VM settings to maintain a smaller footprint, which can generate cost savings for cloud services that charge based on memory usage. The idle tuning mechanism detects when the VM is idle, releasing free memory pages to keep the footprint as small as possible and keep your running costs to a minimum. For more information, see -XX:IdleTuningMinIdleWaitTime . Use the -Xtune:virtualized option, which configures OpenJ9 for typical cloud deployments where VM guests are provisioned with a small number of virtual CPUs to maximize the number of applications that can be run. When enabled, OpenJ9 adapts its internal processes to reduce the amount of CPU consumed and trim down the memory footprint. These changes come at the expense of only a small loss in throughput.",
"title": "Cloud optimizations"
},
{
"location": "/introduction/#runtime-options",
"text": "Runtime options are specified on the command line and include system properties, standard options, nonstandard ( -X ) options, and -XX options. For a detailed list of runtime options, see OpenJ9 command-line options",
"title": "Runtime options"
},
{
"location": "/introduction/#default-settings",
"text": "If you do not specify any options on the command line at run time, the OpenJ9 VM starts with default settings that define how it operates. For more information about these settings, see Default settings for the OpenJ9 VM .",
"title": "Default settings"
},
{
"location": "/introduction/#troubleshooting",
"text": "The OpenJ9 diagnostic component contains extensive features to assist with problem determination. Diagnostic data is produced under default conditions, but can also be controlled by starting the VM with the -Xdump option or using the com.ibm.jvm.Dump API. You can also trace Java applications, methods, and VM operations by using the -Xtrace option . To get started, read Diagnostic tools and data .",
"title": "Troubleshooting"
},
{
"location": "/version0.10/",
"text": "What's new in version 0.10.0\n\n\nThe following new features and notable changes since v.0.9.0 are included in this release:\n\n\n\n\nNew binaries and changes to supported environments.\n\n\nChange to the default shared classes cache size for OpenJDK 8 builds\n\n\nNew information for the SHARED CLASSES section of a Javadump file\n\n\nSupport for OpenJDK HotSpot options\n\n\n\n\nBinaries and supported environments\n\n\nOpenJ9 release 0.10.0 supports OpenJDK 11, which is available from the AdoptOpenJDK community at the following link:\n\n\n\n\nOpenJDK version 11\n\n\n\n\nOpenJDK 11 with Eclipse OpenJ9 is a long term support (LTS) release and supersedes OpenJDK 10 with Eclipse OpenJ9.\n\n\nAlthough it is possible to build an OpenJDK v8 with the OpenJ9 0.10.0 release level, testing at the project is not complete and therefore support is not available.\n\n\nTo learn more about support for OpenJ9 releases, including OpenJDK levels and platform support, see \nSupported environments\n\n\nChange to the default shared classes cache size\n\n\nFor OpenJDK 8 builds, the default shared classes cache size is increased from 16 MB to 300 MB, with a \"soft\" maximum limit for the initial size of the cache set to 64 MB. Certain exceptions apply. For more information, see \n-Xshareclasses\n. The new default also applies to OpenJDK 11 builds.\n\n\nNew information for the SHARED CLASSES section of a Java dump file\n\n\nThe value of the soft maximum size (\n-Xscmx\n) of the shared classes cache is now recorded in the \nSHARED CLASSES\n section of a Java dump file against the string \n2SCLTEXTSMB\n. For example output, see \nJava dump\n.\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:HeapDumpPath\n\n\n-XX:[+|-]HeapDumpOnOutOfMemory\n\n\n-XX:ActiveProcessorCount\n\n\n\n\nFull release information\n\n\nTo see a complete list of changes between Eclipse OpenJ9 V0.9.0 and V0.10.0 releases, see the \nRelease notes\n.",
"title": "Version 0.10.0"
},
{
"location": "/version0.10/#whats-new-in-version-0100",
"text": "The following new features and notable changes since v.0.9.0 are included in this release: New binaries and changes to supported environments. Change to the default shared classes cache size for OpenJDK 8 builds New information for the SHARED CLASSES section of a Javadump file Support for OpenJDK HotSpot options",
"title": "What's new in version 0.10.0"
},
{
"location": "/version0.10/#binaries-and-supported-environments",
"text": "OpenJ9 release 0.10.0 supports OpenJDK 11, which is available from the AdoptOpenJDK community at the following link: OpenJDK version 11 OpenJDK 11 with Eclipse OpenJ9 is a long term support (LTS) release and supersedes OpenJDK 10 with Eclipse OpenJ9. Although it is possible to build an OpenJDK v8 with the OpenJ9 0.10.0 release level, testing at the project is not complete and therefore support is not available. To learn more about support for OpenJ9 releases, including OpenJDK levels and platform support, see Supported environments",
"title": "Binaries and supported environments"
},
{
"location": "/version0.10/#change-to-the-default-shared-classes-cache-size",
"text": "For OpenJDK 8 builds, the default shared classes cache size is increased from 16 MB to 300 MB, with a \"soft\" maximum limit for the initial size of the cache set to 64 MB. Certain exceptions apply. For more information, see -Xshareclasses . The new default also applies to OpenJDK 11 builds.",
"title": "Change to the default shared classes cache size"
},
{
"location": "/version0.10/#new-information-for-the-shared-classes-section-of-a-java-dump-file",
"text": "The value of the soft maximum size ( -Xscmx ) of the shared classes cache is now recorded in the SHARED CLASSES section of a Java dump file against the string 2SCLTEXTSMB . For example output, see Java dump .",
"title": "New information for the SHARED CLASSES section of a Java dump file"
},
{
"location": "/version0.10/#support-for-openjdk-hotspot-options",
"text": "For compatibility, the following OpenJDK Hotspot options are now supported by OpenJ9: -XX:HeapDumpPath -XX:[+|-]HeapDumpOnOutOfMemory -XX:ActiveProcessorCount",
"title": "Support for OpenJDK HotSpot options"
},
{
"location": "/version0.10/#full-release-information",
"text": "To see a complete list of changes between Eclipse OpenJ9 V0.9.0 and V0.10.0 releases, see the Release notes .",
"title": "Full release information"
},
{
"location": "/version0.9/",
"text": "What's new in version 0.9.0\n\n\nThe following new features and notable changes from v.0.8.0 are included in this release:\n\n\n\n\nNew binaries and supported environments.\n\n\nThe idle tuning feature is now supported on Linux running on Power\u00ae Systems and IBM Z\u00ae Systems.\n\n\nA new Garbage Collection (GC) policy is available that performs no housekeeping.\n\n\nA command line option is provided to automatically set a larger Java heap size for applications that run in containers.\n\n\nYou can now specify the maximum Java heap size as a percentage value.\n\n\nThe shared classes feature now supports nested jar files.\n\n\nSystem dump data can now be read to help diagnose problems on Linux and Windows platforms.\n\n\nThere are notable changes to the \njava.lang.String\n class.\n\n\nThere are notable changes to the \ncom.ibm.oti.shared.SharedClassCacheInfo\n class.\n\n\n\n\nBinaries and supported platforms\n\n\nThe following additional OpenJDK binaries that contain the OpenJ9 VM are now available from the AdoptOpenJDK community:\n\n\n\n\nOpenJDK version 10\n\n\nOpenJDK version 8 for 32-bit Windows\n\n\nOpenJDK version 8 for x86 64-bit Linux (Large Heap)\n for Java heaps >57 GB.\n\n\n\n\nComplete platform support information for OpenJ9 can be found in \nSupported environments\n\n\nIdle tuning feature\n\n\nThe idle tuning feature in OpenJ9 keeps your memory footprint small by releasing unused memory back to the\noperating system. Prior to Eclipse v0.9.0 this feature was available only on Linux x86 architectures with the\n\ngencon\n garbage collection policy. From v0.9.0, this feature is now available on Linux for IBM POWER\u00ae and IBM Z\u00ae architectures.\nFor more information about this feature, see the following command line options, which control this\nbehavior:\n\n\n\n\n-XX:[+|-]IdleTuningCompactOnIdle\n\n\n-XX:[+|-]IdleTuningGcOnIdle\n\n\n-XX:IdleTuningMinIdleWaitTime\n\n\n-XX:IdleTuningMinFreeHeapOnIdle\n\n\n\n\nThe following blog post describes the benefits of using this feature: \nAre you still paying for unused memory when your Java app is idle?\n\n\nNew GC policy\n\n\nA new GC policy is introduced for \nJEP 318: Epsilon: A No-Op Garbage Collector\n.\n\n\nWhen this policy is enabled, the Java object heap is expanded in the normal way until the limit is\nreached, but memory is not reclaimed through garbage collection. When the limit is reached the VM shuts down.\n\n\nThis JEP has a number of use cases including short-lived applications and certain test scenarios.\n\n\nTo enable this policy you can use one of the following options:\n\n\n\n\n-Xgcpolicy:nogc\n\n\n-XX:+UseNoGC\n\n\n\n\nModifying the default Java heap size for applications that run in containers\n\n\nWhen using container technology, applications are typically run on their own and do not need to compete for memory. In this release, changes\nare introduced to detect when OpenJ9 is running inside a container. If your application is running in a container and\nyou want the VM to allocate a larger fraction of memory to the Java heap, set the \n-XX:+UseContainerSupport\n option on the command line.\n\n\nThe following table shows the maximum Java heap size that gets set, depending on the memory available:\n\n\n\n\n\n\n\n\nPhysical memory \n<size>\n\n\nMaximum Java heap size\n\n\n\n\n\n\n\n\n\n\nLess than 1 GB\n\n\n50% \n<size>\n\n\n\n\n\n\n1 GB - 2 GB\n\n\n<size>\n - 512M\n\n\n\n\n\n\nGreater than 2 GB\n\n\n75% \n<size>\n\n\n\n\n\n\n\n\nThe default heap size for containers only takes affect when running in a container environment and when \n-XX:+UseContainerSupport\n is specified,\nwhich is expected to be the default in a future release.\n\n\nSpecifying the maximum Java heap size as a percentage value\n\n\nOpenJ9 now supports setting the heap size as a percentage of the physical memory. The following OpenJDK options are recognized and can be\nset for the VM:\n\n\n\n\n-XX:MaxRAMPercentage\n\n\n-XX:InitialRAMPercentage\n\n\n\n\nTo understand how to set these options, see \n-XX:MaxRAMPercentage\n and \n-XX:InitialRAMPercentage\n.\n\n\nIf your application is running in a container and you have specified \n-XX:+UseContainerSupport\n, as described in \nModifying the default Java heap size for applications that run in containers\n, both the default heap size for containers and the \n-XX:MaxRAMPercentage\n and \n-XX:InitialRAMPercentage\n\noptions are based on the available container memory.\n\n\nShared classes support for nested jar files\n\n\nChanges are made to the \ncom.ibm.oti.shared\n API to support nested jar files.\n\n\nDirect Dump Reader enabled on Linux and Windows\n\n\nDirect Dump Reader (DDR) support is now enabled for the OpenJ9 VM on all Linux architectures and on Windows. The DDR code enables the VM to read system dump data by using the OpenJ9 Diagnostic Tool\nFramework for Java (DTFJ) API or the \njdmpview\n tool. If you use the \nEclipse Memory Analyzer Tool (MAT)\n, you can also analyze OpenJ9 or IBM VMs by installing the DTFJ plugin.\n(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)\n\n\nYou must use a 32-bit JVM to look at a 32-bit core, and a 64-bit JVM to look at a 64-bit core. This restriction will be fixed in a later version of OpenJ9.\n\n\nChanges to the \njava.lang.String\n class\n\n\n To match the behavior of OpenJDK, \njava.lang.String\n no longer has a count field, which changes the way that \nString.subString()\n works compared to Java 8. \nString.subString()\n now copies the value array. Similarly, \nStringBuffer\n and \nStringBuilder\n do not share the value array with any \nString\n created by \ntoString()\n.\n\n\nFor performance and compatibility with the new String object layout, the OpenJ9 implementations of \nStringBuffer\n and \nStringBuilder\n have been deprecated in favor of the OpenJDK implementations.\n\n\n\nChanges to the \nSharedClassCacheInfo\n class\n\n\n \nSharedClassCacheInfo.getCacheJVMLevel()\n used to return the JVMLEVEL constant that maps to a Java version number, for example \nJVMLEVEL_JAVA8\n. This call now returns only the Java version number, for example \n10\n for Java 10.\n\n\n\nFull release information\n\n\nTo see a complete list of changes between Eclipse OpenJ9 V0.8.0 and V0.9.0 releases, see the \nRelease notes\n.",
"title": "Version 0.9.0"
},
{
"location": "/version0.9/#whats-new-in-version-090",
"text": "The following new features and notable changes from v.0.8.0 are included in this release: New binaries and supported environments. The idle tuning feature is now supported on Linux running on Power\u00ae Systems and IBM Z\u00ae Systems. A new Garbage Collection (GC) policy is available that performs no housekeeping. A command line option is provided to automatically set a larger Java heap size for applications that run in containers. You can now specify the maximum Java heap size as a percentage value. The shared classes feature now supports nested jar files. System dump data can now be read to help diagnose problems on Linux and Windows platforms. There are notable changes to the java.lang.String class. There are notable changes to the com.ibm.oti.shared.SharedClassCacheInfo class.",
"title": "What's new in version 0.9.0"
},
{
"location": "/version0.9/#binaries-and-supported-platforms",
"text": "The following additional OpenJDK binaries that contain the OpenJ9 VM are now available from the AdoptOpenJDK community: OpenJDK version 10 OpenJDK version 8 for 32-bit Windows OpenJDK version 8 for x86 64-bit Linux (Large Heap) for Java heaps >57 GB. Complete platform support information for OpenJ9 can be found in Supported environments",
"title": "Binaries and supported platforms"
},
{
"location": "/version0.9/#idle-tuning-feature",
"text": "The idle tuning feature in OpenJ9 keeps your memory footprint small by releasing unused memory back to the\noperating system. Prior to Eclipse v0.9.0 this feature was available only on Linux x86 architectures with the gencon garbage collection policy. From v0.9.0, this feature is now available on Linux for IBM POWER\u00ae and IBM Z\u00ae architectures.\nFor more information about this feature, see the following command line options, which control this\nbehavior: -XX:[+|-]IdleTuningCompactOnIdle -XX:[+|-]IdleTuningGcOnIdle -XX:IdleTuningMinIdleWaitTime -XX:IdleTuningMinFreeHeapOnIdle The following blog post describes the benefits of using this feature: Are you still paying for unused memory when your Java app is idle?",
"title": "Idle tuning feature"
},
{
"location": "/version0.9/#new-gc-policy",
"text": "A new GC policy is introduced for JEP 318: Epsilon: A No-Op Garbage Collector . When this policy is enabled, the Java object heap is expanded in the normal way until the limit is\nreached, but memory is not reclaimed through garbage collection. When the limit is reached the VM shuts down. This JEP has a number of use cases including short-lived applications and certain test scenarios. To enable this policy you can use one of the following options: -Xgcpolicy:nogc -XX:+UseNoGC",
"title": "New GC policy"
},
{
"location": "/version0.9/#modifying-the-default-java-heap-size-for-applications-that-run-in-containers",
"text": "When using container technology, applications are typically run on their own and do not need to compete for memory. In this release, changes\nare introduced to detect when OpenJ9 is running inside a container. If your application is running in a container and\nyou want the VM to allocate a larger fraction of memory to the Java heap, set the -XX:+UseContainerSupport option on the command line. The following table shows the maximum Java heap size that gets set, depending on the memory available: Physical memory <size> Maximum Java heap size Less than 1 GB 50% <size> 1 GB - 2 GB <size> - 512M Greater than 2 GB 75% <size> The default heap size for containers only takes affect when running in a container environment and when -XX:+UseContainerSupport is specified,\nwhich is expected to be the default in a future release.",
"title": "Modifying the default Java heap size for applications that run in containers"
},
{
"location": "/version0.9/#specifying-the-maximum-java-heap-size-as-a-percentage-value",
"text": "OpenJ9 now supports setting the heap size as a percentage of the physical memory. The following OpenJDK options are recognized and can be\nset for the VM: -XX:MaxRAMPercentage -XX:InitialRAMPercentage To understand how to set these options, see -XX:MaxRAMPercentage and -XX:InitialRAMPercentage . If your application is running in a container and you have specified -XX:+UseContainerSupport , as described in Modifying the default Java heap size for applications that run in containers , both the default heap size for containers and the -XX:MaxRAMPercentage and -XX:InitialRAMPercentage \noptions are based on the available container memory.",
"title": "Specifying the maximum Java heap size as a percentage value"
},
{
"location": "/version0.9/#shared-classes-support-for-nested-jar-files",
"text": "Changes are made to the com.ibm.oti.shared API to support nested jar files.",
"title": "Shared classes support for nested jar files"
},
{
"location": "/version0.9/#direct-dump-reader-enabled-on-linux-and-windows",
"text": "Direct Dump Reader (DDR) support is now enabled for the OpenJ9 VM on all Linux architectures and on Windows. The DDR code enables the VM to read system dump data by using the OpenJ9 Diagnostic Tool\nFramework for Java (DTFJ) API or the jdmpview tool. If you use the Eclipse Memory Analyzer Tool (MAT) , you can also analyze OpenJ9 or IBM VMs by installing the DTFJ plugin.\n(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) You must use a 32-bit JVM to look at a 32-bit core, and a 64-bit JVM to look at a 64-bit core. This restriction will be fixed in a later version of OpenJ9.",
"title": "Direct Dump Reader enabled on Linux and Windows"
},
{
"location": "/version0.9/#changes-to-the-javalangstring-class",
"text": "To match the behavior of OpenJDK, java.lang.String no longer has a count field, which changes the way that String.subString() works compared to Java 8. String.subString() now copies the value array. Similarly, StringBuffer and StringBuilder do not share the value array with any String created by toString() . For performance and compatibility with the new String object layout, the OpenJ9 implementations of StringBuffer and StringBuilder have been deprecated in favor of the OpenJDK implementations.",
"title": "Changes to the java.lang.String class"
},
{
"location": "/version0.9/#changes-to-the-sharedclasscacheinfo-class",
"text": "SharedClassCacheInfo.getCacheJVMLevel() used to return the JVMLEVEL constant that maps to a Java version number, for example JVMLEVEL_JAVA8 . This call now returns only the Java version number, for example 10 for Java 10.",
"title": "Changes to the SharedClassCacheInfo class"
},
{
"location": "/version0.9/#full-release-information",
"text": "To see a complete list of changes between Eclipse OpenJ9 V0.8.0 and V0.9.0 releases, see the Release notes .",
"title": "Full release information"
},
{
"location": "/version0.8/",
"text": "Release notes - version 0.8.0\n\n\nVersion 0.8.0 is the first release of Eclipse OpenJ9, as defined in the \nrelease plan\n.\n\n\nThis release supports OpenJDK Version 8 binaries at \nAdoptOpenJDK.net\n that contain the Eclipse OpenJ9 virtual machine.\n\n\nFor more information about supported platforms, and any issues and limitations, read the \nOpenJ9 GitHub release notes\n.",
"title": "Version 0.8.0"
},
{
"location": "/version0.8/#release-notes-version-080",
"text": "Version 0.8.0 is the first release of Eclipse OpenJ9, as defined in the release plan . This release supports OpenJDK Version 8 binaries at AdoptOpenJDK.net that contain the Eclipse OpenJ9 virtual machine. For more information about supported platforms, and any issues and limitations, read the OpenJ9 GitHub release notes .",
"title": "Release notes - version 0.8.0"
},
{
"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.",
"title": "Garbage Collection"
},
{
"location": "/gc/#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 clean up is done. This pause is often referred to as a stop-the-world 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. Eclipse 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.",
"title": "Garbage collection"
},
{
"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.",
"title": "Gencon policy"
},
{
"location": "/gc/#other-policies",
"text": "OpenJ9 has the following alternative GC policies: -Xgcpolicy:balanced 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). -Xgcpolicy:metronome 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. -Xgcpolicy:optavgpause 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. -Xgcpolicy:optthruput 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. For more information about these garbage collection policies and options, see -Xgcpolicy .",
"title": "Other policies"
},
{
"location": "/gc/#troubleshooting",
"text": "You 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 -Xverbosegclog 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 Verbose garbage collection 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": "/jit/",
"text": "The JIT compiler\n\n\nThe Just-In-Time (JIT) compiler is a key component of the OpenJ9 VM that improves the performance of Java applications by compiling platform-neutral Java bytecode into native machine code at run time. Without the JIT, the VM has to interpret the bytecodes itself - a process that requires extra CPU and memory.\n\n\nThe JIT compiler doesn't compile every method that gets called because thousands of methods can be called at startup. Instead, OpenJ9 records the number of times a method is called. When the count reaches a pre-defined \ninvocation threshold\n, JIT compilation is triggered. Once a method has been compiled by the JIT, the VM can call the compiled method rather than interpreting it.\n\n\nOptimization levels\n\n\nThe JIT compiler can compile a method at different optimization levels: \ncold\n, \nwarm\n, \nhot\n, \nvery hot (with profiling)\n, or \nscorching\n. The hotter the optimization level, the better the expected performance, but the higher the cost in terms of CPU and memory.\n\n\n\n\ncold\n is used during startup processing for large applications where the goal is to achieve the best compiled code speed for as many methods as possible.\n\n\nwarm\n is the workhorse; after start-up, most methods are compiled when they reach the invocation threshold.\n\n\n\n\nFor higher optimization levels, the VM uses a sampling thread to identify methods that continue to take a lot of time. Methods that consume more than 1% are compiled at hot. Methods that consume more than 12.5% are scheduled for a scorching compilation. However, before that happens the methods are compiled at very hot with profiling to collect detailed profile data that is used by the scorching compilation.\n\n\nThe higher optimization levels use special techniques such as escape analysis and partial redundancy elimination, or loop through certain optimization sequences more times. Although these techniques use more CPU and memory, the improved performance that is delivered by the optimizations can make the tradeoff worthwhile.\n\n\nTroubleshooting\n\n\nThe JIT compiler is enabled by default to optimize performance. However, if you experience a problem running your application, temporarily turning off the JIT will tell you whether the JIT is at fault.\n\n\nBecause JIT starts at the same time as the VM, you can only modify JIT behavior at startup.\n\n\nThere are a number of ways to disable the JIT:\n\n\n\n\nSpecify \n-Djava.compiler=NONE\n on the command line.\n\n\nSpecify \n-Xint\n on the command line, which turns off the JIT and AOT compiler. To eliminate problems with one or the other you can turn these compilers off selectively with the \n-Xnojit\n and \n-Xnoaot\n options.\n\n\nCall the \njava.lang.Compiler\n API programmatically.\n\n\n\n\n \nNote:\n \njava.lang.Compiler\n is deprecated for removal in Java SE 9.\n\n\nIf turning off the JIT solves your problem, you can investigate JIT operations in more detail by using a number of options to control behavior.\n\n\nTurning on verbose logging with the \nverbose\n suboption causes the JIT to record all compiler operations. However, the log file can be difficult to read because there are so many complex operations occuring in rapid succession. Follow these steps to simplify operations, which helps you pinpoint the root cause:\n\n\n\n\nTurn off multiple compilation threads\n\n\n\n\nThe JIT compiler can use more than one compilation thread, which typically improves startup performance. The number of threads is determined by the VM, depending on the system configuration. You can turn off multiple threads by using the \n-XcompilationThreads\n option, which simplifies the output in the verbose log.\n\n\n\n\nLower the invocation threshold\n\n\n\n\nWhen the invocation count is set to \n0\n, the JIT compiles every method and your application will fail immediately when the method causing the problem is reached. You can alter the threshold with the \ncount\n suboption.\n\n\n\n\nTurn off inlining\n\n\n\n\nInlining is a complex process that generates larger and more complex code. To eliminate errors caused by these operations, use the \ndisableImlining\n suboption.\n\n\n\n\nDecrease the optimization levels\n\n\n\n\nUse the \noptlevel\n suboption to gradually decrease the compiler optimization levels to see whether you can isolate the level at which your problem occurs.\n\n\n\n\n\n\nMore information about these suboptions and the command line syntax is covered in \n-Xjit\n.\n\n\nUnderstanding JIT verbose logs\n\n\nAt first glance, a JIT verbose log can look very complex. To help you understand the log we'll look at JIT compiler operations when you run the \njava -version\n command.\n\n\nThe following option turns on verbose logging and directs output to a log file called \nvlogfile\n:\n\n\njava -Xjit:verbose,vlog=vlogfile -version\n\n\n\n\n\nThe first section of the log includes lines that start with \n#INFO:\n, which provides information about the environment that the JIT is operating in. You can determine the version of the JIT and VM that you are using, and the type and number of processors that the JIT has access to.\n\n\n#INFO: _______________________________________\n#INFO: Version Information:\n#INFO: JIT Level - e24e8aa9\n#INFO: JVM Level - 20180315_120\n#INFO: GC Level - e24e8aa9\n#INFO: \n#INFO: Processor Information:\n#INFO: Platform Info:X86 Intel P6\n#INFO: Vendor:GenuineIntel\n#INFO: numProc=1\n#INFO: \n#INFO: _______________________________________\n#INFO: AOT\n#INFO: options specified:\n#INFO: samplingFrequency=2\n#INFO: \n#INFO: options in effect:\n#INFO: verbose=1\n#INFO: vlog=vlogfile\n#INFO: compressedRefs shiftAmount=0\n#INFO: compressedRefs isLowMemHeap=1\n#INFO: _______________________________________\n#INFO: JIT\n#INFO: options specified:\n#INFO: verbose,vlog=vlogfile\n#INFO: \n#INFO: options in effect:\n#INFO: verbose=1\n#INFO: vlog=vlogfile\n#INFO: compressedRefs shiftAmount=0\n#INFO: compressedRefs isLowMemHeap=1\n#INFO: StartTime: Apr 23 09:49:10 2018\n#INFO: Free Physical Memory: 996188 KB\n#INFO: CPU entitlement = 100.00\n\n\n\n\n\nThis section also shows the AOT and JIT options that are in force. The last few lines detail the start time of the compilation activity, how much free physical memory is available to the process, and the CPU entitlement.\n\n\nThe information section is followed by a sequence of lines that describe the methods that are being compiled, as well as other events significant to the operation of the JIT compiler.\n\n\nHere is a typical line from the verbose log:\n\n\n+ (cold) sun/reflect/Reflection.getCallerClass()Ljava/lang/Class; @ 00007FCACED1303C-00007FCACED13182 OrdinaryMethod - Q_SZ=0 Q_SZI=0 QW=1 j9m=00000000011E7EA8 bcsz=2 JNI compThread=0 CpuLoad=2%(2%avg) JvmCpu=0%\n\n\nIn this example:\n\n\n\n\nThe method compiled is sun/reflect/Reflection.getCallerClass()Ljava/lang/Class.\n\n\nThe + indicates that this method is successfully compiled. Failed compilations are marked by a !.\n\n\n(cold) tells you the optimization level that was applied. Other examples may be (warm) or (scorching).\n\n\n00007FCACED1303C-00007FCACED13182 is the code range where the compiled code was generated.\n\n\nQ values provide information about the state of the compilation queues when the compilation occurred.\n\n\nbcsz shows the bytecode size. In this case it is small because this is a native method, so the JIT is simply providing an accelerated JNI transition into the native getCallerClass method.\n\n\n\n\nEach line of output represents a method that is compiled.\n\n\nThe following example requests information about the performance of JIT compiler threads, with output written to \nvlogfile\n.\n\n\njava -Xjit:verbose={compilePerformance},vlog=vlogfile -version\n\n\n\n\n\nThe output generated by using this command adds the values \ntime\n and \nmem\n into each line, as shown in the following example:\n\n\n+ (cold) java/lang/System.getEncoding(I)Ljava/lang/String; @ 00007F29183A921C-00007F29183A936D OrdinaryMethod - Q_SZ=0 Q_SZI=0 QW=1 j9m=0000000000F13A70 bcsz=3 JNI time=311us mem=[region=704 system=16384]KB compThread=0 CpuLoad=2%(2%avg) JvmCpu=0%\n\n\n\n\n\n\n\ntime=311us reflects the amount of time taken to do the compilation.\n\n\nmem=[region=704 system=16384]KB reflects the amount of memory that was allocated during the compilation.\n\n\n\n\nThe following example can be used to create verbose output that includes lines to show when compilation for a method starts and ends, and any methods that are inlined during the compilation.\n\n\njava '-Xjit:verbose={compileStart|compileEnd|inlining},count=5,vlog=vlogfile' -XcompilationThreads1 -version\n\n\n\n\n\n \nNote:\n The suboptions \ncount\n and \n-XcompilationThreads1\n are included only to simplify the output for this example and are not recommended for production.\n\n\nThe following section is taken from the output and describes the compilation and inlining of one method \njava/lang/String.equals\n:\n\n\n(\nwarm\n)\n \nCompiling\n \njava\n/\nlang\n/\nString\n.\nequals\n(\nLjava\n/\nlang\n/\nObject\n;)\nZ\n \nOrdinaryMethod\n \nj9m\n=\n0000000001300\nB30\n \nt\n=\n90\n \ncompThread\n=\n0\n \nmemLimit\n=\n262144\n \nKB\n \nfreePhysicalMemory\n=\n969\n \nMB\n\n\n#INL: 7 methods inlined into 4dce72bd java/lang/String.equals(Ljava/lang/Object;)Z @ 00007F53190A3E40\n\n\n#INL: #0: 4dce72bd #-1 inlined 4dce72bd@22 -> 81670d20 bcsz=37 java/lang/String.lengthInternal()I\n\n\n#INL: #1: 4dce72bd #-1 inlined 4dce72bd@28 -> 81670d20 bcsz=37 java/lang/String.lengthInternal()I\n\n\n#INL: #2: 4dce72bd #-1 inlined 4dce72bd@104 -> bf62dcaf bcsz=182 java/lang/String.regionMatchesInternal(Ljava/lang/String;Ljava/lang/String;[C[CIII)Z\n\n\n#INL: #3: 4dce72bd #2 inlined bf62dcaf@121 -> bbb5af92 bcsz=39 java/lang/String.charAtInternal(I[C)C\n\n\n#INL: #4: 4dce72bd #2 inlined bf62dcaf@131 -> bbb5af92 bcsz=39 java/lang/String.charAtInternal(I[C)C\n\n\n#INL: #5: 4dce72bd #2 inlined bf62dcaf@156 -> bbb5af92 bcsz=39 java/lang/String.charAtInternal(I[C)C\n\n\n#INL: #6: 4dce72bd #2 inlined bf62dcaf@166 -> bbb5af92 bcsz=39 java/lang/String.charAtInternal(I[C)C\n\n\n#INL: 4dce72bd called 4dce72bd@120 -> f734b49c bcsz=233 java/lang/String.deduplicateStrings(Ljava/lang/String;Ljava/lang/String;)V\n\n\n#INL: 4dce72bd coldCalled 4dce72bd@104 -> bf62dcaf bcsz=182 java/lang/String.regionMatchesInternal(Ljava/lang/String;Ljava/lang/String;[C[CIII)Z\n\n\n#INL: 4dce72bd coldCalled 4dce72bd@104 -> bf62dcaf bcsz=182 java/lang/String.regionMatchesInternal(Ljava/lang/String;Ljava/lang/String;[C[CIII)Z\n\n\n+\n \n(\nwarm\n)\n \njava\n/\nlang\n/\nString\n.\nequals\n(\nLjava\n/\nlang\n/\nObject\n;)\nZ\n \n@\n \n00007F\n53190\nA3E40\n-\n00007F\n53190\nA40D0\n \nOrdinaryMethod\n \n-\n \nQ_SZ\n=\n277\n \nQ_SZI\n=\n277\n \nQW\n=\n1667\n \nj9m\n=\n0000000001300\nB30\n \nbcsz\n=\n127\n \nGCR\n \ncompThread\n=\n0\n \nCpuLoad\n=\n2\n%\n(\n2\n%\navg\n)\n \nJvmCpu\n=\n0\n%\n\n\n\n\n\n\nThe first line is included as a result of setting the \ncompileStart\n suboption and shows the start of the warm method compilation:\n\n\n(warm) Compiling java/lang/String.equals(Ljava/lang/Object;)Z OrdinaryMethod j9m=0000000001300B30 t=90 compThread=0 memLimit=262144 KB freePhysicalMemory=969 MB\n\n\n\n\n\nSimilarly, the last line shows the successful compilation of this method, as denoted by the \n+\n:\n\n\n+ (warm) java/lang/String.equals(Ljava/lang/Object;)Z @ 00007F53190A3E40-00007F53190A40D0 OrdinaryMethod - Q_SZ=277 Q_SZI=277 QW=1667 j9m=0000000001300B30 bcsz=127 GCR compThread=0 CpuLoad=2%(2%avg) JvmCpu=0%\n\n\n\n\n\nThe lines inbetween that start with \n#INL\n describe the inlining operations that took place. A total of 7 methods were inlined into \njava/lang/String.equals\n:\n\n\nThe first three methods (\n#0\n, \n#1\n, \n#2\n) are inlined into the top level method, denoted as \n#-1\n:\n\n\n#INL: #0: 4dce72bd #-1 inlined 4dce72bd@22 -> 81670d20 bcsz=37 java/lang/String.lengthInternal()I\n\n\n#INL: #1: 4dce72bd #-1 inlined 4dce72bd@28 -> 81670d20 bcsz=37 java/lang/String.lengthInternal()I\n\n\n#INL: #2: 4dce72bd #-1 inlined 4dce72bd@104 -> bf62dcaf bcsz=182 java/lang/String.regionMatchesInternal(Ljava/lang/String;Ljava/lang/String;[C[CIII)Z\n\n\n\n\n\n\nThe next four methods (\n#3\n, \n#4\n, \n#5\n, \n#6\n) are inlined into the method denoted by \n#2\n.\n\n\n#INL: #3: 4dce72bd #2 inlined bf62dcaf@121 -> bbb5af92 bcsz=39 java/lang/String.charAtInternal(I[C)C\n\n\n#INL: #4: 4dce72bd #2 inlined bf62dcaf@131 -> bbb5af92 bcsz=39 java/lang/String.charAtInternal(I[C)C\n\n\n#INL: #5: 4dce72bd #2 inlined bf62dcaf@156 -> bbb5af92 bcsz=39 java/lang/String.charAtInternal(I[C)C\n\n\n#INL: #6: 4dce72bd #2 inlined bf62dcaf@166 -> bbb5af92 bcsz=39 java/lang/String.charAtInternal(I[C)C\n\n\n\n\n\n\nHere's how to interpret the line for \n#INL: #0:\n:\n\n\nThe method is inlined into \n4dce72bd\n, where \n4dce72bd\n is an internal pointer that corresponds to this method (in this case, \njava/lang/String.equals(Ljava/lang/Object;)Z\n).\nThe value \n@22\n at the end of the pointer is a bytecode index, which describes the bytecode index of the call that is being inlined.\nThe call is \n81670d20 bcsz=37 java/lang/String.lengthInternal()I\n, which shows the corresponding internal pointer, bytecode size (bcsz) and the name of the method that got inlined.\nGoing through the \n#INL\n output line by line then:\n\n\njava\n/\nlang\n/\nString\n.\nlengthInternal\n()\nI\n \ngot\n \ninlined\n \ninto\n \nits\n \ncaller\n \n4\ndce72bd\n \nat\n \nbytecode\n \nindex\n \n@22.\n\n\njava\n/\nlang\n/\nString\n.\nlengthInternal\n()\nI\n \nalso\n \ngot\n \ninlined\n \ninto\n \nits\n \ncaller\n \n4\ndce72bd\n \nat\n \nbytecode\n \nindex\n \n@28.\n\n\njava\n/\nlang\n/\nString\n.\nregionMatchesInternal\n(...)\n \ngot\n \ninlined\n \nat\n \ncall\n \nreference\n \n4\ndce72bd\n \nat\n \nbytecode\n \nindex\n \n@104.\n\n\n\n\n\n\nThen 4 distinct calls to \njava/lang/String.charAtInternal(I[C)C\n were also inlined into \njava/lang/String.regionMatchesInternal(...)\n :\n\n\n#3 at bytecode index @121 of regionMatchesInternal\n\n\n#4 at bytecode index @131 of regionMatchesInternal\n\n\n#5 at bytecode index @156 of regionMatchesInternal\n\n\n#6 at bytecode index @166 of regionMatchesInternal\n\n\n\n\n\n\nThese were all the calls that the inliner decided to inline into the method being compiled. There is some additional output that describes calls to methods that weren't inlined:\n\n\n#INL: 4dce72bd called 4dce72bd@120 -> f734b49c bcsz=233 java/lang/String.deduplicateStrings(Ljava/lang/String;Ljava/lang/String;)V\n\n\n#INL: 4dce72bd coldCalled 4dce72bd@104 -> bf62dcaf bcsz=182 java/lang/String.regionMatchesInternal(Ljava/lang/String;Ljava/lang/String;[C[CIII)Z\n\n\n#INL: 4dce72bd coldCalled 4dce72bd@104 -> bf62dcaf bcsz=182 java/lang/String.regionMatchesInternal(Ljava/lang/String;Ljava/lang/String;[C[CIII)Z\n\n\n\n\n\n\nWhile the output does not specifically say why these methods were not inlined, the relatively larger bytecode size (\nbcsz=233\n) probably prevented the first method from being inlined. It's possible that, at a higher optimization level than cold, this \ndeduplicateStrings\n method may get inlined. The \ncoldCalled\n label on the last two lines, however, indicate that these calls are located in a part of the method that has not ever been executed, so the JIT decided that inlining those last two methods will probably increase compile time without much promise that it will improve performance.\n\n\nBy reading the log in this way you can reconstruct the tree of inlines that are taking place as the compilation proceeds. You can see which methods are being inlined and which methods are not being inlined.\n\n\nSee also\n\n\n\n\nDiagnosing a JIT or AOT problem",
"title": "JIT Compiler"
},
{
"location": "/jit/#the-jit-compiler",
"text": "The Just-In-Time (JIT) compiler is a key component of the OpenJ9 VM that improves the performance of Java applications by compiling platform-neutral Java bytecode into native machine code at run time. Without the JIT, the VM has to interpret the bytecodes itself - a process that requires extra CPU and memory. The JIT compiler doesn't compile every method that gets called because thousands of methods can be called at startup. Instead, OpenJ9 records the number of times a method is called. When the count reaches a pre-defined invocation threshold , JIT compilation is triggered. Once a method has been compiled by the JIT, the VM can call the compiled method rather than interpreting it.",
"title": "The JIT compiler"
},
{
"location": "/jit/#optimization-levels",
"text": "The JIT compiler can compile a method at different optimization levels: cold , warm , hot , very hot (with profiling) , or scorching . The hotter the optimization level, the better the expected performance, but the higher the cost in terms of CPU and memory. cold is used during startup processing for large applications where the goal is to achieve the best compiled code speed for as many methods as possible. warm is the workhorse; after start-up, most methods are compiled when they reach the invocation threshold. For higher optimization levels, the VM uses a sampling thread to identify methods that continue to take a lot of time. Methods that consume more than 1% are compiled at hot. Methods that consume more than 12.5% are scheduled for a scorching compilation. However, before that happens the methods are compiled at very hot with profiling to collect detailed profile data that is used by the scorching compilation. The higher optimization levels use special techniques such as escape analysis and partial redundancy elimination, or loop through certain optimization sequences more times. Although these techniques use more CPU and memory, the improved performance that is delivered by the optimizations can make the tradeoff worthwhile.",
"title": "Optimization levels"
},
{
"location": "/jit/#troubleshooting",
"text": "The JIT compiler is enabled by default to optimize performance. However, if you experience a problem running your application, temporarily turning off the JIT will tell you whether the JIT is at fault. Because JIT starts at the same time as the VM, you can only modify JIT behavior at startup. There are a number of ways to disable the JIT: Specify -Djava.compiler=NONE on the command line. Specify -Xint on the command line, which turns off the JIT and AOT compiler. To eliminate problems with one or the other you can turn these compilers off selectively with the -Xnojit and -Xnoaot options. Call the java.lang.Compiler API programmatically. Note: java.lang.Compiler is deprecated for removal in Java SE 9. If turning off the JIT solves your problem, you can investigate JIT operations in more detail by using a number of options to control behavior. Turning on verbose logging with the verbose suboption causes the JIT to record all compiler operations. However, the log file can be difficult to read because there are so many complex operations occuring in rapid succession. Follow these steps to simplify operations, which helps you pinpoint the root cause: Turn off multiple compilation threads The JIT compiler can use more than one compilation thread, which typically improves startup performance. The number of threads is determined by the VM, depending on the system configuration. You can turn off multiple threads by using the -XcompilationThreads option, which simplifies the output in the verbose log. Lower the invocation threshold When the invocation count is set to 0 , the JIT compiles every method and your application will fail immediately when the method causing the problem is reached. You can alter the threshold with the count suboption. Turn off inlining Inlining is a complex process that generates larger and more complex code. To eliminate errors caused by these operations, use the disableImlining suboption. Decrease the optimization levels Use the optlevel suboption to gradually decrease the compiler optimization levels to see whether you can isolate the level at which your problem occurs. More information about these suboptions and the command line syntax is covered in -Xjit .",
"title": "Troubleshooting"
},
{
"location": "/jit/#understanding-jit-verbose-logs",
"text": "At first glance, a JIT verbose log can look very complex. To help you understand the log we'll look at JIT compiler operations when you run the java -version command. The following option turns on verbose logging and directs output to a log file called vlogfile : java -Xjit:verbose,vlog=vlogfile -version The first section of the log includes lines that start with #INFO: , which provides information about the environment that the JIT is operating in. You can determine the version of the JIT and VM that you are using, and the type and number of processors that the JIT has access to. #INFO: _______________________________________\n#INFO: Version Information:\n#INFO: JIT Level - e24e8aa9\n#INFO: JVM Level - 20180315_120\n#INFO: GC Level - e24e8aa9\n#INFO: \n#INFO: Processor Information:\n#INFO: Platform Info:X86 Intel P6\n#INFO: Vendor:GenuineIntel\n#INFO: numProc=1\n#INFO: \n#INFO: _______________________________________\n#INFO: AOT\n#INFO: options specified:\n#INFO: samplingFrequency=2\n#INFO: \n#INFO: options in effect:\n#INFO: verbose=1\n#INFO: vlog=vlogfile\n#INFO: compressedRefs shiftAmount=0\n#INFO: compressedRefs isLowMemHeap=1\n#INFO: _______________________________________\n#INFO: JIT\n#INFO: options specified:\n#INFO: verbose,vlog=vlogfile\n#INFO: \n#INFO: options in effect:\n#INFO: verbose=1\n#INFO: vlog=vlogfile\n#INFO: compressedRefs shiftAmount=0\n#INFO: compressedRefs isLowMemHeap=1\n#INFO: StartTime: Apr 23 09:49:10 2018\n#INFO: Free Physical Memory: 996188 KB\n#INFO: CPU entitlement = 100.00 This section also shows the AOT and JIT options that are in force. The last few lines detail the start time of the compilation activity, how much free physical memory is available to the process, and the CPU entitlement. The information section is followed by a sequence of lines that describe the methods that are being compiled, as well as other events significant to the operation of the JIT compiler. Here is a typical line from the verbose log: + (cold) sun/reflect/Reflection.getCallerClass()Ljava/lang/Class; @ 00007FCACED1303C-00007FCACED13182 OrdinaryMethod - Q_SZ=0 Q_SZI=0 QW=1 j9m=00000000011E7EA8 bcsz=2 JNI compThread=0 CpuLoad=2%(2%avg) JvmCpu=0% In this example: The method compiled is sun/reflect/Reflection.getCallerClass()Ljava/lang/Class. The + indicates that this method is successfully compiled. Failed compilations are marked by a !. (cold) tells you the optimization level that was applied. Other examples may be (warm) or (scorching). 00007FCACED1303C-00007FCACED13182 is the code range where the compiled code was generated. Q values provide information about the state of the compilation queues when the compilation occurred. bcsz shows the bytecode size. In this case it is small because this is a native method, so the JIT is simply providing an accelerated JNI transition into the native getCallerClass method. Each line of output represents a method that is compiled. The following example requests information about the performance of JIT compiler threads, with output written to vlogfile . java -Xjit:verbose={compilePerformance},vlog=vlogfile -version The output generated by using this command adds the values time and mem into each line, as shown in the following example: + (cold) java/lang/System.getEncoding(I)Ljava/lang/String; @ 00007F29183A921C-00007F29183A936D OrdinaryMethod - Q_SZ=0 Q_SZI=0 QW=1 j9m=0000000000F13A70 bcsz=3 JNI time=311us mem=[region=704 system=16384]KB compThread=0 CpuLoad=2%(2%avg) JvmCpu=0% time=311us reflects the amount of time taken to do the compilation. mem=[region=704 system=16384]KB reflects the amount of memory that was allocated during the compilation. The following example can be used to create verbose output that includes lines to show when compilation for a method starts and ends, and any methods that are inlined during the compilation. java '-Xjit:verbose={compileStart|compileEnd|inlining},count=5,vlog=vlogfile' -XcompilationThreads1 -version Note: The suboptions count and -XcompilationThreads1 are included only to simplify the output for this example and are not recommended for production. The following section is taken from the output and describes the compilation and inlining of one method java/lang/String.equals : ( warm ) Compiling java / lang / String . equals ( Ljava / lang / Object ;) Z OrdinaryMethod j9m = 0000000001300 B30 t = 90 compThread = 0 memLimit = 262144 KB freePhysicalMemory = 969 MB #INL: 7 methods inlined into 4dce72bd java/lang/String.equals(Ljava/lang/Object;)Z @ 00007F53190A3E40 #INL: #0: 4dce72bd #-1 inlined 4dce72bd@22 -> 81670d20 bcsz=37 java/lang/String.lengthInternal()I #INL: #1: 4dce72bd #-1 inlined 4dce72bd@28 -> 81670d20 bcsz=37 java/lang/String.lengthInternal()I #INL: #2: 4dce72bd #-1 inlined 4dce72bd@104 -> bf62dcaf bcsz=182 java/lang/String.regionMatchesInternal(Ljava/lang/String;Ljava/lang/String;[C[CIII)Z #INL: #3: 4dce72bd #2 inlined bf62dcaf@121 -> bbb5af92 bcsz=39 java/lang/String.charAtInternal(I[C)C #INL: #4: 4dce72bd #2 inlined bf62dcaf@131 -> bbb5af92 bcsz=39 java/lang/String.charAtInternal(I[C)C #INL: #5: 4dce72bd #2 inlined bf62dcaf@156 -> bbb5af92 bcsz=39 java/lang/String.charAtInternal(I[C)C #INL: #6: 4dce72bd #2 inlined bf62dcaf@166 -> bbb5af92 bcsz=39 java/lang/String.charAtInternal(I[C)C #INL: 4dce72bd called 4dce72bd@120 -> f734b49c bcsz=233 java/lang/String.deduplicateStrings(Ljava/lang/String;Ljava/lang/String;)V #INL: 4dce72bd coldCalled 4dce72bd@104 -> bf62dcaf bcsz=182 java/lang/String.regionMatchesInternal(Ljava/lang/String;Ljava/lang/String;[C[CIII)Z #INL: 4dce72bd coldCalled 4dce72bd@104 -> bf62dcaf bcsz=182 java/lang/String.regionMatchesInternal(Ljava/lang/String;Ljava/lang/String;[C[CIII)Z + ( warm ) java / lang / String . equals ( Ljava / lang / Object ;) Z @ 00007F 53190 A3E40 - 00007F 53190 A40D0 OrdinaryMethod - Q_SZ = 277 Q_SZI = 277 QW = 1667 j9m = 0000000001300 B30 bcsz = 127 GCR compThread = 0 CpuLoad = 2 % ( 2 % avg ) JvmCpu = 0 % The first line is included as a result of setting the compileStart suboption and shows the start of the warm method compilation: (warm) Compiling java/lang/String.equals(Ljava/lang/Object;)Z OrdinaryMethod j9m=0000000001300B30 t=90 compThread=0 memLimit=262144 KB freePhysicalMemory=969 MB Similarly, the last line shows the successful compilation of this method, as denoted by the + : + (warm) java/lang/String.equals(Ljava/lang/Object;)Z @ 00007F53190A3E40-00007F53190A40D0 OrdinaryMethod - Q_SZ=277 Q_SZI=277 QW=1667 j9m=0000000001300B30 bcsz=127 GCR compThread=0 CpuLoad=2%(2%avg) JvmCpu=0% The lines inbetween that start with #INL describe the inlining operations that took place. A total of 7 methods were inlined into java/lang/String.equals : The first three methods ( #0 , #1 , #2 ) are inlined into the top level method, denoted as #-1 : #INL: #0: 4dce72bd #-1 inlined 4dce72bd@22 -> 81670d20 bcsz=37 java/lang/String.lengthInternal()I #INL: #1: 4dce72bd #-1 inlined 4dce72bd@28 -> 81670d20 bcsz=37 java/lang/String.lengthInternal()I #INL: #2: 4dce72bd #-1 inlined 4dce72bd@104 -> bf62dcaf bcsz=182 java/lang/String.regionMatchesInternal(Ljava/lang/String;Ljava/lang/String;[C[CIII)Z The next four methods ( #3 , #4 , #5 , #6 ) are inlined into the method denoted by #2 . #INL: #3: 4dce72bd #2 inlined bf62dcaf@121 -> bbb5af92 bcsz=39 java/lang/String.charAtInternal(I[C)C #INL: #4: 4dce72bd #2 inlined bf62dcaf@131 -> bbb5af92 bcsz=39 java/lang/String.charAtInternal(I[C)C #INL: #5: 4dce72bd #2 inlined bf62dcaf@156 -> bbb5af92 bcsz=39 java/lang/String.charAtInternal(I[C)C #INL: #6: 4dce72bd #2 inlined bf62dcaf@166 -> bbb5af92 bcsz=39 java/lang/String.charAtInternal(I[C)C Here's how to interpret the line for #INL: #0: : The method is inlined into 4dce72bd , where 4dce72bd is an internal pointer that corresponds to this method (in this case, java/lang/String.equals(Ljava/lang/Object;)Z ).\nThe value @22 at the end of the pointer is a bytecode index, which describes the bytecode index of the call that is being inlined.\nThe call is 81670d20 bcsz=37 java/lang/String.lengthInternal()I , which shows the corresponding internal pointer, bytecode size (bcsz) and the name of the method that got inlined.\nGoing through the #INL output line by line then: java / lang / String . lengthInternal () I got inlined into its caller 4 dce72bd at bytecode index @22. java / lang / String . lengthInternal () I also got inlined into its caller 4 dce72bd at bytecode index @28. java / lang / String . regionMatchesInternal (...) got inlined at call reference 4 dce72bd at bytecode index @104. Then 4 distinct calls to java/lang/String.charAtInternal(I[C)C were also inlined into java/lang/String.regionMatchesInternal(...) : #3 at bytecode index @121 of regionMatchesInternal #4 at bytecode index @131 of regionMatchesInternal #5 at bytecode index @156 of regionMatchesInternal #6 at bytecode index @166 of regionMatchesInternal These were all the calls that the inliner decided to inline into the method being compiled. There is some additional output that describes calls to methods that weren't inlined: #INL: 4dce72bd called 4dce72bd@120 -> f734b49c bcsz=233 java/lang/String.deduplicateStrings(Ljava/lang/String;Ljava/lang/String;)V #INL: 4dce72bd coldCalled 4dce72bd@104 -> bf62dcaf bcsz=182 java/lang/String.regionMatchesInternal(Ljava/lang/String;Ljava/lang/String;[C[CIII)Z #INL: 4dce72bd coldCalled 4dce72bd@104 -> bf62dcaf bcsz=182 java/lang/String.regionMatchesInternal(Ljava/lang/String;Ljava/lang/String;[C[CIII)Z While the output does not specifically say why these methods were not inlined, the relatively larger bytecode size ( bcsz=233 ) probably prevented the first method from being inlined. It's possible that, at a higher optimization level than cold, this deduplicateStrings method may get inlined. The coldCalled label on the last two lines, however, indicate that these calls are located in a part of the method that has not ever been executed, so the JIT decided that inlining those last two methods will probably increase compile time without much promise that it will improve performance. By reading the log in this way you can reconstruct the tree of inlines that are taking place as the compilation proceeds. You can see which methods are being inlined and which methods are not being inlined.",
"title": "Understanding JIT verbose logs"
},
{
"location": "/jit/#see-also",
"text": "Diagnosing a JIT or AOT problem",
"title": "See also"
},
{
"location": "/aot/",
"text": "Ahead-Of-Time (AOT) compiler\n\n\nThe 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 \n-Xshareclasses\n 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.\n\n\nIf you want to turn off AOT compilation and disable the use of AOT-compiled code, set the \n-Xnoaot\n 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. \n\n\nSee also\n\n\n\n\nDiagnosing a JIT or AOT problem\n\n\nJIT compiler\n\n\nClass 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 Class data sharing",
"title": "See also"
},
{
"location": "/shrc/",
"text": "Class Data Sharing\n\n\nSharing class data between JVMs improves start up performance and reduces memory footprint.\n\n\nStart up performance is improved by placing classes that an application needs when initializing into a shared classes cache. The next time the\napplication runs, it takes much less time to start because the classes are already available. When you enable class data sharing, AOT compilation is also enabled by default, which dynamically compiles certain methods into AOT code at runtime. By using these features in combination, startup performance can be improved even further because the cached AOT code can be used to quickly enable native code performance for subsequent runs of your application.\n\n\nClass data sharing is enabled by setting the \n-Xshareclasses\n option on the command line when you start your application. When specified, OpenJ9 automatically creates a memory mapped file that stores and shares the classes in memory. By default, OpenJ9 always shares both the bootstrap and application classes that are loaded by the default system class loader.\n\n\nThe shared classes cache is updated dynamically; When an application loads new classes, the JVM automatically stores them in the cache without any user intervention.\n\n\nMemory footprint is reduced by sharing common classes between applications that run in separate Java VMs.\n\n\nThe \n-Xshareclasses\n option is highly configurable, allowing you to specify where to create the cache, how much space to allocate for AOT code and more. You can also set the cache size by using the \n-Xscmx\n option. \n\n\nSupport for custom class loaders\n\n\nClasses are shared by the bootstrap class loader internally in the OpenJ9 VM. If you are using a custom class loader, you can use the Java Helper API to find and store classes in the shared class cache.\n\n\nFor more information, see \nUsing the Java Helper API\n.\n\n\nCache utilities\n\n\nSeveral utilities are provided for managing active caches, which are invoked by specifying \n-Xshareclasses\n suboptions. These utilities control the following types of operations:\n\n\n\n\nAdjust the minimum and maximum amount of cache space reserved for AOT or JIT data.\n\n\nAdjust the soft maximum size of the cache.\n\n\nCreate snapshots of a cache.\n\n\nCreate a cache from a snapshot.\n\n\nRemove caches and cache snapshots.\n\n\nList all the compatible and incompatible caches and snapshots.\n\n\nFor problem determination, invalidate and revalidate AOT methods that cause a failure in an application.\n\n\nFor problem determination, provide information to analyze the contents of a shared classes cache.\n\n\n\n\nFor more information, see \n-Xshareclasses\n.\n\n\nSee also\n\n\n\n\nAOT compiler\n\n\nClass Sharing\n\n\nDiagnosing class data sharing problems",
"title": "Class data sharing"
},
{
"location": "/shrc/#class-data-sharing",
"text": "Sharing class data between JVMs improves start up performance and reduces memory footprint. Start up performance is improved by placing classes that an application needs when initializing into a shared classes cache. The next time the\napplication runs, it takes much less time to start because the classes are already available. When you enable class data sharing, AOT compilation is also enabled by default, which dynamically compiles certain methods into AOT code at runtime. By using these features in combination, startup performance can be improved even further because the cached AOT code can be used to quickly enable native code performance for subsequent runs of your application. Class data sharing is enabled by setting the -Xshareclasses option on the command line when you start your application. When specified, OpenJ9 automatically creates a memory mapped file that stores and shares the classes in memory. By default, OpenJ9 always shares both the bootstrap and application classes that are loaded by the default system class loader. The shared classes cache is updated dynamically; When an application loads new classes, the JVM automatically stores them in the cache without any user intervention. Memory footprint is reduced by sharing common classes between applications that run in separate Java VMs. The -Xshareclasses option is highly configurable, allowing you to specify where to create the cache, how much space to allocate for AOT code and more. You can also set the cache size by using the -Xscmx option.",
"title": "Class Data Sharing"
},
{
"location": "/shrc/#support-for-custom-class-loaders",
"text": "Classes are shared by the bootstrap class loader internally in the OpenJ9 VM. If you are using a custom class loader, you can use the Java Helper API to find and store classes in the shared class cache. For more information, see Using the Java Helper API .",
"title": "Support for custom class loaders"
},
{
"location": "/shrc/#cache-utilities",
"text": "Several utilities are provided for managing active caches, which are invoked by specifying -Xshareclasses suboptions. These utilities control the following types of operations: Adjust the minimum and maximum amount of cache space reserved for AOT or JIT data. Adjust the soft maximum size of the cache. Create snapshots of a cache. Create a cache from a snapshot. Remove caches and cache snapshots. List all the compatible and incompatible caches and snapshots. For problem determination, invalidate and revalidate AOT methods that cause a failure in an application. For problem determination, provide information to analyze the contents of a shared classes cache. For more information, see -Xshareclasses .",
"title": "Cache utilities"
},
{
"location": "/shrc/#see-also",
"text": "AOT compiler Class Sharing Diagnosing class data sharing problems",
"title": "See also"
},
{
"location": "/diag_overview/",
"text": "Diagnostic data and tooling\n\n\nOpenJ9 contains extensive trace and debugging capabilities to help identify, isolate, and solve run time problems. Various types of dumps are produced by default in response to certain events, such as a GPF fault or an \nOutOfMemoryError\n exception. You can also trigger the production of dumps by using the \ncom.ibm.jvm.Dump\n API or by specifying \n-Xdump\n options on the command line.\n\n\nDumps\n\n\nAll 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: \n\n\n\n\nJava dumps\n (\n-Xdump:java\n) 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.\n\n\nHeap dumps\n (\n-Xdump:heap\n) show the content of the Java heap.\n\n\nSystem dumps\n (\n-Xdump:system\n) contain a raw process image or address space of an application. \n\n\n\n\nOther 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 \nDump agents\n.\n\n\nVerbose log files\n\n\nSome components of OpenJ9 can also produce verbose output or log files to assist with problem determination.\n\n\n\n\n\n\nClass data sharing provides a number of \n-Xshareclasses\n 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 \n-Xshareclasses:printAllStats\n suboption lists every class in chronological order with a reference to the location from which it was loaded. For more information, see \n-Xshareclasses\n. \n\n\n\n\n\n\nGarbage collection operations can be analyzed by producing verbose output from the \n-verbose:gc\n standard option. This output can be redirected to a file by specifying the \n-Xverbosegclog\n option. Information can be obtained about GC initialization, \nstop-the-world\n processing, finalization, reference processing, and allocation failures. Even more granular information can be obtained with the \n-Xtgc\n option.\n\n\n\n\n\n\nThe JIT compiler provides verbose logging, which records all compiler operations. To find out how to enable logging, read the \nJIT troubleshooting\n content.\n\n\n\n\n\n\nClass loader operations can be analyzed by producing verbose output from the \n-verbose:dynload\n standard option, which shows detailed information as each class is loaded by the VM.\n\n\n\n\n\n\nTrace facility\n\n\nThe 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 \n-Xtrace\n command line option, which allows you to control what is traced and when.\n\n\nTrace 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 \nTrace formattter\n.\n\n\nDebugging tools and interfaces\n\n\nDump viewer\n\n\nBecause system dumps are binary files, OpenJ9 provides a dump viewer tool (\njdmpview\n) to analyze the contents. This tool can work with dumps from any platforms independently of a system debugger. For more information, see \nDump viewer\n.\n\n\nJVMTI tools interface\n\n\nOpenJ9 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 \nJVMTI extensions\n.\n\n\nDTFJ Interface\n\n\nOpenJ9 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. For more information, see \nUsing DTFJ\n.\n\n\nJPDA tools\n\n\nOpenJ9 is compliant with the Java Platform Debugging Architecture (JPDA), which means you can use any JPDA tool for diagnosis, including \nEclipse JDT Debug\n.",
"title": "Tools and data"
},
{
"location": "/diag_overview/#diagnostic-data-and-tooling",
"text": "OpenJ9 contains extensive trace and debugging capabilities to help identify, isolate, and solve run time problems. 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.",
"title": "Diagnostic data and tooling"
},
{
"location": "/diag_overview/#dumps",
"text": "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. 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-facility",
"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 formattter .",
"title": "Trace facility"
},
{
"location": "/diag_overview/#debugging-tools-and-interfaces",
"text": "",
"title": "Debugging tools and interfaces"
},
{
"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/#jvmti-tools-interface",
"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 JVMTI extensions .",
"title": "JVMTI tools interface"
},
{
"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. For more information, see Using DTFJ .",
"title": "DTFJ 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": "/dump_javadump/",
"text": "Java dump\n\n\nJava dumps, sometimes referred to as \nJava cores\n, are produced when the VM ends unexpectedly because of an operating system signal, \nOutOfMemoryError\n exception, 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 \n-Xdump:java\n option on the command line.\n\n\nJava dumps summarize the state of the VM when the event occurs, with most of the information relating to components of the VM.\nThe file is made up of a number of sections that provide different types of information. The information that follows describes\neach section and provides examples to help you interpret the data.\n\n\nTITLE\n\n\nThe first section of the Java dump file provides information about the event that triggered the production of the dump.\nIn the following example you can see that a \nvmstop\n event triggered the dump at a specified date and time.\n\n\n0SECTION TITLE subcomponent dump routine\nNULL ===============================\n1TICHARSET UTF-8\n1TISIGINFO Dump Event \"vmstop\" (00000002) Detail \"#0000000000000000\" received\n1TIDATETIME Date: 2018/08/30 at 21:55:47:607\n1TINANOTIME System nanotime: 22012355276134\n1TIFILENAME Javacore filename: /home/doc-javacore/javacore.20180830.215547.30285.0001.txt\n1TIREQFLAGS Request Flags: 0x81 (exclusive+preempt)\n1TIPREPSTATE Prep State: 0x106 (vm_access+exclusive_vm_access+trace_disabled)\n\n\n\n\n\nGPINFO\n\n\nThe GPINFO section provides general information about the system that the JVM is running on. The following example is taken\nfrom a Java dump that was generated on a Linux system.\n\n\nNULL ------------------------------------------------------------------------\n0SECTION GPINFO subcomponent dump routine\nNULL ================================\n2XHOSLEVEL OS Level : Linux 3.10.0-862.11.6.el7.x86_64\n2XHCPUS Processors -\n3XHCPUARCH Architecture : amd64\n3XHNUMCPUS How Many : 4\n3XHNUMASUP NUMA is either not supported or has been disabled by user\nNULL \n1XHERROR2 Register dump section only produced for SIGSEGV, SIGILL or SIGFPE.\nNULL \n\n\n\n\n\nThe content of this section can vary, depending on the cause of the dump. For example, if the dump was caused by a\ngeneral protection fault (gpf), the library in which the crash occurred is also recorded, together with a value shown\nas \nVM flags\n. This value can provide some clues about which component of the VM might have been involved. Look for the\nfollowing line in the output:\n\n\n1XHFLAGS VM flags:0000000000000000\n\n\n\n\n\nThe hexadecimal number recorded for \nVM flags\n ends in MSSSS, where M is the VM component and SSSS is component-specific code as shown in the following table:\n\n\n\n\n\n\n\n\nComponent\n\n\nCode value\n\n\n\n\n\n\n\n\n\n\nINTERPRETER\n\n\n0x10000\n\n\n\n\n\n\nGC\n\n\n0x20000\n\n\n\n\n\n\nGROW_STACK\n\n\n0x30000\n\n\n\n\n\n\nJNI\n\n\n0x40000\n\n\n\n\n\n\nJIT_CODEGEN\n\n\n0x50000\n\n\n\n\n\n\nBCVERIFY\n\n\n0x60000\n\n\n\n\n\n\nRTVERIFY\n\n\n0x70000\n\n\n\n\n\n\nSHAREDCLASSES\n\n\n0x80000\n\n\n\n\n\n\n\n\nA value of \n0000000000000000\n (0x00000) indicates that a crash occurred outside of the VM.\n\n\nENVINFO\n\n\nThis section contains useful information about the environment in which the crash took place, including the following data:\n\n\n\n\nJava version (\n1CIJAVAVERSION\n)\n\n\nOpenJ9 VM and subcomponent version information (\n1CIVMVERSION\n, \n1CIJ9VMVERSION\n, \n1CIJITVERSION\n, \n1CIOMRVERSION\n, \n1CIJCLVERSION\n)\n\n\nVM start time (\n1CISTARTTIME\n) and process information (\n1CIPROCESSID\n)\n\n\nJava home (\n1CIJAVAHOMEDIR\n) and DLL (\n1CIJAVADLLDIR\n) directories\n\n\nUser arguments passed on the command line (\n1CIUSERARG\n)\n\n\nUser limits imposed by the system (\n1CIUSERLIMITS\n)\n\n\nEnvironment variables in place (\n1CIENVVARS\n)\n\n\nSystem information (\n1CISYSINFO\n)\n\n\nCPU information (\n1CICPUINFO\n)\n\n\n\n\n\nFor clarity, the following example shows a shortened version of this section, where \n...\n indicates that lines are removed:\n\n\nNULL\n \n------------------------------------------------------------------------\n\n\n0\nSECTION\n \nENVINFO\n \nsubcomponent\n \ndump\n \nroutine\n\n\nNULL\n \n=================================\n\n\n1\nCIJAVAVERSION\n \nJRE\n \n9\n \nLinux\n \namd64\n-\n64\n \n(\nbuild\n \n9.0.4\n-\ninternal\n+\n0\n-\nadhoc\n..\nopenj9\n-\nopenjdk\n-\njdk9\n)\n\n\n1\nCIVMVERSION\n \n20180830\n_000000\n\n\n1\nCIJ9VMVERSION\n \n8e7\nc6ec\n\n\n1\nCIJITVERSION\n \n8e7\nc6ec\n\n\n1\nCIOMRVERSION\n \n553811\nb_CMPRSS\n\n\n1\nCIJCLVERSION\n \nec1d223\n \nbased\n \non\n \njdk\n-\n9.0.4\n+\n12\n\n\n1\nCIJITMODES\n \nJIT\n \nenabled\n,\n \nAOT\n \nenabled\n,\n \nFSD\n \ndisabled\n,\n \nHCR\n \nenabled\n\n\n1\nCIRUNNINGAS\n \nRunning\n \nas\n \na\n \nstandalone\n \nJVM\n\n\n1\nCIVMIDLESTATE\n \nVM\n \nIdle\n \nState\n:\n \nACTIVE\n\n\n1\nCISTARTTIME\n \nJVM\n \nstart\n \ntime\n:\n \n2018\n/\n08\n/\n30\n \nat\n \n21\n:\n55\n:\n47\n:\n387\n\n\n1\nCISTARTNANO\n \nJVM\n \nstart\n \nnanotime\n:\n \n22012135233549\n\n\n1\nCIPROCESSID\n \nProcess\n \nID\n:\n \n30285\n \n(\n0x764D\n)\n\n\n1\nCICMDLINE\n \n[\nnot\n \navailable\n]\n\n\n1\nCIJAVAHOMEDIR\n \nJava\n \nHome\n \nDir\n:\n \n/\nhome\n/\nme\n/\nopenj9\n-\nopenjdk\n-\njdk9\n/\nbuild\n/\nlinux\n-\nx86_64\n-\nnormal\n-\nserver\n-\nrelease\n/\nimages\n/\njdk\n\n\n1\nCIJAVADLLDIR\n \nJava\n \nDLL\n \nDir\n:\n \n/\nhome\n/\nme\n/\nopenj9\n-\nopenjdk\n-\njdk9\n/\nbuild\n/\nlinux\n-\nx86_64\n-\nnormal\n-\nserver\n-\nrelease\n/\nimages\n/\njdk\n/\nbin\n\n\n1\nCISYSCP\n \nSys\n \nClasspath\n:\n \n\n1\nCIUSERARGS\n \nUserArgs\n:\n\n\n2\nCIUSERARG\n \n-\nXoptionsfile\n=/\nhome\n/\nme\n/\nopenj9\n-\nopenjdk\n-\njdk9\n/\nbuild\n/\nlinux\n-\nx86_64\n-\nnormal\n-\nserver\n-\nrelease\n/\nimages\n/\njdk\n/\nlib\n/\noptions\n.\ndefault\n\n\n...\n\n\nNULL\n\n\n1\nCIUSERLIMITS\n \nUser\n \nLimits\n \n(\nin\n \nbytes\n \nexcept\n \nfor\n \nNOFILE\n \nand\n \nNPROC\n)\n\n\nNULL\n \n------------------------------------------------------------------------\n\n\nNULL\n \ntype\n \nsoft\n \nlimit\n \nhard\n \nlimit\n\n\n2\nCIUSERLIMIT\n \nRLIMIT_AS\n \nunlimited\n \nunlimited\n\n\n2\nCIUSERLIMIT\n \nRLIMIT_CORE\n \n0\n \nunlimited\n\n\n2\nCIUSERLIMIT\n \nRLIMIT_CPU\n \nunlimited\n \nunlimited\n\n\n2\nCIUSERLIMIT\n \nRLIMIT_DATA\n \nunlimited\n \nunlimited\n\n\n2\nCIUSERLIMIT\n \nRLIMIT_FSIZE\n \nunlimited\n \nunlimited\n\n\n2\nCIUSERLIMIT\n \nRLIMIT_LOCKS\n \nunlimited\n \nunlimited\n\n\n2\nCIUSERLIMIT\n \nRLIMIT_MEMLOCK\n \n65536\n \n65536\n\n\n2\nCIUSERLIMIT\n \nRLIMIT_NOFILE\n \n4096\n \n4096\n\n\n2\nCIUSERLIMIT\n \nRLIMIT_NPROC\n \n4096\n \n30592\n\n\n2\nCIUSERLIMIT\n \nRLIMIT_RSS\n \nunlimited\n \nunlimited\n\n\n2\nCIUSERLIMIT\n \nRLIMIT_STACK\n \n8388608\n \nunlimited\n\n\n2\nCIUSERLIMIT\n \nRLIMIT_MSGQUEUE\n \n819200\n \n819200\n\n\n2\nCIUSERLIMIT\n \nRLIMIT_NICE\n \n0\n \n0\n\n\n2\nCIUSERLIMIT\n \nRLIMIT_RTPRIO\n \n0\n \n0\n\n\n2\nCIUSERLIMIT\n \nRLIMIT_SIGPENDING\n \n30592\n \n30592\n\n\nNULL\n\n\n1\nCIENVVARS\n \nEnvironment\n \nVariables\n\n\nNULL\n \n------------------------------------------------------------------------\n\n\n2\nCIENVVAR\n \nXDG_VTNR\n=\n1\n\n\n2\nCIENVVAR\n \nSSH_AGENT_PID\n=\n2653\n\n\n...\n\n\nNULL\n \n\n1\nCISYSINFO\n \nSystem\n \nInformation\n\n\nNULL\n \n------------------------------------------------------------------------\n\n\n2\nCISYSINFO\n \n/\nproc\n/\nsys\n/\nkernel\n/\ncore_pattern\n \n=\n \ncore\n\n\n2\nCISYSINFO\n \n/\nproc\n/\nsys\n/\nkernel\n/\ncore_uses_pid\n \n=\n \n1\n\n\nNULL\n \n\n1\nCICPUINFO\n \nCPU\n \nInformation\n\n\nNULL\n \n------------------------------------------------------------------------\n\n\n2\nCIPHYSCPU\n \nPhysical\n \nCPUs\n:\n \n4\n\n\n2\nCIONLNCPU\n \nOnline\n \nCPUs\n:\n \n4\n\n\n2\nCIBOUNDCPU\n \nBound\n \nCPUs\n:\n \n4\n\n\n2\nCIACTIVECPU\n \nActive\n \nCPUs\n:\n \n0\n\n\n2\nCITARGETCPU\n \nTarget\n \nCPUs\n:\n \n4\n\n\n\n\n\n\n\n\n\nNATIVEMEMINFO\n\n\nThis section records information about native memory that is requested by using library functions such as \nmalloc()\n and \nmmap()\n.\nValues are provided as a breakdown, per component, indicating the total number of bytes allocated and the number of native memory allocations.\nIn the following example, 4,682,840 bytes of native memory are allocated (but not yet freed) to VM Classes, which corresponds to 141 allocations.\n\n\nNULL ------------------------------------------------------------------------\n0SECTION NATIVEMEMINFO subcomponent dump routine\nNULL =================================\n0MEMUSER\n1MEMUSER JRE: 2,569,088,312 bytes / 4653 allocations\n1MEMUSER |\n2MEMUSER +--VM: 2,280,088,336 bytes / 2423 allocations\n2MEMUSER | |\n3MEMUSER | +--Classes: 4,682,840 bytes / 141 allocations\n2MEMUSER | |\n3MEMUSER | +--Memory Manager (GC): 2,054,966,784 bytes / 433 allocations\n3MEMUSER | | |\n4MEMUSER | | +--Java Heap: 2,014,113,792 bytes / 1 allocation\n3MEMUSER | | |\n4MEMUSER | | +--Other: 40,852,992 bytes / 432 allocations\n2MEMUSER | |\n3MEMUSER | +--Threads: 10,970,016 bytes / 156 allocations\n3MEMUSER | | |\n4MEMUSER | | +--Java Stack: 197,760 bytes / 16 allocations\n3MEMUSER | | |\n4MEMUSER | | +--Native Stack: 10,616,832 bytes / 17 allocations\n3MEMUSER | | |\n4MEMUSER | | +--Other: 155,424 bytes / 123 allocations\n2MEMUSER | |\n3MEMUSER | +--Trace: 180,056 bytes / 263 allocations\n2MEMUSER | |\n3MEMUSER | +--JVMTI: 17,776 bytes / 13 allocations\n2MEMUSER | |\n3MEMUSER | +--JNI: 36,184 bytes / 52 allocations\n2MEMUSER | |\n3MEMUSER | +--Port Library: 208,179,632 bytes / 72 allocations\n3MEMUSER | | |\n4MEMUSER | | +--Unused <32bit allocation regions: 208,168,752 bytes / 1 allocation\n3MEMUSER | | |\n4MEMUSER | | +--Other: 10,880 bytes / 71 allocations\n2MEMUSER | |\n3MEMUSER | +--Other: 1,055,048 bytes / 1293 allocations\n1MEMUSER |\n2MEMUSER +--JIT: 288,472,816 bytes / 140 allocations\n2MEMUSER | |\n3MEMUSER | +--JIT Code Cache: 268,435,456 bytes / 1 allocation\n2MEMUSER | |\n3MEMUSER | +--JIT Data Cache: 2,097,216 bytes / 1 allocation\n2MEMUSER | |\n3MEMUSER | +--Other: 17,940,144 bytes / 138 allocations\n1MEMUSER |\n2MEMUSER +--Class Libraries: 13,432 bytes / 25 allocations\n2MEMUSER | |\n3MEMUSER | +--VM Class Libraries: 13,432 bytes / 25 allocations\n3MEMUSER | | |\n4MEMUSER | | +--sun.misc.Unsafe: 3,184 bytes / 13 allocations\n4MEMUSER | | | |\n5MEMUSER | | | +--Direct Byte Buffers: 1,056 bytes / 12 allocations\n4MEMUSER | | | |\n5MEMUSER | | | +--Other: 2,128 bytes / 1 allocation\n3MEMUSER | | |\n4MEMUSER | | +--Other: 10,248 bytes / 12 allocations\n1MEMUSER |\n2MEMUSER +--Unknown: 513,728 bytes / 2065 allocations\nNULL \n\n\n\n\n\nThis section does not record memory that is allocated by application or JNI code and is typically a little less than the\nvalue recorded by operating system tools.\n\n\nMEMINFO\n\n\nThis section relates to memory management, providing a breakdown of memory usage in the VM for the object heap,\ninternal memory, memory used for classes, the JIT code cache, and JIT data cache in decimal and hexadecimal format.\nYou can also find out which garbage collection policy is in use when the dump is produced. \n\n\nThe object memory area (\n1STHEAPTYPE\n) records each memory region in use, its start and end address, and region size.\nFurther information is recorded about the memory segments used for internal memory, class memory, the JIT code cache and JIT data cache (\n1STSEGMENT\n).\nThis information includes the address of the segment control data structure, the start and end address of the native memory segment, as well as\nthe segment size.\n\n\nFor clarity, the following example shows a shortened version of this section, where \n...\n indicates that lines are removed:\n\n\nNULL ------------------------------------------------------------------------\n0SECTION MEMINFO subcomponent dump routine\nNULL =================================\nNULL \n1STHEAPTYPE Object Memory\nNULL id start end size space/region\n1STHEAPSPACE 0x00007FF4F00744A0 -- -- -- Generational\n1STHEAPREGION 0x00007FF4F0074CE0 0x0000000087F40000 0x0000000088540000 0x0000000000600000 Generational/Tenured Region\n1STHEAPREGION 0x00007FF4F0074930 0x00000000FFE00000 0x00000000FFF00000 0x0000000000100000 Generational/Nursery Region\n1STHEAPREGION 0x00007FF4F0074580 0x00000000FFF00000 0x0000000100000000 0x0000000000100000 Generational/Nursery Region\nNULL\n1STHEAPTOTAL Total memory: 8388608 (0x0000000000800000)\n1STHEAPINUSE Total memory in use: 2030408 (0x00000000001EFB48)\n1STHEAPFREE Total memory free: 6358200 (0x00000000006104B8)\nNULL\n1STSEGTYPE Internal Memory\nNULL segment start alloc end type size\n1STSEGMENT 0x00007FF4F004CBC8 0x00007FF4CD33C000 0x00007FF4CD33C000 0x00007FF4CE33C000 0x01000440 0x0000000001000000\n1STSEGMENT 0x00007FF4F004CB08 0x00007FF4DE43D030 0x00007FF4DE517770 0x00007FF4DE53D030 0x00800040 0x0000000000100000\nNULL\n1STSEGTOTAL Total memory: 17825792 (0x0000000001100000)\n1STSEGINUSE Total memory in use: 894784 (0x00000000000DA740)\n1STSEGFREE Total memory free: 16931008 (0x00000000010258C0)\nNULL \n1STSEGTYPE Class Memory\nNULL segment start alloc end type size\n1STSEGMENT 0x00007FF4F03B5638 0x0000000001053D98 0x000000000105BD98 0x000000000105BD98 0x00010040 0x0000000000008000\n1STSEGMENT 0x00007FF4F03B5578 0x0000000001048188 0x0000000001050188 0x0000000001050188 0x00010040 0x0000000000008000\n...\nNULL\n1STSEGTOTAL Total memory: 3512520 (0x00000000003598C8)\n1STSEGINUSE Total memory in use: 3433944 (0x00000000003465D8)\n1STSEGFREE Total memory free: 78576 (0x00000000000132F0)\nNULL \n1STSEGTYPE JIT Code Cache\nNULL segment start alloc end type size\n1STSEGMENT 0x00007FF4F00961F8 0x00007FF4CE43D000 0x00007FF4CE445790 0x00007FF4DE43D000 0x00000068 0x0000000010000000\nNULL\n1STSEGTOTAL Total memory: 268435456 (0x0000000010000000)\n1STSEGINUSE Total memory in use: 34704 (0x0000000000008790)\n1STSEGFREE Total memory free: 268400752 (0x000000000FFF7870)\n1STSEGLIMIT Allocation limit: 268435456 (0x0000000010000000)\nNULL \n1STSEGTYPE JIT Data Cache\nNULL segment start alloc end type size\n1STSEGMENT 0x00007FF4F0096668 0x00007FF4CC553030 0x00007FF4CC753030 0x00007FF4CC753030 0x00000048 0x0000000000200000\nNULL\n1STSEGTOTAL Total memory: 2097152 (0x0000000000200000)\n1STSEGINUSE Total memory in use: 2097152 (0x0000000000200000)\n1STSEGFREE Total memory free: 0 (0x0000000000000000)\n1STSEGLIMIT Allocation limit: 402653184 (0x0000000018000000)\nNULL \n1STGCHTYPE GC History \nNULL \n\n\n\n\n\nIn the example, the GC History (\n1STGCHTYPE\n) section is blank. This section is populated if a garbage collection cycle occurred in\na VM that is being diagnosed with the trace facility.\n\n\nLOCKS\n\n\nThis 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.\n\n\nThe 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 \n...\n indicates that lines are removed:\n\n\nNULL\n \n------------------------------------------------------------------------\n\n\n0\nSECTION\n \nLOCKS\n \nsubcomponent\n \ndump\n \nroutine\n\n\nNULL\n \n===============================\n\n\nNULL\n \n\n1L\nKPOOLINFO\n \nMonitor\n \npool\n \ninfo\n:\n\n\n2L\nKPOOLTOTAL\n \nCurrent\n \ntotal\n \nnumber\n \nof\n \nmonitors\n:\n \n3\n\n\nNULL\n \n\n1L\nKMONPOOLDUMP\n \nMonitor\n \nPool\n \nDump\n \n(\nflat\n \n&\n \ninflated\n \nobject\n-\nmonitors\n)\n:\n\n\n2L\nKMONINUSE\n \nsys_mon_t\n:\n0x00007FF4B0001D78\n \ninfl_mon_t\n:\n \n0x00007FF4B0001DF8\n:\n\n\n3L\nKMONOBJECT\n \njava\n/\nlang\n/\nref\n/\nReferenceQueue\n@0x00000000FFE26A10\n:\n \n<\nunowned\n>\n\n\n3L\nKNOTIFYQ\n \nWaiting\n \nto\n \nbe\n \nnotified\n:\n\n\n3L\nKWAITNOTIFY\n \n\"Common-Cleaner\"\n \n(\nJ9VMThread\n:\n0x0000000000FD0100\n)\n\n\nNULL\n \n\n1L\nKREGMONDUMP\n \nJVM\n \nSystem\n \nMonitor\n \nDump\n \n(\nregistered\n \nmonitors\n)\n:\n\n\n2L\nKREGMON\n \nThread\n \nglobal\n \nlock\n \n(\n0x00007FF4F0004FE8\n)\n:\n \n<\nunowned\n>\n\n\n2L\nKREGMON\n \n&\n(\nPPG_mem_mem32_subAllocHeapMem32\n.\nmonitor\n)\n \nlock\n \n(\n0x00007FF4F0005098\n)\n:\n \n<\nunowned\n>\n\n\n2L\nKREGMON\n \nNLS\n \nhash\n \ntable\n \nlock\n \n(\n0x00007FF4F0005148\n)\n:\n \n<\nunowned\n>\n\n\n...\n\n\nNULL\n \n\n\n\n\n\nTHREADS\n\n\nThe 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.\n\n\nA Java thread runs on a native thread. Several lines are recorded for each Java thread in the \nThread Details\n subsection, which include the following key pieces of information:\n\n\n\n\n3XMTHREADINFO\n: The thread name, address information for the VM thread structures and Java thread object, the thread state, and thread priority.\n\n\n3XMJAVALTHREAD\n: The Java thread ID and daemon status from the thread object.\n\n\n3XMTHREADINFO1\n: The native operating system thread ID, priority, scheduling policy, internal VM thread state, and VM thread flags.\n\n\n3XMTHREADINFO2\n: The native stack address range.\n\n\n3XMTHREADINFO3\n: Java callstack information (\n4XESTACKTRACE\n) or Native call stack information (\n4XENATIVESTACK\n).\n\n\n5XESTACKTRACE\n: This line indicates whether locks were taken by a specific method.\n\n\n\n\nJava thread priorities are mapped to operating system priority values. Thread states are shown in the following table:\n\n\n\n\n\n\n\n\nThread state value\n\n\nStatus\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\nR\n\n\nRunnable\n\n\nThe thread is able to run\n\n\n\n\n\n\nCW\n\n\nCondition Wait\n\n\nThe thread is waiting\n\n\n\n\n\n\nS\n\n\nSuspended\n\n\nThe thread is suspended by another thread\n\n\n\n\n\n\nZ\n\n\nZombie\n\n\nThe thread is destroyed\n\n\n\n\n\n\nP\n\n\nParked\n\n\nThe thread is parked by \njava.util.concurrent\n\n\n\n\n\n\nB\n\n\nBlocked\n\n\nThe thread is waiting to obtain a lock\n\n\n\n\n\n\n\n\nFor threads that are parked (P), blocked (B), or waiting (CW), an additional line (\n3XMTHREADBLOCK\n) is included in the output that shows what the thread is parked on, blocked on, or waiting for.\n\n\nFor clarity, the following example shows a shortened version of a typical THREADS section, where \n...\n indicates that lines are removed:\n\n\nNULL\n \n------------------------------------------------------------------------\n\n\n0\nSECTION\n \nTHREADS\n \nsubcomponent\n \ndump\n \nroutine\n\n\nNULL\n \n=================================\n\n\nNULL\n\n\n1\nXMPOOLINFO\n \nJVM\n \nThread\n \npool\n \ninfo\n:\n\n\n2\nXMPOOLTOTAL\n \nCurrent\n \ntotal\n \nnumber\n \nof\n \npooled\n \nthreads\n:\n \n18\n\n\n2\nXMPOOLLIVE\n \nCurrent\n \ntotal\n \nnumber\n \nof\n \nlive\n \nthreads\n:\n \n16\n\n\n2\nXMPOOLDAEMON\n \nCurrent\n \ntotal\n \nnumber\n \nof\n \nlive\n \ndaemon\n \nthreads\n:\n \n15\n\n\nNULL\n \n\n1\nXMTHDINFO\n \nThread\n \nDetails\n\n\nNULL\n \n\n3\nXMTHREADINFO\n \n\"JIT Diagnostic Compilation Thread-7 Suspended\"\n \nJ9VMThread\n:\n0x0000000000EFC500\n,\n \nomrthread_t:\n0x00007FF4F00A77E8\n,\n \njava\n/\nlang\n/\nThread\n:\n0x00000000FFE97480\n,\n \nstate\n:\nR\n,\n \nprio\n=\n10\n\n\n3\nXMJAVALTHREAD\n \n(\njava\n/\nlang\n/\nThread\n \ngetId:\n0xA\n,\n \nisDaemon:true\n)\n\n\n3\nXMTHREADINFO1\n \n(\nnative\n \nthread\n \nID\n:\n0x7657\n,\n \nnative\n \npriority\n:\n0xB\n,\n \nnative\n \npolicy\n:\nUNKNOWN\n,\n \nvmstate\n:\nCW\n,\n \nvm\n \nthread\n \nflags\n:\n0x00000081\n)\n\n\n3\nXMTHREADINFO2\n \n(\nnative\n \nstack\n \naddress\n \nrange\n \nfrom\n:\n0x00007FF4CCC36000\n,\n \nto\n:\n0x00007FF4CCD36000\n,\n \nsize\n:\n0x100000\n)\n\n\n3\nXMCPUTIME\n \nCPU\n \nusage\n \ntotal\n:\n \n0.000037663\n \nsecs\n,\n \ncurrent\n \ncategory=\n\"JIT\"\n\n\n3\nXMHEAPALLOC\n \nHeap\n \nbytes\n \nallocated\n \nsince\n \nlast\n \nGC\n \ncycle\n=\n0\n \n(\n0x0\n)\n\n\n3\nXMTHREADINFO3\n \nNo\n \nJava\n \ncallstack\n \nassociated\n \nwith\n \nthis\n \nthread\n\n\n3\nXMTHREADINFO3\n \nNo\n \nnative\n \ncallstack\n \navailable\n \nfor\n \nthis\n \nthread\n\n\nNULL\n\n\n...\n\n\n3\nXMTHREADINFO\n \n\"Common-Cleaner\"\n \nJ9VMThread\n:\n0x0000000000FD0100\n,\n \nomrthread_t:\n0x00007FF4F022A520\n,\n \njava\n/\nlang\n/\nThread\n:\n0x00000000FFE26F40\n,\n \nstate\n:\nCW\n,\n \nprio\n=\n8\n\n\n3\nXMJAVALTHREAD\n \n(\njava\n/\nlang\n/\nThread\n \ngetId:\n0x2\n,\n \nisDaemon:true\n)\n\n\n3\nXMTHREADINFO1\n \n(\nnative\n \nthread\n \nID\n:\n0x765A\n,\n \nnative\n \npriority\n:\n0x8\n,\n \nnative\n \npolicy\n:\nUNKNOWN\n,\n \nvmstate\n:\nCW\n,\n \nvm\n \nthread\n \nflags\n:\n0x00080181\n)\n\n\n3\nXMTHREADINFO2\n \n(\nnative\n \nstack\n \naddress\n \nrange\n \nfrom\n:\n0x00007FF4CC0B8000\n,\n \nto\n:\n0x00007FF4CC0F8000\n,\n \nsize\n:\n0x40000\n)\n\n\n3\nXMCPUTIME\n \nCPU\n \nusage\n \ntotal\n:\n \n0.000150926\n \nsecs\n,\n \ncurrent\n \ncategory=\n\"Application\"\n\n\n3\nXMTHREADBLOCK\n \nWaiting\n \non\n:\n \njava\n/\nlang\n/\nref\n/\nReferenceQueue\n@\n0x00000000FFE26A10\n \nOwned\n \nby\n:\n \n<\nunowned\n>\n\n\n3\nXMHEAPALLOC\n \nHeap\n \nbytes\n \nallocated\n \nsince\n \nlast\n \nGC\n \ncycle\n=\n0\n \n(\n0x0\n)\n\n\n3\nXMTHREADINFO3\n \nJava\n \ncallstack\n:\n\n\n4\nXESTACKTRACE\n \nat\n \njava\n/\nlang\n/\nObject\n.\nwait\n(\nNative\n \nMethod\n)\n\n\n4\nXESTACKTRACE\n \nat\n \njava\n/\nlang\n/\nObject\n.\nwait\n(\nObject\n.\njava\n:\n221\n)\n\n\n4\nXESTACKTRACE\n \nat\n \njava\n/\nlang\n/\nref\n/\nReferenceQueue\n.\nremove\n(\nReferenceQueue\n.\njava\n:\n138\n)\n\n\n5\nXESTACKTRACE\n \n(\nentered\n \nlock\n:\n \njava\n/\nlang\n/\nref\n/\nReferenceQueue\n@\n0x00000000FFE26A10\n,\n \nentry\n \ncount\n:\n \n1\n)\n\n\n4\nXESTACKTRACE\n \nat\n \njdk\n/\ninternal\n/\nref\n/\nCleanerImpl\n.\nrun\n(\nCleanerImpl\n.\njava\n:\n148\n)\n\n\n4\nXESTACKTRACE\n \nat\n \njava\n/\nlang\n/\nThread\n.\nrun\n(\nThread\n.\njava\n:\n835\n)\n\n\n4\nXESTACKTRACE\n \nat\n \njdk\n/\ninternal\n/\nmisc\n/\nInnocuousThread\n.\nrun\n(\nInnocuousThread\n.\njava\n:\n122\n)\n\n\n3\nXMTHREADINFO3\n \nNo\n \nnative\n \ncallstack\n \navailable\n \nfor\n \nthis\n \nthread\n\n\nNULL\n\n\nNULL\n\n\n3\nXMTHREADINFO\n \n\"IProfiler\"\n \nJ9VMThread\n:\n0x0000000000F03D00\n,\n \nomrthread_t:\n0x00007FF4F00B06F8\n,\n \njava\n/\nlang\n/\nThread\n:\n0x00000000FFE97B60\n,\n \nstate\n:\nR\n,\n \nprio\n=\n5\n\n\n3\nXMJAVALTHREAD\n \n(\njava\n/\nlang\n/\nThread\n \ngetId:\n0xC\n,\n \nisDaemon:true\n)\n\n\n3\nXMTHREADINFO1\n \n(\nnative\n \nthread\n \nID\n:\n0x7659\n,\n \nnative\n \npriority\n:\n0x5\n,\n \nnative\n \npolicy\n:\nUNKNOWN\n,\n \nvmstate\n:\nCW\n,\n \nvm\n \nthread\n \nflags\n:\n0x00000081\n)\n\n\n3\nXMTHREADINFO2\n \n(\nnative\n \nstack\n \naddress\n \nrange\n \nfrom\n:\n0x00007FF4F8940000\n,\n \nto\n:\n0x00007FF4F8960000\n,\n \nsize\n:\n0x20000\n)\n\n\n3\nXMCPUTIME\n \nCPU\n \nusage\n \ntotal\n:\n \n0.004753103\n \nsecs\n,\n \ncurrent\n \ncategory=\n\"JIT\"\n\n\n3\nXMHEAPALLOC\n \nHeap\n \nbytes\n \nallocated\n \nsince\n \nlast\n \nGC\n \ncycle\n=\n0\n \n(\n0x0\n)\n\n\n3\nXMTHREADINFO3\n \nNo\n \nJava\n \ncallstack\n \nassociated\n \nwith\n \nthis\n \nthread\n\n\n3\nXMTHREADINFO3\n \nNo\n \nnative\n \ncallstack\n \navailable\n \nfor\n \nthis\n \nthread\n\n\nNULL\n\n\n...\n\n\n1\nXMWLKTHDERR\n \nThe\n \nfollowing\n \nwas\n \nreported\n \nwhile\n \ncollecting\n \nnative\n \nstacks\n:\n\n\n2\nXMWLKTHDERR\n \nunable\n \nto\n \ncount\n \nthreads\n(\n3\n,\n \n-\n2\n)\n\n\nNULL\n\n\n1\nXMTHDSUMMARY\n \nThreads\n \nCPU\n \nUsage\n \nSummary\n\n\nNULL\n \n=========================\n\n\nNULL\n\n\n1\nXMTHDCATINFO\n \nWarning\n:\n \nto\n \nget\n \nmore\n \naccurate\n \nCPU\n \ntimes\n \nfor\n \nthe\n \nGC\n,\n \nthe\n \noption\n \n-\nXX\n:-\nReduceCPUMonitorOverhead\n \ncan\n \nbe\n \nused\n.\n \nSee\n \nthe\n \nuser\n \nguide\n \nfor\n \nmore\n \ninformation\n.\n\n\nNULL\n\n\n1\nXMTHDCATEGORY\n \nAll\n \nJVM\n \nattached\n \nthreads\n:\n \n0.280083000\n \nsecs\n\n\n1\nXMTHDCATEGORY\n \n|\n\n\n2\nXMTHDCATEGORY\n \n+--\nSystem\n-\nJVM\n:\n \n0.270814000\n \nsecs\n\n\n2\nXMTHDCATEGORY\n \n|\n \n|\n\n\n3\nXMTHDCATEGORY\n \n|\n \n+--\nGC\n:\n \n0.000599000\n \nsecs\n\n\n2\nXMTHDCATEGORY\n \n|\n \n|\n\n\n3\nXMTHDCATEGORY\n \n|\n \n+--\nJIT\n:\n \n0.071904000\n \nsecs\n\n\n1\nXMTHDCATEGORY\n \n|\n\n\n2\nXMTHDCATEGORY\n \n+--\nApplication\n:\n \n0.009269000\n \nsecs\n\n\nNULL\n\n\n\n\n\n\nHOOKS\n\n\nThis 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 \nJ9VMHookInterface\n, including the call site location (source file:line number), start time, and duration of the last callback and the longest callback.\n\n\nNULL ------------------------------------------------------------------------\n0SECTION HOOK subcomponent dump routine\nNULL ==============================\n1HKINTERFACE MM_OMRHookInterface\nNULL ------------------------------------------------------------------------\n1HKINTERFACE MM_PrivateHookInterface\nNULL ------------------------------------------------------------------------\n1HKINTERFACE MM_HookInterface\nNULL ------------------------------------------------------------------------\n1HKINTERFACE J9VMHookInterface\nNULL ------------------------------------------------------------------------\n2HKEVENTID 1\n3HKCALLCOUNT 18\n3HKLAST Last Callback\n4HKCALLSITE trcengine.c:392\n4HKSTARTTIME Start Time: 2018-08-30T21:55:47.601\n4HKDURATION DurationMs: 0\n3HKLONGST Longest Callback\n4HKCALLSITE trcengine.c:392\n4HKSTARTTIME Start Time: 2018-08-30T21:55:47.460\n4HKDURATION DurationMs: 1\nNULL\n...\n1HKINTERFACE J9VMZipCachePoolHookInterface\nNULL ------------------------------------------------------------------------\n1HKINTERFACE J9JITHookInterface\nNULL ------------------------------------------------------------------------\n2HKEVENTID 3\n3HKCALLCOUNT 65\n3HKLAST Last Callback\n4HKCALLSITE ../common/mgmtinit.c:191\n4HKSTARTTIME Start Time: 2018-08-30T21:55:47.601\n4HKDURATION DurationMs: 0\n3HKLONGST Longest Callback\n4HKCALLSITE ../common/mgmtinit.c:191\n4HKSTARTTIME Start Time: 2018-08-30T21:55:47.486\n4HKDURATION DurationMs: 0\n...\nNULL\n\n\n\n\n\nSHARED CLASSES\n\n\nIf 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.\n\n\nIn the following example, the shared classes cache was created with a Class Debug Area (\n-Xnolinenumbers=false\n). 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.\n\n\nThe \nCache Summary\n shows a cache size (\n2SCLTEXTCSZ\n) of 16776608 bytes, with a soft maximum size (\n2SCLTEXTSMB\n) also of 16776608 bytes, which leaves 12691668 bytes of free space (\n2SCLTEXTFRB\n). The size of the Class Debug Area (\n2SCLTEXTDAS\n) is 1331200 bytes and only 11% of this space is used.\n\n\nIn the \nCache Memory Status\n subsection, the line \n2SCLTEXTCMDT\n indicates the name and location of the shared cache and \ncr\n indicates that the cache is a 64-bit compressed references cache.\n\n\nNULL ------------------------------------------------------------------------\n0SECTION SHARED CLASSES subcomponent dump routine\nNULL ========================================\nNULL\n1SCLTEXTCRTW Cache Created With\nNULL ------------------\nNULL\n2SCLTEXTXNL -Xnolinenumbers = false\n2SCLTEXTBCI BCI Enabled = true\n2SCLTEXTBCI Restrict Classpaths = false\nNULL\n1SCLTEXTCSUM Cache Summary\nNULL ------------------\nNULL\n2SCLTEXTNLC No line number content = false\n2SCLTEXTLNC Line number content = true\nNULL\n2SCLTEXTRCS ROMClass start address = 0x00007F423061C000\n2SCLTEXTRCE ROMClass end address = 0x00007F42307B9A28\n2SCLTEXTMSA Metadata start address = 0x00007F42313D42FC\n2SCLTEXTCEA Cache end address = 0x00007F4231600000\n2SCLTEXTRTF Runtime flags = 0x00102001ECA6028B\n2SCLTEXTCGN Cache generation = 35\nNULL\n2SCLTEXTCSZ Cache size = 16776608\n2SCLTEXTSMB Softmx bytes = 16776608\n2SCLTEXTFRB Free bytes = 12691668\n2SCLTEXTRCB ROMClass bytes = 1694248\n2SCLTEXTAOB AOT code bytes = 0\n2SCLTEXTADB AOT data bytes = 0\n2SCLTEXTAHB AOT class hierarchy bytes = 32\n2SCLTEXTATB AOT thunk bytes = 0\n2SCLTEXTARB Reserved space for AOT bytes = -1\n2SCLTEXTAMB Maximum space for AOT bytes = -1\n2SCLTEXTJHB JIT hint bytes = 308\n2SCLTEXTJPB JIT profile bytes = 2296\n2SCLTEXTJRB Reserved space for JIT data bytes = -1\n2SCLTEXTJMB Maximum space for JIT data bytes = -1\n2SCLTEXTNOB Java Object bytes = 0\n2SCLTEXTZCB Zip cache bytes = 919328\n2SCLTEXTRWB ReadWrite bytes = 114080\n2SCLTEXTJCB JCL data bytes = 0\n2SCLTEXTBDA Byte data bytes = 0\n2SCLTEXTMDA Metadata bytes = 23448\n2SCLTEXTDAS Class debug area size = 1331200\n2SCLTEXTDAU Class debug area % used = 11%\n2SCLTEXTDAN Class LineNumberTable bytes = 156240\n2SCLTEXTDAV Class LocalVariableTable bytes = 0\nNULL\n2SCLTEXTNRC Number ROMClasses = 595\n2SCLTEXTNAM Number AOT Methods = 0\n2SCLTEXTNAD Number AOT Data Entries = 0\n2SCLTEXTNAH Number AOT Class Hierarchy = 1\n2SCLTEXTNAT Number AOT Thunks = 0\n2SCLTEXTNJH Number JIT Hints = 14\n2SCLTEXTNJP Number JIT Profiles = 20\n2SCLTEXTNCP Number Classpaths = 1\n2SCLTEXTNUR Number URLs = 0\n2SCLTEXTNTK Number Tokens = 0\n2SCLTEXTNOJ Number Java Objects = 0\n2SCLTEXTNZC Number Zip Caches = 5\n2SCLTEXTNJC Number JCL Entries = 0\n2SCLTEXTNST Number Stale classes = 0\n2SCLTEXTPST Percent Stale classes = 0%\nNULL\n2SCLTEXTCPF Cache is 24% full\nNULL\n1SCLTEXTCMST Cache Memory Status\nNULL ------------------\n1SCLTEXTCNTD Cache Name Feature Memory type Cache path\nNULL\n2SCLTEXTCMDT sharedcc_doc-javacore CR Memory mapped file /tmp/javasharedresources/C290M4F1A64P_sharedcc_doc-javacore_G35\nNULL\n1SCLTEXTCMST Cache Lock Status\nNULL ------------------\n1SCLTEXTCNTD Lock Name Lock type TID owning lock\nNULL\n2SCLTEXTCWRL Cache write lock File lock Unowned\n2SCLTEXTCRWL Cache read/write lock File lock Unowned\nNULL\n\n\n\n\n\nCLASSES\n\n\nThe classes section shows information about class loaders. The first part is a summary that records each available class loader (\n2CLTEXTCLLOADER\n) followed by the number of libraries and classes that it loaded. This information is followed by a more detailed list of libraries (\n1CLTEXTCLLIB\n) and classes (\n1CLTEXTCLLO\n) that are loaded.\n\n\nIn the example we can see that the \njava/lang/InternalAnonymousClassLoader\n loaded 2 classes, \njdk/internal/loader/BuiltinClassLoader$$Lambda$2/00000000F03876A0(0x0000000001030F00)\n and \njdk/internal/loader/BuiltinClassLoader$$Lambda$1/00000000F00D2460(0x0000000001018A00)\n.\n\n\nNULL ------------------------------------------------------------------------\n0SECTION CLASSES subcomponent dump routine\nNULL =================================\n1CLTEXTCLLOS Classloader summaries\n1CLTEXTCLLSS 12345678: 1=primordial,2=extension,3=shareable,4=middleware,5=system,6=trusted,7=application,8=delegating\n2CLTEXTCLLOADER p---st-- Loader *System*(0x00000000FFE1D258)\n3CLNMBRLOADEDLIB Number of loaded libraries 5\n3CLNMBRLOADEDCL Number of loaded classes 638\n2CLTEXTCLLOADER -x--st-- Loader jdk/internal/loader/ClassLoaders$PlatformClassLoader(0x00000000FFE1D4F0), Parent *none*(0x0000000000000000)\n3CLNMBRLOADEDLIB Number of loaded libraries 0\n3CLNMBRLOADEDCL Number of loaded classes 0\n2CLTEXTCLLOADER ----st-- Loader java/lang/InternalAnonymousClassLoader(0x00000000FFE1DFD0), Parent *none*(0x0000000000000000)\n3CLNMBRLOADEDLIB Number of loaded libraries 0\n3CLNMBRLOADEDCL Number of loaded classes 2\n2CLTEXTCLLOADER -----ta- Loader jdk/internal/loader/ClassLoaders$AppClassLoader(0x00000000FFE1DAD0), Parent jdk/internal/loader/ClassLoaders$PlatformClassLoader(0x00000000FFE1D4F0)\n3CLNMBRLOADEDLIB Number of loaded libraries 0\n3CLNMBRLOADEDCL Number of loaded classes 0\n1CLTEXTCLLIB ClassLoader loaded libraries\n2CLTEXTCLLIB Loader *System*(0x00000000FFE1D258)\n3CLTEXTLIB /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/compressedrefs/jclse9_29\n3CLTEXTLIB /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/java\n3CLTEXTLIB /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/compressedrefs/j9jit29\n3CLTEXTLIB /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/zip\n3CLTEXTLIB /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/nio\n1CLTEXTCLLOD ClassLoader loaded classes\n2CLTEXTCLLOAD Loader *System*(0x00000000FFE1D258)\n3CLTEXTCLASS [Ljava/lang/Thread$State;(0x0000000001056400)\n...\n2CLTEXTCLLOAD Loader jdk/internal/loader/ClassLoaders$PlatformClassLoader(0x00000000FFE1D4F0)\n2CLTEXTCLLOAD Loader java/lang/InternalAnonymousClassLoader(0x00000000FFE1DFD0)\n3CLTEXTCLASS jdk/internal/loader/BuiltinClassLoader$$Lambda$2/00000000F03876A0(0x0000000001030F00)\n3CLTEXTCLASS jdk/internal/loader/BuiltinClassLoader$$Lambda$1/00000000F00D2460(0x0000000001018A00)\n2CLTEXTCLLOAD Loader jdk/internal/loader/ClassLoaders$AppClassLoader(0x00000000FFE1DAD0)",
"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 exception, 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. Java dumps summarize the state of the VM when the event occurs, with most of the information relating to components of the VM.\nThe file is made up of a number of sections that provide different types of information. The information that follows describes\neach section and provides examples to help you interpret the data.",
"title": "Java dump"
},
{
"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.\nIn the following example you can see that a vmstop event triggered the dump at a specified date and time. 0SECTION TITLE subcomponent dump routine\nNULL ===============================\n1TICHARSET UTF-8\n1TISIGINFO Dump Event \"vmstop\" (00000002) Detail \"#0000000000000000\" received\n1TIDATETIME Date: 2018/08/30 at 21:55:47:607\n1TINANOTIME System nanotime: 22012355276134\n1TIFILENAME Javacore filename: /home/doc-javacore/javacore.20180830.215547.30285.0001.txt\n1TIREQFLAGS Request Flags: 0x81 (exclusive+preempt)\n1TIPREPSTATE 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 JVM is running on. The following example is taken\nfrom a Java dump that was generated on a Linux system. NULL ------------------------------------------------------------------------\n0SECTION GPINFO subcomponent dump routine\nNULL ================================\n2XHOSLEVEL OS Level : Linux 3.10.0-862.11.6.el7.x86_64\n2XHCPUS Processors -\n3XHCPUARCH Architecture : amd64\n3XHNUMCPUS How Many : 4\n3XHNUMASUP NUMA is either not supported or has been disabled by user\nNULL \n1XHERROR2 Register dump section only produced for SIGSEGV, SIGILL or SIGFPE.\nNULL The content of this section can vary, depending on the cause of the dump. For example, if the dump was caused by a\ngeneral protection fault (gpf), the library in which the crash occurred is also recorded, together with a value shown\nas VM flags . This value can provide some clues about which component of the VM might have been involved. Look for the\nfollowing 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 ) For clarity, the following example shows a shortened version of this section, where ... indicates that lines are removed: NULL ------------------------------------------------------------------------ 0 SECTION ENVINFO subcomponent dump routine NULL ================================= 1 CIJAVAVERSION JRE 9 Linux amd64 - 64 ( build 9.0.4 - internal + 0 - adhoc .. openj9 - openjdk - jdk9 ) 1 CIVMVERSION 20180830 _000000 1 CIJ9VMVERSION 8e7 c6ec 1 CIJITVERSION 8e7 c6ec 1 CIOMRVERSION 553811 b_CMPRSS 1 CIJCLVERSION ec1d223 based on jdk - 9.0.4 + 12 1 CIJITMODES JIT enabled , AOT enabled , FSD disabled , HCR enabled 1 CIRUNNINGAS Running as a standalone JVM 1 CIVMIDLESTATE VM Idle State : ACTIVE 1 CISTARTTIME JVM start time : 2018 / 08 / 30 at 21 : 55 : 47 : 387 1 CISTARTNANO JVM start nanotime : 22012135233549 1 CIPROCESSID Process ID : 30285 ( 0x764D ) 1 CICMDLINE [ not available ] 1 CIJAVAHOMEDIR Java Home Dir : / home / me / openj9 - openjdk - jdk9 / build / linux - x86_64 - normal - server - release / images / jdk 1 CIJAVADLLDIR Java DLL Dir : / home / me / openj9 - openjdk - jdk9 / build / linux - x86_64 - normal - server - release / images / jdk / bin 1 CISYSCP Sys Classpath : 1 CIUSERARGS UserArgs : 2 CIUSERARG - Xoptionsfile =/ home / me / openj9 - openjdk - jdk9 / build / linux - x86_64 - normal - server - release / images / jdk / lib / options . default ... NULL 1 CIUSERLIMITS User Limits ( in bytes except for NOFILE and NPROC ) NULL ------------------------------------------------------------------------ NULL type soft limit hard limit 2 CIUSERLIMIT RLIMIT_AS unlimited unlimited 2 CIUSERLIMIT RLIMIT_CORE 0 unlimited 2 CIUSERLIMIT RLIMIT_CPU unlimited unlimited 2 CIUSERLIMIT RLIMIT_DATA unlimited unlimited 2 CIUSERLIMIT RLIMIT_FSIZE unlimited unlimited 2 CIUSERLIMIT RLIMIT_LOCKS unlimited unlimited 2 CIUSERLIMIT RLIMIT_MEMLOCK 65536 65536 2 CIUSERLIMIT RLIMIT_NOFILE 4096 4096 2 CIUSERLIMIT RLIMIT_NPROC 4096 30592 2 CIUSERLIMIT RLIMIT_RSS unlimited unlimited 2 CIUSERLIMIT RLIMIT_STACK 8388608 unlimited 2 CIUSERLIMIT RLIMIT_MSGQUEUE 819200 819200 2 CIUSERLIMIT RLIMIT_NICE 0 0 2 CIUSERLIMIT RLIMIT_RTPRIO 0 0 2 CIUSERLIMIT RLIMIT_SIGPENDING 30592 30592 NULL 1 CIENVVARS Environment Variables NULL ------------------------------------------------------------------------ 2 CIENVVAR XDG_VTNR = 1 2 CIENVVAR SSH_AGENT_PID = 2653 ... NULL 1 CISYSINFO System Information NULL ------------------------------------------------------------------------ 2 CISYSINFO / proc / sys / kernel / core_pattern = core 2 CISYSINFO / proc / sys / kernel / core_uses_pid = 1 NULL 1 CICPUINFO CPU Information NULL ------------------------------------------------------------------------ 2 CIPHYSCPU Physical CPUs : 4 2 CIONLNCPU Online CPUs : 4 2 CIBOUNDCPU Bound CPUs : 4 2 CIACTIVECPU Active CPUs : 0 2 CITARGETCPU Target CPUs : 4",
"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() .\nValues are provided as a breakdown, per component, indicating the total number of bytes allocated and the number of native memory allocations.\nIn 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 ------------------------------------------------------------------------\n0SECTION NATIVEMEMINFO subcomponent dump routine\nNULL =================================\n0MEMUSER\n1MEMUSER JRE: 2,569,088,312 bytes / 4653 allocations\n1MEMUSER |\n2MEMUSER +--VM: 2,280,088,336 bytes / 2423 allocations\n2MEMUSER | |\n3MEMUSER | +--Classes: 4,682,840 bytes / 141 allocations\n2MEMUSER | |\n3MEMUSER | +--Memory Manager (GC): 2,054,966,784 bytes / 433 allocations\n3MEMUSER | | |\n4MEMUSER | | +--Java Heap: 2,014,113,792 bytes / 1 allocation\n3MEMUSER | | |\n4MEMUSER | | +--Other: 40,852,992 bytes / 432 allocations\n2MEMUSER | |\n3MEMUSER | +--Threads: 10,970,016 bytes / 156 allocations\n3MEMUSER | | |\n4MEMUSER | | +--Java Stack: 197,760 bytes / 16 allocations\n3MEMUSER | | |\n4MEMUSER | | +--Native Stack: 10,616,832 bytes / 17 allocations\n3MEMUSER | | |\n4MEMUSER | | +--Other: 155,424 bytes / 123 allocations\n2MEMUSER | |\n3MEMUSER | +--Trace: 180,056 bytes / 263 allocations\n2MEMUSER | |\n3MEMUSER | +--JVMTI: 17,776 bytes / 13 allocations\n2MEMUSER | |\n3MEMUSER | +--JNI: 36,184 bytes / 52 allocations\n2MEMUSER | |\n3MEMUSER | +--Port Library: 208,179,632 bytes / 72 allocations\n3MEMUSER | | |\n4MEMUSER | | +--Unused <32bit allocation regions: 208,168,752 bytes / 1 allocation\n3MEMUSER | | |\n4MEMUSER | | +--Other: 10,880 bytes / 71 allocations\n2MEMUSER | |\n3MEMUSER | +--Other: 1,055,048 bytes / 1293 allocations\n1MEMUSER |\n2MEMUSER +--JIT: 288,472,816 bytes / 140 allocations\n2MEMUSER | |\n3MEMUSER | +--JIT Code Cache: 268,435,456 bytes / 1 allocation\n2MEMUSER | |\n3MEMUSER | +--JIT Data Cache: 2,097,216 bytes / 1 allocation\n2MEMUSER | |\n3MEMUSER | +--Other: 17,940,144 bytes / 138 allocations\n1MEMUSER |\n2MEMUSER +--Class Libraries: 13,432 bytes / 25 allocations\n2MEMUSER | |\n3MEMUSER | +--VM Class Libraries: 13,432 bytes / 25 allocations\n3MEMUSER | | |\n4MEMUSER | | +--sun.misc.Unsafe: 3,184 bytes / 13 allocations\n4MEMUSER | | | |\n5MEMUSER | | | +--Direct Byte Buffers: 1,056 bytes / 12 allocations\n4MEMUSER | | | |\n5MEMUSER | | | +--Other: 2,128 bytes / 1 allocation\n3MEMUSER | | |\n4MEMUSER | | +--Other: 10,248 bytes / 12 allocations\n1MEMUSER |\n2MEMUSER +--Unknown: 513,728 bytes / 2065 allocations\nNULL This section does not record memory that is allocated by application or JNI code and is typically a little less than the\nvalue 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,\ninternal memory, memory used for classes, the JIT code cache, and JIT data cache in decimal and hexadecimal format.\nYou 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.\nFurther information is recorded about the memory segments used for internal memory, class memory, the JIT code cache and JIT data cache ( 1STSEGMENT ).\nThis information includes the address of the segment control data structure, the start and end address of the native memory segment, as well as\nthe segment size. For clarity, the following example shows a shortened version of this section, where ... indicates that lines are removed: NULL ------------------------------------------------------------------------\n0SECTION MEMINFO subcomponent dump routine\nNULL =================================\nNULL \n1STHEAPTYPE Object Memory\nNULL id start end size space/region\n1STHEAPSPACE 0x00007FF4F00744A0 -- -- -- Generational\n1STHEAPREGION 0x00007FF4F0074CE0 0x0000000087F40000 0x0000000088540000 0x0000000000600000 Generational/Tenured Region\n1STHEAPREGION 0x00007FF4F0074930 0x00000000FFE00000 0x00000000FFF00000 0x0000000000100000 Generational/Nursery Region\n1STHEAPREGION 0x00007FF4F0074580 0x00000000FFF00000 0x0000000100000000 0x0000000000100000 Generational/Nursery Region\nNULL\n1STHEAPTOTAL Total memory: 8388608 (0x0000000000800000)\n1STHEAPINUSE Total memory in use: 2030408 (0x00000000001EFB48)\n1STHEAPFREE Total memory free: 6358200 (0x00000000006104B8)\nNULL\n1STSEGTYPE Internal Memory\nNULL segment start alloc end type size\n1STSEGMENT 0x00007FF4F004CBC8 0x00007FF4CD33C000 0x00007FF4CD33C000 0x00007FF4CE33C000 0x01000440 0x0000000001000000\n1STSEGMENT 0x00007FF4F004CB08 0x00007FF4DE43D030 0x00007FF4DE517770 0x00007FF4DE53D030 0x00800040 0x0000000000100000\nNULL\n1STSEGTOTAL Total memory: 17825792 (0x0000000001100000)\n1STSEGINUSE Total memory in use: 894784 (0x00000000000DA740)\n1STSEGFREE Total memory free: 16931008 (0x00000000010258C0)\nNULL \n1STSEGTYPE Class Memory\nNULL segment start alloc end type size\n1STSEGMENT 0x00007FF4F03B5638 0x0000000001053D98 0x000000000105BD98 0x000000000105BD98 0x00010040 0x0000000000008000\n1STSEGMENT 0x00007FF4F03B5578 0x0000000001048188 0x0000000001050188 0x0000000001050188 0x00010040 0x0000000000008000\n...\nNULL\n1STSEGTOTAL Total memory: 3512520 (0x00000000003598C8)\n1STSEGINUSE Total memory in use: 3433944 (0x00000000003465D8)\n1STSEGFREE Total memory free: 78576 (0x00000000000132F0)\nNULL \n1STSEGTYPE JIT Code Cache\nNULL segment start alloc end type size\n1STSEGMENT 0x00007FF4F00961F8 0x00007FF4CE43D000 0x00007FF4CE445790 0x00007FF4DE43D000 0x00000068 0x0000000010000000\nNULL\n1STSEGTOTAL Total memory: 268435456 (0x0000000010000000)\n1STSEGINUSE Total memory in use: 34704 (0x0000000000008790)\n1STSEGFREE Total memory free: 268400752 (0x000000000FFF7870)\n1STSEGLIMIT Allocation limit: 268435456 (0x0000000010000000)\nNULL \n1STSEGTYPE JIT Data Cache\nNULL segment start alloc end type size\n1STSEGMENT 0x00007FF4F0096668 0x00007FF4CC553030 0x00007FF4CC753030 0x00007FF4CC753030 0x00000048 0x0000000000200000\nNULL\n1STSEGTOTAL Total memory: 2097152 (0x0000000000200000)\n1STSEGINUSE Total memory in use: 2097152 (0x0000000000200000)\n1STSEGFREE Total memory free: 0 (0x0000000000000000)\n1STSEGLIMIT Allocation limit: 402653184 (0x0000000018000000)\nNULL \n1STGCHTYPE GC History \nNULL In the example, the GC History ( 1STGCHTYPE ) section is blank. This section is populated if a garbage collection cycle occurred in\na 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 ------------------------------------------------------------------------ 0 SECTION LOCKS subcomponent dump routine NULL =============================== NULL 1L KPOOLINFO Monitor pool info : 2L KPOOLTOTAL Current total number of monitors : 3 NULL 1L KMONPOOLDUMP Monitor Pool Dump ( flat & inflated object - monitors ) : 2L KMONINUSE sys_mon_t : 0x00007FF4B0001D78 infl_mon_t : 0x00007FF4B0001DF8 : 3L KMONOBJECT java / lang / ref / ReferenceQueue @0x00000000FFE26A10 : < unowned > 3L KNOTIFYQ Waiting to be notified : 3L KWAITNOTIFY \"Common-Cleaner\" ( J9VMThread : 0x0000000000FD0100 ) NULL 1L KREGMONDUMP JVM System Monitor Dump ( registered monitors ) : 2L KREGMON Thread global lock ( 0x00007FF4F0004FE8 ) : < unowned > 2L KREGMON & ( PPG_mem_mem32_subAllocHeapMem32 . monitor ) lock ( 0x00007FF4F0005098 ) : < unowned > 2L KREGMON 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 ------------------------------------------------------------------------ 0 SECTION THREADS subcomponent dump routine NULL ================================= NULL 1 XMPOOLINFO JVM Thread pool info : 2 XMPOOLTOTAL Current total number of pooled threads : 18 2 XMPOOLLIVE Current total number of live threads : 16 2 XMPOOLDAEMON Current total number of live daemon threads : 15 NULL 1 XMTHDINFO Thread Details NULL 3 XMTHREADINFO \"JIT Diagnostic Compilation Thread-7 Suspended\" J9VMThread : 0x0000000000EFC500 , omrthread_t: 0x00007FF4F00A77E8 , java / lang / Thread : 0x00000000FFE97480 , state : R , prio = 10 3 XMJAVALTHREAD ( java / lang / Thread getId: 0xA , isDaemon:true ) 3 XMTHREADINFO1 ( native thread ID : 0x7657 , native priority : 0xB , native policy : UNKNOWN , vmstate : CW , vm thread flags : 0x00000081 ) 3 XMTHREADINFO2 ( native stack address range from : 0x00007FF4CCC36000 , to : 0x00007FF4CCD36000 , size : 0x100000 ) 3 XMCPUTIME CPU usage total : 0.000037663 secs , current category= \"JIT\" 3 XMHEAPALLOC Heap bytes allocated since last GC cycle = 0 ( 0x0 ) 3 XMTHREADINFO3 No Java callstack associated with this thread 3 XMTHREADINFO3 No native callstack available for this thread NULL ... 3 XMTHREADINFO \"Common-Cleaner\" J9VMThread : 0x0000000000FD0100 , omrthread_t: 0x00007FF4F022A520 , java / lang / Thread : 0x00000000FFE26F40 , state : CW , prio = 8 3 XMJAVALTHREAD ( java / lang / Thread getId: 0x2 , isDaemon:true ) 3 XMTHREADINFO1 ( native thread ID : 0x765A , native priority : 0x8 , native policy : UNKNOWN , vmstate : CW , vm thread flags : 0x00080181 ) 3 XMTHREADINFO2 ( native stack address range from : 0x00007FF4CC0B8000 , to : 0x00007FF4CC0F8000 , size : 0x40000 ) 3 XMCPUTIME CPU usage total : 0.000150926 secs , current category= \"Application\" 3 XMTHREADBLOCK Waiting on : java / lang / ref / ReferenceQueue @ 0x00000000FFE26A10 Owned by : < unowned > 3 XMHEAPALLOC Heap bytes allocated since last GC cycle = 0 ( 0x0 ) 3 XMTHREADINFO3 Java callstack : 4 XESTACKTRACE at java / lang / Object . wait ( Native Method ) 4 XESTACKTRACE at java / lang / Object . wait ( Object . java : 221 ) 4 XESTACKTRACE at java / lang / ref / ReferenceQueue . remove ( ReferenceQueue . java : 138 ) 5 XESTACKTRACE ( entered lock : java / lang / ref / ReferenceQueue @ 0x00000000FFE26A10 , entry count : 1 ) 4 XESTACKTRACE at jdk / internal / ref / CleanerImpl . run ( CleanerImpl . java : 148 ) 4 XESTACKTRACE at java / lang / Thread . run ( Thread . java : 835 ) 4 XESTACKTRACE at jdk / internal / misc / InnocuousThread . run ( InnocuousThread . java : 122 ) 3 XMTHREADINFO3 No native callstack available for this thread NULL NULL 3 XMTHREADINFO \"IProfiler\" J9VMThread : 0x0000000000F03D00 , omrthread_t: 0x00007FF4F00B06F8 , java / lang / Thread : 0x00000000FFE97B60 , state : R , prio = 5 3 XMJAVALTHREAD ( java / lang / Thread getId: 0xC , isDaemon:true ) 3 XMTHREADINFO1 ( native thread ID : 0x7659 , native priority : 0x5 , native policy : UNKNOWN , vmstate : CW , vm thread flags : 0x00000081 ) 3 XMTHREADINFO2 ( native stack address range from : 0x00007FF4F8940000 , to : 0x00007FF4F8960000 , size : 0x20000 ) 3 XMCPUTIME CPU usage total : 0.004753103 secs , current category= \"JIT\" 3 XMHEAPALLOC Heap bytes allocated since last GC cycle = 0 ( 0x0 ) 3 XMTHREADINFO3 No Java callstack associated with this thread 3 XMTHREADINFO3 No native callstack available for this thread NULL ... 1 XMWLKTHDERR The following was reported while collecting native stacks : 2 XMWLKTHDERR unable to count threads ( 3 , - 2 ) NULL 1 XMTHDSUMMARY Threads CPU Usage Summary NULL ========================= NULL 1 XMTHDCATINFO 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 1 XMTHDCATEGORY All JVM attached threads : 0.280083000 secs 1 XMTHDCATEGORY | 2 XMTHDCATEGORY +-- System - JVM : 0.270814000 secs 2 XMTHDCATEGORY | | 3 XMTHDCATEGORY | +-- GC : 0.000599000 secs 2 XMTHDCATEGORY | | 3 XMTHDCATEGORY | +-- JIT : 0.071904000 secs 1 XMTHDCATEGORY | 2 XMTHDCATEGORY +-- 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 call site location (source file:line number), start time, and duration of the last callback and the longest callback. NULL ------------------------------------------------------------------------\n0SECTION HOOK subcomponent dump routine\nNULL ==============================\n1HKINTERFACE MM_OMRHookInterface\nNULL ------------------------------------------------------------------------\n1HKINTERFACE MM_PrivateHookInterface\nNULL ------------------------------------------------------------------------\n1HKINTERFACE MM_HookInterface\nNULL ------------------------------------------------------------------------\n1HKINTERFACE J9VMHookInterface\nNULL ------------------------------------------------------------------------\n2HKEVENTID 1\n3HKCALLCOUNT 18\n3HKLAST Last Callback\n4HKCALLSITE trcengine.c:392\n4HKSTARTTIME Start Time: 2018-08-30T21:55:47.601\n4HKDURATION DurationMs: 0\n3HKLONGST Longest Callback\n4HKCALLSITE trcengine.c:392\n4HKSTARTTIME Start Time: 2018-08-30T21:55:47.460\n4HKDURATION DurationMs: 1\nNULL\n...\n1HKINTERFACE J9VMZipCachePoolHookInterface\nNULL ------------------------------------------------------------------------\n1HKINTERFACE J9JITHookInterface\nNULL ------------------------------------------------------------------------\n2HKEVENTID 3\n3HKCALLCOUNT 65\n3HKLAST Last Callback\n4HKCALLSITE ../common/mgmtinit.c:191\n4HKSTARTTIME Start Time: 2018-08-30T21:55:47.601\n4HKDURATION DurationMs: 0\n3HKLONGST Longest Callback\n4HKCALLSITE ../common/mgmtinit.c:191\n4HKSTARTTIME Start Time: 2018-08-30T21:55:47.486\n4HKDURATION DurationMs: 0\n...\nNULL",
"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 ------------------------------------------------------------------------\n0SECTION SHARED CLASSES subcomponent dump routine\nNULL ========================================\nNULL\n1SCLTEXTCRTW Cache Created With\nNULL ------------------\nNULL\n2SCLTEXTXNL -Xnolinenumbers = false\n2SCLTEXTBCI BCI Enabled = true\n2SCLTEXTBCI Restrict Classpaths = false\nNULL\n1SCLTEXTCSUM Cache Summary\nNULL ------------------\nNULL\n2SCLTEXTNLC No line number content = false\n2SCLTEXTLNC Line number content = true\nNULL\n2SCLTEXTRCS ROMClass start address = 0x00007F423061C000\n2SCLTEXTRCE ROMClass end address = 0x00007F42307B9A28\n2SCLTEXTMSA Metadata start address = 0x00007F42313D42FC\n2SCLTEXTCEA Cache end address = 0x00007F4231600000\n2SCLTEXTRTF Runtime flags = 0x00102001ECA6028B\n2SCLTEXTCGN Cache generation = 35\nNULL\n2SCLTEXTCSZ Cache size = 16776608\n2SCLTEXTSMB Softmx bytes = 16776608\n2SCLTEXTFRB Free bytes = 12691668\n2SCLTEXTRCB ROMClass bytes = 1694248\n2SCLTEXTAOB AOT code bytes = 0\n2SCLTEXTADB AOT data bytes = 0\n2SCLTEXTAHB AOT class hierarchy bytes = 32\n2SCLTEXTATB AOT thunk bytes = 0\n2SCLTEXTARB Reserved space for AOT bytes = -1\n2SCLTEXTAMB Maximum space for AOT bytes = -1\n2SCLTEXTJHB JIT hint bytes = 308\n2SCLTEXTJPB JIT profile bytes = 2296\n2SCLTEXTJRB Reserved space for JIT data bytes = -1\n2SCLTEXTJMB Maximum space for JIT data bytes = -1\n2SCLTEXTNOB Java Object bytes = 0\n2SCLTEXTZCB Zip cache bytes = 919328\n2SCLTEXTRWB ReadWrite bytes = 114080\n2SCLTEXTJCB JCL data bytes = 0\n2SCLTEXTBDA Byte data bytes = 0\n2SCLTEXTMDA Metadata bytes = 23448\n2SCLTEXTDAS Class debug area size = 1331200\n2SCLTEXTDAU Class debug area % used = 11%\n2SCLTEXTDAN Class LineNumberTable bytes = 156240\n2SCLTEXTDAV Class LocalVariableTable bytes = 0\nNULL\n2SCLTEXTNRC Number ROMClasses = 595\n2SCLTEXTNAM Number AOT Methods = 0\n2SCLTEXTNAD Number AOT Data Entries = 0\n2SCLTEXTNAH Number AOT Class Hierarchy = 1\n2SCLTEXTNAT Number AOT Thunks = 0\n2SCLTEXTNJH Number JIT Hints = 14\n2SCLTEXTNJP Number JIT Profiles = 20\n2SCLTEXTNCP Number Classpaths = 1\n2SCLTEXTNUR Number URLs = 0\n2SCLTEXTNTK Number Tokens = 0\n2SCLTEXTNOJ Number Java Objects = 0\n2SCLTEXTNZC Number Zip Caches = 5\n2SCLTEXTNJC Number JCL Entries = 0\n2SCLTEXTNST Number Stale classes = 0\n2SCLTEXTPST Percent Stale classes = 0%\nNULL\n2SCLTEXTCPF Cache is 24% full\nNULL\n1SCLTEXTCMST Cache Memory Status\nNULL ------------------\n1SCLTEXTCNTD Cache Name Feature Memory type Cache path\nNULL\n2SCLTEXTCMDT sharedcc_doc-javacore CR Memory mapped file /tmp/javasharedresources/C290M4F1A64P_sharedcc_doc-javacore_G35\nNULL\n1SCLTEXTCMST Cache Lock Status\nNULL ------------------\n1SCLTEXTCNTD Lock Name Lock type TID owning lock\nNULL\n2SCLTEXTCWRL Cache write lock File lock Unowned\n2SCLTEXTCRWL Cache read/write lock File lock Unowned\nNULL",
"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 we 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 ------------------------------------------------------------------------\n0SECTION CLASSES subcomponent dump routine\nNULL =================================\n1CLTEXTCLLOS Classloader summaries\n1CLTEXTCLLSS 12345678: 1=primordial,2=extension,3=shareable,4=middleware,5=system,6=trusted,7=application,8=delegating\n2CLTEXTCLLOADER p---st-- Loader *System*(0x00000000FFE1D258)\n3CLNMBRLOADEDLIB Number of loaded libraries 5\n3CLNMBRLOADEDCL Number of loaded classes 638\n2CLTEXTCLLOADER -x--st-- Loader jdk/internal/loader/ClassLoaders$PlatformClassLoader(0x00000000FFE1D4F0), Parent *none*(0x0000000000000000)\n3CLNMBRLOADEDLIB Number of loaded libraries 0\n3CLNMBRLOADEDCL Number of loaded classes 0\n2CLTEXTCLLOADER ----st-- Loader java/lang/InternalAnonymousClassLoader(0x00000000FFE1DFD0), Parent *none*(0x0000000000000000)\n3CLNMBRLOADEDLIB Number of loaded libraries 0\n3CLNMBRLOADEDCL Number of loaded classes 2\n2CLTEXTCLLOADER -----ta- Loader jdk/internal/loader/ClassLoaders$AppClassLoader(0x00000000FFE1DAD0), Parent jdk/internal/loader/ClassLoaders$PlatformClassLoader(0x00000000FFE1D4F0)\n3CLNMBRLOADEDLIB Number of loaded libraries 0\n3CLNMBRLOADEDCL Number of loaded classes 0\n1CLTEXTCLLIB ClassLoader loaded libraries\n2CLTEXTCLLIB Loader *System*(0x00000000FFE1D258)\n3CLTEXTLIB /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/compressedrefs/jclse9_29\n3CLTEXTLIB /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/java\n3CLTEXTLIB /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/compressedrefs/j9jit29\n3CLTEXTLIB /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/zip\n3CLTEXTLIB /home/me/openj9-openjdk-jdk9/build/linux-x86_64-normal-server-release/images/jdk/lib/nio\n1CLTEXTCLLOD ClassLoader loaded classes\n2CLTEXTCLLOAD Loader *System*(0x00000000FFE1D258)\n3CLTEXTCLASS [Ljava/lang/Thread$State;(0x0000000001056400)\n...\n2CLTEXTCLLOAD Loader jdk/internal/loader/ClassLoaders$PlatformClassLoader(0x00000000FFE1D4F0)\n2CLTEXTCLLOAD Loader java/lang/InternalAnonymousClassLoader(0x00000000FFE1DFD0)\n3CLTEXTCLASS jdk/internal/loader/BuiltinClassLoader$$Lambda$2/00000000F03876A0(0x0000000001030F00)\n3CLTEXTCLASS jdk/internal/loader/BuiltinClassLoader$$Lambda$1/00000000F00D2460(0x0000000001018A00)\n2CLTEXTCLLOAD Loader jdk/internal/loader/ClassLoaders$AppClassLoader(0x00000000FFE1DAD0)",
"title": "CLASSES"
},
{
"location": "/dump_heapdump/",
"text": "Heap dump\n\n\nHeap dumps contain a snapshot of all the live objects that are being used by a running Java application on the Java heap. There are two formats for heap dumps; the classic format, which is ascii text and the PHD format, which is compressed and not readable.\n\n\nA heap dump contains a list of all object instances. For each object instance you can find the following additional data:\n\n\n\n\nThe object address\n\n\nThe type or class name\n\n\nThe size\n\n\nAny references to other objects\n\n\n\n\nFor a visual analysis of a heap dump as an aid to problem determination, use the \nEclipse Memory Analyzer tool (MAT)\n or the \nIBM Memory Analyzer tool\n. 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:\n\n\nHelp > Install New Software > Work with \"IBM Diagnostic Tool Framework for Java\" > IBM Monitoring and Diagnostic Tools > Diagnostic Tool Framework for Java \n\n\n\n\n\nFor more information about using the Heapdump feature, see \nUsing Heapdump\n.\n\n\nSee also\n\n\n\n\nUsing DTFJ",
"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 application on the Java heap. There are two formats for heap dumps; the classic format, which is ascii text and the PHD format, which is compressed and not readable. A heap dump contains a list of all object instances. For each object instance you can find the following additional data: The object address The type or class name The size Any references to other objects For a visual analysis of a heap dump as an aid to problem determination, use the Eclipse Memory Analyzer tool (MAT) or the IBM Memory Analyzer tool . 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 For more information about using the Heapdump feature, see Using Heapdump .",
"title": "Heap dump"
},
{
"location": "/dump_heapdump/#see-also",
"text": "Using DTFJ",
"title": "See also"
},
{
"location": "/dump_systemdump/",
"text": "System dump\n\n\nSystem dumps, often known as \ncore dumps\n, 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.\n\n\nTo examine a system dump you can use the \nOpenJ9 dump viewer\n (\njdmpview\n), a platform-specific debugging tool, or the \nEclipse Memory Analyzer tool (MAT)\n.\n\n\nIf 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:\n\n\nHelp > Install New Software > Work with \"IBM Diagnostic Tool Framework for Java\" > IBM Monitoring and Diagnostic Tools > Diagnostic Tool Framework for Java \n\n\n\n\n\nSee also\n\n\n\n\nUsing system dumps and the dump viewer",
"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. 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/#see-also",
"text": "Using system dumps and the dump viewer",
"title": "See also"
},
{
"location": "/cmdline_specifying/",
"text": "OpenJ9 command-line options\n\n\nWhen you start a Java\u2122 application you can specify various options on the command line to configure the runtime environment. These options include:\n\n\n\n\nSystem properties\n\n\nStandard options\n\n\nNonstandard (or -X) options\n\n\n-XX options\n\n\n\n\nAlthough 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.\n\n\nOptions specified on the command line override the equivalent environment variables. For example, specifying \njava -cp <dir1>\n completely overrides setting the environment variable \nCLASSPATH=<dir2>\n.\n\n\nQuotation marks\n\n\nUse 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 \n'-X<option>'\n or \n\"-X<option>\"\n. Instead, you must use \n-X<option>\n. For example, do not use \n'-Xmx500m'\n and \n\"-Xmx500m\"\n. Write this option as \n-Xmx500m\n.\n\n\nPrecedence\n\n\nThe 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 \n-Xjit\n option takes precedence:\n\n\njava\n \n-\nXint\n \n-\nXjit\n \nmyClass\n\n\n\n\n\n\nAt startup, the list of VM arguments is constructed in the following order, with the lowest precedence first:\n\n\n\n\n\n\nCertain options are created automatically by the VM, which specify arguments such as search paths and version information. The VM automatically adds \n-Xoptionsfile=<path>/options.default\n at the beginning of the command line, where \n<path>\n is the path to the VM directory.\n\n\nYou can modify the \noptions.default\n 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 \n-Xoptionsfile\n.\n\n\n\n\n\n\nOptions can be specified in an executable JAR file by using the \nMETA-INF/MANIFEST.MF\n file. Options are placed in the main section in a header named \nIBM-Java-Options\n. Only one \nIBM-Java-Options\n 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.\n\n\nExample manifest file:\n\n\nManifest-Version: 1.0\nClass-Path: .\nMain-Class: HelloWorld\nIBM-Java-Options: -Xshareclasses:name=mycache,nonfa\n tal,cacheDirPerm=1000 -Dproperty=example -Da.long.system.pro\n perty=\"this is a long system property value to\n demonstrate long VM arguments\n in the manifest file\"\n\n\n\n\n\nThis example manifest file is parsed as the following string:\n\n\n-Xshareclasses:name=mycache,nonfatal,cacheDirPerm=1000\n-Dproperty=example\n-Da.long.system.property=this is a long system property value to\ndemonstrate long VM arguments in the manifest file\n\n\n\n\n\nOptions specified in the manifest file are subject to the same restrictions as options files. For more information, see the \n-Xoptionsfile\n topic in the user guide.\n\n\n\n\n\n\nEnvironment variables that are described in \nOpenJ9 environment variables\n are translated into command-line options. For example, the following environment variable adds the parameter \n-Xrs\n to the list of arguments:\n\n\n\n\n\n\nOn Windows\u2122 systems:\n\n\nset\n \nIBM_NOSIGHANDLER\n=<\nnon_null_string\n>\n\n\n\n\n\n\n\n\n\n\nOn AIX\u00ae, Linux\u2122, and z/OS\u00ae systems:\n\n\nexport\n \nIBM_NOSIGHANDLER\n=<\nnon_null_string\n>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nThe \nIBM_JAVA_OPTIONS\n 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:\n\n\n\n\n\n\nOn Windows systems:\n\n\nset\n \nIBM_JAVA_OPTIONS\n=\n\"-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump\"\n\n\n\n\n\n\n\n\n\n\nOn AIX, Linux, and z/OS systems:\n\n\nexport\n \nIBM_JAVA_OPTIONS\n=\n\"-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump\"\n\n\n\n\n\n\n\n\n\n\n \nNote:\n The environment variable \nJAVA_TOOLS_OPTIONS\n is equivalent to \nIBM_JAVA_OPTIONS\n and is available for compatibility with JVMTI.\n\n\n\n\n\n\nOptions that are specified on the command line. For example:\n\n\njava\n \n-\nDmysysprop1\n=\ntcpip\n \n-\nDmysysprop2\n=\nwait\n \n-\nXdisablejavadump\n \nMyJavaClass\n\n\n\n\n\n\nThe Java launcher adds some automatically generated arguments to this list, such as the names of the main class.\n\n\n\n\n\n\nYou can also use the \n-Xoptionsfile\n parameter to specify VM options. This parameter can be used on the command line, or as part of the \nIBM_JAVA_OPTIONS\n 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 \n-Xoptionsfile\n.\n\n\nTo 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:\n\n\n-\nXdump\n:\njava\n:\nevents\n=\nvmstart\n\n\n\n\n\n\nHere is an extract from a Java core file that shows the options that are used:\n\n\n 2CIUSERARG -Xdump:java:file=/home/test_javacore.txt,events=vmstop\n 2CIUSERARG -Dtest.cmdlineOption=1\n 2CIUSERARG -XXallowvmshutdown:true\n 2CIUSERARG -Xoptionsfile=test1.test_options_file",
"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\nClass-Path: .\nMain-Class: HelloWorld\nIBM-Java-Options: -Xshareclasses:name=mycache,nonfa\n tal,cacheDirPerm=1000 -Dproperty=example -Da.long.system.pro\n perty=\"this is a long system property value to\n demonstrate long VM arguments\n in the manifest file\" This example manifest file is parsed as the following string: -Xshareclasses:name=mycache,nonfatal,cacheDirPerm=1000\n-Dproperty=example\n-Da.long.system.property=this is a long system property value to\ndemonstrate 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\u2122, and z/OS\u00ae systems: export IBM_NOSIGHANDLER =< non_null_string > The IBM_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 IBM_JAVA_OPTIONS = \"-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump\" On AIX, Linux, and z/OS systems: export IBM_JAVA_OPTIONS = \"-Dmysysprop1=tcpip -Dmysysprop2=wait -Xdisablejavadump\" Note: The environment variable JAVA_TOOLS_OPTIONS is equivalent to IBM_JAVA_OPTIONS and is available for compatibility with JVMTI. 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 IBM_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\n 2CIUSERARG -Dtest.cmdlineOption=1\n 2CIUSERARG -XXallowvmshutdown:true\n 2CIUSERARG -Xoptionsfile=test1.test_options_file",
"title": "Precedence"
},
{
"location": "/cmdline_general/",
"text": "Standard command-line options\n\n\nThe OpenJ9 virtual machine supports the standard Java\u2122 options that are common to all Java virtual machine implementations, including Oracle's Hotspot VM.\nSome of the common options supported are summarised in the following table:\n\n\n\n\n\n\n\n\nStandard option name\n\n\nPurpose\n\n\n\n\n\n\n\n\n\n\n-classpath:<resource_name>[:<resource_name>]\n\n\nSets the search path for application classes and resources (directories and compressed or .jar files). \ncp\n can be used instead of \nclasspath\n.\n\n\n\n\n\n\n-help\n, \n-?\n\n\nPrints a usage message.\n\n\n\n\n\n\n-fullversion\n\n\nPrints the build and version information for a VM\n\n\n\n\n\n\n-showversion\n\n\nPrints product version and continues.\n\n\n\n\n\n\n-verbose:<option>[,<option>]\n\n\nEnables verbose output. Options include \nclass\n, \ndynload\n, \ngc\n, \ninit\n, \njni\n, \nsizes\n and \nstack\n. (See \nNotes\n)\n\n\n\n\n\n\n-version\n\n\nPrints the full build and version information a VM\n\n\n\n\n\n\n\n\n \nNotes:\n\n\n\n\n-verbose:class\n: Writes an entry to \nstderr\n for each class that is loaded.\n\n\n-verbose:dynload\n: Writes detailed class information to \nstderr\n as each bootstrap class is loaded by the VM:\n\n\n-verbose:gc\n: Provides verbose garbage collection information.\n\n\n-verbose:init\n: Writes information to \nstderr\n describing VM initialization and termination.\n\n\n-verbose:jni\n: Writes information to \nstderr\n describing the JNI services called by the application and VM.\n\n\n-verbose:sizes\n: Writes information to \nstderr\n describing the active memory usage settings.\n\n\n-verbose:stack\n: Writes information to \nstderr\n describing the Java and C stack usage for each thread.\n\n\n\n\nFor more information about standard options, see \nOracle Java SE Standard Options",
"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.\nSome 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 and stack . (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. For more information about standard options, see Oracle Java SE Standard Options",
"title": "Standard command-line options"
},
{
"location": "/cmdline_migration/",
"text": "Migrating to OpenJ9\n\n\nIf 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.\n\n\nCompatible options\n\n\nYou 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:\n\n\n\n\n\n\n\n\nOption\n\n\nUsage\n\n\n\n\n\n\n\n\n\n\n-X\n\n\nDisplays help on nonstandard options.\n\n\n\n\n\n\n-Xbootclasspath\n\n\nSpecifies the search path for bootstrap classes and resources.\n\n\n\n\n\n\n-Xcheck:jni\n\n\nRuns additional checks for JNI functions during VM startup.\n\n\n\n\n\n\n-Xfuture\n\n\nTurns on strict class-file format checks.\n\n\n\n\n\n\n-Xint\n\n\nRuns an application in interpreted-only mode.\n\n\n\n\n\n\n-Xmn\n\n\nSets the initial and maximum size of the new area when using -Xgcpolicy:gencon.\n\n\n\n\n\n\n-Xms\n\n\nSets the initial size of the heap. (Equivalent to \n-XX:InitialHeapSize\n)\n\n\n\n\n\n\n-Xmx\n\n\nSpecifies the maximum size of the object memory allocation pool. (Equivalent to \n-XX:MaxHeapSize\n)\n\n\n\n\n\n\n-Xnoclassgc\n\n\nDisables class garbage collection (GC).\n\n\n\n\n\n\n-Xrs\n\n\nPrevents the OpenJ9 run time environment from handling signals.\n\n\n\n\n\n\n-Xss\n\n\nSets the thread stack size. (Equivalent to \n-XX:ThreadStackSize\n)\n\n\n\n\n\n\n-Xverify:mode\n\n\nEnables or disables the verifier.\n\n\n\n\n\n\n-XX:[+|-]DisableExplicitGC\n\n\nEnables/disables \nSystem.gc()\n calls. (Alias for \n-Xdisableexplicitgc\n / \n-Xenableexplicitgc\n)\n\n\n\n\n\n\n-XX:[+|-]HeapDumpOnOutOfMemory\n\n\nEnables/disables dumps on out-of-memory conditions.\n\n\n\n\n\n\n-XX:HeapDumpPath\n\n\nSpecifies a directory for all VM dumps including heap dumps, javacores, and system dumps. (Alias for \n-Xdump:directory\n)\n\n\n\n\n\n\n-XX:MaxDirectMemorySize\n\n\nSets a limit on the amount of memory that can be reserved for all direct byte buffers.\n\n\n\n\n\n\n-XX:InitialHeapSize\n\n\nSets the initial size of the heap. (Alias for \n-Xms\n)\n\n\n\n\n\n\n-XX:MaxHeapSize\n \n\n\nSpecifies the maximum size of the object memory allocation pool. (Alias for \n-Xmx\n)\n\n\n\n\n\n\n-XX:ThreadStackSize\n\n\nSets the thread stack size. (Alias for \n-Xss\n)\n\n\n\n\n\n\n-XX:-UseCompressedOops\n\n\nDisables compressed references in 64-bit JVMs. (See also \n-Xcompressedrefs\n)\n\n\n\n\n\n\n\n\nEquivalent options\n\n\nThese Hotspot command-line options have equivalents in OpenJ9 that are not specified in the same way, but perform a related function:\n\n\n\n\n\n\n\n\nHotSpot Option\n\n\nOpenJ9 Option\n\n\nUsage\n\n\n\n\n\n\n\n\n\n\n-Xcomp\n\n\n-Xjit:count=0\n1\n\n\n-Xcomp\n disables interpreted method invocations.\n\n\n\n\n\n\n-Xgc\n\n\n-Xgcpolicy\n2\n\n\nConfiguring your garbage collection policy.\n\n\n\n\n\n\n-XX:ParallelGCThreads\n\n\n-Xgcthreads\n\n\nConfigure number of GC threads.\n\n\n\n\n\n\n-XX:+UseNUMA\n\n\n-Xnuma:none\n3\n\n\nControls non-uniform memory architecture (NUMA) awareness.\n\n\n\n\n\n\n\n\n \nNotes:\n\n\n\n\n\n\nHotspot uses \n-Xcomp\n to force compilation of methods on first invocation. Use \n-Xjit\n with \ncount\nset to \n0\n. (\n-Xjit\n sets the number of times a method is called before it is compiled. Setting \ncount=0\n forces the JIT compiler to compile everything on first execution.)\n\n\n\n\n\n\nHotspot uses \n-Xgc\n to both select policies and configure them; OpenJ9 uses \n-Xgcpolicy\n to select policies, reserving \n-Xgc\n for configuration.\n\n\n\n\n\n\nIn Hotspot, NUMA awareness is turned off by default and is turned on by using the \n-XX:+UseNUMA\n option. Conversely, the OpenJ9 VM automatically enables NUMA awareness and uses \n-Xnuma:none\n to turn it \noff\n. \n\n\n\n\nIf you were previously using Hotspot in its default mode, you must now explicitly turn off NUMA awareness in OpenJ9.\n\n\nIf you are used to using \n-XX:+UseNUMA\n in Hotspot, you no longer need to explicitly turn on NUMA awareness; it's on by default.",
"title": "Migrating to OpenJ9"
},
{
"location": "/cmdline_migration/#migrating-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.",
"title": "Migrating 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. -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 thread stack size. (Equivalent to -XX:ThreadStackSize ) -Xverify:mode Enables or disables the verifier. -XX:[+|-]DisableExplicitGC Enables/disables System.gc() calls. (Alias for -Xdisableexplicitgc / -Xenableexplicitgc ) -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:MaxDirectMemorySize Sets a limit on the amount of memory that can be reserved for all direct byte buffers. -XX:InitialHeapSize Sets the initial size of the heap. (Alias for -Xms ) -XX:MaxHeapSize Specifies the maximum size of the object memory allocation pool. (Alias for -Xmx ) -XX:ThreadStackSize Sets the thread stack size. (Alias for -Xss ) -XX:-UseCompressedOops Disables compressed references in 64-bit JVMs. (See also -Xcompressedrefs )",
"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:ParallelGCThreads -Xgcthreads Configure number of GC threads. -XX:+UseNUMA -Xnuma:none 3 Controls non-uniform memory architecture (NUMA) awareness. Notes: Hotspot uses -Xcomp to force compilation of methods on first invocation. Use -Xjit with count set to 0 . ( -Xjit sets the number of times a method is called before it is compiled. Setting count=0 forces the JIT compiler to compile everything on first execution.) 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": "/d_jvm_commands/",
"text": "Using system property command-line options\n\n\nJava\u2122 system properties determine the environment in which a Java program runs by starting a Java virtual machine with a set of values.\nYou 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.\n\n\nTo set a system property from the command line, use:\n\n\njava -D<property_name>=<value> <program_name>\n\n\n\n\n\nFor example, to specify the UTF-8 file encoding for your application \nMyProgram\n, use:\n\n\njava -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.\nYou 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\n\n\nSetting this property to \ntrue\n enables caching of the Latest User Defined Class Loader (LUDCL).\n\n\nSyntax\n\n\n -Dcom.ibm.enableClassCaching=[true|false]\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\ntrue\n\n\nEnable\n\n\n\n\n\n\n\n\nfalse\n\n\nDisable\n\n\nyes\n\n\n\n\n\n\n\n\nExplanation\n\n\nBy reducing repeated lookups, Java\u2122 applications that use deserialization extensively can see a performance improvement.\n\n\nSee also\n\n\n\n\n \nJava 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 false Disable yes",
"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\n\n\nTo improve security, the security checks in the certain \ncom.ibm.jvm.Dump\n APIs are now enabled by default, when the \nSecurityManger\n is enabled. Use this system property to turn off security checking for these APIs.\n\n\nSyntax\n\n\n -Dcom.ibm.enableLegacyDumpSecurity=[true|false]\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\ntrue\n\n\nEnable\n\n\nyes\n\n\n\n\n\n\nfalse\n\n\nDisable\n\n\n\n\n\n\n\n\n\n\nExplanation\n\n\nSecurity checking is enabled in the following APIs:\n\n\n\n\ncom.ibm.jvm.Dump.JavaDump()\n\n\ncom.ibm.jvm.Dump.HeapDump()\n\n\ncom.ibm.jvm.Dump.SnapDump()\n\n\n\n\nSee also\n\n\n\n\n-Dcom.ibm.enableLegacyLogSecurity\n\n\n-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\n\n\nTo improve security, the security checks in the certain \ncom.ibm.jvm.Log\n APIs are now enabled by default, when the \nSecurityManger\n is enabled. Use this system property to turn off security checking for these APIs.\n\n\nSyntax\n\n\n -Dcom.ibm.enableLegacyLogSecurity=[true|false]\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\ntrue\n\n\nEnable\n\n\nyes\n\n\n\n\n\n\nfalse\n\n\nDisable\n\n\n\n\n\n\n\n\n\n\nExplanation\n\n\nSecurity checking is enabled in the following APIs:\n\n\n\n\ncom.ibm.jvm.Log.QueryOptions()\n\n\ncom.ibm.jvm.Log.SetOptions(String)\n\n\n\n\nSee also\n\n\n\n\n-Dcom.ibm.enableLegacyDumpSecurity\n\n\n-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\n\n\nTo improve security, the security checks in certain \ncom.ibm.jvm.Trace\n APIs are now enabled by default, when the \nSecurityManger\n is enabled. Use this system property to turn off security checking for these APIs.\n\n\nSyntax\n\n\n -Dcom.ibm.enableLegacyTraceSecurity=[true|false]\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\ntrue\n\n\nEnable\n\n\nyes\n\n\n\n\n\n\nfalse\n\n\nDisable\n\n\n\n\n\n\n\n\n\n\nExplanation\n\n\nSecurity checking is enabled in the following APIs:\n\n\n\n\ncom.ibm.jvm.Trace.set(String)\n\n\ncom.ibm.jvm.Trace.snap()\n\n\ncom.ibm.jvm.Trace.suspend()\n\n\ncom.ibm.jvm.Trace.suspendThis()\n\n\ncom.ibm.jvm.Trace.resume()\n\n\ncom.ibm.jvm.Trace.resumeThis()\n\n\ncom.ibm.jvm.Trace.registerApplication(String, String[])\n\n\n\n\nSee also\n\n\n\n\n-Dcom.ibm.enableLegacyDumpSecurity\n\n\n-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": "/dcomibmlangmanagementosmxbeaniscputime100ns/",
"text": "-Dcom.ibm.lang.management.\nOperatingSystemMXBean.isCpuTime100ns\n\n\nChanges the unit of the return value of the \nOperatingSystemMXBean.getProcessCpuTime()\n method.\n\n\nSyntax\n\n\n -Dcom.ibm.lang.management.OperatingSystemMXBean.isCpuTime100ns=[true|false]\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\ntrue\n\n\nEnable\n\n\n\n\n\n\n\n\nfalse\n\n\nDisable\n\n\nyes\n\n\n\n\n\n\n\n\nExplanation\n\n\nThe Oracle \njava.lang.management\n package includes MBean categories such as \nMemory\n, \nOperatingSystem\n, and \nGarbageCollector\n. The OpenJ9 VM provides additional MXBeans to extend the monitoring and management capabilities. For example, the \nOperatingSystemMXBean\n, which monitors operating system settings such as physical and virtual memory size, processor capacity, and processor utilization.\n\n\nThe \nOperatingSystemMXBean.getProcessCpuTime()\n method returns a value in nanoseconds (10\n-9\n s), for compatibility with the \ncom.sun.management.OperatingSystemMXBean\n and \nUnixOperatingSystemMXBean\n interfaces.\n\n\nIn earlier VM releases, the return value was in hundreds of nanoseconds. If you want to revert to this behavior, set the \n-Dcom.ibm.lang.management.OperatingSystemMXBean.isCpuTime100ns\n property to \ntrue\n.\n\n\nThe default value for this property is \nfalse\n.\n\n\nSee also\n\n\n\n\ncom.ibm.lang.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": "com.ibm.lang.management API documentation",
"title": "See also"
},
{
"location": "/dcomibmlangmanagementverbose/",
"text": "-Dcom.ibm.lang.management.verbose\n\n\nEnables verbose information from \njava.lang.management\n operations to be written to the output channel during VM operations.\n\n\nSyntax\n\n\n -Dcom.ibm.lang.management.verbose\n\n\n\n\n\nThere 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": "/dcomibmtoolsattachdirectory/",
"text": "-Dcom.ibm.tools.attach.directory\n\n\nSpecify a different common directory for Attach API working files.\n\n\nSyntax\n\n\n -Dcom.ibm.tools.attach.directory=<directory_name>\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<directory_name>\n\n\n[string]\n\n\n.com_ibm_tools_attach\n\n\n\n\n\n\n\n\nTo change the value for \ndirectory_name\n, specify a different directory name. If the directory does not exist, it is created. However, if a\nparent directory is specified, it must exist.\n\n\nSee also\n\n\n\n\nSupport for the Java\u2122 Attach API\n\n\n-Dcom.ibm.tools.attach.enable\n\n\n-Dcom.ibm.tools.attach.displayName\n\n\n-Dcom.ibm.tools.attach.id\n\n\n-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\nparent directory is specified, it must exist.",
"title": "Syntax"
},
{
"location": "/dcomibmtoolsattachdirectory/#see-also",
"text": "Support for the Java\u2122 Attach API -Dcom.ibm.tools.attach.enable -Dcom.ibm.tools.attach.displayName -Dcom.ibm.tools.attach.id -Dcom.ibm.tools.attach.timeout",
"title": "See also"
},
{
"location": "/dcomibmtoolsattachdisplayname/",
"text": "-Dcom.ibm.tools.attach.displayName\n\n\nChange the default display name for the target virtual machine.\n\n\nSyntax\n\n\n -Dcom.ibm.tools.attach.displayName=<display_name>\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<display_name>\n\n\n[string]\n\n\nThe command line invocation used to start the application\n\n\n\n\n\n\n\n\nTo change the value for \n<display_name>\n, enter a character string of your choice.\n\n\nSee also\n\n\n\n\nSupport for the Java\u2122 Attach API\n\n\n-Dcom.ibm.tools.attach.enable\n\n\n-Dcom.ibm.tools.attach.directory\n\n\n-Dcom.ibm.tools.attach.id\n\n\n-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=<display_name> Setting Value Default <display_name> [string] The command line invocation used to start the application To change the value for <display_name> , enter a character string of your choice.",
"title": "Syntax"
},
{
"location": "/dcomibmtoolsattachdisplayname/#see-also",
"text": "Support for the Java\u2122 Attach API -Dcom.ibm.tools.attach.enable -Dcom.ibm.tools.attach.directory -Dcom.ibm.tools.attach.id -Dcom.ibm.tools.attach.timeout",
"title": "See also"
},
{
"location": "/dcomibmtoolsattachenable/",
"text": "-Dcom.ibm.tools.attach.enable\n\n\nEnable the Attach API for this application.\n\n\nSyntax\n\n\n -Dcom.ibm.tools.attach.enable=[yes|no]\n\n\n\n\n\nOn AIX\u00ae, Linux\u2122, and Windows\u2122 systems, the following default applies:\n\n\n\n\n\n\n\n\nValue\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\nyes\n\n\nEnable\n\n\nyes\n\n\n\n\n\n\nno\n\n\nDisable\n\n\n\n\n\n\n\n\n\n\nOn z/OS\u00ae systems, the following default applies:\n\n\n\n\n\n\n\n\nValue\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\nyes\n\n\nEnable\n\n\n\n\n\n\n\n\nno\n\n\nDisable\n\n\nyes\n\n\n\n\n\n\n\n\nExplanation\n\n\nA useful reference for information about the Java\u2122 Attach API can be found at \nhttp://docs.oracle.com/javase/8/docs/technotes/guides/attach/index.html\n. The following extract is taken from the Oracle documentation:\n\n\n\n\nThe 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.\n\n\n\n\nFor example, to late attach the IBM\u00ae Health Center agent to a virtual machine (VM) that is already running.\n\n\nThe 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.\n\n\nSee also\n\n\n\n\nSupport for the Java Attach API\n\n\n-Dcom.ibm.tools.attach.directory\n\n\n-Dcom.ibm.tools.attach.displayName\n\n\n-Dcom.ibm.tools.attach.id\n\n\n-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\u2122, 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. For example, 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": "Support for the Java Attach API -Dcom.ibm.tools.attach.directory -Dcom.ibm.tools.attach.displayName -Dcom.ibm.tools.attach.id -Dcom.ibm.tools.attach.timeout",
"title": "See also"
},
{
"location": "/dcomibmtoolsattachid/",
"text": "-Dcom.ibm.tools.attach.id\n\n\nSpecify a different target virtual machine (VM) to attach to.\n\n\nSyntax\n\n\n -Dcom.ibm.tools.attach.id=<process_ID>\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<process_ID>\n\n\n[string]\n\n\nTarget VM process ID\n\n\n\n\n\n\n\n\nTo use a different target, change the value for \n<process_ID>\n.\n\n\nSee also\n\n\n\n\nSupport for the Java\u2122 Attach API\n\n\n-Dcom.ibm.tools.attach.enable\n\n\n-Dcom.ibm.tools.attach.displayName\n\n\n-Dcom.ibm.tools.attach.directory\n\n\n-Dcom.ibm.tools.attach.timeout",
"title": "-Dcom.ibm.tools.attach.id"
},
{
"location": "/dcomibmtoolsattachid/#-dcomibmtoolsattachid",
"text": "Specify a different target virtual machine (VM) to attach to.",
"title": "-Dcom.ibm.tools.attach.id"
},
{
"location": "/dcomibmtoolsattachid/#syntax",
"text": "-Dcom.ibm.tools.attach.id=<process_ID> Setting Value Default <process_ID> [string] Target VM process ID To use a different target, change the value for <process_ID> .",
"title": "Syntax"
},
{
"location": "/dcomibmtoolsattachid/#see-also",
"text": "Support for the Java\u2122 Attach API -Dcom.ibm.tools.attach.enable -Dcom.ibm.tools.attach.displayName -Dcom.ibm.tools.attach.directory -Dcom.ibm.tools.attach.timeout",
"title": "See also"
},
{
"location": "/dcomibmtoolsattachtimeout/",
"text": "-Dcom.ibm.tools.attach.timeout\n\n\nSpecify a time that an application should wait when attempting to connect to a target virtual machine (VM) before ending.\n\n\nSyntax\n\n\n -Dcom.ibm.tools.attach.timeout=<ms>\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<ms>\n\n\n[1 millisecond or greater]\n\n\n120000 milliseconds (120 seconds)\n\n\n\n\n\n\n\n\nExample\n\n\nTo timeout after 60 seconds, specify:\n\n\n-Dcom.ibm.tools.attach.timeout=60000\n\n\nSee also\n\n\n\n\nSupport for the Java\u2122 Attach API\n\n\n-Dcom.ibm.tools.attach.enable\n\n\n-Dcom.ibm.tools.attach.directory\n\n\n-Dcom.ibm.tools.attach.displayName\n\n\n-Dcom.ibm.tools.attach.id",
"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> [1 millisecond or greater] 120000 milliseconds (120 seconds)",
"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": "Support for the Java\u2122 Attach API -Dcom.ibm.tools.attach.enable -Dcom.ibm.tools.attach.directory -Dcom.ibm.tools.attach.displayName -Dcom.ibm.tools.attach.id",
"title": "See also"
},
{
"location": "/dfileencoding/",
"text": "-Dfile.encoding\n\n\nUse this OpenJDK property to define the file encoding that is required.\n\n\nSyntax\n\n\n -Dfile.encoding=<value>\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[string]\n\n\nUnicode 3.0 standards\n\n\n\n\n\n\n\n\n\n\nwhere \n<value>\n defines the file encoding that is required.\n\n\n\n\nExplanation\n\n\nBy default the GBK converter follows Unicode 3.0 standards. To force the GBK converter to follow Unicode 2.0 standards, use a value of \nbestfit936\n.",
"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": "/djavacompiler/",
"text": "-Djava.compiler\n\n\nThis 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.\n\n\nSyntax\n\n\n -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": "/x_jvm_commands/",
"text": "Using -X command-line options\n\n\nUse these options to configure the OpenJ9 virtual machine (VM). Unlike standard options, options prefixed with \n-X\n are nonstandard and are typically unique to a Java\u2122 virtual\nmachine implementation. However, in some cases, \n-X\n option names are common to different VM implementations and might have the same function.\n\n\nFor options that take a \n<size>\n parameter, suffix the number with \"k\" or \"K\" to indicate kilobytes, \"m\" or \"M\" to indicate megabytes, or \"g\" or \"G\" to indicate gigabytes.\n\n\nFor example, to set the \n-Xmx\n value to 16 MB, you can specify \n-Xmx16M\n, \n-Xmx16m\n, \n-Xmx16384K\n, \n-Xmx16384k\n, or \n-Xmx16777216\n on the command line.",
"title": "Using -X options"
},
{
"location": "/x_jvm_commands/#using-x-command-line-options",
"text": "Use these options to configure the OpenJ9 virtual machine (VM). Unlike standard options, options prefixed with -X are nonstandard and are typically unique to a Java\u2122 virtual\nmachine implementation. However, in some cases, -X option names are common to different VM implementations and might have the same function. For options that take a <size> parameter, suffix the number with \"k\" or \"K\" to indicate kilobytes, \"m\" or \"M\" to indicate megabytes, or \"g\" or \"G\" to indicate gigabytes. For example, to set the -Xmx value to 16 MB, you can specify -Xmx16M , -Xmx16m , -Xmx16384K , -Xmx16384k , or -Xmx16777216 on the command line.",
"title": "Using -X command-line options"
},
{
"location": "/x/",
"text": "-X\n\n\nDisplays help on nonstandard options.\n\n\nSyntax\n\n\n -X",
"title": "-X"
},
{
"location": "/x/#-x",
"text": "Displays help on nonstandard options.",
"title": "-X"
},
{
"location": "/x/#syntax",
"text": "-X",
"title": "Syntax"
},
{
"location": "/xaggressive/",
"text": "-Xaggressive\n\n\nEnables performance optimizations and new platform exploitation that are expected to be the default in future releases.\n\n\nSyntax\n\n\n -Xaggressive",
"title": "-Xaggressive"
},
{
"location": "/xaggressive/#-xaggressive",
"text": "Enables performance optimizations and new platform exploitation that are expected to be the default in future releases.",
"title": "-Xaggressive"
},
{
"location": "/xaggressive/#syntax",
"text": "-Xaggressive",
"title": "Syntax"
},
{
"location": "/xalwaysclassgc/",
"text": "-Xalwaysclassgc\n\n\nAlways perform dynamic class unloading checks during global garbage collection.\n\n\nSyntax\n\n\n -Xalwaysclassgc\n\n\n\n\n\nDefault behavior\n\n\nIf you don't set this option, the default behavior is defined by \n-Xclassgc\n.",
"title": "-Xalwaysclassgc"
},
{
"location": "/xalwaysclassgc/#-xalwaysclassgc",
"text": "Always perform dynamic class unloading checks during global garbage collection.",
"title": "-Xalwaysclassgc"
},
{
"location": "/xalwaysclassgc/#syntax",
"text": "-Xalwaysclassgc",
"title": "Syntax"
},
{
"location": "/xalwaysclassgc/#default-behavior",
"text": "If you don't set this option, the default behavior is defined by -Xclassgc .",
"title": "Default behavior"
},
{
"location": "/xaot/",
"text": "-Xaot / -Xnoaot\n\n\nUse this option to control the behavior of the ahead-of-time (AOT) compiler.\n\n\nAOT compilation allows the compilation of Java\u2122 classes into native code for subsequent executions of the same program. The AOT compiler works with the class data sharing framework.\n\n\nThe AOT compiler generates native code dynamically while an application runs and caches any generated AOT code in the shared data cache. Subsequent VMs that execute the method can load and use the AOT code from the shared data cache without incurring the performance decrease experienced with JIT-compiled native code.\n\n\nPerformance\n\n\nBecause AOT code must persist over different program executions, AOT-generated code does not perform as well as JIT-generated code. AOT code usually performs better than interpreted code.\n\n\nIn a VM without an AOT compiler or with the AOT compiler disabled, the JIT compiler selectively compiles frequently used methods into optimized native code. There is a time cost associated with compiling methods because the JIT compiler operates while the application is running. Because methods begin by being interpreted and most JIT compilations occur during startup, startup times can be increased.\n\n\nStartup performance can be improved by using the shared AOT code to provide native code without compiling. There is a small time cost to load the AOT code for a method from the shared data cache and bind it into a running program. The time cost is low compared to the time it takes the JIT compiler to compile that method.\n\n\nDefault behavior\n\n\nThe AOT compiler is enabled by default, but is only active when \nshared classes\n are enabled. By default, shared classes are disabled so that no AOT activity occurs.\n\n\nWhen the AOT compiler is active, the compiler selects the methods to be AOT compiled with the primary goal of improving startup time.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nAction\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xaot\n\n\nEnable AOT\n\n\nyes\n\n\n\n\n\n\n-Xaot:<parameter>[=<value>]{,<parameter>[=<value>]}\n\n\nEnable AOT with modifications\n\n\n\n\n\n\n\n\n-Xnoaot\n\n\nDisable AOT\n\n\n\n\n\n\n\n\n\n\nParameters for \n-Xaot\n\n\n\n\n\n\n \nNote:\n Although the AOT compiler is enabled by default, it is not active unless shared classes are enabled. Using this option on its own therefore has no effect. Use the \n-Xshareclasses\n option to enable shared classes.\n\n\nYou can concatenate several parameters by using commas.\n\n\n\n\n\n\n\n\n\n\n\n\nParameter\n\n\nEffect\n\n\n\n\n\n\n\n\n\n\ncount\n\n\nThe number of times a method is called before it is compiled or loaded from an existing shared class cache.\n\n\n\n\n\n\nexclude\n\n\nThe method you want to exclude when AOT code is compiled or loaded from the shared classes cache.\n\n\n\n\n\n\nlimitFile\n\n\nCompile or load only the methods listed in the specified limit file.\n\n\n\n\n\n\nloadExclude\n\n\nDo not load specified methods.\n\n\n\n\n\n\nloadLimit\n\n\nLoad specified methods only.\n\n\n\n\n\n\nloadLimitFile\n\n\nLoad only the methods listed in the specified limit file).\n\n\n\n\n\n\nverbose\n\n\nReports information about the AOT and JIT compiler configuration and method compilation.\n\n\n\n\n\n\n\n\ncount\n\n\n -Xaot:count=<n>\n\n\n\n\n\n\n\nwhere \n<n>\n is the number of times a method is called before it is compiled or loaded from an existing shared class cache. For example, setting \n-Xaot:count=0\n forces the AOT compiler to compile everything on first execution.\n\n\n\n\nexclude\n\n\n -Xaot:exclude=<method>\n\n\n\n\n\n\n\n\n\nwhere \n<method>\n is the Java method you want to exclude when AOT code is compiled or loaded from the shared classes cache.\n\n\nUse this option if the method causes the program to fail.\n\n\n\n\n\n\nlimitFile\n\n\n -Xaot:limitFile=(<filename>,<m>,<n>)\n\n\n\n\n\n\n\nCompile or load only the methods listed on lines \n<m>\n to \n<n>\n in the specified limit file (\n<filename>\n). Methods not listed in the limit file and methods listed on lines outside the range are not compiled or loaded.\n\n\n\n\nloadExclude\n\n\n -Xaot:loadExclude=<method_prefix>\n\n\n\n\n\n\n\nDo not load methods beginning with \n<method_prefix>\n.\n\n\n\n\nloadLimit\n\n\n -Xaot:loadLimit=<method_prefix>\n\n\n\n\n\n\n\nLoad methods beginning with \n<method_prefix>\n only.\n\n\n\n\nloadLimitFile\n\n\n -Xaot:loadLimitFile=(<filename>,<m>,<n>)\n\n\n\n\n\n\n\nLoad only the methods listed on lines \n<m>\n to \n<n>\n in the specified limit file (\n<filename>\n). Methods not listed in the limit file and methods listed on lines outside the range are not loaded.\n\n\n\n\nverbose\n\n\n -Xaot:verbose\n\n\n\n\n\n\n\nReports information about the AOT and JIT compiler configuration and method compilation.\n\n\n\n\nSee also\n\n\n\n\n-Xquickstart",
"title": "-Xaot"
},
{
"location": "/xaot/#-xaot-xnoaot",
"text": "Use this option to control the behavior of the ahead-of-time (AOT) compiler. AOT compilation allows the compilation of Java\u2122 classes into native code for subsequent executions of the same program. The AOT compiler works with the class data sharing framework. The AOT compiler generates native code dynamically while an application runs and caches any generated AOT code in the shared data cache. Subsequent VMs that execute the method can load and use the AOT code from the shared data cache without incurring the performance decrease experienced with JIT-compiled native code.",
"title": "-Xaot / -Xnoaot"
},
{
"location": "/xaot/#performance",
"text": "Because AOT code must persist over different program executions, AOT-generated code does not perform as well as JIT-generated code. AOT code usually performs better than interpreted code. In a VM without an AOT compiler or with the AOT compiler disabled, the JIT compiler selectively compiles frequently used methods into optimized native code. There is a time cost associated with compiling methods because the JIT compiler operates while the application is running. Because methods begin by being interpreted and most JIT compilations occur during startup, startup times can be increased. Startup performance can be improved by using the shared AOT code to provide native code without compiling. There is a small time cost to load the AOT code for a method from the shared data cache and bind it into a running program. The time cost is low compared to the time it takes the JIT compiler to compile that method.",
"title": "Performance"
},
{
"location": "/xaot/#default-behavior",
"text": "The AOT compiler is enabled by default, but is only active when shared classes are enabled. By default, shared classes are disabled so that no AOT activity occurs. When the AOT compiler is active, the compiler selects the methods to be AOT compiled with the primary goal of improving startup time.",
"title": "Default behavior"
},
{
"location": "/xaot/#syntax",
"text": "Setting Action Default -Xaot Enable AOT yes -Xaot:<parameter>[=<value>]{,<parameter>[=<value>]} Enable AOT with modifications -Xnoaot Disable AOT",
"title": "Syntax"
},
{
"location": "/xaot/#parameters-for-xaot",
"text": "Note: Although the AOT compiler is enabled by default, it is not active unless shared classes are enabled. Using this option on its own therefore has no effect. Use the -Xshareclasses option to enable shared classes. You can concatenate several parameters by using commas. Parameter Effect count The number of times a method is called before it is compiled or loaded from an existing shared class cache. exclude The method you want to exclude when AOT code is compiled or loaded from the shared classes cache. limitFile Compile or load only the methods listed in the specified limit file. loadExclude Do not load specified methods. loadLimit Load specified methods only. loadLimitFile Load only the methods listed in the specified limit file). verbose Reports information about the AOT and JIT compiler configuration and method compilation.",
"title": "Parameters for -Xaot"
},
{
"location": "/xaot/#count",
"text": "-Xaot:count=<n> where <n> is the number of times a method is called before it is compiled or loaded from an existing shared class cache. For example, setting -Xaot:count=0 forces the AOT compiler to compile everything on first execution.",
"title": "count"
},
{
"location": "/xaot/#exclude",
"text": "-Xaot:exclude=<method> where <method> is the Java method you want to exclude when AOT code is compiled or loaded from the shared classes cache. Use this option if the method causes the program to fail.",
"title": "exclude"
},
{
"location": "/xaot/#limitfile",
"text": "-Xaot:limitFile=(<filename>,<m>,<n>) Compile or load only the methods listed on lines <m> to <n> in the specified limit file ( <filename> ). Methods not listed in the limit file and methods listed on lines outside the range are not compiled or loaded.",
"title": "limitFile"
},
{
"location": "/xaot/#loadexclude",
"text": "-Xaot:loadExclude=<method_prefix> Do not load methods beginning with <method_prefix> .",
"title": "loadExclude"
},
{
"location": "/xaot/#loadlimit",
"text": "-Xaot:loadLimit=<method_prefix> Load methods beginning with <method_prefix> only.",
"title": "loadLimit"
},
{
"location": "/xaot/#loadlimitfile",
"text": "-Xaot:loadLimitFile=(<filename>,<m>,<n>) Load only the methods listed on lines <m> to <n> in the specified limit file ( <filename> ). Methods not listed in the limit file and methods listed on lines outside the range are not loaded.",
"title": "loadLimitFile"
},
{
"location": "/xaot/#verbose",
"text": "-Xaot:verbose Reports information about the AOT and JIT compiler configuration and method compilation.",
"title": "verbose"
},
{
"location": "/xaot/#see-also",
"text": "-Xquickstart",
"title": "See also"
},
{
"location": "/xargencoding/",
"text": "-Xargencoding\n\n\nThe \njava\n and \njavaw\n launchers accept arguments and class names containing any character that is in the character set of the current locale. You can also specify any Unicode character in the class name and arguments by using Java\u2122 escape sequences.\n\n\nTo do this, use the \n-Xargencoding\n command-line option.\n\n\nSyntax\n\n\n -Xargencoding:<parameter>\n\n\n\n\n\nParameters\n\n\nNo parameter\n\n\n -Xargencoding\n\n\n\n\n\n\n\nYou can use Unicode escape sequences in the argument list that you pass to this option. To specify a Unicode character, use escape sequences in the form \n\\u####\n, where \n#\n is a hexadecimal digit (0-9, A-F). For example, to specify a class that is called \nHelloWorld\n and use Unicode encoding for both capital letters, use this command:\njava\n \n-\nXargencoding\n \n\\\nu0048ello\n\\\nu0057orld\n\n\n\n\n\n\n\n\n\n\nutf8\n\n\n -Xargencoding:utf8\n\n\n\n\n\n\n\nUse utf8 encoding.\n\n\n\n\nlatin\n\n\n -Xargencoding:latin\n\n\n\n\n\n\n\nUse ISO8859_1 encoding.",
"title": "-Xargencoding"
},
{
"location": "/xargencoding/#-xargencoding",
"text": "The java and javaw launchers accept arguments and class names containing any character that is in the character set of the current locale. You can also specify any Unicode character in the class name and arguments by using Java\u2122 escape sequences. To do this, use the -Xargencoding command-line option.",
"title": "-Xargencoding"
},
{
"location": "/xargencoding/#syntax",
"text": "-Xargencoding:<parameter>",
"title": "Syntax"
},
{
"location": "/xargencoding/#parameters",
"text": "",
"title": "Parameters"
},
{
"location": "/xargencoding/#no-parameter",
"text": "-Xargencoding You can use Unicode escape sequences in the argument list that you pass to this option. To specify a Unicode character, use escape sequences in the form \\u#### , where # is a hexadecimal digit (0-9, A-F). For example, to specify a class that is called HelloWorld and use Unicode encoding for both capital letters, use this command: java - Xargencoding \\ u0048ello \\ u0057orld",
"title": "No parameter"
},
{
"location": "/xargencoding/#utf8",
"text": "-Xargencoding:utf8 Use utf8 encoding.",
"title": "utf8"
},
{
"location": "/xargencoding/#latin",
"text": "-Xargencoding:latin Use ISO8859_1 encoding.",
"title": "latin"
},
{
"location": "/xbootclasspath/",
"text": "-Xbootclasspath\n\n\nThis Oracle\u00ae Hotspot\u2122 option specifies the search path for bootstrap classes and resources. The default is to search for bootstrap classes and resources in the internal VM directories and \n.jar\n files. The option is recognized by the OpenJ9 VM.\n\n\nSyntax\n\n\n\n\n\n\n\n\nLimited to...\n\n\nSetting\n\n\nEffect\n\n\n\n\n\n\n\n\n\n\n\n\n-Xbootclasspath:<path>\n\n\nSets the search path for bootstrap classes and resources.\n\n\n\n\n\n\n\n\n-Xbootclasspath/p:<path>\n\n\nPrepends the specified resources to the front of the bootstrap class path.\n\n\n\n\n\n\n\n\n-Xbootclasspath/a:<path>\n\n\nAppends the specified resources to the end of the bootstrap class path.\n\n\n\n\n\n\n\n\n\n\nwhere \n<path>\n represents directories and compressed or Java\u2122 archive files separated with colons (:). On Windows\u2122 systems, use a semicolon (;) as a separator.\n\n\n\n\n Oracle advise that you should \"not deploy applications that use this option to override a class in \nrt.jar\n, because this violates the JRE binary code license.\"",
"title": "-Xbootclasspath"
},
{
"location": "/xbootclasspath/#-xbootclasspath",
"text": "This Oracle\u00ae Hotspot\u2122 option specifies the search path for bootstrap classes and resources. The default is to search for bootstrap classes and resources in the internal VM directories and .jar files. The option is recognized by the OpenJ9 VM.",
"title": "-Xbootclasspath"
},
{
"location": "/xbootclasspath/#syntax",
"text": "Limited to... Setting Effect -Xbootclasspath:<path> Sets the search path for bootstrap classes and resources. -Xbootclasspath/p:<path> Prepends the specified resources to the front of the bootstrap class path. -Xbootclasspath/a:<path> Appends the specified resources to the end of the bootstrap class path. where <path> represents directories and compressed or Java\u2122 archive files separated with colons (:). On Windows\u2122 systems, use a semicolon (;) as a separator. Oracle advise that you should \"not deploy applications that use this option to override a class in rt.jar , because this violates the JRE binary code license.\"",
"title": "Syntax"
},
{
"location": "/xceehdlr/",
"text": "-XCEEHDLR\n\n\n(31-bit z/OS\u00ae only)\n\n\nControls OpenJ9 VM Language Environment\u00ae condition handling.\n\n\nSyntax\n\n\n -XCEEHDLR\n\n\n\n\n\nExplanation\n\n\nUse the \n-XCEEHDLR\n option if you want the new behavior for the Java\u2122 and COBOL interoperability batch mode environment, because this option makes signal and condition handling behavior more predictable in a mixed Java and COBOL environment.\n\n\nWhen the \n-XCEEHDLR\n option is enabled, a condition triggered by an arithmetic operation while executing a Java Native Interface (JNI) component causes the VM to convert the Language Environment condition into a Java \nConditionException\n.\n\n\nWhen the \n-XCEEHDLR\n option is used the VM does not install POSIX signal handlers for the following signals:\n\n\n\n\nSIGBUS\n\n\nSIGFPE\n\n\nSIGILL\n\n\nSIGSEGV\n\n\nSIGTRAP\n\n\n\n\nInstead, user condition handlers are registered by the VM, using the \nCEEHDLR()\n method. These condition handlers are registered every time a thread calls into the VM. Threads call into the VM using the Java Native Interface and including the invocation interfaces, for example \nJNI\\_CreateJavaVM\n.\n\n\nThe Java runtime continues to register POSIX signal handlers for the following signals:\n\n\n\n\nSIGABRT\n\n\nSIGINT\n\n\nSIGQUIT\n\n\nSIGTERM\n\n\n\n\nSignal chaining using the \nlibjsig.so\n library is not supported.\n\n\nWhen the \n-XCEEHDLR\n option is used, condition handler actions take place in the following sequence:\n\n\n\n\nAll severity 0 and severity 1 conditions are percolated.\n\n\nIf a Language Environment condition is triggered in JNI code as a result of an arithmetic operation, the VM condition handler resumes executing Java code as if the JNI native code had thrown a \ncom.ibm.le.conditionhandling.ConditionException\n exception. This exception class is a subclass of \njava.lang.RuntimeException\n.\n\n\n \nNote:\n The Language Environment conditions that correspond to arithmetic operations are \nCEE3208S\n through \nCEE3234S\n. However, the Language Environment does not deliver conditions \nCEE3208S\n, \nCEE3213S\n, or \nCEE3234S\n to C applications, so the VM condition handler will not receive them.\n\n\nIf the condition handling reaches this step, the condition is considered to be unrecoverable. RAS diagnostic information is generated, and the VM ends by calling the \nCEE3AB2()\n service with abend code 3565, reason code 0, and cleanup code 0.\n\n\n\n\n \nRestriction:\n You cannot use \n-Xsignal:userConditionHandler=percolate\n and \n-XCEEHDLR\n together.\n\n\nSee also\n\n\n\n\n\n\n-Xsignal:userConditionHandler=percolate\n\n\n\n\n\n\nSignals used by the VM\n.",
"title": "-XCEEHDLR"
},
{
"location": "/xceehdlr/#-xceehdlr",
"text": "(31-bit z/OS\u00ae only) Controls OpenJ9 VM Language Environment\u00ae condition handling.",
"title": "-XCEEHDLR"
},
{
"location": "/xceehdlr/#syntax",
"text": "-XCEEHDLR",
"title": "Syntax"
},
{
"location": "/xceehdlr/#explanation",
"text": "Use the -XCEEHDLR option if you want the new behavior for the Java\u2122 and COBOL interoperability batch mode environment, because this option makes signal and condition handling behavior more predictable in a mixed Java and COBOL environment. When the -XCEEHDLR option is enabled, a condition triggered by an arithmetic operation while executing a Java Native Interface (JNI) component causes the VM to convert the Language Environment condition into a Java ConditionException . When the -XCEEHDLR option is used the VM does not install POSIX signal handlers for the following signals: SIGBUS SIGFPE SIGILL SIGSEGV SIGTRAP Instead, user condition handlers are registered by the VM, using the CEEHDLR() method. These condition handlers are registered every time a thread calls into the VM. Threads call into the VM using the Java Native Interface and including the invocation interfaces, for example JNI\\_CreateJavaVM . The Java runtime continues to register POSIX signal handlers for the following signals: SIGABRT SIGINT SIGQUIT SIGTERM Signal chaining using the libjsig.so library is not supported. When the -XCEEHDLR option is used, condition handler actions take place in the following sequence: All severity 0 and severity 1 conditions are percolated. If a Language Environment condition is triggered in JNI code as a result of an arithmetic operation, the VM condition handler resumes executing Java code as if the JNI native code had thrown a com.ibm.le.conditionhandling.ConditionException exception. This exception class is a subclass of java.lang.RuntimeException . Note: The Language Environment conditions that correspond to arithmetic operations are CEE3208S through CEE3234S . However, the Language Environment does not deliver conditions CEE3208S , CEE3213S , or CEE3234S to C applications, so the VM condition handler will not receive them. If the condition handling reaches this step, the condition is considered to be unrecoverable. RAS diagnostic information is generated, and the VM ends by calling the CEE3AB2() service with abend code 3565, reason code 0, and cleanup code 0. Restriction: You cannot use -Xsignal:userConditionHandler=percolate and -XCEEHDLR together.",
"title": "Explanation"
},
{
"location": "/xceehdlr/#see-also",
"text": "-Xsignal:userConditionHandler=percolate Signals used by the VM .",
"title": "See also"
},
{
"location": "/xcheck/",
"text": "-Xcheck\n\n\nYou can use the \n-Xcheck\n option to run checks during OpenJ9 virtual machine (VM) startup, such as memory checks or checks on JNI functions.\n\n\nSyntax\n\n\n -Xcheck:<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\nclasspath\n\n\nChecks the classpath and reports errors such as a missing directory or JAR file.\n\n\n\n\n\n\ndump\n\n\nChecks the operating system for settings that might truncate system dumps. (AIX\u00ae and Linux\u2122 only)\n\n\n\n\n\n\ngc\n\n\nRuns additional checks on garbage collection.\n\n\n\n\n\n\njni\n\n\nRuns additional checks for JNI functions.\n\n\n\n\n\n\nmemory\n\n\nIdentifies memory leaks inside the VM using strict checks that cause the VM to exit on failure.\n\n\n\n\n\n\nvm\n\n\nPerforms additional checks on the VM.\n\n\n\n\n\n\n\n\nclasspath\n\n\n -Xcheck:classpath\n\n\n\n\n\n\n\nChecks the classpath and reports errors such as a missing directory or JAR file.\n\n\n\n\ndump\n\n\nAIX and Linux only\n\n\n -Xcheck:dump\n\n\n\n\n\n\n\n\n\nChecks operating system settings during VM startup. Messages are issued if the operating system has settings that might truncate system dumps.\n\n\nOn \nAIX\n systems, the following messages are possible:\n\n\n\n\nJVMJ9VM133W The system core size hard ulimit is set to <value>, system dumps may be truncated\n\n\n\n\n\n\nThis message indicates that the AIX operating system user limit is set to restrict the size of system dumps to the value indicated. If a system dump is produced by the VM it might be truncated, and therefore of greatly reduced value in investigating the cause of crashes and other issues. For more information about how to set user limits on AIX, see \nSetting system resource limits on AIX and Linux systems\n.\n\n\n\n\n\n\nJVMJ9VM134W The system fullcore option is set to FALSE, system dumps may be truncated\n\n\n\n\n\n\nThis message indicates that the AIX operating system \nEnable full CORE dump\noption is set to \nFALSE\n. This setting might result in truncated system dumps. For more information about how to set this option correctly on AIX, see \nSetting system resource limits on AIX and Linux systems\n.\n\n\n\n\nOn \nLinux\n systems, the following messages are possible:\n\n\n\n\nJVMJ9VM133W The system core size hard ulimit is set to <value>, system dumps may be truncated.\n\n\n\n\n\n\nThis message indicates that the Linux operating system user limit is set to restrict the size of system dumps to the value indicated. If a system dump is produced by the VM, it might be truncated and therefore of greatly reduced value in investigating the cause of crashes and other issues. Review the documentation that is provided for your operating system to correctly configure the value for \nulimits\n. For further information, see \nSetting system resource limits on AIX and Linux systems\n.\n\n\n\n\n\n\nJVMJ9VM135W /proc/sys/kernel/core_pattern setting \"|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e\" specifies that core dumps are to be piped to an external program. The JVM may be unable to locate core dumps and rename them.\n\n\n\n\n\n\nThis message means that an external program, \nabrt-hook-ccpp\n, is configured in the operating system to intercept any system dump files that are generated. This program is part of the Automatic Bug Reporting Tool (ABRT).\n\n\nFor more information, see \nAutomatic Bug Reporting Tool\n. This tool might interfere with the VM's system dump file processing by renaming or truncating system dumps. Review the configuration of the ABRT tool and messages that are written by the tool in\n/var/log/messages\n. If problems occur when generating system dumps from the VM, consider disabling ABRT.\n\n\n\n\n\n\nJVMJ9VM135W /proc/sys/kernel/core_pattern setting \"|/usr/share/apport/apport %p %s %c\" specifies that core dumps are to be piped to an external program. The JVM may be unable to locate core dumps and rename them.\n\n\n\n\n\n\nThis message means that an external program, \napport\n, is configured in the operating system to intercept any system dump files that are generated. For more information about this tool, see: \nApport\n The tool might interfere with the VM's system dump file processing by renaming or truncating system dumps. Review the configuration of the Apport tool and messages that are written by the tool in \n/var/log/apport.log\n. If problems occur when generating system dumps from the VM, consider disabling the Apport tool.\n\n\n\n\n\n\nJVMJ9VM136W \"/proc/sys/kernel/core_pattern setting \"/tmp/cores/core.%e.%p.%h.%t \" specifies a format string for renaming core dumps. The JVM may be unable to locate core dumps and rename them.\n\n\n\n\n\n\nThis message indicates that the Linux \n/proc/sys/kernel/core_pattern\n option is set to rename system dumps. The tokens that are used in the operating system dump name might interfere with the VM's system dump file processing, in particular with file names specified in the VM \n-Xdump\n options. If problems occur when generating system dumps from the VM, consider changing the \n/proc/sys/kernel/core_pattern\n setting to the default value of \ncore\n.\n\n\n\n\n\n\n\n\ngc\n\n\n -Xcheck:gc[:help][:<scan options>][:<verify options>][:<misc options>]\n\n\n\n\n\n\n\nRuns additional checks on garbage collection. By default, no checks are made. There are many scan, verify, and miscellaneous suboptions available. If you do not specify any, all possible scan and verify suboptions are run, plus the miscellaneous verbose and check suboptions. For more information, see the output of \n-Xcheck:gc:help\n.\n\n\n\n\njni\n\n\n -Xcheck:jni[:help][:<option>]\n\n\n\n\n\n\n\nRuns additional checks for JNI functions. By default, no checks are made. For more information, see the output of \n-Xcheck:jni:help\n.\n\n\n\n\nmemory\n\n\n -Xcheck:memory[:<option>]\n\n\n\n\n\n\n\nIdentifies memory leaks inside the VM by using strict checks that cause the VM to exit on failure.\n\n\n \nRestriction:\n You cannot include \n-Xcheck:memory\n in the options file (see \n-Xoptionsfile\n).\n\n\n\n\nThe available parameters are as follows:\n\n\n\n\n:all\n\n\n(Default if no options specified)\n Enables checking of all allocated and freed blocks on every free and allocate call. This check of the heap is the most thorough. It typically causes the VM to exit on nearly all memory-related problems soon after they are caused. This option has the greatest affect on performance.\n\n\n:callsite=<number_of_allocations>\n\n\n\n\nDisplays callsite information every \n<number_of_allocations>\n. De-allocations are not counted. Callsite information is presented in a table with separate information for each callsite. Statistics include:\n\n\n\n\nThe number and size of allocation and free requests since the last report.\n\n\nThe number of the allocation request responsible for the largest allocation from each site.\n\n\n\n\nCallsites are presented as \nsourcefile:linenumber\n for C code and assembly function name for assembler code.\n\n\nCallsites that do not provide callsite information are accumulated into an \"unknown\" entry.\n\n\n\n\n:failat=<number_of_allocations>\n\n\n\n\nCauses memory allocation to fail (return NULL) after \n<number_of_allocations>\n. For example, setting \n<number_of_allocations>\n to 13 causes the 14th allocation to return NULL. De-allocations are not counted. Use this option to ensure that VM code reliably handles allocation failures. This option is useful for checking allocation site behavior rather than setting a specific allocation limit.\n\n\n\n\n:ignoreUnknownBlocks\n\n\nIgnores attempts to free memory that was not allocated using the \n-Xcheck:memory\n tool. Instead, the \n-Xcheck:memory\n statistics that are printed out at the end of a run indicates the number of \n\"unknown\"\n blocks that were freed.\n\n\n:mprotect=[top|bottom]\n\n\nLocks pages of memory on supported platforms, causing the program to stop if padding before or after the allocated block is accessed for reads or writes. An extra page is locked on each side of the block returned to the user.\n\n\nIf you do not request an exact multiple of one page of memory, a region on one side of your memory is not locked. The \ntop\n and \nbottom\n options control which side of the memory area is locked. \ntop\n aligns your memory blocks to the top of the page (lower address), so buffer underruns result in an application failure. \nbottom\n aligns your memory blocks to the bottom of the page (higher address) so buffer overruns result in an application failure.\n\n\nStandard padding scans detect buffer underruns when using \ntop\n and buffer overruns when using \nbottom\n.\n\n\n:nofree\n\n\nKeeps a list of blocks that are already used instead of freeing memory. This list, and the list of currently allocated blocks, is checked for memory corruption on every allocation and deallocation. Use this option to detect a dangling pointer (a pointer that is \"dereferenced\" after its target memory is freed). This option cannot be reliably used with long-running applications (such as WebSphere\u00ae Application Server), because \n\"freed\"\n memory is never reused or released by the VM.\n\n\n:noscan\n\n\nChecks for blocks that are not freed. This option has little effect on performance, but memory corruption is not detected. This option is compatible only with \nsubAllocator\n, \ncallsite\n, and \ncallsitesmall\n.\n\n\n:quick\n\n\nEnables block padding only and is used to detect basic heap corruption. Every allocated block is padded with sentinel bytes, which are verified on every allocate and free. Block padding is faster than the default of checking every block, but is not as effective.\n\n\n:skipto=<number_of_allocations>\n\n\nCauses the program to check only on allocations that occur after \n<number_of_allocations>\n. De-allocations are not counted. Use this option to speed up VM startup when early allocations are not causing the memory problem. The VM performs approximately 250+ allocations during startup.\n\n\n:subAllocator[=<size_in_MB>]\n\n\nAllocates a dedicated and contiguous region of memory for all VM allocations. This option helps to determine if user JNI code or the VM is responsible for memory corruption. Corruption in the VM \nsubAllocator\n heap suggests that the VM is causing the problem; corruption in the user-allocated memory suggests that user code is corrupting memory. Typically, user and VM allocated memory are interleaved.\n\n\n:zero\n\n\nNewly allocated blocks are set to 0 instead of being filled with the \n0xE7E7xxxxxxxxE7E7\n pattern. Setting these blocks to 0 helps you to determine whether a callsite is expecting zeroed memory, in which case the allocation request is followed by \nmemset(pointer, 0, size)\n.\n\n\n\n\n\n\n\n\nvm\n\n\n -Xcheck:vm[:<option>]\n\n\n\n\n\n\n\nPerforms additional checks on the VM. By default, no checking is performed. For more information, run \n-Xcheck:vm``:help\n.",
"title": "-Xcheck"
},
{
"location": "/xcheck/#-xcheck",
"text": "You can use the -Xcheck option to run checks during OpenJ9 virtual machine (VM) startup, such as memory checks or checks on JNI functions.",
"title": "-Xcheck"
},
{
"location": "/xcheck/#syntax",
"text": "-Xcheck:<parameter>",
"title": "Syntax"
},
{
"location": "/xcheck/#parameters",
"text": "Parameter Effect classpath Checks the classpath and reports errors such as a missing directory or JAR file. dump Checks the operating system for settings that might truncate system dumps. (AIX\u00ae and Linux\u2122 only) gc Runs additional checks on garbage collection. jni Runs additional checks for JNI functions. memory Identifies memory leaks inside the VM using strict checks that cause the VM to exit on failure. vm Performs additional checks on the VM.",
"title": "Parameters"
},
{
"location": "/xcheck/#classpath",
"text": "-Xcheck:classpath Checks the classpath and reports errors such as a missing directory or JAR file.",
"title": "classpath"
},
{
"location": "/xcheck/#dump",
"text": "AIX and Linux only -Xcheck:dump Checks operating system settings during VM startup. Messages are issued if the operating system has settings that might truncate system dumps. On AIX systems, the following messages are possible: JVMJ9VM133W The system core size hard ulimit is set to <value>, system dumps may be truncated This message indicates that the AIX operating system user limit is set to restrict the size of system dumps to the value indicated. If a system dump is produced by the VM it might be truncated, and therefore of greatly reduced value in investigating the cause of crashes and other issues. For more information about how to set user limits on AIX, see Setting system resource limits on AIX and Linux systems . JVMJ9VM134W The system fullcore option is set to FALSE, system dumps may be truncated This message indicates that the AIX operating system Enable full CORE dump option is set to FALSE . This setting might result in truncated system dumps. For more information about how to set this option correctly on AIX, see Setting system resource limits on AIX and Linux systems . On Linux systems, the following messages are possible: JVMJ9VM133W The system core size hard ulimit is set to <value>, system dumps may be truncated. This message indicates that the Linux operating system user limit is set to restrict the size of system dumps to the value indicated. If a system dump is produced by the VM, it might be truncated and therefore of greatly reduced value in investigating the cause of crashes and other issues. Review the documentation that is provided for your operating system to correctly configure the value for ulimits . For further information, see Setting system resource limits on AIX and Linux systems . JVMJ9VM135W /proc/sys/kernel/core_pattern setting \"|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e\" specifies that core dumps are to be piped to an external program. The JVM may be unable to locate core dumps and rename them. This message means that an external program, abrt-hook-ccpp , is configured in the operating system to intercept any system dump files that are generated. This program is part of the Automatic Bug Reporting Tool (ABRT). For more information, see Automatic Bug Reporting Tool . This tool might interfere with the VM's system dump file processing by renaming or truncating system dumps. Review the configuration of the ABRT tool and messages that are written by the tool in /var/log/messages . If problems occur when generating system dumps from the VM, consider disabling ABRT. JVMJ9VM135W /proc/sys/kernel/core_pattern setting \"|/usr/share/apport/apport %p %s %c\" specifies that core dumps are to be piped to an external program. The JVM may be unable to locate core dumps and rename them. This message means that an external program, apport , is configured in the operating system to intercept any system dump files that are generated. For more information about this tool, see: Apport The tool might interfere with the VM's system dump file processing by renaming or truncating system dumps. Review the configuration of the Apport tool and messages that are written by the tool in /var/log/apport.log . If problems occur when generating system dumps from the VM, consider disabling the Apport tool. JVMJ9VM136W \"/proc/sys/kernel/core_pattern setting \"/tmp/cores/core.%e.%p.%h.%t \" specifies a format string for renaming core dumps. The JVM may be unable to locate core dumps and rename them. This message indicates that the Linux /proc/sys/kernel/core_pattern option is set to rename system dumps. The tokens that are used in the operating system dump name might interfere with the VM's system dump file processing, in particular with file names specified in the VM -Xdump options. If problems occur when generating system dumps from the VM, consider changing the /proc/sys/kernel/core_pattern setting to the default value of core .",
"title": "dump"
},
{
"location": "/xcheck/#gc",
"text": "-Xcheck:gc[:help][:<scan options>][:<verify options>][:<misc options>] Runs additional checks on garbage collection. By default, no checks are made. There are many scan, verify, and miscellaneous suboptions available. If you do not specify any, all possible scan and verify suboptions are run, plus the miscellaneous verbose and check suboptions. For more information, see the output of -Xcheck:gc:help .",
"title": "gc"
},
{
"location": "/xcheck/#jni",
"text": "-Xcheck:jni[:help][:<option>] Runs additional checks for JNI functions. By default, no checks are made. For more information, see the output of -Xcheck:jni:help .",
"title": "jni"
},
{
"location": "/xcheck/#memory",
"text": "-Xcheck:memory[:<option>] Identifies memory leaks inside the VM by using strict checks that cause the VM to exit on failure. Restriction: You cannot include -Xcheck:memory in the options file (see -Xoptionsfile ). The available parameters are as follows: :all (Default if no options specified) Enables checking of all allocated and freed blocks on every free and allocate call. This check of the heap is the most thorough. It typically causes the VM to exit on nearly all memory-related problems soon after they are caused. This option has the greatest affect on performance. :callsite=<number_of_allocations> Displays callsite information every <number_of_allocations> . De-allocations are not counted. Callsite information is presented in a table with separate information for each callsite. Statistics include: The number and size of allocation and free requests since the last report. The number of the allocation request responsible for the largest allocation from each site. Callsites are presented as sourcefile:linenumber for C code and assembly function name for assembler code. Callsites that do not provide callsite information are accumulated into an \"unknown\" entry. :failat=<number_of_allocations> Causes memory allocation to fail (return NULL) after <number_of_allocations> . For example, setting <number_of_allocations> to 13 causes the 14th allocation to return NULL. De-allocations are not counted. Use this option to ensure that VM code reliably handles allocation failures. This option is useful for checking allocation site behavior rather than setting a specific allocation limit. :ignoreUnknownBlocks Ignores attempts to free memory that was not allocated using the -Xcheck:memory tool. Instead, the -Xcheck:memory statistics that are printed out at the end of a run indicates the number of \"unknown\" blocks that were freed. :mprotect=[top|bottom] Locks pages of memory on supported platforms, causing the program to stop if padding before or after the allocated block is accessed for reads or writes. An extra page is locked on each side of the block returned to the user. If you do not request an exact multiple of one page of memory, a region on one side of your memory is not locked. The top and bottom options control which side of the memory area is locked. top aligns your memory blocks to the top of the page (lower address), so buffer underruns result in an application failure. bottom aligns your memory blocks to the bottom of the page (higher address) so buffer overruns result in an application failure. Standard padding scans detect buffer underruns when using top and buffer overruns when using bottom . :nofree Keeps a list of blocks that are already used instead of freeing memory. This list, and the list of currently allocated blocks, is checked for memory corruption on every allocation and deallocation. Use this option to detect a dangling pointer (a pointer that is \"dereferenced\" after its target memory is freed). This option cannot be reliably used with long-running applications (such as WebSphere\u00ae Application Server), because \"freed\" memory is never reused or released by the VM. :noscan Checks for blocks that are not freed. This option has little effect on performance, but memory corruption is not detected. This option is compatible only with subAllocator , callsite , and callsitesmall . :quick Enables block padding only and is used to detect basic heap corruption. Every allocated block is padded with sentinel bytes, which are verified on every allocate and free. Block padding is faster than the default of checking every block, but is not as effective. :skipto=<number_of_allocations> Causes the program to check only on allocations that occur after <number_of_allocations> . De-allocations are not counted. Use this option to speed up VM startup when early allocations are not causing the memory problem. The VM performs approximately 250+ allocations during startup. :subAllocator[=<size_in_MB>] Allocates a dedicated and contiguous region of memory for all VM allocations. This option helps to determine if user JNI code or the VM is responsible for memory corruption. Corruption in the VM subAllocator heap suggests that the VM is causing the problem; corruption in the user-allocated memory suggests that user code is corrupting memory. Typically, user and VM allocated memory are interleaved. :zero Newly allocated blocks are set to 0 instead of being filled with the 0xE7E7xxxxxxxxE7E7 pattern. Setting these blocks to 0 helps you to determine whether a callsite is expecting zeroed memory, in which case the allocation request is followed by memset(pointer, 0, size) .",
"title": "memory"
},
{
"location": "/xcheck/#vm",
"text": "-Xcheck:vm[:<option>] Performs additional checks on the VM. By default, no checking is performed. For more information, run -Xcheck:vm``:help .",
"title": "vm"
},
{
"location": "/xclassgc/",
"text": "-Xclassgc / -Xnoclassgc\n\n\nEnables and disables class garbage collection (the dynamic unloading of class objects by the VM). \n\n\nWhen enabled, garbage collection, occurs only on class loader changes. This is the default behavior.\n\n\n \nNote:\n Disabling class garbage collection is not recommended as this causes unlimited native memory growth, leading to out-of-memory errors.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nAction\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xclassgc\n\n\nEnable GC\n\n\nyes\n\n\n\n\n\n\n-Xnoclassgc\n\n\nDisable GC",
"title": "-Xclassgc"
},
{
"location": "/xclassgc/#-xclassgc-xnoclassgc",
"text": "Enables and disables class garbage collection (the dynamic unloading of class objects by the VM). When enabled, garbage collection, occurs only on class loader changes. This is the default behavior. Note: Disabling class garbage collection is not recommended as this causes unlimited native memory growth, leading to out-of-memory errors.",
"title": "-Xclassgc / -Xnoclassgc"
},
{
"location": "/xclassgc/#syntax",
"text": "Setting Action Default -Xclassgc Enable GC yes -Xnoclassgc Disable GC",
"title": "Syntax"
},
{
"location": "/xcodecache/",
"text": "-Xcodecache\n\n\nUse this option to tune performance.\n\n\nThis option sets the size of each block of memory that is allocated to store the native code of compiled Java\u2122 methods. By default, this size is selected internally according to the processor architecture and the capability of your system. The maximum value you can specify is 32 MB. If you set a value larger than 32 MB, the JIT ignores the input and sets the value to 32 MB.\n\n\n \nNote:\n The JIT compiler might allocate more than one code cache for an application. Use the \n-Xcodecachetotal\n option to set the maximum amount of memory that is used by all code caches.\n\n\nSyntax\n\n\n -Xcodecache <size>\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about specifying the \n<size>\n parameter.",
"title": "-Xcodecache"
},
{
"location": "/xcodecache/#-xcodecache",
"text": "Use this option to tune performance. This option sets the size of each block of memory that is allocated to store the native code of compiled Java\u2122 methods. By default, this size is selected internally according to the processor architecture and the capability of your system. The maximum value you can specify is 32 MB. If you set a value larger than 32 MB, the JIT ignores the input and sets the value to 32 MB. Note: The JIT compiler might allocate more than one code cache for an application. Use the -Xcodecachetotal option to set the maximum amount of memory that is used by all code caches.",
"title": "-Xcodecache"
},
{
"location": "/xcodecache/#syntax",
"text": "-Xcodecache <size> See Using -X command-line options for more information about specifying the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xcodecachetotal/",
"text": "-Xcodecachetotal\n\n\nUse this option to set the maximum size limit for the JIT code cache. This option also affects the size of the JIT data cache.\n\n\nSyntax\n\n\n -Xcodecachetotal<size>\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about specifying the \n<size>\n parameter.\n\n\nExplanation\n\n\nBy default, the total size of the JIT code cache is determined by your operating system, architecture, and the version of the VM that you are using. Long-running, complex, server-type applications can fill the JIT code cache, which can cause performance problems because not all of the important methods can be JIT-compiled. Use the \n-Xcodecachetotal\n option to increase the maximum code cache size beyond the default setting, to a setting that suits your application.\n\n\nThe value that you specify is rounded up to a multiple of the code cache block size, as specified by the \n-Xcodecache\n option. If you specify a value for the \n-Xcodecachetotal\n option that is smaller than the default setting, that value is ignored.\n\n\nWhen you use this option, the maximum size limit for the JIT data cache, which holds metadata about compiled methods, is increased proportionally to support the additional JIT compilations.\n\n\nThe maximum size limits, for both the JIT code and data caches, that are in use by the VM are shown in Javadump output. Look for lines that begin with \n1STSEGLIMIT\n. Use this information together with verbose JIT tracing to determine suitable values for this option on your system. For example Javadump output, see \nInterpreting a Java dump: Storage Management (MEMINFO)\n.\n\n\nSee also\n\n\n\n\n-Xjit\n\n\nUsing Javadump",
"title": "-Xcodecachetotal"
},
{
"location": "/xcodecachetotal/#-xcodecachetotal",
"text": "Use this option to set the maximum size limit for the JIT code cache. This option also affects the size of the JIT data cache.",
"title": "-Xcodecachetotal"
},
{
"location": "/xcodecachetotal/#syntax",
"text": "-Xcodecachetotal<size> See Using -X command-line options for more information about specifying the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xcodecachetotal/#explanation",
"text": "By default, the total size of the JIT code cache is determined by your operating system, architecture, and the version of the VM that you are using. Long-running, complex, server-type applications can fill the JIT code cache, which can cause performance problems because not all of the important methods can be JIT-compiled. Use the -Xcodecachetotal option to increase the maximum code cache size beyond the default setting, to a setting that suits your application. The value that you specify is rounded up to a multiple of the code cache block size, as specified by the -Xcodecache option. If you specify a value for the -Xcodecachetotal option that is smaller than the default setting, that value is ignored. When you use this option, the maximum size limit for the JIT data cache, which holds metadata about compiled methods, is increased proportionally to support the additional JIT compilations. The maximum size limits, for both the JIT code and data caches, that are in use by the VM are shown in Javadump output. Look for lines that begin with 1STSEGLIMIT . Use this information together with verbose JIT tracing to determine suitable values for this option on your system. For example Javadump output, see Interpreting a Java dump: Storage Management (MEMINFO) .",
"title": "Explanation"
},
{
"location": "/xcodecachetotal/#see-also",
"text": "-Xjit Using Javadump",
"title": "See also"
},
{
"location": "/xcomp/",
"text": "-Xcomp\n\n\nThe use of this option is deprecated; use \n-Xjit:count=0\n instead.\n\n\nSyntax\n\n\n -Xcomp",
"title": "-Xcomp"
},
{
"location": "/xcomp/#-xcomp",
"text": "The use of this option is deprecated; use -Xjit:count=0 instead.",
"title": "-Xcomp"
},
{
"location": "/xcomp/#syntax",
"text": "-Xcomp",
"title": "Syntax"
},
{
"location": "/xcompactexplicitgc/",
"text": "\u2011Xcompactexplicitgc / \u2011Xnocompactexplicitgc\n\n\nEnables or disables full compaction each time \nSystem.gc()\n is called. \n\n\nCompaction takes place on global garbage collections if you specify \n-Xcompactgc\n or if compaction triggers are met. \n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nAction\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xcompactexplicitgc\n\n\nEnable compaction\n\n\nyes\n\n\n\n\n\n\n-Xnocompactexplicitgc\n\n\nDisable compaction\n\n\n\n\n\n\n\n\n\n\nSee also\n\n\n\n\nGlobal garbage collection: Compaction phase",
"title": "-Xcompactexplicitgc"
},
{
"location": "/xcompactexplicitgc/#xcompactexplicitgc-xnocompactexplicitgc",
"text": "Enables or disables full compaction each time System.gc() is called. Compaction takes place on global garbage collections if you specify -Xcompactgc or if compaction triggers are met.",
"title": "\u2011Xcompactexplicitgc / \u2011Xnocompactexplicitgc"
},
{
"location": "/xcompactexplicitgc/#syntax",
"text": "Setting Action Default -Xcompactexplicitgc Enable compaction yes -Xnocompactexplicitgc Disable compaction",
"title": "Syntax"
},
{
"location": "/xcompactexplicitgc/#see-also",
"text": "Global garbage collection: Compaction phase",
"title": "See also"
},
{
"location": "/xcompactgc/",
"text": "-Xcompactgc / -Xnocompactgc\n\n\nEnables or disables full compaction on all garbage collections (system and global).\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nAction\n\n\n\n\n\n\n\n\n\n\n-Xcompactgc\n\n\nEnable full compaction\n\n\n\n\n\n\n-Xnocompactgc\n\n\nDisable full compaction\n\n\n\n\n\n\n\n\nDefault behavior\n\n\nIf no compaction option is specified, the garbage collector compacts based on a series of triggers that attempt to compact only when it is beneficial to the future performance of the OpenJ9 VM.\n\n\nSee also\n\n\n\n\nGlobal garbage collection: Compaction phase",
"title": "-Xcompactgc"
},
{
"location": "/xcompactgc/#-xcompactgc-xnocompactgc",
"text": "Enables or disables full compaction on all garbage collections (system and global).",
"title": "-Xcompactgc / -Xnocompactgc"
},
{
"location": "/xcompactgc/#syntax",
"text": "Setting Action -Xcompactgc Enable full compaction -Xnocompactgc Disable full compaction",
"title": "Syntax"
},
{
"location": "/xcompactgc/#default-behavior",
"text": "If no compaction option is specified, the garbage collector compacts based on a series of triggers that attempt to compact only when it is beneficial to the future performance of the OpenJ9 VM.",
"title": "Default behavior"
},
{
"location": "/xcompactgc/#see-also",
"text": "Global garbage collection: Compaction phase",
"title": "See also"
},
{
"location": "/xcompilationthreads/",
"text": "-XcompilationThreads\n\n\nUse this option to specify the number of compilation threads that are used by the JIT compiler.\n\n\nSyntax\n\n\n -XcompilationThreads<n>\n\n\n\n\n\n\n\nwhere \n<n>\n is the number of threads, in the range 1-4 inclusive. A number greater than 4 prevents the Java\u2122 VM from starting successfully. \n\n\nSetting the compilation threads to zero does not prevent the JIT from working. Instead, if you do not want the JIT to work, use the \n-Xint\n option.\n\n\n\n\nExplanation\n\n\nWhen multiple compilation threads are used, the JIT might generate several diagnostic log files. A log file is generated for each compilation thread. The naming convention for the log file generated by the first compilation thread uses the following pattern:\n\n\n<\nspecified_filename\n>.<\ndate\n>.<\ntime\n>.<\npid\n>\n\n\n\n\n\n\nThe first compilation thread has ID 0. Log files generated by the second and subsequent compilation threads append the ID of the corresponding compilation thread as a suffix to the log file name. The pattern for these log file names is as follows:\n\n\n<\nspecified_filename\n>.<\ndate\n>.<\ntime\n>.<\npid\n>.<\ncompilation_thread_ID\n>\n\n\n\n\n\n\nFor example, the second compilation thread has ID 1. The result is that the corresponding log file name has the form:\n\n\n<\nspecified_filename\n>.<\ndate\n>.<\ntime\n>.<\npid\n>\n.1",
"title": "-XcompilationThreads"
},
{
"location": "/xcompilationthreads/#-xcompilationthreads",
"text": "Use this option to specify the number of compilation threads that are used by the JIT compiler.",
"title": "-XcompilationThreads"
},
{
"location": "/xcompilationthreads/#syntax",
"text": "-XcompilationThreads<n> where <n> is the number of threads, in the range 1-4 inclusive. A number greater than 4 prevents the Java\u2122 VM from starting successfully. Setting the compilation threads to zero does not prevent the JIT from working. Instead, if you do not want the JIT to work, use the -Xint option.",
"title": "Syntax"
},
{
"location": "/xcompilationthreads/#explanation",
"text": "When multiple compilation threads are used, the JIT might generate several diagnostic log files. A log file is generated for each compilation thread. The naming convention for the log file generated by the first compilation thread uses the following pattern: < specified_filename >.< date >.< time >.< pid > The first compilation thread has ID 0. Log files generated by the second and subsequent compilation threads append the ID of the corresponding compilation thread as a suffix to the log file name. The pattern for these log file names is as follows: < specified_filename >.< date >.< time >.< pid >.< compilation_thread_ID > For example, the second compilation thread has ID 1. The result is that the corresponding log file name has the form: < specified_filename >.< date >.< time >.< pid > .1",
"title": "Explanation"
},
{
"location": "/xcompressedrefs/",
"text": "-Xcompressedrefs / -Xnocompressedrefs\n\n\n(64-bit only)\n\n\nEnables or disables the use of compressed references.\n\n\n \nRestriction:\n You cannot include \n-Xcompressedrefs\n in the options file (see \n-Xoptionsfile\n).\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nAction\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xcompressedrefs\n\n\nEnable compression\n\n\nyes\n (see \nDefault behavior\n)\n\n\n\n\n\n\n-Xnocompressedrefs\n\n\nDisable compression\n\n\n\n\n\n\n\n\n\n\nDefault behavior\n\n\nCompressed references are enabled by default when \n-Xmx\n \u2264 57 GB.\n\n\nz/OS\u00ae:\n This threshold value assumes that you have \nAPAR OA49416\n installed. If you do not have the APAR installed, the threshold value is 25 GB.\n\n\nAIX\u00ae and Linux\u2122:\n For the metronome garbage collection policy, the threshold is 25 GB.\n\n\nSee also\n\n\n\n\nCompressed references",
"title": "-Xcompressedrefs"
},
{
"location": "/xcompressedrefs/#-xcompressedrefs-xnocompressedrefs",
"text": "(64-bit only) Enables or disables the use of compressed references. Restriction: You cannot include -Xcompressedrefs in the options file (see -Xoptionsfile ).",
"title": "-Xcompressedrefs / -Xnocompressedrefs"
},
{
"location": "/xcompressedrefs/#syntax",
"text": "Setting Action Default -Xcompressedrefs Enable compression yes (see Default behavior ) -Xnocompressedrefs Disable compression",
"title": "Syntax"
},
{
"location": "/xcompressedrefs/#default-behavior",
"text": "Compressed references are enabled by default when -Xmx \u2264 57 GB. z/OS\u00ae: This threshold value assumes that you have APAR OA49416 installed. If you do not have the APAR installed, the threshold value is 25 GB. AIX\u00ae and Linux\u2122: For the metronome garbage collection policy, the threshold is 25 GB.",
"title": "Default behavior"
},
{
"location": "/xcompressedrefs/#see-also",
"text": "Compressed references",
"title": "See also"
},
{
"location": "/xconcurrentbackground/",
"text": "-Xconcurrentbackground\n\n\nSpecifies the number of low-priority background threads attached to assist the mutator threads in concurrent mark.\n\n\nSyntax\n\n\n -Xconcurrentbackground<n>\n\n\n\n\n\nDefault behavior\n\n\nThe default is \n0\n for Linux\u2122 on IBM Z\u00ae and \n1\n on all other platforms.",
"title": "-Xconcurrentbackground"
},
{
"location": "/xconcurrentbackground/#-xconcurrentbackground",
"text": "Specifies the number of low-priority background threads attached to assist the mutator threads in concurrent mark.",
"title": "-Xconcurrentbackground"
},
{
"location": "/xconcurrentbackground/#syntax",
"text": "-Xconcurrentbackground<n>",
"title": "Syntax"
},
{
"location": "/xconcurrentbackground/#default-behavior",
"text": "The default is 0 for Linux\u2122 on IBM Z\u00ae and 1 on all other platforms.",
"title": "Default behavior"
},
{
"location": "/xconcurrentlevel/",
"text": "-Xconcurrentlevel\n\n\nThis option indicates the ratio between the amount of heap allocated and the amount of heap marked (the allocation \"tax\" rate).\n\n\nSyntax\n\n\n -Xconcurrentlevel<number>\n\n\n\n\n\nDefault behavior\n\n\nThe default is 8.",
"title": "-Xconcurrentlevel"
},
{
"location": "/xconcurrentlevel/#-xconcurrentlevel",
"text": "This option indicates the ratio between the amount of heap allocated and the amount of heap marked (the allocation \"tax\" rate).",
"title": "-Xconcurrentlevel"
},
{
"location": "/xconcurrentlevel/#syntax",
"text": "-Xconcurrentlevel<number>",
"title": "Syntax"
},
{
"location": "/xconcurrentlevel/#default-behavior",
"text": "The default is 8.",
"title": "Default behavior"
},
{
"location": "/xconcurrentslack/",
"text": "-Xconcurrentslack\n\n\nAttempts to keep the specified amount of the heap space free in concurrent collectors by starting the concurrent operations earlier.\n\n\nUsing this option can sometimes alleviate pause time problems in concurrent collectors at the cost of longer concurrent cycles, affecting total throughput. \n\n\nSyntax\n\n\n -Xconcurrentslack<size>\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about specifying the \n<size>\n parameter.\n\n\n\n\nDefault behavior\n\n\nThe default value is 0, which is optimal for most applications.",
"title": "-Xconcurrentslack"
},
{
"location": "/xconcurrentslack/#-xconcurrentslack",
"text": "Attempts to keep the specified amount of the heap space free in concurrent collectors by starting the concurrent operations earlier. Using this option can sometimes alleviate pause time problems in concurrent collectors at the cost of longer concurrent cycles, affecting total throughput.",
"title": "-Xconcurrentslack"
},
{
"location": "/xconcurrentslack/#syntax",
"text": "-Xconcurrentslack<size> See Using -X command-line options for more information about specifying the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xconcurrentslack/#default-behavior",
"text": "The default value is 0, which is optimal for most applications.",
"title": "Default behavior"
},
{
"location": "/xconmeter/",
"text": "-Xconmeter\n\n\nThis option determines the usage of which area, LOA (large object area) or SOA (small object area), is metered and hence which allocations are taxed during concurrent mark.\n\n\nSyntax\n\n\n -Xconmeter:<parameter>\n\n\n\n\n\nParameters\n\n\nsoa\n\n\n -Xconmeter:soa\n\n\n\n\n\n\n\n(Default) Applies the allocation tax to allocations from the small object area (SOA).\n\n\n\n\nloa\n\n\n -Xconmeter:loa\n\n\n\n\n\n\n\nApplies the allocation tax to allocations from the large object area (LOA).\n\n\n\n\ndynamic\n\n\n -Xconmeter:dynamic\n\n\n\n\n\n\n\nThe collector dynamically determines which area to meter based on which area is exhausted first, whether it is the SOA or the LOA.\n\n\n\n\nDefault behavior\n\n\nBy default, allocation tax is applied to the SOA.",
"title": "-Xconmeter"
},
{
"location": "/xconmeter/#-xconmeter",
"text": "This option determines the usage of which area, LOA (large object area) or SOA (small object area), is metered and hence which allocations are taxed during concurrent mark.",
"title": "-Xconmeter"
},
{
"location": "/xconmeter/#syntax",
"text": "-Xconmeter:<parameter>",
"title": "Syntax"
},
{
"location": "/xconmeter/#parameters",
"text": "",
"title": "Parameters"
},
{
"location": "/xconmeter/#soa",
"text": "-Xconmeter:soa (Default) Applies the allocation tax to allocations from the small object area (SOA).",
"title": "soa"
},
{
"location": "/xconmeter/#loa",
"text": "-Xconmeter:loa Applies the allocation tax to allocations from the large object area (LOA).",
"title": "loa"
},
{
"location": "/xconmeter/#dynamic",
"text": "-Xconmeter:dynamic The collector dynamically determines which area to meter based on which area is exhausted first, whether it is the SOA or the LOA.",
"title": "dynamic"
},
{
"location": "/xconmeter/#default-behavior",
"text": "By default, allocation tax is applied to the SOA.",
"title": "Default behavior"
},
{
"location": "/xdiagnosticscollector/",
"text": "-Xdiagnosticscollector\n\n\nThis option is now redundant, and only generates a warning message. Use the \nIBM\u00ae Support Assistant Data Collector\n instead.\n\n\nSyntax\n\n\n -Xdiagnosticscollector[:settings=<filename>]",
"title": "-Xdiagnosticscollector"
},
{
"location": "/xdiagnosticscollector/#-xdiagnosticscollector",
"text": "This option is now redundant, and only generates a warning message. Use the IBM\u00ae Support Assistant Data Collector instead.",
"title": "-Xdiagnosticscollector"
},
{
"location": "/xdiagnosticscollector/#syntax",
"text": "-Xdiagnosticscollector[:settings=<filename>]",
"title": "Syntax"
},
{
"location": "/xenableexcessivegc/",
"text": "\u2011Xenableexcessivegc / \u2011Xdisableexcessivegc\n\n\nEnables or disables the throwing of an \nOutOfMemory\n exception if excessive time is spent in the GC.\n\n\nIf excessive time is spent in the GC, the option returns \nnull\n for an allocate request and thus causes an \nOutOfMemory\n exception to be thrown.\n\n\n \nNote:\n The \nOutOfMemory\n exception is thrown only when the heap has been fully expanded and the percentage of application run time that is not spent in garbage collection is at least 95%. This percentage is the default value that triggers an excessive GC event. You can control this value with the \n-Xgc:excessiveGCratio\n option.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xenableexcessivegc\n\n\nEnable exception\n\n\n\n\n\n\n\n\n-Xdisableexcessivegc\n\n\nDisable exception\n\n\nyes",
"title": "-Xdisableexcessivegc"
},
{
"location": "/xenableexcessivegc/#xenableexcessivegc-xdisableexcessivegc",
"text": "Enables or disables the throwing of an OutOfMemory exception if excessive time is spent in the GC. If excessive time is spent in the GC, the option returns null for an allocate request and thus causes an OutOfMemory exception to be thrown. Note: The OutOfMemory exception is thrown only when the heap has been fully expanded and the percentage of application run time that is not spent in garbage collection is at least 95%. This percentage is the default value that triggers an excessive GC event. You can control this value with the -Xgc:excessiveGCratio option.",
"title": "\u2011Xenableexcessivegc / \u2011Xdisableexcessivegc"
},
{
"location": "/xenableexcessivegc/#syntax",
"text": "Setting Effect Default -Xenableexcessivegc Enable exception -Xdisableexcessivegc Disable exception yes",
"title": "Syntax"
},
{
"location": "/xenableexplicitgc/",
"text": "\u2011Xenableexplicitgc / \u2011Xdisableexplicitgc\n\n\nEnables and disables garbage collection (GC) when calls are made to \nSystem.gc()\n.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xenableexplicitgc\n\n\nEnable GC\n\n\nyes\n\n\n\n\n\n\n-Xdisableexplicitgc\n\n\nDisable GC\n\n\n\n\n\n\n\n\n\n\nExplanation\n\n\nAlthough it is possible to programmatically trigger a garbage collection by calling \nSystem.gc()\n, performance can be adversely affected by halting the application before it is really necessary. Use this option to prevent the VM responding to application requests for a garage collection cycle.",
"title": "-Xdisableexplicitgc"
},
{
"location": "/xenableexplicitgc/#xenableexplicitgc-xdisableexplicitgc",
"text": "Enables and disables garbage collection (GC) when calls are made to System.gc() .",
"title": "\u2011Xenableexplicitgc / \u2011Xdisableexplicitgc"
},
{
"location": "/xenableexplicitgc/#syntax",
"text": "Setting Effect Default -Xenableexplicitgc Enable GC yes -Xdisableexplicitgc Disable GC",
"title": "Syntax"
},
{
"location": "/xenableexplicitgc/#explanation",
"text": "Although it is possible to programmatically trigger a garbage collection by calling System.gc() , performance can be adversely affected by halting the application before it is really necessary. Use this option to prevent the VM responding to application requests for a garage collection cycle.",
"title": "Explanation"
},
{
"location": "/xdisablejavadump/",
"text": "-Xdisablejavadump\n\n\nTurns off Java dump generation on errors and signals.\n\n\nSyntax\n\n\n -Xdisablejavadump\n\n\n\n\n\nDefault behavior\n\n\nBy default, Javadump generation is enabled.\n\n\nSee also\n\n\n\n\n-Xdump",
"title": "-Xdisablejavadump"
},
{
"location": "/xdisablejavadump/#-xdisablejavadump",
"text": "Turns off Java dump generation on errors and signals.",
"title": "-Xdisablejavadump"
},
{
"location": "/xdisablejavadump/#syntax",
"text": "-Xdisablejavadump",
"title": "Syntax"
},
{
"location": "/xdisablejavadump/#default-behavior",
"text": "By default, Javadump generation is enabled.",
"title": "Default behavior"
},
{
"location": "/xdisablejavadump/#see-also",
"text": "-Xdump",
"title": "See also"
},
{
"location": "/xenablestringconstantgc/",
"text": "\u2011Xenablestringconstantgc / \u2011Xdisablestringconstantgc\n\n\nEnables or disables the collection of strings from the string intern table.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xenablestringconstantgc\n\n\nEnable collection\n\n\nyes\n\n\n\n\n\n\n-Xdisablestringconstantgc\n\n\nDisable collection",
"title": "-Xdisablestringconstantgc"
},
{
"location": "/xenablestringconstantgc/#xenablestringconstantgc-xdisablestringconstantgc",
"text": "Enables or disables the collection of strings from the string intern table.",
"title": "\u2011Xenablestringconstantgc / \u2011Xdisablestringconstantgc"
},
{
"location": "/xenablestringconstantgc/#syntax",
"text": "Setting Effect Default -Xenablestringconstantgc Enable collection yes -Xdisablestringconstantgc Disable collection",
"title": "Syntax"
},
{
"location": "/xdump/",
"text": "-Xdump\n\n\nOpenJ9 produces various types of diagnostic information for analysis when different events occur, such as a general protection fault. The dumps produced are controlled by dump agents, which are initialized when the OpenJ9 virtual machine (VM) starts. The default settings for the dump agents are sufficient for most cases. However, you can use the \n-Xdump\n option on the command line to fine tune the dump agent settings. For example, you can use the \n-Xdump\n option to add and remove dump agents for various VM events, update default dump settings, and limit the number of dumps that are produced.\n\n\nA large set of options and suboptions are available for controlling dumps, which provides a lot of flexibility.\n\n\nXdump Option Builder\n\n\nUse the \nXdump Option Builder tool\n to help you specify the correct options and avoid incompatibilities.\n\n\nSyntax\n\n\n -Xdump:<parameter>\n\n\n\n\n\nThe following table lists the help options for \n-Xdump\n, which provide usage and configuration information:\n\n\n\n\n\n\n\n\nCommand\n\n\nResult\n\n\n\n\n\n\n\n\n\n\n-Xdump:help\n\n\nDisplays general dump help.\n\n\n\n\n\n\n-Xdump:events\n\n\nLists available trigger events.\n\n\n\n\n\n\n-Xdump:request\n\n\nLists additional VM requests.\n\n\n\n\n\n\n-Xdump:tokens\n\n\nLists recognized label tokens.\n\n\n\n\n\n\n-Xdump:what\n\n\nShows registered agents on startup.\n\n\n\n\n\n\n-Xdump:<agent>:help\n\n\nDisplays dump agent usage information.\n\n\n\n\n\n\n\n\nThe following options can be used to control the production of diagnostic data: \n\n\n\n\n\n\n\n\nParameter\n\n\nResult\n\n\n\n\n\n\n\n\n\n\n-Xdump:none\n\n\nRemoves all default dump agents and any preceding dump options.\n\n\n\n\n\n\n-Xdump:dynamic\n\n\nEnable support for pluggable agents\n\n\n\n\n\n\n-Xdump:nofailover\n\n\nDiscards dumps when the default or specified dump location is full.\n\n\n\n\n\n\n-Xdump:directory=<path>\n\n\nSpecifies a directory for all dump types to be written to. This directory path is prefixed to the path of all non-absolute dump file names, including the file names for the default dump agents.\n\n\n\n\n\n\n-Xdump:suspendwith=<offset>\n\n\nModifies the signal that is used to suspend VM threads while a dump file is being written. Use \n<offset>\n to change the default signal number. (Linux\u2122 only)\n\n\n\n\n\n\n-Xdump:<agent>:<suboptions>\n\n\nProvides detailed suboptions per dump agent that provide more granular control.\n\n\n\n\n\n\n\n\nDump agents can be configured at a very granular level by specifying suboptions. The \n<events>\n suboption is the prime trigger mechanism. The full set of suboptions are listed in the following table:\n\n\n\n\n\n\n\n\nDump agent suboptions\n\n\nResult\n\n\n\n\n\n\n\n\n\n\n-Xdump:<agent>:none\n\n\nRemoves the dump agent.\n\n\n\n\n\n\n-Xdump:<agent>:defaults\n\n\nPrints the default options for the dump agent.\n\n\n\n\n\n\n-Xdump:<agent>:events=<events>\n\n\nTriggers a dump agent when a specific event occurs.\n\n\n\n\n\n\n-Xdump:<agent>:exec=<command>\n\n\nStarts an external application for the dump agent.\n\n\n\n\n\n\n-Xdump:<agent>:file=<filename>\n\n\nSpecifies where to write the dump for the dump agent.\n\n\n\n\n\n\n-Xdump:<agent>:filter=<filter>\n\n\nFilters dumps by wildcards or events.\n\n\n\n\n\n\n-Xdump:<agent>:msg_filter=<filter>\n\n\nFilters on text strings within an exception message.\n\n\n\n\n\n\n-Xdump:<agent>:opts=<options>\n\n\nUsed by specific dump agents to select the type of dump file to produce.\n\n\n\n\n\n\n-Xdump:<agent>:priority=<0-999>\n\n\nSpecifies the priority that the dump agents run in.\n\n\n\n\n\n\n-Xdump:<agent>:range=<ranges>\n\n\nStarts and stops a dump agent on a particular occurrence of a VM.\n\n\n\n\n\n\n-Xdump:<agent>:request=<requests>\n\n\nAsks the VM to prepare the state before starting the dump agent.\n\n\n\n\n\n\n\n\nYou can have multiple \n-Xdump\n options on the command line. You can also have multiple dump types triggered by multiple events. For example, the following command turns off the creation of heap dump files, and creates a dump agent that produces a heap dump file and a Java\u2122 dump file when either a \nvmstart\n or \nvmstop\n event occurs:\n\n\njava -Xdump:heap:none -Xdump:heap+java:events=vmstart+vmstop -mp . -m <class> [args...]\n\n\n\n\n\nFor more detailed information on the these parameters and suboptions, including examples, see \nParameters\n.\n\n\nDump agents\n\n\nA dump agent performs diagnostic tasks when triggered. Most dump agents save information on the state of the VM in some form of dump or trace file for later analysis.\nAn exception is the \"tool\" agent, which can be used to trigger external processes when specific events occur.\n\n\n\n\n\n\n\n\nDump agent\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\nstack\n\n\nStack dumps are very basic dumps in which the status and Java stack of the thread is written to stderr.\n\n\n\n\n\n\nconsole\n\n\nConsole dumps are very basic dumps, in which the status of every Java thread is written to stderr.\n\n\n\n\n\n\nsystem\n\n\nSystem dumps capture the raw process image or address space of an application.\n\n\n\n\n\n\ntool\n\n\nThe tool option allows external processes to be started when an event occurs.\n\n\n\n\n\n\njava\n\n\nJava dumps are an internally generated and formatted analysis of the VM, giving information that includes the Java threads present, the classes loaded, and heap statistics.\n\n\n\n\n\n\nheap\n\n\nHeap dumps capture all object instances in the heap, including each object address, type or class name, size, and references to other objects.\n\n\n\n\n\n\nsnap\n\n\nTake a snap of the trace buffers, which contain tracepoint data.\n\n\n\n\n\n\nceedump\n\n\nLE CEEDUMP dumps are z/OS\u00ae formatted summary system dumps that show stack traces for each thread that is in the VM process, together with register information and a short dump of storage for each register.\n\n\n\n\n\n\njit\n\n\nJIT compiler dumps contain diagnostic data in a binary format.\n\n\n\n\n\n\n\n\nDefault dump agents\n\n\nDuring VM initialization a set of dump agents are added by default. You can override this set of dump agents using \n-Xdump\n on the command line. To show the registered dump agents, user the \nXdump:what\n option on the command line. The following sample output shows the default dump agents that are in place on a Linux system:\n\n\njava -Xdump:what\n\nRegistered dump agents\n----------------------\n-Xdump:system:\n events=gpf+abort+traceassert+corruptcache,\n label=/home/user/core.%Y%m%d.%H%M%S.%pid.%seq.dmp,\n range=1..0,\n priority=999,\n request=serial\n----------------------\n-Xdump:system:\n events=systhrow,\n filter=java/lang/OutOfMemoryError,\n label=/home/user/core.%Y%m%d.%H%M%S.%pid.%seq.dmp,\n range=1..1,\n priority=999,\n request=exclusive+compact+prepwalk\n----------------------\n-Xdump:heap:\n events=systhrow,\n filter=java/lang/OutOfMemoryError,\n label=/home/user/heapdump.%Y%m%d.%H%M%S.%pid.%seq.phd,\n range=1..4,\n priority=500,\n request=exclusive+compact+prepwalk,\n opts=PHD\n----------------------\n-Xdump:java:\n events=gpf+user+abort+traceassert+corruptcache,\n label=/home/user/javacore.%Y%m%d.%H%M%S.%pid.%seq.txt,\n range=1..0,\n priority=400,\n request=exclusive+preempt\n----------------------\n-Xdump:java:\n events=systhrow,\n filter=java/lang/OutOfMemoryError,\n label=/home/user/javacore.%Y%m%d.%H%M%S.%pid.%seq.txt,\n range=1..4,\n priority=400,\n request=exclusive+preempt\n----------------------\n-Xdump:snap:\n events=gpf+abort+traceassert+corruptcache,\n label=/home/user/Snap.%Y%m%d.%H%M%S.%pid.%seq.trc,\n range=1..0,\n priority=300,\n request=serial\n----------------------\n-Xdump:snap:\n events=systhrow,\n filter=java/lang/OutOfMemoryError,\n label=/home/user/Snap.%Y%m%d.%H%M%S.%pid.%seq.trc,\n range=1..4,\n priority=300,\n request=serial\n----------------------\n-Xdump:jit:\n events=gpf+abort,\n label=/home/user/jitdump.%Y%m%d.%H%M%S.%pid.%seq.dmp,\n range=1..0,\n priority=200,\n request=serial\n----------------------\n\n\n\n\n\nDump agent tokens\n\n\nYou can use tokens to add context to dump file names and directories, and to pass command-line arguments to the tool agent. The tokens available are listed in the following table:\n\n\n\n\n\n\n\n\nToken\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\n%Y\n\n\nYear (4 digits)\n\n\n\n\n\n\n%y\n\n\nYear (2 digits)\n\n\n\n\n\n\n%m\n\n\nMonth (2 digits)\n\n\n\n\n\n\n%d\n\n\nDay of the month (2 digits)\n\n\n\n\n\n\n%H\n\n\nHour ( 2 digits)\n\n\n\n\n\n\n%M\n\n\nMinute (2 digits)\n\n\n\n\n\n\n%S\n\n\nSecond (2 digits)\n\n\n\n\n\n\n%pid\n\n\nProcess ID\n\n\n\n\n\n\n%uid\n\n\nUser name\n\n\n\n\n\n\n%seq\n\n\nDump counter\n\n\n\n\n\n\n%tick\n\n\nmsec counter\n\n\n\n\n\n\n%home\n\n\nJava home directory\n\n\n\n\n\n\n%last\n\n\nLast dump\n\n\n\n\n\n\n%job\n\n\nJob name (z/OS only)\n\n\n\n\n\n\n&DS\n\n\nDump Section. An incrementing sequence number used for splitting TDUMP files to be less than 2 GB in size. (z/OS 64-bit only)\n\n\n\n\n\n\n\n\nMerging -Xdump agents\n\n\nIf you configure more than one dump agent, each responds to events according to its configuration. However, the internal structures representing the dump agent configuration might not match the command line, because dump agents are merged for efficiency. Two sets of options can be merged as long as none of the agent settings conflict. This means that the list of installed dump agents and their parameters produced by \n-Xdump:what\n might not be grouped in the same way as the original \n-Xdump\n options that configured them.\n\n\nFor example, you can use the following command to specify that a dump agent creates a Java dump file on class unload:\n\n\njava -Xdump:java:events=unload -Xdump:what\n\n\n\n\n\nThis command does not create a new agent, as can be seen in the results from the \n-Xdump:what\n option.\n\n\n...\n----------------------\n-Xdump:java:\n events=gpf+user+abort+unload+traceassert+corruptcache,\n label=/home/user/javacore.%Y%m%d.%H%M%S.%pid.%seq.txt,\n range=1..0,\n priority=400,\n request=exclusive+preempt\n----------------------\n\n\n\n\n\nThe configuration is merged with the existing Java dump agent for events \ngpf\n, \nuser\n, \nabort\n, \ntraceassert\n, and \ncorruptcache\n, because none of the specified options for the new unload agent conflict with those for the existing agent.\n\n\nIn the previous example, if one of the parameters for the unload agent is changed so that it conflicts with the existing agent, then it cannot be merged. For example, the following command specifies a different priority, forcing a separate agent to be created:\n\n\njava -Xdump:java:events=unload,priority=100 -Xdump:what\n\n\n\n\n\nThe results of the \n-Xdump:what\n option in the command are as follows.\n\n\n...\n----------------------\n-Xdump:java:\n events=unload,\n label=/home/user/javacore.%Y%m%d.%H%M%S.%pid.%seq.txt,\n range=1..0,\n priority=100,\n request=exclusive+preempt\n----------------------\n-Xdump:java:\n events=gpf+user+abort+traceassert+corruptcache,\n label=/home/user/javacore.%Y%m%d.%H%M%S.%pid.%seq.txt,\n range=1..0,\n priority=400,\n request=exclusive+preempt\n----------------------\n\n\n\n\n\nTo merge dump agents, the \nrequest\n, \nfilter\n, \nopts\n, \nlabel\n, and \nrange\n parameters must match exactly. If you specify multiple agents that filter on the same string, but keep all other parameters the same, the agents are merged. For example:\n\n\njava -Xdump:none -Xdump:java:events=uncaught,filter=java/lang/NullPointerException -Xdump:java:events=unload,filter=java/lang/NullPointerException -Xdump:what\n\n\n\n\n\nThe results of this command are as follows:\n\n\nRegistered dump agents\n\n\n----------------------\n\n-Xdump:java:\n events=unload+uncaught,\n filter=java/lang/NullPointerException,\n label=/home/user/javacore.%Y%m%d.%H%M%S.%pid.%seq.txt,\n range=1..0,\n priority=400,\n request=exclusive+preempt\n----------------------\n\n\n\n\n\nDump events\n\n\nDump agents are triggered by events occurring during operation of the OpenJ9 VM. Some events can be filtered to improve the relevance of the output.\n\n\nThe following table shows the events that are available as dump agent triggers:\n\n\n\n\n\n\n\n\nEvent\n\n\nTriggered when....\n\n\nFilters on ....\n\n\n\n\n\n\n\n\n\n\ngpf\n\n\nA General Protection Fault (GPF) occurs.\n\n\nNot applicable\n\n\n\n\n\n\nuser\n\n\nThe VM receives the SIGQUIT (Linux, AIX\u00ae, z/OS) or SIGBREAK (Windows\u2122) signal from the operating system.\n\n\nNot applicable\n\n\n\n\n\n\nabort\n\n\nThe VM receives the SIGABRT signal from the operating system.\n\n\nNot applicable\n\n\n\n\n\n\nvmstart\n\n\nThe virtual machine is started.\n\n\nNot applicable\n\n\n\n\n\n\nvmstop\n\n\nThe virtual machine stops.\n\n\nExit code; for example, \nfilter=#129..#192#-42#255\n\n\n\n\n\n\nload\n\n\nA class is loaded.\n\n\nClass name; for example, \nfilter=java/lang/String\n\n\n\n\n\n\nunload\n\n\nA class us unloaded.\n\n\nNot applicable\n\n\n\n\n\n\nthrow\n\n\nAn exception is thrown.\n\n\nException class name; for example, \nfilter=java/lang/OutOfMem*\n\n\n\n\n\n\ncatch\n\n\nAn exception is caught.\n\n\nException class name; for example, \nfilter=*Memory*\n\n\n\n\n\n\nuncaught\n\n\nA Java exception is not caught by the application.\n\n\nException class name; for example, \nfilter=*MemoryError\n\n\n\n\n\n\nsysthrow\n\n\nA Java exception is about to be thrown by the VM. This is different from the 'throw' event because it is only triggered for error conditions detected internally in the VM.\n\n\nException class name; for example, \nfilter=java/lang/OutOfMem*\n.\n\n\n\n\n\n\nthrstart\n\n\nA new thread is started.\n\n\nNot applicable\n\n\n\n\n\n\nblocked\n\n\nA thread becomes blocked.\n\n\nNot applicable\n\n\n\n\n\n\nthrstop\n\n\nA thread stops.\n\n\nNot applicable\n\n\n\n\n\n\nfullgc\n\n\nA garbage collection cycle is started.\n\n\nNot applicable\n\n\n\n\n\n\nslow\n\n\nA thread takes longer than 50ms to respond to an internal VM request.\n\n\nTime taken; for example, filter=#300ms will trigger when a thread takes longer than 300ms to respond to an internal VM request.\n\n\n\n\n\n\nallocation\n\n\nA Java object is allocated with a size matching the given filter specification.\n\n\nObject size; a filter must be supplied. For example, filter=#5m will trigger on objects larger than 5 Mb. Ranges are also supported; for example, filter=#256k..512k will trigger on objects between 256 Kb and 512 Kb in size.\n\n\n\n\n\n\ntraceassert\n\n\nAn internal error occurs in the VM.\n\n\nNot applicable\n\n\n\n\n\n\ncorruptcache\n\n\nThe VM finds that the shared class cache is corrupt.\n\n\nNot applicable\n\n\n\n\n\n\nexcessivegc\n\n\nAn excessive amount of time is being spent in the garbage collector.\n\n\nNot applicable\n\n\n\n\n\n\n\n\n \nNote:\n The \ngpf\n, \ntraceassert\n, and \nabort\n events cannot trigger a heap dump, prepare the heap (request=prepwalk), or compact the heap (request=compact).\n\n\nParameters\n\n\n-Xdump:<agent>:<suboptions>\n descriptions and examples.\n\n\nhelp\n\n\nTo print usage information for a specific dump agent, use \n-Xdump:<agent>:help\n\n\nnone:<options>\n\n\nUse the \n-Xdump:none\n option to add and remove dump agents for various VM events, update default dump settings (such as the dump name), and limit the number of dumps that are produced.\n\n\nThe option can be used to affect all agents by specifying \n-Xdump:none:<options>\n or specific agents by specifying \n-Xdump:<agent>:none:<suboptions>\n\n\nwhere \n<suboptions>\n is one of the following control types:\n\n\n\n\nevents=<event>\n\n\nexec=<command>\n\n\nfile=<filename>\n\n\nfilter=<filter>\n\n\nopts=<options>\n\n\npriority=<0-999>\n\n\nrange=<ranges>\n\n\nrequest=<requests>\n\n\n\n\nExplanations for these suboptions are provided elsewhere in this topic.\n\n\nTo remove all default dump agents and any preceding dump options, use \n-Xdump:none\n. Use this option so that you can subsequently specify a completely new dump configuration.\n\n\nYou can also remove dump agents of a particular type. Here are some examples:\n\n\nTo turn off all heap dumps (including default agents) but leave Java dumps enabled, use the following option:\n\n\n-Xdump:java+heap:events=vmstop -Xdump:heap:none\n\n\n\n\n\nTo turn off all dump agents for corruptcache events:\n\n\n-Xdump:none:events=corruptcache\n\n\n\n\n\nTo turn off just system dumps for corruptcache events:\n\n\n-Xdump:system:none:events=corruptcache\n\n\n\n\n\nTo turn off all dumps when a \njava/lang/OutOfMemory\n error is thrown:\n\n\n-Xdump:none:events=systhrow,filter=java/lang/OutOfMemoryError\n\n\n\n\n\nTo turn off just system dumps when a \njava/lang/OutOfMemory\n error is thrown:\n\n\n-Xdump:system:none:events=systhrow,filter=java/lang/OutOfMemoryError\n\n\n\n\n\nIf you remove all dump agents by using \n-Xdump:none\n with no further \n-Xdump\n options, the VM still provides these basic diagnostic outputs:\n\n\n\n\nIf a user signal (kill -QUIT) is sent to the VM, a brief listing of the Java threads including their stacks, status, and monitor information is written to stderr.\n\n\nIf a crash occurs, information about the location of the crash, VM options, and native and Java stack traces are written to stderr. A system dump file is also written to the user's home directory.\n\n\n\n\n \nNote:\n Removing dump agents and specifying a new dump configuration can require a long set of command-line options. To reuse command-line options, save the new dump configuration in a file and use the \n-Xoptionsfile\n option. For more information, see \n-Xoptionsfile\n.\n\n\ndefaults\n\n\nEach dump type has default options. To view the default options for a particular dump type, use \n-Xdump:<agent>:defaults\n.\n\n\nYou can change the default options at run time. For example, you can direct Java dump files into a separate directory for each process, and guarantee unique files by adding a sequence number to the file name using:\n\n\n-Xdump:java:defaults:file=dumps/%pid/javacore-%seq.txt`\n\n\n\n\n\nOr, for example, on z/OS, you can add the jobname to the Java dump file name using:\n\n\n-Xdump:java:defaults:file=javacore.%job.%H%M%S.txt\n\n\n\n\n\nThis option does not add a Java dump agent; it updates the default settings for Java dump agents. Further Java dump agents will then create dump files using this specification for filenames, unless overridden.\n\n\n \nNote:\n Changing the defaults for a dump type will also affect the default agents for that dump type added by the VM during initialization. For example if you change the default file name for Java dump files, that will change the file name used by the default Java dump agents. However, changing the default range option will not change the range used by the default Java dump agents, because those agents override the range option with specific values.\n\n\nevents=<event>\n\n\nTo trigger a dump as a result of an event, use the \n-Xdump:<agent>:events=<event>\n suboption. For a list of possible events, see \nDump events\n.\n\n\nFor example, the following command instructs the VM to create a dump agent at startup that produces a Heap dump whenever the \nvmstop\n event happens:\n\n\n-Xdump:heap:events=vmstop\n\n\n\n\n\nexec=<command>\n\n\nThe exec suboption is used by the tool dump agent to specify an external application to start. You can set a specific command to run for a particular dump agent with the following command: \n-Xdump:<agent>:exec=<command>\n.\n\n\nfile=<filename>\n\n\nThe file suboption specifies where the diagnostics information is written for the specified dump type. The syntax is \n-Xdump:<agent>:file=<filename>\n.\n\n\nFor example, to create a Heap dump called \nmy.dmp\n when a \nvmstop\n event is received, use:\n\n\njava -Xdump:heap:events=vmstop,file=my.dmp\n\n\n\n\n\nWhen producing system dump files or CEEDUMPs on z/OS platforms, use the \ndsn\n option instead of the \nfile\n option. For example:\n\n\njava -Xdump:system:events=vmstop,dsn=%uid.MYDUMP\n\n\n\n\n\nYou can use tokens to add context to dump file names. For a list of tokens, see \nDump agent tokens\n.\n\n\nThe location for the dump file is selected from the following options, in this order:\n\n\n\n\nThe location specified by the \n-Xdump:<agent>:file\n suboption on the command line (if that location includes a path). This location applies to the specified dump agent type only.\n\n\nThe location specified by the \n-Xdump:directory\n option on the command line. This location applies to all dump agent types.\n\n\nThe location specified by the relevant environment variable (See \nTable: Environment Variables\n).\n\n\nThe current working directory of the OpenJ9 VM process.\n\n\n\n\nTable: Environment Variables\n\n\n\n\n\n\n\n\nDump agent type\n\n\nz/OS operating systems\n\n\nOther operating systems\n\n\n\n\n\n\n\n\n\n\nJava dumps\n\n\n_CEE_DMPTARG\n\n\nIBM_JAVACOREDIR\n\n\n\n\n\n\nHeap dumps\n\n\n_CEE_DMPTARG\n\n\nIBM_HEAPDUMPDIR\n\n\n\n\n\n\nSystem dumps and JIT dumps\n\n\nJAVA_DUMP_TDUMP_PATTERN\n\n\nIBM_COREDIR\n\n\n\n\n\n\nSnap traces\n\n\n_CEE_DMPTARG\n\n\nIBM_COREDIR\n\n\n\n\n\n\n\n\nIf the directory does not exist, it is created.\n\n\nIf the dump file cannot be written to the selected location, the VM reverts to using the following locations, in this order:\n\n\n\n\nOn Windows platforms only, the system default location is \nC:\\WINDOWS\n.\n\n\nThe location specified by the \nTMPDIR\n environment variable.\n\n\nThe \nC:\\Temp\n on Windows operating systems, or the \n/tmp\n directory on other operating systems.\n\n\n\n\nThis VM action does not apply to CEEDUMPs on z/OS operating systems that use the \ndsn\n option.\nYou can prevent the VM reverting to different dump locations by using the \n-Xdump:nofailover\n option.\n\n\nfilter=<filter>\n\n\nSome VM events occur thousands of times during the lifetime of an application. Dump agents can use filters and ranges to avoid producing an excessive number of dump files. The following syntax must be used:\n\n\n-Xdump:<agent>:filter=<filter>\n\n\n\n\n\nWildcards\n\n\nYou can use a wildcard in your exception event filter by placing an asterisk only at the beginning or end of the filter. The following command does not work because the second asterisk is not at the end:\n\n\n-Xdump:java:events=throw,filter=*InvalidArgumentException#*.myVirtualMethod\n\n\n\n\n\nTo fix the problem, change this filter to the following string:\n\n\n-Xdump:java:events=throw,filter=*InvalidArgumentException#MyApplication.*\n\n\n\n\n\nClass loading and exception events\n\n\nYou can filter class loading (\nload\n) and exception (\nthrow\n, \ncatch\n, \nuncaught\n, \nsysthrow\n) events by the name of the class that is being loaded, thrown or caught. For example:\n\n\n-Xdump:java:events=load,filter=java/lang/String\n-Xdump:java:events=throw,filter=java/lang/ArrayStoreException\n-Xdump:java:events=catch,filter=java/lang/NullPointerException\n\n\n\n\n\nIn addition, you can filter \nthrow\n, \nuncaught\n, and \nsysthrow\n exception events by the name of the method that throws the exception. The name of the parent class must include the full package name, using the forward slash (/) as a separator. Use a dot (.) to separate the method name from the class name. You can use an asterisk (*) as a wildcard character, to include all methods (optional portions are shown in brackets). For example:\n\n\n-Xdump:java:events=throw,filter=ExceptionClassName[#com/ibm/ThrowingClassName.throwingMethodName[#stackFrameOffset]]\n\n\n\n\n\nFor example, to trigger a Java dump when method \nMyApplication.myMethod()\n throws a \nNullPointerException\n exception, use the following syntax:\n\n\n-Xdump:java:events=throw,filter=java/lang/NullPointerException#com/ibm/MyApplication.myMethod\n\n\n\n\n\nThe stack frame offset allows you to filter on the name of a method that calls the throwing method. This option is useful if the exception is being thrown from a general purpose or utility class. For example, to trigger a Java dump when a method called by \nMyApplication.main()\n throws a \nNullPointerException\n, use the following syntax:\n\n\n-Xdump:java:events=throw,filter=java/lang/NullPointerException#com/ibm/MyApplication.main#1\n\n\n\n\n\nThe default value of the stack frame offset is zero.\n\n\nYou can filter the \ncatch\n exception events by Java method name (optional portions are shown in brackets). For example:\n\n\n-Xdump:java:events=catch,filter=ExceptionClassName[#com/ibm/CatchingClassName.catchingMethodName]\n\n\n\n\n\nYou can filter \nthrow\n, \nuncaught\n, and \nsysthrowexception\n events by Java method name (optional portions are shown in brackets):\n\n\n-Xdump:java:events=throw,filter=ExceptionClassName[#com/ibm/ThrowingClassName.throwingMethodName[#stackFrameOffset]]\n\n\n\n\n\nYou can filter the \ncatch\n exception events by Java method name (optional portions are shown in brackets):\n\n\n-Xdump:java:events=catch,filter=ExceptionClassName[#com/ibm/CatchingClassName.catchingMethodName]\n\n\n\n\n\n \nNote:\n The filters apply to the stacktrace and fire every time the same exception is rethrown, which might result in multiple Java core files.\n\n\nvmstop event\n\n\nYou can filter the VM shut down event (\nvmstop\n) by using one or more exit codes:\n\n\n-Xdump:java:events=vmstop,filter=#129..192#-42#255\n\n\n\n\n\nslow event\n\n\nYou can filter the \nslow\n event to change the time threshold from the default of 50 ms:\n\n\n-Xdump:java:events=slow,filter=#300ms\n\n\n\n\n\nallocation event\n\n\n(Linux and Windows only)\n\n\nYou must filter the \nallocation\n event to specify the size of objects that cause a trigger. You can set the filter size from zero up to the maximum value of a 32-bit pointer on 32-bit platforms, or the maximum value of a 64-bit pointer on 64-bit platforms. Setting the lower filter value to zero triggers a dump on all allocations.\n\n\nFor example, to trigger dumps on allocations greater than 5 Mb in size, use:\n\n\n-Xdump:stack:events=allocation,filter=#5m\n\n\n\n\n\nTo trigger dumps on allocations between 256Kb and 512Kb in size, use:\n\n\n-Xdump:stack:events=allocation,filter=#256k..512k\n\n\n\n\n\nOther events\n\n\nIf you apply a filter to an event that does not support filtering, the filter is ignored.\n\n\nmsg_filter=<filter>\n\n\nYou can use the msg_filter suboption to filter on text strings within an exception message, allowing you to reduce the number of dump files produced. This option is supported only for the following events: \nthrow\n, \ncatch\n, \nsysthrow\n, and \nuncaught\n.\n\n\nUse the following syntax to include message filtering in your dump output:\n\n\n-Xdump:<agent>:events=<event>,msg_filter=<filter>`\n\n\n\n\n\nwhere \n<filter>\n is a text string from the exceptions that you want to include in the dump file. This suboption supports asterisks as wild cards.\n\n\nThe following example filters \njava/lang/VerifyError\n exceptions that contains the text string \nclass format\n:\n\n\n-Xdump:java:events=throw,filter=java/lang/VerifyError,msg_filter=*class format*\n\n\n\n\n\nopts=<options>\n\n\nThe full syntax is \n-Xdump:<agent>:opts=<options>\n.\n\n\nThe heap dump agent uses this suboption to specify the type of file to produce. On z/OS, the system dump agent uses this suboption to specify the type of dump to produce.\n\n\nHeap dumps\n\n\nYou can specify a PHD heap dump file (PHD), a classic text heap dump file (CLASSIC), or both. The default is a PHD file. For example:\n\n\n-Xdump:heap:opts=PHD \n-Xdump:heap:opts=CLASSIC\n-Xdump:heap:opts=PHD+CLASSIC\n\n\n\n\n\nz/OS system dumps\n\n\nYou can specify a system transaction dump (IEATDUMP), an LE dump (CEEDUMP), or both. The default is an IEADUMP file. For example:\n\n\n-Xdump:system:opts=IEATDUMP\n-Xdump:system:opts=CEEDUMP\n-Xdump:system:opts=IEATDUMP+CEEDUMP\n\n\n\n\n\nThe ceedump agent is the preferred way to specify LE dumps, for example:\n\n\n-Xdump:ceedump:events=gpf\n\n\n\n\n\nTool dumps\n\n\nThe tool dump agent supports two suboptions that can be specified using the \nopts\n subption. You can run the external process asynchronously with opts=ASYNC. You can also specify a delay in milliseconds that produces a pause after starting the command. These two options can be used independently or together. The following examples show different options for starting a new process that runs \nmyProgram\n:\n\n\n-Xdump:tool:events=vmstop,exec=myProgram\n\n\n\n\n\nWithout the \nopts\n suboption, the tool dump agent starts the process, and waits for the process to end before continuing.\n\n\n-Xdump:tool:events=vmstop,exec=myProgram,opts=ASYNC\n\n\n\n\n\nWhen \nopts=ASYNC\n is specified, the tool dump agent starts the process, and continues without waiting for the new process to end.\n\n\n-Xdump:tool:events=vmstop,exec=myProgram,opts=WAIT1000\n\n\n\n\n\nThis option starts the process, waits for the process to end, and then waits a further 1 second (1000 milliseconds) before continuing.\n\n\n-Xdump:tool:events=vmstop,exec=myProgram,opts=ASYNC+WAIT10000\n\n\n\n\n\nFinally the last example starts the process and waits for 10 seconds before continuing, whether the process is still running or not. This last form is useful if you are starting a process that does not end, but requires time to initialize properly.\n\n\npriority=<0-999>\n\n\nOne event can generate multiple dump files. The agents that produce each dump file run sequentially and their order is determined by the priority keyword set for each agent. The full syntax for this command is \n-Xdump:<agent>:priority=<0-999>\n.\n\n\nExamination of the output from \n-Xdump:what\n shows that a \ngpf\n event produces a snap trace, a Java dump file, and a system dump file. In this example, the system dump runs first, with priority 999. The snap dump runs second, with priority 500. The Java dump runs last, with priority 10:\n\n\n-Xdump:heap:events=vmstop,priority=123\n\n\n\n\n\nThe maximum value allowed for priority is 999. Higher priority dump agents are started first.\n\n\nIf you do not specifically set a priority, default values are taken based on the dump type. The default priority and the other default values for a particular type of dump, can be displayed by using \n-Xdump:<type>:defaults\n. For example:\n\n\njava -Xdump:heap:defaults -version\n\n\n\n\n\nDefault \n-Xdump:heap\n settings:\n\n\n events=gpf+user\n filter=\n file=/home/user/heapdump.%Y%m%d.%H%M%S.%pid.phd\n range=1..0\n priority=500\n request=exclusive+compact+prepwalk\n opts=PHD\n\n\n\n\n\nrange=<ranges>\n\n\nYou can start and stop dump agents on a particular occurrence of a VM event by using the \nrange\n suboption: \n-Xdump:<agent>:range=<ranges>\n\n\nFor example:\n\n\n-Xdump:java:events=fullgc,range=100..200\n\n\n\n\n\n \nNote:\n range=1..0 against an event means \"on every occurrence\".\n\n\nThe VM default dump agents have the range suboption set to 1..0 for all events except systhrow. Most systhrow events with \nfilter=java/lang/OutOfMemoryError\n have the range suboption set to 1..4, which limits the number of dump files produced on \nOutOfMemory\n conditions to a maximum of 4. For more information, see \nDefault dump agents\n.\n\n\nIf you add a new dump agent and do not specify the range, a default of 1..0 is used.\n\n\nrequest=<requests>\n\n\nUse the request suboption to ask the VM to prepare the state before starting the dump agent: \n-Xdump:<agent>:request=<requests>\n\n\nThe available suboptions are listed in the following table:\n\n\n\n\n\n\n\n\nsuboption value\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\nexclusive\n\n\nRequest exclusive access to the VM.\n\n\n\n\n\n\ncompact\n\n\nRun garbage collection. This option removes all unreachable objects from the heap before the dump file is generated.\n\n\n\n\n\n\nprepwalk\n\n\nPrepare the heap for walking. You must also specify exclusive when you use this option.\n\n\n\n\n\n\nserial\n\n\nSuspend other dumps until this dump is finished.\n\n\n\n\n\n\npreempt\n\n\nApplies to the Java dump agent and controls whether native threads in the process are forcibly pre-empted in order to collect stack traces. If this option is not specified, only Java stack traces are collected in the Java dump.\n\n\n\n\n\n\n\n\nYou can specify more than one request option by using \n+\n. For example:\n\n\n-Xdump:heap:request=exclusive+compact+prepwalk\n\n\n\n\n\nThe VM exclusive access mechanism allows a VM thread to halt the activity of other VM threads in a controlled way by using internal VM locks. When the \nrequest=exclusive\n option is specified for a dump agent, the VM thread that is producing the dump waits for threads that are running Java code to halt, and for garbage collection operations to complete, before the dump file is written. This process helps ensure that the dump has consistent data. When the dump is complete, the mechanism allows the other threads to resume.\n\n\nBy default, only system dumps for \nOutOfMemoryError\n exceptions request exclusive access. Other system dump events typically result from a crash. In these cases, exclusive access is not requested because acquiring locks during a crash can be problematic.\n\n\nIf system dumps are requested by using the \ncom.ibm.jvm.Dump.SystemDump()\n API, the default system dump agent settings are used, and exclusive access is not requested. However, if you intend to use the system dump file for Java heap memory analysis, use the following option to request exclusive access when the dump is taken:\n\n\n-Xdump:system:defaults:request=exclusive+compact+prewalk\n\n\n\n\n\nThese settings avoid capturing a dump file with in-flight data during garbage collection.\nAs an alternative, you can use the \ncom.ibm.jvm.Dump.triggerDump()\n API and specify \nrequest=exclusive+compact+prepwalk\n on the API call.\n\n\nFor more information about the \ncom.ibm.jvm.Dump API\n, see the API reference information.\n\n\nThe default setting of the \nrequest\n suboption for Java dump files is \nrequest=exclusive+preempt\n. To change the settings so that Java dump files are produced without pre-empting threads to collect native stack traces, use the following option:\n\n\n-Xdump:java:request=exclusive\n\n\n\n\n\nIn general, the default request options are sufficient.\n\n\nDump output\n\n\nDump output is written to different files, depending on the type of dump and the platform. File names include a time stamp.\n\n\n\n\n\n\n\n\nDump type\n\n\nFile name (AIX, Linux, Windows)\n\n\nFile name (z/OS)\n\n\n\n\n\n\n\n\n\n\nSystem dump\n\n\ncore.%Y%m%d.%H%M%S.%pid.dmp\n\n\n%uid.JVM.TDUMP.%job.D%Y%m%d.T%H%M%S (31-bit), %uid.JVM.%job.D%y%m%d.T%H%M%S.X&DS (64-bit) See \nNote\n\n\n\n\n\n\nJava dump\n\n\njavacore.%Y%m%d.%H%M%S.%pid.%seq.txt\n\n\njavacore.%Y%m%d.%H%M%S.%pid.%seq.txt\n\n\n\n\n\n\nHeap dump\n\n\nheapdump.%Y%m%d.%H%M%S.%pid.phd\n\n\nheapdump.%Y%m%d.T%H%M%S.phd\n\n\n\n\n\n\nJIT dump\n\n\njitdump%Y%m%d.%H%M%S.%pid.%seq.dmp\n\n\njitdump%Y%m%d.%H%M%S.%pid.%seq.dmp\n\n\n\n\n\n\nLE CEEDUMP\n\n\n-\n\n\nCEEDUMP.%Y%m%d.%H%M%S.%pid See \nNote\n\n\n\n\n\n\n\n\nThe tokens used in this table, for example \n%Y\n, are described in \nDump agent tokens\n.\n\n\n \nNote:\n On z/OS, the system dump file name can be set with the \nJAVA_DUMP_TDUMP_PATTERN\n environment variable. The CEEDUMP, which is not produced by default, is stored in the directory specified by\n\n_CEE_DMPTARG\n or the current directory if \n_CEE_DMPTARG\n is not specified.\n\n\nSystem dumps on Linux\n\n\nLinux does not provide an operating system API for generating a system dump from a running process. The VM produces system dumps on Linux by using the fork() API to start an identical process to the parent VM process. The VM then generates a SIGSEGV signal in the child process. The SIGSEGV signal causes Linux to create a system dump for the child process. The parent VM processes and renames the system dump, as required, by the \n-Xdump\n options, and might add additional data into the dump file.\n\n\nThe system dump file for the child process contains an exact copy of the memory areas used in the parent. The \ndump viewer\n can obtain information about the Java threads, classes, and heap from the system dump. However, the dump viewer, and other system dump debuggers show only the single native thread that was running in the child process.\n\n\nYou can use the Linux \nkernel.core_pattern\n setting to specify the name and path for system dumps. The VM dump agents override the Linux system dump name and path by renaming the dump as specified in the \n-Xdump\n options. If the \nkernel.core_pattern\n setting specifies a different file system to the \n-Xdump\n options, the VM dump agents might be unable to change the file path. In this case the VM renames the dump file, but leaves the file path unchanged. You can find the dump file name and location in the JVMDUMP010I message.\n\n\n \nNote:\n If you use the \n%t\n specifier in the \nkernel.core_pattern\n setting, the VM does not rename the dump. The VM cannot determine the exact time that Linux generated the core file, and therefore cannot be certain which Linux dump file is the correct one to rename.\n\n\nSee also\n\n\n\n\n-Xtrace\n\n\n-Xdisablejavadump",
"title": "-Xdump"
},
{
"location": "/xdump/#-xdump",
"text": "OpenJ9 produces various types of diagnostic information for analysis when different events occur, such as a general protection fault. The dumps produced are controlled by dump agents, which are initialized when the OpenJ9 virtual machine (VM) starts. The default settings for the dump agents are sufficient for most cases. However, you can use the -Xdump option on the command line to fine tune the dump agent settings. For example, you can use the -Xdump option to add and remove dump agents for various VM events, update default dump settings, and limit the number of dumps that are produced. A large set of options and suboptions are available for controlling dumps, which provides a lot of flexibility.",
"title": "-Xdump"
},
{
"location": "/xdump/#xdump-option-builder",
"text": "Use the Xdump Option Builder tool to help you specify the correct options and avoid incompatibilities.",
"title": "Xdump Option Builder"
},
{
"location": "/xdump/#syntax",
"text": "-Xdump:<parameter> The following table lists the help options for -Xdump , which provide usage and configuration information: Command Result -Xdump:help Displays general dump help. -Xdump:events Lists available trigger events. -Xdump:request Lists additional VM requests. -Xdump:tokens Lists recognized label tokens. -Xdump:what Shows registered agents on startup. -Xdump:<agent>:help Displays dump agent usage information. The following options can be used to control the production of diagnostic data: Parameter Result -Xdump:none Removes all default dump agents and any preceding dump options. -Xdump:dynamic Enable support for pluggable agents -Xdump:nofailover Discards dumps when the default or specified dump location is full. -Xdump:directory=<path> Specifies a directory for all dump types to be written to. This directory path is prefixed to the path of all non-absolute dump file names, including the file names for the default dump agents. -Xdump:suspendwith=<offset> Modifies the signal that is used to suspend VM threads while a dump file is being written. Use <offset> to change the default signal number. (Linux\u2122 only) -Xdump:<agent>:<suboptions> Provides detailed suboptions per dump agent that provide more granular control. Dump agents can be configured at a very granular level by specifying suboptions. The <events> suboption is the prime trigger mechanism. The full set of suboptions are listed in the following table: Dump agent suboptions Result -Xdump:<agent>:none Removes the dump agent. -Xdump:<agent>:defaults Prints the default options for the dump agent. -Xdump:<agent>:events=<events> Triggers a dump agent when a specific event occurs. -Xdump:<agent>:exec=<command> Starts an external application for the dump agent. -Xdump:<agent>:file=<filename> Specifies where to write the dump for the dump agent. -Xdump:<agent>:filter=<filter> Filters dumps by wildcards or events. -Xdump:<agent>:msg_filter=<filter> Filters on text strings within an exception message. -Xdump:<agent>:opts=<options> Used by specific dump agents to select the type of dump file to produce. -Xdump:<agent>:priority=<0-999> Specifies the priority that the dump agents run in. -Xdump:<agent>:range=<ranges> Starts and stops a dump agent on a particular occurrence of a VM. -Xdump:<agent>:request=<requests> Asks the VM to prepare the state before starting the dump agent. You can have multiple -Xdump options on the command line. You can also have multiple dump types triggered by multiple events. For example, the following command turns off the creation of heap dump files, and creates a dump agent that produces a heap dump file and a Java\u2122 dump file when either a vmstart or vmstop event occurs: java -Xdump:heap:none -Xdump:heap+java:events=vmstart+vmstop -mp . -m <class> [args...] For more detailed information on the these parameters and suboptions, including examples, see Parameters .",
"title": "Syntax"
},
{
"location": "/xdump/#dump-agents",
"text": "A dump agent performs diagnostic tasks when triggered. Most dump agents save information on the state of the VM in some form of dump or trace file for later analysis.\nAn exception is the \"tool\" agent, which can be used to trigger external processes when specific events occur. Dump agent Description stack Stack dumps are very basic dumps in which the status and Java stack of the thread is written to stderr. console Console dumps are very basic dumps, in which the status of every Java thread is written to stderr. system System dumps capture the raw process image or address space of an application. tool The tool option allows external processes to be started when an event occurs. java Java dumps are an internally generated and formatted analysis of the VM, giving information that includes the Java threads present, the classes loaded, and heap statistics. heap Heap dumps capture all object instances in the heap, including each object address, type or class name, size, and references to other objects. snap Take a snap of the trace buffers, which contain tracepoint data. ceedump LE CEEDUMP dumps are z/OS\u00ae formatted summary system dumps that show stack traces for each thread that is in the VM process, together with register information and a short dump of storage for each register. jit JIT compiler dumps contain diagnostic data in a binary format.",
"title": "Dump agents"
},
{
"location": "/xdump/#default-dump-agents",
"text": "During VM initialization a set of dump agents are added by default. You can override this set of dump agents using -Xdump on the command line. To show the registered dump agents, user the Xdump:what option on the command line. The following sample output shows the default dump agents that are in place on a Linux system: java -Xdump:what\n\nRegistered dump agents\n----------------------\n-Xdump:system:\n events=gpf+abort+traceassert+corruptcache,\n label=/home/user/core.%Y%m%d.%H%M%S.%pid.%seq.dmp,\n range=1..0,\n priority=999,\n request=serial\n----------------------\n-Xdump:system:\n events=systhrow,\n filter=java/lang/OutOfMemoryError,\n label=/home/user/core.%Y%m%d.%H%M%S.%pid.%seq.dmp,\n range=1..1,\n priority=999,\n request=exclusive+compact+prepwalk\n----------------------\n-Xdump:heap:\n events=systhrow,\n filter=java/lang/OutOfMemoryError,\n label=/home/user/heapdump.%Y%m%d.%H%M%S.%pid.%seq.phd,\n range=1..4,\n priority=500,\n request=exclusive+compact+prepwalk,\n opts=PHD\n----------------------\n-Xdump:java:\n events=gpf+user+abort+traceassert+corruptcache,\n label=/home/user/javacore.%Y%m%d.%H%M%S.%pid.%seq.txt,\n range=1..0,\n priority=400,\n request=exclusive+preempt\n----------------------\n-Xdump:java:\n events=systhrow,\n filter=java/lang/OutOfMemoryError,\n label=/home/user/javacore.%Y%m%d.%H%M%S.%pid.%seq.txt,\n range=1..4,\n priority=400,\n request=exclusive+preempt\n----------------------\n-Xdump:snap:\n events=gpf+abort+traceassert+corruptcache,\n label=/home/user/Snap.%Y%m%d.%H%M%S.%pid.%seq.trc,\n range=1..0,\n priority=300,\n request=serial\n----------------------\n-Xdump:snap:\n events=systhrow,\n filter=java/lang/OutOfMemoryError,\n label=/home/user/Snap.%Y%m%d.%H%M%S.%pid.%seq.trc,\n range=1..4,\n priority=300,\n request=serial\n----------------------\n-Xdump:jit:\n events=gpf+abort,\n label=/home/user/jitdump.%Y%m%d.%H%M%S.%pid.%seq.dmp,\n range=1..0,\n priority=200,\n request=serial\n----------------------",
"title": "Default dump agents"
},
{
"location": "/xdump/#dump-agent-tokens",
"text": "You can use tokens to add context to dump file names and directories, and to pass command-line arguments to the tool agent. The tokens available are listed in the following table: Token Description %Y Year (4 digits) %y Year (2 digits) %m Month (2 digits) %d Day of the month (2 digits) %H Hour ( 2 digits) %M Minute (2 digits) %S Second (2 digits) %pid Process ID %uid User name %seq Dump counter %tick msec counter %home Java home directory %last Last dump %job Job name (z/OS only) &DS Dump Section. An incrementing sequence number used for splitting TDUMP files to be less than 2 GB in size. (z/OS 64-bit only)",
"title": "Dump agent tokens"
},
{
"location": "/xdump/#merging-xdump-agents",
"text": "If you configure more than one dump agent, each responds to events according to its configuration. However, the internal structures representing the dump agent configuration might not match the command line, because dump agents are merged for efficiency. Two sets of options can be merged as long as none of the agent settings conflict. This means that the list of installed dump agents and their parameters produced by -Xdump:what might not be grouped in the same way as the original -Xdump options that configured them. For example, you can use the following command to specify that a dump agent creates a Java dump file on class unload: java -Xdump:java:events=unload -Xdump:what This command does not create a new agent, as can be seen in the results from the -Xdump:what option. ...\n----------------------\n-Xdump:java:\n events=gpf+user+abort+unload+traceassert+corruptcache,\n label=/home/user/javacore.%Y%m%d.%H%M%S.%pid.%seq.txt,\n range=1..0,\n priority=400,\n request=exclusive+preempt\n---------------------- The configuration is merged with the existing Java dump agent for events gpf , user , abort , traceassert , and corruptcache , because none of the specified options for the new unload agent conflict with those for the existing agent. In the previous example, if one of the parameters for the unload agent is changed so that it conflicts with the existing agent, then it cannot be merged. For example, the following command specifies a different priority, forcing a separate agent to be created: java -Xdump:java:events=unload,priority=100 -Xdump:what The results of the -Xdump:what option in the command are as follows. ...\n----------------------\n-Xdump:java:\n events=unload,\n label=/home/user/javacore.%Y%m%d.%H%M%S.%pid.%seq.txt,\n range=1..0,\n priority=100,\n request=exclusive+preempt\n----------------------\n-Xdump:java:\n events=gpf+user+abort+traceassert+corruptcache,\n label=/home/user/javacore.%Y%m%d.%H%M%S.%pid.%seq.txt,\n range=1..0,\n priority=400,\n request=exclusive+preempt\n---------------------- To merge dump agents, the request , filter , opts , label , and range parameters must match exactly. If you specify multiple agents that filter on the same string, but keep all other parameters the same, the agents are merged. For example: java -Xdump:none -Xdump:java:events=uncaught,filter=java/lang/NullPointerException -Xdump:java:events=unload,filter=java/lang/NullPointerException -Xdump:what The results of this command are as follows: Registered dump agents ---------------------- \n-Xdump:java:\n events=unload+uncaught,\n filter=java/lang/NullPointerException,\n label=/home/user/javacore.%Y%m%d.%H%M%S.%pid.%seq.txt,\n range=1..0,\n priority=400,\n request=exclusive+preempt\n----------------------",
"title": "Merging -Xdump agents"
},
{
"location": "/xdump/#dump-events",
"text": "Dump agents are triggered by events occurring during operation of the OpenJ9 VM. Some events can be filtered to improve the relevance of the output. The following table shows the events that are available as dump agent triggers: Event Triggered when.... Filters on .... gpf A General Protection Fault (GPF) occurs. Not applicable user The VM receives the SIGQUIT (Linux, AIX\u00ae, z/OS) or SIGBREAK (Windows\u2122) signal from the operating system. Not applicable abort The VM receives the SIGABRT signal from the operating system. Not applicable vmstart The virtual machine is started. Not applicable vmstop The virtual machine stops. Exit code; for example, filter=#129..#192#-42#255 load A class is loaded. Class name; for example, filter=java/lang/String unload A class us unloaded. Not applicable throw An exception is thrown. Exception class name; for example, filter=java/lang/OutOfMem* catch An exception is caught. Exception class name; for example, filter=*Memory* uncaught A Java exception is not caught by the application. Exception class name; for example, filter=*MemoryError systhrow A Java exception is about to be thrown by the VM. This is different from the 'throw' event because it is only triggered for error conditions detected internally in the VM. Exception class name; for example, filter=java/lang/OutOfMem* . thrstart A new thread is started. Not applicable blocked A thread becomes blocked. Not applicable thrstop A thread stops. Not applicable fullgc A garbage collection cycle is started. Not applicable slow A thread takes longer than 50ms to respond to an internal VM request. Time taken; for example, filter=#300ms will trigger when a thread takes longer than 300ms to respond to an internal VM request. allocation A Java object is allocated with a size matching the given filter specification. Object size; a filter must be supplied. For example, filter=#5m will trigger on objects larger than 5 Mb. Ranges are also supported; for example, filter=#256k..512k will trigger on objects between 256 Kb and 512 Kb in size. traceassert An internal error occurs in the VM. Not applicable corruptcache The VM finds that the shared class cache is corrupt. Not applicable excessivegc An excessive amount of time is being spent in the garbage collector. Not applicable Note: The gpf , traceassert , and abort events cannot trigger a heap dump, prepare the heap (request=prepwalk), or compact the heap (request=compact).",
"title": "Dump events"
},
{
"location": "/xdump/#parameters",
"text": "-Xdump:<agent>:<suboptions> descriptions and examples.",
"title": "Parameters"
},
{
"location": "/xdump/#help",
"text": "To print usage information for a specific dump agent, use -Xdump:<agent>:help",
"title": "help"
},
{
"location": "/xdump/#noneoptions",
"text": "Use the -Xdump:none option to add and remove dump agents for various VM events, update default dump settings (such as the dump name), and limit the number of dumps that are produced. The option can be used to affect all agents by specifying -Xdump:none:<options> or specific agents by specifying -Xdump:<agent>:none:<suboptions> where <suboptions> is one of the following control types: events=<event> exec=<command> file=<filename> filter=<filter> opts=<options> priority=<0-999> range=<ranges> request=<requests> Explanations for these suboptions are provided elsewhere in this topic. To remove all default dump agents and any preceding dump options, use -Xdump:none . Use this option so that you can subsequently specify a completely new dump configuration. You can also remove dump agents of a particular type. Here are some examples: To turn off all heap dumps (including default agents) but leave Java dumps enabled, use the following option: -Xdump:java+heap:events=vmstop -Xdump:heap:none To turn off all dump agents for corruptcache events: -Xdump:none:events=corruptcache To turn off just system dumps for corruptcache events: -Xdump:system:none:events=corruptcache To turn off all dumps when a java/lang/OutOfMemory error is thrown: -Xdump:none:events=systhrow,filter=java/lang/OutOfMemoryError To turn off just system dumps when a java/lang/OutOfMemory error is thrown: -Xdump:system:none:events=systhrow,filter=java/lang/OutOfMemoryError If you remove all dump agents by using -Xdump:none with no further -Xdump options, the VM still provides these basic diagnostic outputs: If a user signal (kill -QUIT) is sent to the VM, a brief listing of the Java threads including their stacks, status, and monitor information is written to stderr. If a crash occurs, information about the location of the crash, VM options, and native and Java stack traces are written to stderr. A system dump file is also written to the user's home directory. Note: Removing dump agents and specifying a new dump configuration can require a long set of command-line options. To reuse command-line options, save the new dump configuration in a file and use the -Xoptionsfile option. For more information, see -Xoptionsfile .",
"title": "none:&lt;options&gt;"
},
{
"location": "/xdump/#defaults",
"text": "Each dump type has default options. To view the default options for a particular dump type, use -Xdump:<agent>:defaults . You can change the default options at run time. For example, you can direct Java dump files into a separate directory for each process, and guarantee unique files by adding a sequence number to the file name using: -Xdump:java:defaults:file=dumps/%pid/javacore-%seq.txt` Or, for example, on z/OS, you can add the jobname to the Java dump file name using: -Xdump:java:defaults:file=javacore.%job.%H%M%S.txt This option does not add a Java dump agent; it updates the default settings for Java dump agents. Further Java dump agents will then create dump files using this specification for filenames, unless overridden. Note: Changing the defaults for a dump type will also affect the default agents for that dump type added by the VM during initialization. For example if you change the default file name for Java dump files, that will change the file name used by the default Java dump agents. However, changing the default range option will not change the range used by the default Java dump agents, because those agents override the range option with specific values.",
"title": "defaults"
},
{
"location": "/xdump/#eventsevent",
"text": "To trigger a dump as a result of an event, use the -Xdump:<agent>:events=<event> suboption. For a list of possible events, see Dump events . For example, the following command instructs the VM to create a dump agent at startup that produces a Heap dump whenever the vmstop event happens: -Xdump:heap:events=vmstop",
"title": "events=&lt;event&gt;"
},
{
"location": "/xdump/#execcommand",
"text": "The exec suboption is used by the tool dump agent to specify an external application to start. You can set a specific command to run for a particular dump agent with the following command: -Xdump:<agent>:exec=<command> .",
"title": "exec=&lt;command&gt;"
},
{
"location": "/xdump/#filefilename",
"text": "The file suboption specifies where the diagnostics information is written for the specified dump type. The syntax is -Xdump:<agent>:file=<filename> . For example, to create a Heap dump called my.dmp when a vmstop event is received, use: java -Xdump:heap:events=vmstop,file=my.dmp When producing system dump files or CEEDUMPs on z/OS platforms, use the dsn option instead of the file option. For example: java -Xdump:system:events=vmstop,dsn=%uid.MYDUMP You can use tokens to add context to dump file names. For a list of tokens, see Dump agent tokens . The location for the dump file is selected from the following options, in this order: The location specified by the -Xdump:<agent>:file suboption on the command line (if that location includes a path). This location applies to the specified dump agent type only. The location specified by the -Xdump:directory option on the command line. This location applies to all dump agent types. The location specified by the relevant environment variable (See Table: Environment Variables ). The current working directory of the OpenJ9 VM process. Table: Environment Variables Dump agent type z/OS operating systems Other operating systems Java dumps _CEE_DMPTARG IBM_JAVACOREDIR Heap dumps _CEE_DMPTARG IBM_HEAPDUMPDIR System dumps and JIT dumps JAVA_DUMP_TDUMP_PATTERN IBM_COREDIR Snap traces _CEE_DMPTARG IBM_COREDIR If the directory does not exist, it is created. If the dump file cannot be written to the selected location, the VM reverts to using the following locations, in this order: On Windows platforms only, the system default location is C:\\WINDOWS . The location specified by the TMPDIR environment variable. The C:\\Temp on Windows operating systems, or the /tmp directory on other operating systems. This VM action does not apply to CEEDUMPs on z/OS operating systems that use the dsn option.\nYou can prevent the VM reverting to different dump locations by using the -Xdump:nofailover option.",
"title": "file=&lt;filename&gt;"
},
{
"location": "/xdump/#filterfilter",
"text": "Some VM events occur thousands of times during the lifetime of an application. Dump agents can use filters and ranges to avoid producing an excessive number of dump files. The following syntax must be used: -Xdump:<agent>:filter=<filter>",
"title": "filter=&lt;filter&gt;"
},
{
"location": "/xdump/#wildcards",
"text": "You can use a wildcard in your exception event filter by placing an asterisk only at the beginning or end of the filter. The following command does not work because the second asterisk is not at the end: -Xdump:java:events=throw,filter=*InvalidArgumentException#*.myVirtualMethod To fix the problem, change this filter to the following string: -Xdump:java:events=throw,filter=*InvalidArgumentException#MyApplication.*",
"title": "Wildcards"
},
{
"location": "/xdump/#class-loading-and-exception-events",
"text": "You can filter class loading ( load ) and exception ( throw , catch , uncaught , systhrow ) events by the name of the class that is being loaded, thrown or caught. For example: -Xdump:java:events=load,filter=java/lang/String\n-Xdump:java:events=throw,filter=java/lang/ArrayStoreException\n-Xdump:java:events=catch,filter=java/lang/NullPointerException In addition, you can filter throw , uncaught , and systhrow exception events by the name of the method that throws the exception. The name of the parent class must include the full package name, using the forward slash (/) as a separator. Use a dot (.) to separate the method name from the class name. You can use an asterisk (*) as a wildcard character, to include all methods (optional portions are shown in brackets). For example: -Xdump:java:events=throw,filter=ExceptionClassName[#com/ibm/ThrowingClassName.throwingMethodName[#stackFrameOffset]] For example, to trigger a Java dump when method MyApplication.myMethod() throws a NullPointerException exception, use the following syntax: -Xdump:java:events=throw,filter=java/lang/NullPointerException#com/ibm/MyApplication.myMethod The stack frame offset allows you to filter on the name of a method that calls the throwing method. This option is useful if the exception is being thrown from a general purpose or utility class. For example, to trigger a Java dump when a method called by MyApplication.main() throws a NullPointerException , use the following syntax: -Xdump:java:events=throw,filter=java/lang/NullPointerException#com/ibm/MyApplication.main#1 The default value of the stack frame offset is zero. You can filter the catch exception events by Java method name (optional portions are shown in brackets). For example: -Xdump:java:events=catch,filter=ExceptionClassName[#com/ibm/CatchingClassName.catchingMethodName] You can filter throw , uncaught , and systhrowexception events by Java method name (optional portions are shown in brackets): -Xdump:java:events=throw,filter=ExceptionClassName[#com/ibm/ThrowingClassName.throwingMethodName[#stackFrameOffset]] You can filter the catch exception events by Java method name (optional portions are shown in brackets): -Xdump:java:events=catch,filter=ExceptionClassName[#com/ibm/CatchingClassName.catchingMethodName] Note: The filters apply to the stacktrace and fire every time the same exception is rethrown, which might result in multiple Java core files.",
"title": "Class loading and exception events"
},
{
"location": "/xdump/#vmstop-event",
"text": "You can filter the VM shut down event ( vmstop ) by using one or more exit codes: -Xdump:java:events=vmstop,filter=#129..192#-42#255",
"title": "vmstop event"
},
{
"location": "/xdump/#slow-event",
"text": "You can filter the slow event to change the time threshold from the default of 50 ms: -Xdump:java:events=slow,filter=#300ms",
"title": "slow event"
},
{
"location": "/xdump/#allocation-event",
"text": "(Linux and Windows only) You must filter the allocation event to specify the size of objects that cause a trigger. You can set the filter size from zero up to the maximum value of a 32-bit pointer on 32-bit platforms, or the maximum value of a 64-bit pointer on 64-bit platforms. Setting the lower filter value to zero triggers a dump on all allocations. For example, to trigger dumps on allocations greater than 5 Mb in size, use: -Xdump:stack:events=allocation,filter=#5m To trigger dumps on allocations between 256Kb and 512Kb in size, use: -Xdump:stack:events=allocation,filter=#256k..512k",
"title": "allocation event"
},
{
"location": "/xdump/#other-events",
"text": "If you apply a filter to an event that does not support filtering, the filter is ignored.",
"title": "Other events"
},
{
"location": "/xdump/#msg_filterfilter",
"text": "You can use the msg_filter suboption to filter on text strings within an exception message, allowing you to reduce the number of dump files produced. This option is supported only for the following events: throw , catch , systhrow , and uncaught . Use the following syntax to include message filtering in your dump output: -Xdump:<agent>:events=<event>,msg_filter=<filter>` where <filter> is a text string from the exceptions that you want to include in the dump file. This suboption supports asterisks as wild cards. The following example filters java/lang/VerifyError exceptions that contains the text string class format : -Xdump:java:events=throw,filter=java/lang/VerifyError,msg_filter=*class format*",
"title": "msg_filter=&lt;filter&gt;"
},
{
"location": "/xdump/#optsoptions",
"text": "The full syntax is -Xdump:<agent>:opts=<options> . The heap dump agent uses this suboption to specify the type of file to produce. On z/OS, the system dump agent uses this suboption to specify the type of dump to produce.",
"title": "opts=&lt;options&gt;"
},
{
"location": "/xdump/#heap-dumps",
"text": "You can specify a PHD heap dump file (PHD), a classic text heap dump file (CLASSIC), or both. The default is a PHD file. For example: -Xdump:heap:opts=PHD \n-Xdump:heap:opts=CLASSIC\n-Xdump:heap:opts=PHD+CLASSIC",
"title": "Heap dumps"
},
{
"location": "/xdump/#zos-system-dumps",
"text": "You can specify a system transaction dump (IEATDUMP), an LE dump (CEEDUMP), or both. The default is an IEADUMP file. For example: -Xdump:system:opts=IEATDUMP\n-Xdump:system:opts=CEEDUMP\n-Xdump:system:opts=IEATDUMP+CEEDUMP The ceedump agent is the preferred way to specify LE dumps, for example: -Xdump:ceedump:events=gpf",
"title": "z/OS system dumps"
},
{
"location": "/xdump/#tool-dumps",
"text": "The tool dump agent supports two suboptions that can be specified using the opts subption. You can run the external process asynchronously with opts=ASYNC. You can also specify a delay in milliseconds that produces a pause after starting the command. These two options can be used independently or together. The following examples show different options for starting a new process that runs myProgram : -Xdump:tool:events=vmstop,exec=myProgram Without the opts suboption, the tool dump agent starts the process, and waits for the process to end before continuing. -Xdump:tool:events=vmstop,exec=myProgram,opts=ASYNC When opts=ASYNC is specified, the tool dump agent starts the process, and continues without waiting for the new process to end. -Xdump:tool:events=vmstop,exec=myProgram,opts=WAIT1000 This option starts the process, waits for the process to end, and then waits a further 1 second (1000 milliseconds) before continuing. -Xdump:tool:events=vmstop,exec=myProgram,opts=ASYNC+WAIT10000 Finally the last example starts the process and waits for 10 seconds before continuing, whether the process is still running or not. This last form is useful if you are starting a process that does not end, but requires time to initialize properly.",
"title": "Tool dumps"
},
{
"location": "/xdump/#priority0-999",
"text": "One event can generate multiple dump files. The agents that produce each dump file run sequentially and their order is determined by the priority keyword set for each agent. The full syntax for this command is -Xdump:<agent>:priority=<0-999> . Examination of the output from -Xdump:what shows that a gpf event produces a snap trace, a Java dump file, and a system dump file. In this example, the system dump runs first, with priority 999. The snap dump runs second, with priority 500. The Java dump runs last, with priority 10: -Xdump:heap:events=vmstop,priority=123 The maximum value allowed for priority is 999. Higher priority dump agents are started first. If you do not specifically set a priority, default values are taken based on the dump type. The default priority and the other default values for a particular type of dump, can be displayed by using -Xdump:<type>:defaults . For example: java -Xdump:heap:defaults -version Default -Xdump:heap settings: events=gpf+user\n filter=\n file=/home/user/heapdump.%Y%m%d.%H%M%S.%pid.phd\n range=1..0\n priority=500\n request=exclusive+compact+prepwalk\n opts=PHD",
"title": "priority=&lt;0-999&gt;"
},
{
"location": "/xdump/#rangeranges",
"text": "You can start and stop dump agents on a particular occurrence of a VM event by using the range suboption: -Xdump:<agent>:range=<ranges> For example: -Xdump:java:events=fullgc,range=100..200 Note: range=1..0 against an event means \"on every occurrence\". The VM default dump agents have the range suboption set to 1..0 for all events except systhrow. Most systhrow events with filter=java/lang/OutOfMemoryError have the range suboption set to 1..4, which limits the number of dump files produced on OutOfMemory conditions to a maximum of 4. For more information, see Default dump agents . If you add a new dump agent and do not specify the range, a default of 1..0 is used.",
"title": "range=&lt;ranges&gt;"
},
{
"location": "/xdump/#requestrequests",
"text": "Use the request suboption to ask the VM to prepare the state before starting the dump agent: -Xdump:<agent>:request=<requests> The available suboptions are listed in the following table: suboption value Description exclusive Request exclusive access to the VM. compact Run garbage collection. This option removes all unreachable objects from the heap before the dump file is generated. prepwalk Prepare the heap for walking. You must also specify exclusive when you use this option. serial Suspend other dumps until this dump is finished. preempt Applies to the Java dump agent and controls whether native threads in the process are forcibly pre-empted in order to collect stack traces. If this option is not specified, only Java stack traces are collected in the Java dump. You can specify more than one request option by using + . For example: -Xdump:heap:request=exclusive+compact+prepwalk The VM exclusive access mechanism allows a VM thread to halt the activity of other VM threads in a controlled way by using internal VM locks. When the request=exclusive option is specified for a dump agent, the VM thread that is producing the dump waits for threads that are running Java code to halt, and for garbage collection operations to complete, before the dump file is written. This process helps ensure that the dump has consistent data. When the dump is complete, the mechanism allows the other threads to resume. By default, only system dumps for OutOfMemoryError exceptions request exclusive access. Other system dump events typically result from a crash. In these cases, exclusive access is not requested because acquiring locks during a crash can be problematic. If system dumps are requested by using the com.ibm.jvm.Dump.SystemDump() API, the default system dump agent settings are used, and exclusive access is not requested. However, if you intend to use the system dump file for Java heap memory analysis, use the following option to request exclusive access when the dump is taken: -Xdump:system:defaults:request=exclusive+compact+prewalk These settings avoid capturing a dump file with in-flight data during garbage collection.\nAs an alternative, you can use the com.ibm.jvm.Dump.triggerDump() API and specify request=exclusive+compact+prepwalk on the API call. For more information about the com.ibm.jvm.Dump API , see the API reference information. The default setting of the request suboption for Java dump files is request=exclusive+preempt . To change the settings so that Java dump files are produced without pre-empting threads to collect native stack traces, use the following option: -Xdump:java:request=exclusive In general, the default request options are sufficient.",
"title": "request=&lt;requests&gt;"
},
{
"location": "/xdump/#dump-output",
"text": "Dump output is written to different files, depending on the type of dump and the platform. File names include a time stamp. Dump type File name (AIX, Linux, Windows) File name (z/OS) System dump core.%Y%m%d.%H%M%S.%pid.dmp %uid.JVM.TDUMP.%job.D%Y%m%d.T%H%M%S (31-bit), %uid.JVM.%job.D%y%m%d.T%H%M%S.X&DS (64-bit) See Note Java dump javacore.%Y%m%d.%H%M%S.%pid.%seq.txt javacore.%Y%m%d.%H%M%S.%pid.%seq.txt Heap dump heapdump.%Y%m%d.%H%M%S.%pid.phd heapdump.%Y%m%d.T%H%M%S.phd JIT dump jitdump%Y%m%d.%H%M%S.%pid.%seq.dmp jitdump%Y%m%d.%H%M%S.%pid.%seq.dmp LE CEEDUMP - CEEDUMP.%Y%m%d.%H%M%S.%pid See Note The tokens used in this table, for example %Y , are described in Dump agent tokens . Note: On z/OS, the system dump file name can be set with the JAVA_DUMP_TDUMP_PATTERN environment variable. The CEEDUMP, which is not produced by default, is stored in the directory specified by _CEE_DMPTARG or the current directory if _CEE_DMPTARG is not specified.",
"title": "Dump output"
},
{
"location": "/xdump/#system-dumps-on-linux",
"text": "Linux does not provide an operating system API for generating a system dump from a running process. The VM produces system dumps on Linux by using the fork() API to start an identical process to the parent VM process. The VM then generates a SIGSEGV signal in the child process. The SIGSEGV signal causes Linux to create a system dump for the child process. The parent VM processes and renames the system dump, as required, by the -Xdump options, and might add additional data into the dump file. The system dump file for the child process contains an exact copy of the memory areas used in the parent. The dump viewer can obtain information about the Java threads, classes, and heap from the system dump. However, the dump viewer, and other system dump debuggers show only the single native thread that was running in the child process. You can use the Linux kernel.core_pattern setting to specify the name and path for system dumps. The VM dump agents override the Linux system dump name and path by renaming the dump as specified in the -Xdump options. If the kernel.core_pattern setting specifies a different file system to the -Xdump options, the VM dump agents might be unable to change the file path. In this case the VM renames the dump file, but leaves the file path unchanged. You can find the dump file name and location in the JVMDUMP010I message. Note: If you use the %t specifier in the kernel.core_pattern setting, the VM does not rename the dump. The VM cannot determine the exact time that Linux generated the core file, and therefore cannot be certain which Linux dump file is the correct one to rename.",
"title": "System dumps on Linux"
},
{
"location": "/xdump/#see-also",
"text": "-Xtrace -Xdisablejavadump",
"title": "See also"
},
{
"location": "/xenableexcessivegc/",
"text": "\u2011Xenableexcessivegc / \u2011Xdisableexcessivegc\n\n\nEnables or disables the throwing of an \nOutOfMemory\n exception if excessive time is spent in the GC.\n\n\nIf excessive time is spent in the GC, the option returns \nnull\n for an allocate request and thus causes an \nOutOfMemory\n exception to be thrown.\n\n\n \nNote:\n The \nOutOfMemory\n exception is thrown only when the heap has been fully expanded and the percentage of application run time that is not spent in garbage collection is at least 95%. This percentage is the default value that triggers an excessive GC event. You can control this value with the \n-Xgc:excessiveGCratio\n option.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xenableexcessivegc\n\n\nEnable exception\n\n\n\n\n\n\n\n\n-Xdisableexcessivegc\n\n\nDisable exception\n\n\nyes",
"title": "-Xenableexcessivegc"
},
{
"location": "/xenableexcessivegc/#xenableexcessivegc-xdisableexcessivegc",
"text": "Enables or disables the throwing of an OutOfMemory exception if excessive time is spent in the GC. If excessive time is spent in the GC, the option returns null for an allocate request and thus causes an OutOfMemory exception to be thrown. Note: The OutOfMemory exception is thrown only when the heap has been fully expanded and the percentage of application run time that is not spent in garbage collection is at least 95%. This percentage is the default value that triggers an excessive GC event. You can control this value with the -Xgc:excessiveGCratio option.",
"title": "\u2011Xenableexcessivegc / \u2011Xdisableexcessivegc"
},
{
"location": "/xenableexcessivegc/#syntax",
"text": "Setting Effect Default -Xenableexcessivegc Enable exception -Xdisableexcessivegc Disable exception yes",
"title": "Syntax"
},
{
"location": "/xenableexplicitgc/",
"text": "\u2011Xenableexplicitgc / \u2011Xdisableexplicitgc\n\n\nEnables and disables garbage collection (GC) when calls are made to \nSystem.gc()\n.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xenableexplicitgc\n\n\nEnable GC\n\n\nyes\n\n\n\n\n\n\n-Xdisableexplicitgc\n\n\nDisable GC\n\n\n\n\n\n\n\n\n\n\nExplanation\n\n\nAlthough it is possible to programmatically trigger a garbage collection by calling \nSystem.gc()\n, performance can be adversely affected by halting the application before it is really necessary. Use this option to prevent the VM responding to application requests for a garage collection cycle.",
"title": "-Xenableexplicitgc"
},
{
"location": "/xenableexplicitgc/#xenableexplicitgc-xdisableexplicitgc",
"text": "Enables and disables garbage collection (GC) when calls are made to System.gc() .",
"title": "\u2011Xenableexplicitgc / \u2011Xdisableexplicitgc"
},
{
"location": "/xenableexplicitgc/#syntax",
"text": "Setting Effect Default -Xenableexplicitgc Enable GC yes -Xdisableexplicitgc Disable GC",
"title": "Syntax"
},
{
"location": "/xenableexplicitgc/#explanation",
"text": "Although it is possible to programmatically trigger a garbage collection by calling System.gc() , performance can be adversely affected by halting the application before it is really necessary. Use this option to prevent the VM responding to application requests for a garage collection cycle.",
"title": "Explanation"
},
{
"location": "/xenablestringconstantgc/",
"text": "\u2011Xenablestringconstantgc / \u2011Xdisablestringconstantgc\n\n\nEnables or disables the collection of strings from the string intern table.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xenablestringconstantgc\n\n\nEnable collection\n\n\nyes\n\n\n\n\n\n\n-Xdisablestringconstantgc\n\n\nDisable collection",
"title": "-Xenablestringconstantgc"
},
{
"location": "/xenablestringconstantgc/#xenablestringconstantgc-xdisablestringconstantgc",
"text": "Enables or disables the collection of strings from the string intern table.",
"title": "\u2011Xenablestringconstantgc / \u2011Xdisablestringconstantgc"
},
{
"location": "/xenablestringconstantgc/#syntax",
"text": "Setting Effect Default -Xenablestringconstantgc Enable collection yes -Xdisablestringconstantgc Disable collection",
"title": "Syntax"
},
{
"location": "/xfastresolve/",
"text": "-Xfastresolve\n\n\nTune performance by improving the resolution time for classes when the field count exceeds the specified threshold.\n\n\nIf profiling tools show significant costs in field resolution, change the threshold until the costs are reduced. If you enable this option, additional memory is used when the threshold is exceeded.\n\n\n \nNote:\n The use of this option is deprecated.\n\n\nSyntax\n\n\n -Xfastresolve<n>\n\n\n\n\n\n\n\nwhere \n<n>\n is the required threshold.",
"title": "-Xfastresolve"
},
{
"location": "/xfastresolve/#-xfastresolve",
"text": "Tune performance by improving the resolution time for classes when the field count exceeds the specified threshold. If profiling tools show significant costs in field resolution, change the threshold until the costs are reduced. If you enable this option, additional memory is used when the threshold is exceeded. Note: The use of this option is deprecated.",
"title": "-Xfastresolve"
},
{
"location": "/xfastresolve/#syntax",
"text": "-Xfastresolve<n> where <n> is the required threshold.",
"title": "Syntax"
},
{
"location": "/xfuture/",
"text": "-Xfuture\n\n\nAs described in the \nOracle \"Non-Standard Options\" documentation\n, this Hotspot option turns on strict class-file format checks. For compatibility, this option is also supported by the OpenJ9 VM.\n\n\nSyntax\n\n\n -Xfuture\n\n\n\n\n\nExplanation\n\n\nOracle recommend that you use this flag when you are developing new code because stricter checks will become the default in future releases.\n\n\nDefault behavior\n\n\nBy default, strict format checks are disabled.",
"title": "-Xfuture"
},
{
"location": "/xfuture/#-xfuture",
"text": "As described in the Oracle \"Non-Standard Options\" documentation , this Hotspot option turns on strict class-file format checks. For compatibility, this option is also supported by the OpenJ9 VM.",
"title": "-Xfuture"
},
{
"location": "/xfuture/#syntax",
"text": "-Xfuture",
"title": "Syntax"
},
{
"location": "/xfuture/#explanation",
"text": "Oracle recommend that you use this flag when you are developing new code because stricter checks will become the default in future releases.",
"title": "Explanation"
},
{
"location": "/xfuture/#default-behavior",
"text": "By default, strict format checks are disabled.",
"title": "Default behavior"
},
{
"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 (Linux on IBM Z\u00ae and z/OS\u00ae only).\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(Linux on Z and z/OS only)\n\n\n -Xgc:concurrentScavenge\n\n\n\n\n\n\n\nThis option is supported only on the 64-bit VM with the Generational Concurrent (\ngencon\n) garbage collection policy. When this mode is enabled, the VM attempts to reduce GC pause-times for response-time sensitive, large heap applications. This option is supported only on IBM z14\u2122 hardware and the following software:\n\n\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\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"
},
{
"location": "/xgc/#-xgc",
"text": "Options that change the behavior of the Garbage Collector (GC).",
"title": "-Xgc"
},
{
"location": "/xgc/#syntax",
"text": "-Xgc:<parameter>",
"title": "Syntax"
},
{
"location": "/xgc/#parameters",
"text": "Parameter Effect concurrentScavenge Enables a garbage collection (GC) mode with less pause times (Linux on IBM Z\u00ae and z/OS\u00ae only). dnssExpectedTimeRatioMaximum Sets the maximum time to spend on GC of the nursery area. dnssExpectedTimeRatioMinimum Sets the minimum time to spend on GC of the nursery area. excessiveGCratio Sets a boundary value beyond which GC is deemed to be excessive. minContractPercent Sets the minimum percentage of the heap that can be contracted at any given time. maxContractPercent Sets the maximum percentage of the heap that can be contracted at any given time. overrideHiresTimerCheck Overrides GC operating system checks for timer resolution. preferredHeapBase Sets a memory range for the Java\u2122 heap. (AIX\u00ae, Linux\u2122, and Windows\u2122 only) scvNoAdaptiveTenure Turns off the adaptive tenure age in the generational concurrent GC policy. scvTenureAge Sets the initial scavenger tenure age in the generational concurrent GC policy. tlhIncrementSize Sets the size of the thread local heap (TLH) increment tlhInitialSize Sets the initial size of the thread local heap tlhMaximumSize Sets the maximum size of the thread local heap verboseFormat Sets the verbose GC format.",
"title": "Parameters"
},
{
"location": "/xgc/#concurrentscavenge",
"text": "(Linux on Z and z/OS only) -Xgc:concurrentScavenge This option is supported only on the 64-bit VM with the Generational Concurrent ( gencon ) garbage collection policy. When this mode is enabled, the VM attempts to reduce GC pause-times for response-time sensitive, large heap applications. This option is supported only on IBM z14\u2122 hardware and 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"
},
{
"location": "/xgc/#dnssexpectedtimeratiomaximum",
"text": "-Xgc:dnssExpectedTimeRatioMaximum=<value> Setting Value Default <value> [percentage] 5 The 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.",
"title": "dnssExpectedTimeRatioMaximum"
},
{
"location": "/xgc/#dnssexpectedtimeratiominimum",
"text": "-Xgc:dnssExpectedTimeRatioMinimum=<value> Setting Value Default <value> [percentage] 1 The 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.",
"title": "dnssExpectedTimeRatioMinimum"
},
{
"location": "/xgc/#excessivegcratio",
"text": "-Xgc:excessiveGCratio=<value> Setting Value Default <value> [percentage] 95 where <value> is a percentage of total application run time that is not spent in GC. The 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 -Xenableexcessivegc is set.",
"title": "excessiveGCratio"
},
{
"location": "/xgc/#mincontractpercent",
"text": "-Xgc:minContractPercent=<n> Setting Value Default <n> [percentage] - The minimum percentage of the heap that can be contracted at any given time.",
"title": "minContractPercent"
},
{
"location": "/xgc/#maxcontractpercent",
"text": "-Xgc:maxContractPercent=<n> Setting Value Default <n> [percentage] - The maximum percentage of the heap that can be contracted at any given time. For example, -Xgc:maxContractPercent=20 causes the heap to contract by as much as 20%.",
"title": "maxContractPercent"
},
{
"location": "/xgc/#overridehirestimercheck",
"text": "-Xgc:overrideHiresTimerCheck When 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. Note: Use this option with caution, and only when you are unable to use a supported operating system.",
"title": "overrideHiresTimerCheck"
},
{
"location": "/xgc/#preferredheapbase",
"text": "(AIX, Linux, Windows only) -Xgc:preferredHeapBase=<address> Setting Value Default <value> [hexadecimal] - where, <address> is the base memory address for the heap. Use this option with the -Xcompressedrefs option to allocate the heap you specify with the -Xmx option, in a memory range of your choice. If -Xcompressedrefs 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. - Xgc : preferredHeapBase = 0x100000000 If the heap cannot be allocated in a contiguous block at the preferredHeapBase address you specified, an error occurs detailing a Garbage Collection (GC) allocation failure startup. When the preferredHeapBase option is used with the -Xlp option, the preferredHeapBase 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.",
"title": "preferredHeapBase"
},
{
"location": "/xgc/#scvnoadaptivetenure",
"text": "-Xgc:scvNoAdaptiveTenure Turns 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 scvTenureAge .",
"title": "scvNoAdaptiveTenure"
},
{
"location": "/xgc/#scvtenureage",
"text": "-Xgc:scvTenureAge=<n> Setting Value Default <n> [1 - 14] 10 Sets the initial scavenger tenure age in the generational concurrent GC policy. For more information, see Tenure age .",
"title": "scvTenureAge"
},
{
"location": "/xgc/#tlhincrementsize",
"text": "-Xgc:tlhIncrementSize=<bytes> Sets 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.",
"title": "tlhIncrementSize"
},
{
"location": "/xgc/#tlhinitialsize",
"text": "-Xgc:tlhInitialSize=<bytes> Sets the initial size of the TLH. The default size is 2 KB.",
"title": "tlhInitialSize"
},
{
"location": "/xgc/#tlhmaximumsize",
"text": "-Xgc:tlhMaximumSize=<bytes> Sets 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 ( -XtlhIncrementSize ) proportionally, so that active threads can reach the maximum requested TLH size more quickly.",
"title": "tlhMaximumSize"
},
{
"location": "/xgc/#verboseformat",
"text": "-Xgc:verboseFormat=<format> Setting Value Default <format> default yes deprecated default : The default verbose garbage collection format for OpenJ9. For more information, see Verbose garbage collection logging . deprecated : The verbose garbage collection format available in the IBM J9 VM V2.4 and earlier.",
"title": "verboseFormat"
},
{
"location": "/xgcsplitheap/",
"text": "-Xgc:splitheap\n\n\n(Windows\u2122 32-bit only)\n\n\nBy default, the VM uses a contiguous Java\u2122 heap to store Java objects. However, on Windows 32-bit systems, there are restrictions in the 32-bit memory space that prevents a process accessing more than 2GB of memory, even if there is more memory available. To increase the maximum allocatable heap size, OpenJ9 can split the heap, allowing memory use up to the 4GB limit.\n\n\n \nRestrictions:\n\n\n\n\nA split heap forces the Garbage Collector to use the \ngencon\n policy and allocates the new and old areas of the generational Java heap in separate areas of memory. Resizing of the new and old memory areas is disabled.\n\n\n This option can be used only with Java SE version 8 runtime environments. \n This option is deprecated in Version 8 and will be removed from future versions.\n\n\n\n\nSyntax\n\n\n -Xgc:splitheap\n\n\n\n\n\nExplanation\n\n\nUse \n-Xgc:splitheap\n for applications that must run on the 32-bit VM because of 32-bit JNI libraries, a 32-bit operating system, or 32-bit hardware, but need large Java heaps. By using a larger heap, you can allocate more objects before incurring a garbage collection and you can increase the number of live objects that you can use before an \nOutOfMemoryError\n exception occurs.\n\n\nWith a split heap, the old area is committed to its maximum size (set with \n-Xmox\n) in a lower region of memory and the new area is committed to its maximum size (set with \n-Xmnx\n) in a higher region of memory.\n\n\nThis option is not recommended if your application works in the any of the following ways:\n\n\n\n\nPerforms poorly under the gencon garbage collection policy.\n\n\nLoads a very large number of classes.\n\n\nUses large amounts of native system memory in JNI libraries; the increased size Java heap might reserve too much of the application's address space.",
"title": "-Xgc:splitheap"
},
{
"location": "/xgcsplitheap/#-xgcsplitheap",
"text": "(Windows\u2122 32-bit only) By default, the VM uses a contiguous Java\u2122 heap to store Java objects. However, on Windows 32-bit systems, there are restrictions in the 32-bit memory space that prevents a process accessing more than 2GB of memory, even if there is more memory available. To increase the maximum allocatable heap size, OpenJ9 can split the heap, allowing memory use up to the 4GB limit. Restrictions: A split heap forces the Garbage Collector to use the gencon policy and allocates the new and old areas of the generational Java heap in separate areas of memory. Resizing of the new and old memory areas is disabled. This option can be used only with Java SE version 8 runtime environments. This option is deprecated in Version 8 and will be removed from future versions.",
"title": "-Xgc:splitheap"
},
{
"location": "/xgcsplitheap/#syntax",
"text": "-Xgc:splitheap",
"title": "Syntax"
},
{
"location": "/xgcsplitheap/#explanation",
"text": "Use -Xgc:splitheap for applications that must run on the 32-bit VM because of 32-bit JNI libraries, a 32-bit operating system, or 32-bit hardware, but need large Java heaps. By using a larger heap, you can allocate more objects before incurring a garbage collection and you can increase the number of live objects that you can use before an OutOfMemoryError exception occurs. With a split heap, the old area is committed to its maximum size (set with -Xmox ) in a lower region of memory and the new area is committed to its maximum size (set with -Xmnx ) in a higher region of memory. This option is not recommended if your application works in the any of the following ways: Performs poorly under the gencon garbage collection policy. Loads a very large number of classes. Uses large amounts of native system memory in JNI libraries; the increased size Java heap might reserve too much of the application's address space.",
"title": "Explanation"
},
{
"location": "/xgcpolicy/",
"text": "-Xgcpolicy\n\n\nControls the behavior of the garbage collector by specifying different garbage collection policies.\n\n\nSyntax\n\n\n -Xgcpolicy:<parameter>\n\n\n\n\n\nParameters\n\n\n\n\n\n\n\n\nParameter\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\nbalanced\n\n\n\n\n\n\n\n\ngencon\n\n\nyes\n\n\n\n\n\n\nmetronome\n (AIX\u00ae, Linux x86 only)\n\n\n\n\n\n\n\n\noptavgpause\n\n\n\n\n\n\n\n\noptthruput\n\n\n\n\n\n\n\n\n\n\nSpecify the garbage collection policy that you want the OpenJ9 VM to use:\n\n\nbalanced\n\n\n -Xgcpolicy:balanced\n\n\n\n\n\n\n\nThe balanced policy policy uses mark, sweep, compact and generational style garbage collection. The concurrent mark phase is disabled; concurrent garbage collection technology is used, but not in the way that concurrent mark is implemented for other policies. The \nbalanced\n policy uses a region-based layout for the Java\u2122 heap. These regions are individually managed to reduce the maximum pause time on large heaps and increase the efficiency of garbage collection. The policy tries to avoid global collections by matching object allocation and survival rates.\n\n\n\n\nIf 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.\n\n\nFor more information about this policy, including when to use it, see \nBalanced Garbage Collection policy\n.\n\n\n\n\n\n\nDefaults and options\n\n\nThe initial heap size is \nXmx/1024\n, rounded down to the nearest power of 2, where \nXmx\n is the maximum heap size available. You can override this value by specifying the \n-Xms\n option on the command line.\n\n\nThe following options can also be specified on the command line with \n-Xgcpolicy:balanced\n:\n\n\n\n\n-Xalwaysclassgc\n\n\n-Xclassgc\n\n\n-Xcompactexplicitgc\n\n\n-Xdisableexcessivegc\n\n\n-Xdisableexplicitgc\n\n\n-Xenableexcessivegc\n\n\n-Xgcthreads<number>\n\n\n-Xgcworkpackets<number>\n\n\n-Xmaxe<size>\n\n\n-Xmaxf<percentage>\n\n\n-Xmaxt<percentage>\n\n\n-Xmca<size>\n\n\n-Xmco<size>\n\n\n-Xmine<size>\n\n\n-Xminf<percentage>\n\n\n-Xmint<percentage>\n\n\n-Xmn<size>\n\n\n-Xmns<size>\n\n\n-Xmnx<size>\n\n\n-Xms<size>\n\n\n-Xmx<size>\n\n\n-Xnoclassgc\n\n\n-Xnocompactexplicitgc\n\n\n-Xnuma:none\n\n\n-Xsoftmx<size>\n\n\n-Xsoftrefthreshold<number>\n\n\n-Xverbosegclog[:<file> [, <X>,<Y>]]\n\n\n\n\nThe behavior of the following options is different when specified with \n-Xgcpolicy:balanced\n:\n\n\n\n\n-Xcompactgc\n\n\nCompaction occurs when a System.gc() call is received (default). Compaction always occurs on all other collection types.\n\n\n-Xnocompactgc\n\n\nCompaction does not occur when a System.gc() call is received. Compaction always occurs on all other collection types.\n\n\n\n\nThe following options are ignored when specified with \n-Xgcpolicy:balanced\n:\n\n\n\n\n-Xconcurrentbackground<number>\n\n\n-Xconcurrentlevel<number>\n\n\n-Xconcurrentslack<size>\n\n\n-Xconmeter:<soa | loa | dynamic>\n\n\n-Xdisablestringconstantgc\n\n\n-Xenablestringconstantgc\n\n\n-Xloa\n\n\n-Xloainitial<percentage>\n\n\n-Xloamaximum<percentage>\n\n\n-Xloaminimum<percentage>\n\n\n-Xmo<size>\n\n\n-Xmoi<size>\n\n\n-Xmos<size>\n\n\n-Xmr<size>\n\n\n-Xmrx<size>\n\n\n-Xnoloa\n\n\n-Xnopartialcompactgc\n (deprecated)\n\n\n-Xpartialcompactgc\n (deprecated)\n\n\n\n\ngencon\n\n\n -Xgcpolicy:gencon\n\n\n\n\n\n\n\nThe generational concurrent policy (default) uses a concurrent mark phase combined with generational garbage collection to help minimize the time that is spent in any garbage collection pause. This policy is particularly useful for applications with many short-lived objects, such as transactional applications. Pause times can be significantly shorter than with the \noptthruput\n policy, while still producing good throughput. Heap fragmentation is also reduced.\n\n\n\n\nmetronome\n (AIX\u00ae, Linux\u2122 only)\n\n\n -Xgcpolicy:metronome\n\n\n\n\n\n\n\n\n\nThe metronome policy 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 garbage collection activity. The metronome policy is supported on specific hardware and operating system configurations.\n\n\nFor more information, see \nUsing the Metronome Garbage Collector\n.\n\n\n\n\n\n\nDefaults and options\n\n\n\n\n-Xgc:synchronousGCOnOOM | -Xgc:nosynchronousGCOnOOM\n\n\nOne occasion when garbage collection occurs is when the heap runs out of memory. If there is no more free space in the heap, using \n-Xgc:synchronousGCOnOOM\n stops your application while garbage collection removes unused objects. If free space runs out again, consider decreasing the target utilization to allow garbage collection more time to complete. Setting \n-Xgc:nosynchronousGCOnOOM\n implies that when heap memory is full your application stops and issues an out-of-memory message. The default is \n-Xgc:synchronousGCOnOOM\n.\n\n\n-Xnoclassgc\n\n\nDisables class garbage collection. This option switches off garbage collection of storage associated with Java classes that are no longer being used by the OpenJ9 VM. The default behavior is -Xnoclassgc.\n\n\n-Xgc:targetPauseTime=N\n\n\nSets the garbage collection pause time, where N is the time in milliseconds. When this option is specified, the GC operates with pauses that do not exceed the value specified. If this option is not specified the default pause time is set to 3 milliseconds. For example, running with \n-Xgc:targetPauseTime=20\n causes the GC to pause for no longer than 20 milliseconds during GC operations.\n\n\n-Xgc:targetUtilization=N\n\n\n\n\nSets the application utilization to \nN%\n; the Garbage Collector attempts to use at most (100-N)% of each time interval. Reasonable values are in the range of 50-80%. Applications with low allocation rates might be able to run at 90%. The default is 70%.\n\n\nThis example shows the maximum size of the heap memory is 30 MB. The garbage collector attempts to use 25% of each time interval because the target utilization for the application is 75%.\n\n\njava -Xgcpolicy:metronome -Xmx30m -Xgc:targetUtilization=75 Test\n\n\n\n\n-Xgc:threads=N\n\n\nSpecifies the number of GC threads to run. The default is the number of processor cores available to the process. The maximum value you can specify is the number of processors available to the operating system.\n\n\n-Xgc:verboseGCCycleTime=N\n\n\n\n\nN is the time in milliseconds that the summary information should be dumped.\n\n\n \nNote:\n The cycle time does not mean that the summary information is dumped precisely at that time, but when the last garbage collection event that meets this time criterion passes.\n\n\n\n\n-Xmx<size>\n\n\nSpecifies the Java heap size. Unlike other garbage collection strategies, the real-time Metronome GC does not support heap expansion. There is not an initial or maximum heap size option. You can specify only the maximum heap size.\n\n\n\n\nnogc\n\n\n -Xgcpolicy:nogc\n\n\n\n\n\n\n\nWhen this policy is enabled, the Java object heap is expanded in the normal way until the limit is reached, but memory is not reclaimed through garbage collection. This policy can be useful for test\npurposes and for short-lived applications. When the limit is reached an \nOutOfMemory\n error is generated and the VM shuts down. This policy can also be enabled with the \n-XX:+UseNoGC\n option.\n\n\n\n\noptavgpause\n\n\n -Xgcpolicy:optavgpause\n\n\n\n\n\n\n\nThe \"optimize for pause time\" policy uses concurrent mark and concurrent sweep phases. Pause times are shorter than with \noptthruput\n, but application throughput is reduced because some garbage collection work is taking place while the application is running. 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 garbage collection pause. However, if your application uses many short-lived objects, the \ngencon\n policy might produce better performance.\n\n\n\n\noptthruput\n\n\n -Xgcpolicy:optthruput\n\n\n\n\n\n\n\nThe \"optimize for throughput\" policy disables the concurrent mark phase. The application stops during global garbage collection, so long pauses can occur. This configuration is typically used for large-heap applications when high application throughput, rather than short garbage collection pauses, is the main performance goal. If your application cannot tolerate long garbage collection pauses, consider using another policy, such as \ngencon\n.",
"title": "-Xgcpolicy"
},
{
"location": "/xgcpolicy/#-xgcpolicy",
"text": "Controls the behavior of the garbage collector by specifying different garbage collection policies.",
"title": "-Xgcpolicy"
},
{
"location": "/xgcpolicy/#syntax",
"text": "-Xgcpolicy:<parameter>",
"title": "Syntax"
},
{
"location": "/xgcpolicy/#parameters",
"text": "Parameter Default balanced gencon yes metronome (AIX\u00ae, Linux x86 only) optavgpause optthruput Specify the garbage collection policy that you want the OpenJ9 VM to use:",
"title": "Parameters"
},
{
"location": "/xgcpolicy/#balanced",
"text": "-Xgcpolicy:balanced The balanced policy policy uses mark, sweep, compact and generational style garbage collection. The concurrent mark phase is disabled; concurrent garbage collection technology is used, but not in the way that concurrent mark is implemented for other policies. The balanced policy uses a region-based layout for the Java\u2122 heap. These regions are individually managed to reduce the maximum pause time on large heaps and increase the efficiency of garbage collection. The policy tries 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. 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. For more information about this policy, including when to use it, see Balanced Garbage Collection policy .",
"title": "balanced"
},
{
"location": "/xgcpolicy/#defaults-and-options",
"text": "The initial heap size is Xmx/1024 , rounded down to the nearest power of 2, where Xmx is the maximum heap size available. You can override this value by specifying the -Xms option on the command line. The following options can also be specified on the command line with -Xgcpolicy:balanced : -Xalwaysclassgc -Xclassgc -Xcompactexplicitgc -Xdisableexcessivegc -Xdisableexplicitgc -Xenableexcessivegc -Xgcthreads<number> -Xgcworkpackets<number> -Xmaxe<size> -Xmaxf<percentage> -Xmaxt<percentage> -Xmca<size> -Xmco<size> -Xmine<size> -Xminf<percentage> -Xmint<percentage> -Xmn<size> -Xmns<size> -Xmnx<size> -Xms<size> -Xmx<size> -Xnoclassgc -Xnocompactexplicitgc -Xnuma:none -Xsoftmx<size> -Xsoftrefthreshold<number> -Xverbosegclog[:<file> [, <X>,<Y>]] The behavior of the following options is different when specified with -Xgcpolicy:balanced : -Xcompactgc Compaction occurs when a System.gc() call is received (default). Compaction always occurs on all other collection types. -Xnocompactgc Compaction does not occur when a System.gc() call is received. Compaction always occurs on all other collection types. The following options are ignored when specified with -Xgcpolicy:balanced : -Xconcurrentbackground<number> -Xconcurrentlevel<number> -Xconcurrentslack<size> -Xconmeter:<soa | loa | dynamic> -Xdisablestringconstantgc -Xenablestringconstantgc -Xloa -Xloainitial<percentage> -Xloamaximum<percentage> -Xloaminimum<percentage> -Xmo<size> -Xmoi<size> -Xmos<size> -Xmr<size> -Xmrx<size> -Xnoloa -Xnopartialcompactgc (deprecated) -Xpartialcompactgc (deprecated)",
"title": "Defaults and options"
},
{
"location": "/xgcpolicy/#gencon",
"text": "-Xgcpolicy:gencon The generational concurrent policy (default) uses a concurrent mark phase combined with generational garbage collection to help minimize the time that is spent in any garbage collection pause. This policy is particularly useful for applications with many short-lived objects, such as transactional applications. Pause times can be significantly shorter than with the optthruput policy, while still producing good throughput. Heap fragmentation is also reduced.",
"title": "gencon"
},
{
"location": "/xgcpolicy/#metronome-aix-linux-only",
"text": "-Xgcpolicy:metronome The metronome policy 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 garbage collection activity. The metronome policy is supported on specific hardware and operating system configurations. For more information, see Using the Metronome Garbage Collector .",
"title": "metronome (AIX&reg;, Linux&trade; only)"
},
{
"location": "/xgcpolicy/#defaults-and-options_1",
"text": "-Xgc:synchronousGCOnOOM | -Xgc:nosynchronousGCOnOOM One occasion when garbage collection occurs is when the heap runs out of memory. If there is no more free space in the heap, using -Xgc:synchronousGCOnOOM stops your application while garbage collection removes unused objects. If free space runs out again, consider decreasing the target utilization to allow garbage collection more time to complete. Setting -Xgc:nosynchronousGCOnOOM implies that when heap memory is full your application stops and issues an out-of-memory message. The default is -Xgc:synchronousGCOnOOM . -Xnoclassgc Disables class garbage collection. This option switches off garbage collection of storage associated with Java classes that are no longer being used by the OpenJ9 VM. The default behavior is -Xnoclassgc. -Xgc:targetPauseTime=N Sets the garbage collection pause time, where N is the time in milliseconds. When this option is specified, the GC operates with pauses that do not exceed the value specified. If this option is not specified the default pause time is set to 3 milliseconds. For example, running with -Xgc:targetPauseTime=20 causes the GC to pause for no longer than 20 milliseconds during GC operations. -Xgc:targetUtilization=N Sets the application utilization to N% ; the Garbage Collector attempts to use at most (100-N)% of each time interval. Reasonable values are in the range of 50-80%. Applications with low allocation rates might be able to run at 90%. The default is 70%. This example shows the maximum size of the heap memory is 30 MB. The garbage collector attempts to use 25% of each time interval because the target utilization for the application is 75%. java -Xgcpolicy:metronome -Xmx30m -Xgc:targetUtilization=75 Test -Xgc:threads=N Specifies the number of GC threads to run. The default is the number of processor cores available to the process. The maximum value you can specify is the number of processors available to the operating system. -Xgc:verboseGCCycleTime=N N is the time in milliseconds that the summary information should be dumped. Note: The cycle time does not mean that the summary information is dumped precisely at that time, but when the last garbage collection event that meets this time criterion passes. -Xmx<size> Specifies the Java heap size. Unlike other garbage collection strategies, the real-time Metronome GC does not support heap expansion. There is not an initial or maximum heap size option. You can specify only the maximum heap size.",
"title": "Defaults and options"
},
{
"location": "/xgcpolicy/#nogc",
"text": "-Xgcpolicy:nogc When this policy is enabled, the Java object heap is expanded in the normal way until the limit is reached, but memory is not reclaimed through garbage collection. This policy can be useful for test\npurposes and for short-lived applications. When the limit is reached an OutOfMemory error is generated and the VM shuts down. This policy can also be enabled with the -XX:+UseNoGC option.",
"title": "nogc"
},
{
"location": "/xgcpolicy/#optavgpause",
"text": "-Xgcpolicy:optavgpause The \"optimize for pause time\" policy uses concurrent mark and concurrent sweep phases. Pause times are shorter than with optthruput , but application throughput is reduced because some garbage collection work is taking place while the application is running. 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 garbage collection pause. However, if your application uses many short-lived objects, the gencon policy might produce better performance.",
"title": "optavgpause"
},
{
"location": "/xgcpolicy/#optthruput",
"text": "-Xgcpolicy:optthruput The \"optimize for throughput\" policy disables the concurrent mark phase. The application stops during global garbage collection, so long pauses can occur. This configuration is typically used for large-heap applications when high application throughput, rather than short garbage collection pauses, is the main performance goal. If your application cannot tolerate long garbage collection pauses, consider using another policy, such as gencon .",
"title": "optthruput"
},
{
"location": "/xgcthreads/",
"text": "-Xgcthreads\n\n\nSets the number of threads that the Garbage Collector uses for parallel operations.\n\n\nSyntax\n\n\n -Xgcthreads<number>\n\n\n\n\n\nExplanation\n\n\nThe total number of GC threads is composed of one application thread with the remainder being dedicated GC threads. By default, the number is set to \nn-1\n, where \nn\n is the number of reported CPUs, up to a maximum of 64. Where SMT or hyperthreading is in place, the number of reported CPUs is larger than the number of physical CPUs. Likewise, where virtualization is in place, the number of reported CPUs is the number of virtual CPUs assigned to the operating system. To set it to a different number, for example 4, use \n-Xgcthreads4\n. The minimum valid value is 1, which disables parallel operations, at the cost of performance. No advantage is gained if you increase the number of threads to more than the default setting.\n\n\nOn systems running multiple VMs or in LPAR environments where multiple VMs can share the same physical CPUs, you might want to restrict the number of GC threads used by each VM. The restriction helps prevent the total number of parallel operation GC threads for all VMs exceeding the number of physical CPUs present, when multiple VMs perform garbage collection at the same time.",
"title": "-Xgcthreads"
},
{
"location": "/xgcthreads/#-xgcthreads",
"text": "Sets the number of threads that the Garbage Collector uses for parallel operations.",
"title": "-Xgcthreads"
},
{
"location": "/xgcthreads/#syntax",
"text": "-Xgcthreads<number>",
"title": "Syntax"
},
{
"location": "/xgcthreads/#explanation",
"text": "The total number of GC threads is composed of one application thread with the remainder being dedicated GC threads. By default, the number is set to n-1 , where n is the number of reported CPUs, up to a maximum of 64. Where SMT or hyperthreading is in place, the number of reported CPUs is larger than the number of physical CPUs. Likewise, where virtualization is in place, the number of reported CPUs is the number of virtual CPUs assigned to the operating system. To set it to a different number, for example 4, use -Xgcthreads4 . The minimum valid value is 1, which disables parallel operations, at the cost of performance. No advantage is gained if you increase the number of threads to more than the default setting. On systems running multiple VMs or in LPAR environments where multiple VMs can share the same physical CPUs, you might want to restrict the number of GC threads used by each VM. The restriction helps prevent the total number of parallel operation GC threads for all VMs exceeding the number of physical CPUs present, when multiple VMs perform garbage collection at the same time.",
"title": "Explanation"
},
{
"location": "/xgcworkpackets/",
"text": "-Xgcworkpackets\n\n\nSpecifies the total number of work packets available in the global collector.\n\n\nSyntax\n\n\n -Xgcworkpackets<number>\n\n\n\n\n\nExplanation\n\n\nIf you do not specify a value, the collector allocates a number of packets based on the maximum heap size.",
"title": "-Xgcworkpackets"
},
{
"location": "/xgcworkpackets/#-xgcworkpackets",
"text": "Specifies the total number of work packets available in the global collector.",
"title": "-Xgcworkpackets"
},
{
"location": "/xgcworkpackets/#syntax",
"text": "-Xgcworkpackets<number>",
"title": "Syntax"
},
{
"location": "/xgcworkpackets/#explanation",
"text": "If you do not specify a value, the collector allocates a number of packets based on the maximum heap size.",
"title": "Explanation"
},
{
"location": "/xifa/",
"text": "-Xifa\n\n\n(z/OS\u00ae only)\n\n\nEnables Java\u2122 applications to run on IFAs if they are available.\n\n\nz/OS V1R6 or later can run Java applications on a special-purpose assist processor called the System z\u2122 Application Assist Processor (zAAP). zAAPs operate asynchronously with the general purpose processors to execute Java programming under control of the VM. The zAAP is also known as an IFA (Integrated Facility for Applications).\n\n\nOnly Java code and system native methods can be on IFA processors.\n\n\nSyntax\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-Xifa:<value>\n\n\non\n\n\nyes\n\n\n\n\n\n\n\n\noff\n\n\n\n\n\n\n\n\n\n\nforce\n (obsolete)\n\n\n\n\n\n\n\n\n\n\n \nNote:\n The \nforce\n option is obsolete and should not normally be used. This option is superseded by the \nSYS1.PARMLIB(IEAOPTxx) PROJECTCPU=YES\n parameter, which is available on all supported levels of z/OS. \nXifa:force\n can be used for testing purposes when a zAAP is not available, but can have a negative performance impact.",
"title": "-Xifa"
},
{
"location": "/xifa/#-xifa",
"text": "(z/OS\u00ae only) Enables Java\u2122 applications to run on IFAs if they are available. z/OS V1R6 or later can run Java applications on a special-purpose assist processor called the System z\u2122 Application Assist Processor (zAAP). zAAPs operate asynchronously with the general purpose processors to execute Java programming under control of the VM. The zAAP is also known as an IFA (Integrated Facility for Applications). Only Java code and system native methods can be on IFA processors.",
"title": "-Xifa"
},
{
"location": "/xifa/#syntax",
"text": "Setting Value Default -Xifa:<value> on yes off force (obsolete) Note: The force option is obsolete and should not normally be used. This option is superseded by the SYS1.PARMLIB(IEAOPTxx) PROJECTCPU=YES parameter, which is available on all supported levels of z/OS. Xifa:force can be used for testing purposes when a zAAP is not available, but can have a negative performance impact.",
"title": "Syntax"
},
{
"location": "/xint/",
"text": "-Xint\n\n\nAs described in the \nOracle \"Non-Standard Options\" documentation\n, this VM option runs an application in interpreted-only mode. For compatibility, this option is also supported by the OpenJ9 VM.\n\n\nSyntax\n\n\n -Xint\n\n\n\n\n\nExplanation\n\n\nIf you use this option, the OpenJ9 VM uses only the interpreter, disabling the OpenJ9 just-in-time (JIT) and ahead-of-time (AOT) compilers. By default, both these compilers are enabled, although the AOT compiler is not used by the VM unless \nshared classes\n are also enabled.",
"title": "-Xint"
},
{
"location": "/xint/#-xint",
"text": "As described in the Oracle \"Non-Standard Options\" documentation , this VM option runs an application in interpreted-only mode. For compatibility, this option is also supported by the OpenJ9 VM.",
"title": "-Xint"
},
{
"location": "/xint/#syntax",
"text": "-Xint",
"title": "Syntax"
},
{
"location": "/xint/#explanation",
"text": "If you use this option, the OpenJ9 VM uses only the interpreter, disabling the OpenJ9 just-in-time (JIT) and ahead-of-time (AOT) compilers. By default, both these compilers are enabled, although the AOT compiler is not used by the VM unless shared classes are also enabled.",
"title": "Explanation"
},
{
"location": "/xss/",
"text": "-Xiss / -Xss / -Xssi\n\n\nDetermines the size and behavior of the stack size for Java\u2122 threads. \n\n\nTo increase the maximum number of threads your system can support, reduce the maximum native stack size.\n\n\nIf you exceed the maximum Java thread stack size, a \njava/lang/OutOfMemoryError\n message is reported.\n\n\nYou can use the \n-verbose:sizes\n option to find out the values that the VM is currently using.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xiss<size>\n\n\nSet initial Java thread stack size\n\n\n2 KB\n\n\n\n\n\n\n-Xss<size>\n\n\nSet maximum Java thread stack size\n\n\n320 KB (31/32-bit); 1024 KB (64-bit)\n\n\n\n\n\n\n-Xssi<size>\n\n\nSet Java thread stack size increment\n\n\n16 KB\n\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter. \n\n\nSee \nDefault settings for the OpenJ9 VM\n for more about default values.\n\n\nSee also\n\n\n\n\n-Xmso\n (Initial stack size for operating system threads)",
"title": "-Xiss"
},
{
"location": "/xss/#-xiss-xss-xssi",
"text": "Determines the size and behavior of the stack size for Java\u2122 threads. To increase the maximum number of threads your system can support, reduce the maximum native stack size. If you exceed the maximum Java thread stack size, a java/lang/OutOfMemoryError message is reported. You can use the -verbose:sizes option to find out the values that the VM is currently using.",
"title": "-Xiss / -Xss / -Xssi"
},
{
"location": "/xss/#syntax",
"text": "Setting Effect Default -Xiss<size> Set initial Java thread stack size 2 KB -Xss<size> Set maximum Java thread stack size 320 KB (31/32-bit); 1024 KB (64-bit) -Xssi<size> Set Java thread stack size increment 16 KB See Using -X command-line options for more information about the <size> parameter. See Default settings for the OpenJ9 VM for more about default values.",
"title": "Syntax"
},
{
"location": "/xss/#see-also",
"text": "-Xmso (Initial stack size for operating system threads)",
"title": "See also"
},
{
"location": "/xjit/",
"text": "-Xjit / -Xnojit\n\n\nUse this option to control the behavior of the JIT compiler.\n\n\nSpecifying \n-Xjit\n with no parameters, has no effect as the JIT compiler is enabled by default.\n\n\n-Xnojit\n turns off the JIT compiler but does not affect the AOT compiler.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nAction\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xjit\n\n\nEnable JIT\n\n\nyes\n\n\n\n\n\n\n-Xjit[:<parameter>=<value>{,<parameter>=<value>}]\n\n\nEnable JIT with options\n\n\n\n\n\n\n\n\n-Xnojit\n\n\nDisable JIT\n\n\n\n\n\n\n\n\n\n\nParameters\n\n\nThese parameters can be used to modify the behavior of \n-Xjit\n:\n\n\n\n\n\n\n\n\nParameter\n\n\nEffect\n\n\n\n\n\n\n\n\n\n\ncount\n \n\n\nForces compilation of methods on first invocation.\n\n\n\n\n\n\ndisableRMODE64\n\n\nAllows the JIT to allocate executable code caches above the 2 GB memory bar.\n\n\n\n\n\n\nexclude\n \n\n\nExcludes the specified method from compilation.\n\n\n\n\n\n\n<limitFile>\n \n\n\nCompile methods that are listed in the limit file.\n\n\n\n\n\n\noptlevel\n \n\n\nForces the JIT compiler to compile all methods at a specific optimization level.\n\n\n\n\n\n\nverbose\n \n\n\nReports information about the JIT and AOT compiler configuration and method compilation.\n\n\n\n\n\n\nvlog\n \n\n\nSends verbose output to a file.\n\n\n\n\n\n\n\n\ncount\n\n\n -Xjit:count=<n>\n\n\n\n\n\n\n\nwhere \n<n>\n is the number of times a method is called before it is compiled. For example, setting \ncount=0\n forces the JIT compiler to compile everything on first execution, which is useful for problem determination.\n\n\n\n\ndisableRMODE64\n\n\n(z/OS\u00ae only)\n\n\n -Xjit:disableRMODE64\n\n\n\n\n\n\n\nFrom z/OS V2R3, residency mode for 64-bit applications (RMODE64) is enabled by default. This feature allows the JIT to allocate executable code caches above the 2 GB memory bar, which is the default behavior. Use this option to turn off this JIT behavior.\n\n\n\n\nexclude\n\n\n -Xjit:exclude=<method>\n\n\n\n\n\n\n\nExcludes the specified method from compilation.\n\n\n\n\nlimitFile\n\n\n -Xjit:limitFile=(<vlog_filename>, <m>, <n>)\n\n\n\n\n\n\n\nCompile only the methods that are listed on lines \n<m>\n to \n<n>\n in the specified limit file, where the limit file is a verbose log that you generated with the \n-Xjit:verbose,vlog=<vlog_filename>\n option. Methods that are not listed in the limit file and methods that are listed on lines outside the range are not compiled.\n\n\n\n\noptlevel\n\n\n -Xjit:optlevel=[noOpt|cold|warm|hot|veryHot|scorching]\n\n\n\n\n\n\n\nForces the JIT compiler to compile all methods at a specific optimization level. Specifying \noptlevel\n might have an unexpected effect on performance, including reduced overall performance.\n\n\n\n\nverbose\n\n\n -Xjit:verbose\n\n\n\n\n\n\n\nGenerates a JIT verbose log. The log provides a summary of which methods were compiled by the JIT and some of the compilation heurisic decisions that were taken while the JIT operates inside the OpenJ9 VM.\n-Xjit:verbose={compileStart}\n\n\n\n\n\n\n\n\n\nPrints out a line when the JIT is about to start compiling a method.\n\n\n-Xjit:verbose={compileEnd}\n\n\n\n\n\n\n\n\n\nPrints out a line when the JIT stops compiling a method.\n\n\n-Xjit:verbose={compilePerformance}\n\n\n\n\n\n\n\n\n\nAdds the values \ntime\n (time taken to do the compilation) and \nmem\n (the amount of memory that was allocated during the compilation) into each line. This option includes the \ncompileStart\n and \ncompileEnd\n suboptions by default.\n\n\n-Xjit:verbose={disableInlining}\n\n\n\n\n\n\n\n\n\nTurns off inlining operations.\n\n\n-Xjit:verbose={inlining}\n\n\n\n\n\n\n\n\n\nShows the methods that are inlined.\n\n\n\n\n\n\n \nNote:\n Suboptions can be chained together by using a \n|\n character. When used, you must enclose the full option name in single quotes (') to avoid the shell misinterpreting these characters as pipe commands. For example:\n\n\njava '-Xjit:verbose={compileStart|compileEnd|inlining}' -version\n\n\n\n\n\nvlog\n\n\n -Xjit:vlog=<vlog_filename>\n\n\n\n\n\n\n\nSends verbose output to a file, of the format \n<vlog_filename>.<date>.<time>.<JVM_process_ID>\n, which is created in your current directory. Running the command multiple times produces multiple distinct versions of this file. If you do not specify this parameter, the output is sent to the standard error output stream (STDERR). This type of log file can be used with the \nlimitFile\n suboption to target the compilation of specific methods.\n\n\n\n\nExamples\n\n\nGenerating a JIT verbose log\n\n\nThe following example requests a JIT verbose log of the \njava -version\n command:\n\n\njava -Xjit:verbose,vlog=vlogfile -version\n\n\n\n\n\nAnalyzing JIT performance\n\n\nThe following example requests information about the performance of JIT compiler threads, with output written to \nvlogfile\n.\n\n\njava -Xjit:verbose={compilePerformance},vlog=vlogfile -version\n\n\n\n\n\nThe output generated by using this command adds the following information to compilation entry:\n\n\n\n\nthe amount of time taken to do the compilation.\n\n\nthe amount of memory that was allocated during the compilation.\n\n\n\n\nAnalyzing inlining operations\n\n\nThe following example generates output that contains performance data and inlining operations. The suboptions \ncount\n and \n-XcompilationThreads1\n are used only to simplify the output. These options are not recommended for production because performance will be affected.\n\n\njava '-Xjit:verbose={compileStart|compileEnd|inlining},count=5,vlog=vlogfile' -XcompilationThreads1 -version\n\n\n\n\n\n\n\n\nSee also\n\n\n\n\nDiagnosing a JIT or AOT problem",
"title": "-Xjit"
},
{
"location": "/xjit/#-xjit-xnojit",
"text": "Use this option to control the behavior of the JIT compiler. Specifying -Xjit with no parameters, has no effect as the JIT compiler is enabled by default. -Xnojit turns off the JIT compiler but does not affect the AOT compiler.",
"title": "-Xjit / -Xnojit"
},
{
"location": "/xjit/#syntax",
"text": "Setting Action Default -Xjit Enable JIT yes -Xjit[:<parameter>=<value>{,<parameter>=<value>}] Enable JIT with options -Xnojit Disable JIT",
"title": "Syntax"
},
{
"location": "/xjit/#parameters",
"text": "These parameters can be used to modify the behavior of -Xjit : Parameter Effect count Forces compilation of methods on first invocation. disableRMODE64 Allows the JIT to allocate executable code caches above the 2 GB memory bar. exclude Excludes the specified method from compilation. <limitFile> Compile methods that are listed in the limit file. optlevel Forces the JIT compiler to compile all methods at a specific optimization level. verbose Reports information about the JIT and AOT compiler configuration and method compilation. vlog Sends verbose output to a file.",
"title": "Parameters"
},
{
"location": "/xjit/#count",
"text": "-Xjit:count=<n> where <n> is the number of times a method is called before it is compiled. For example, setting count=0 forces the JIT compiler to compile everything on first execution, which is useful for problem determination.",
"title": "count"
},
{
"location": "/xjit/#disablermode64",
"text": "(z/OS\u00ae only) -Xjit:disableRMODE64 From z/OS V2R3, residency mode for 64-bit applications (RMODE64) is enabled by default. This feature allows the JIT to allocate executable code caches above the 2 GB memory bar, which is the default behavior. Use this option to turn off this JIT behavior.",
"title": "disableRMODE64"
},
{
"location": "/xjit/#exclude",
"text": "-Xjit:exclude=<method> Excludes the specified method from compilation.",
"title": "exclude"
},
{
"location": "/xjit/#limitfile",
"text": "-Xjit:limitFile=(<vlog_filename>, <m>, <n>) Compile only the methods that are listed on lines <m> to <n> in the specified limit file, where the limit file is a verbose log that you generated with the -Xjit:verbose,vlog=<vlog_filename> option. Methods that are not listed in the limit file and methods that are listed on lines outside the range are not compiled.",
"title": "limitFile"
},
{
"location": "/xjit/#optlevel",
"text": "-Xjit:optlevel=[noOpt|cold|warm|hot|veryHot|scorching] Forces the JIT compiler to compile all methods at a specific optimization level. Specifying optlevel might have an unexpected effect on performance, including reduced overall performance.",
"title": "optlevel"
},
{
"location": "/xjit/#verbose",
"text": "-Xjit:verbose Generates a JIT verbose log. The log provides a summary of which methods were compiled by the JIT and some of the compilation heurisic decisions that were taken while the JIT operates inside the OpenJ9 VM. -Xjit:verbose={compileStart} Prints out a line when the JIT is about to start compiling a method. -Xjit:verbose={compileEnd} Prints out a line when the JIT stops compiling a method. -Xjit:verbose={compilePerformance} Adds the values time (time taken to do the compilation) and mem (the amount of memory that was allocated during the compilation) into each line. This option includes the compileStart and compileEnd suboptions by default. -Xjit:verbose={disableInlining} Turns off inlining operations. -Xjit:verbose={inlining} Shows the methods that are inlined. Note: Suboptions can be chained together by using a | character. When used, you must enclose the full option name in single quotes (') to avoid the shell misinterpreting these characters as pipe commands. For example: java '-Xjit:verbose={compileStart|compileEnd|inlining}' -version",
"title": "verbose"
},
{
"location": "/xjit/#vlog",
"text": "-Xjit:vlog=<vlog_filename> Sends verbose output to a file, of the format <vlog_filename>.<date>.<time>.<JVM_process_ID> , which is created in your current directory. Running the command multiple times produces multiple distinct versions of this file. If you do not specify this parameter, the output is sent to the standard error output stream (STDERR). This type of log file can be used with the limitFile suboption to target the compilation of specific methods.",
"title": "vlog"
},
{
"location": "/xjit/#examples",
"text": "",
"title": "Examples"
},
{
"location": "/xjit/#generating-a-jit-verbose-log",
"text": "The following example requests a JIT verbose log of the java -version command: java -Xjit:verbose,vlog=vlogfile -version",
"title": "Generating a JIT verbose log"
},
{
"location": "/xjit/#analyzing-jit-performance",
"text": "The following example requests information about the performance of JIT compiler threads, with output written to vlogfile . java -Xjit:verbose={compilePerformance},vlog=vlogfile -version The output generated by using this command adds the following information to compilation entry: the amount of time taken to do the compilation. the amount of memory that was allocated during the compilation.",
"title": "Analyzing JIT performance"
},
{
"location": "/xjit/#analyzing-inlining-operations",
"text": "The following example generates output that contains performance data and inlining operations. The suboptions count and -XcompilationThreads1 are used only to simplify the output. These options are not recommended for production because performance will be affected. java '-Xjit:verbose={compileStart|compileEnd|inlining},count=5,vlog=vlogfile' -XcompilationThreads1 -version",
"title": "Analyzing inlining operations"
},
{
"location": "/xjit/#see-also",
"text": "Diagnosing a JIT or AOT problem",
"title": "See also"
},
{
"location": "/xjni/",
"text": "-Xjni\n\n\nSets JNI options.\n\n\nSyntax\n\n\n -Xjni:<parameter>\n\n\n\n\n\nParameters\n\n\narrayCacheMax\n\n\n -Xjni:arrayCacheMax=<size in bytes>\n -Xjni:arrayCacheMax=unlimited\n\n\n\n\n\n\n\nSets the maximum size of the array cache. The default size is 128 KB (\n-Xjni:arrayCacheMax=131072\n).",
"title": "-Xjni"
},
{
"location": "/xjni/#-xjni",
"text": "Sets JNI options.",
"title": "-Xjni"
},
{
"location": "/xjni/#syntax",
"text": "-Xjni:<parameter>",
"title": "Syntax"
},
{
"location": "/xjni/#parameters",
"text": "",
"title": "Parameters"
},
{
"location": "/xjni/#arraycachemax",
"text": "-Xjni:arrayCacheMax=<size in bytes>\n -Xjni:arrayCacheMax=unlimited Sets the maximum size of the array cache. The default size is 128 KB ( -Xjni:arrayCacheMax=131072 ).",
"title": "arrayCacheMax"
},
{
"location": "/xlinenumbers/",
"text": "-Xlinenumbers / -Xnolinenumbers\n\n\nEnables or disables line numbers in stack traces for debugging.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xlinenumbers\n\n\nEnable\n\n\nyes\n\n\n\n\n\n\n-Xnolinenumbers\n\n\nDisable\n\n\n\n\n\n\n\n\n\n\nExplanation\n\n\nIf you start the OpenJ9 VM with \n-Xnolinenumbers\n when creating a new shared classes cache, the Class Debug Area is not created. The option \n-Xnolinenumbers\n advises the VM not to load any class debug information, so there is no need for this region. If \n-Xscdmx\n is also used on the command line to specify a non zero debug area size, then a debug area is created despite the use of \n-Xnolinenumbers\n.",
"title": "-Xlinenumbers"
},
{
"location": "/xlinenumbers/#-xlinenumbers-xnolinenumbers",
"text": "Enables or disables line numbers in stack traces for debugging.",
"title": "-Xlinenumbers / -Xnolinenumbers"
},
{
"location": "/xlinenumbers/#syntax",
"text": "Setting Effect Default -Xlinenumbers Enable yes -Xnolinenumbers Disable",
"title": "Syntax"
},
{
"location": "/xlinenumbers/#explanation",
"text": "If you start the OpenJ9 VM with -Xnolinenumbers when creating a new shared classes cache, the Class Debug Area is not created. The option -Xnolinenumbers advises the VM not to load any class debug information, so there is no need for this region. If -Xscdmx is also used on the command line to specify a non zero debug area size, then a debug area is created despite the use of -Xnolinenumbers .",
"title": "Explanation"
},
{
"location": "/xloa/",
"text": "-Xloa / -Xnoloa\n\n\nThis option enables or prevents allocation of a large object area (LOA) during garbage collection.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xloa\n\n\nEnable LOA\n\n\nyes\n (see \nDefault behavior)\n\n\n\n\n\n\n-Xnoloa\n\n\nDisable LOA\n\n\n\n\n\n\n\n\n\n\nDefault behavior\n\n\nBy default, allocations are made in the small object area (SOA). If there is no room in the SOA, and an object is larger than 64KB, the object is allocated in the LOA.\n\n\nIf the LOA is not used, it is shrunk to zero after a few collections. You can disable it explicitly by specifying the \n-Xnoloa\n option.\n\n\nExplanation\n\n\nThe LOA is an area of the tenure area of the heap set used solely to satisfy allocations for large objects. The LOA is used when the allocation request cannot be satisfied in the main area (the SOA of the tenure heap.\n\n\nAs objects are allocated and freed, the heap can become fragmented in such a way that allocation can be met only by time-consuming compactions. This problem is more pronounced if an application allocates large objects. In an attempt to alleviate this problem, the LOA is allocated. A large object in this context is considered to be any object 64 KB or greater in size. Allocations for new TLH objects are not considered to be large objects.\n\n\n \nNote:\n The Balanced Garbage Collection policy does not use the LOA. Therefore, when specifying -\nXgcpolicy:balanced\n, any LOA options passed on the command line are ignored. The policy addresses the issues of LOA by reorganizing object layout with the VM to reduce heap fragmentation and compaction requirements. \n\n\nSee also\n\n\n\n\n-Xloainitial / -Xloaminimum / -Xloamaximum",
"title": "-Xloa"
},
{
"location": "/xloa/#-xloa-xnoloa",
"text": "This option enables or prevents allocation of a large object area (LOA) during garbage collection.",
"title": "-Xloa / -Xnoloa"
},
{
"location": "/xloa/#syntax",
"text": "Setting Effect Default -Xloa Enable LOA yes (see Default behavior) -Xnoloa Disable LOA",
"title": "Syntax"
},
{
"location": "/xloa/#default-behavior",
"text": "By default, allocations are made in the small object area (SOA). If there is no room in the SOA, and an object is larger than 64KB, the object is allocated in the LOA. If the LOA is not used, it is shrunk to zero after a few collections. You can disable it explicitly by specifying the -Xnoloa option.",
"title": "Default behavior"
},
{
"location": "/xloa/#explanation",
"text": "The LOA is an area of the tenure area of the heap set used solely to satisfy allocations for large objects. The LOA is used when the allocation request cannot be satisfied in the main area (the SOA of the tenure heap. As objects are allocated and freed, the heap can become fragmented in such a way that allocation can be met only by time-consuming compactions. This problem is more pronounced if an application allocates large objects. In an attempt to alleviate this problem, the LOA is allocated. A large object in this context is considered to be any object 64 KB or greater in size. Allocations for new TLH objects are not considered to be large objects. Note: The Balanced Garbage Collection policy does not use the LOA. Therefore, when specifying - Xgcpolicy:balanced , any LOA options passed on the command line are ignored. The policy addresses the issues of LOA by reorganizing object layout with the VM to reduce heap fragmentation and compaction requirements.",
"title": "Explanation"
},
{
"location": "/xloa/#see-also",
"text": "-Xloainitial / -Xloaminimum / -Xloamaximum",
"title": "See also"
},
{
"location": "/xloaminimum/",
"text": "-Xloainitial / -Xloaminimum / -Xloamaximum\n\n\nSpecifies the initial, minimum, and maximum proportion of the current tenure space allocated to the large object area (LOA). \n\n\nThe LOA does not shrink to less than the minimum value. \n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xloainitial<value>\n\n\nSet initial space\n\n\n0.05\n\n\n\n\n\n\n-Xloaminimum<value>\n\n\nSet minimum space\n\n\n0.01\n\n\n\n\n\n\n-Xloamaximum<value>\n\n\nSet minimum space\n\n\n0.5\n\n\n\n\n\n\n\n\nSee also\n\n\n\n\n-Xloa / Xnoloa",
"title": "-Xloainitial"
},
{
"location": "/xloaminimum/#-xloainitial-xloaminimum-xloamaximum",
"text": "Specifies the initial, minimum, and maximum proportion of the current tenure space allocated to the large object area (LOA). The LOA does not shrink to less than the minimum value.",
"title": "-Xloainitial / -Xloaminimum / -Xloamaximum"
},
{
"location": "/xloaminimum/#syntax",
"text": "Setting Effect Default -Xloainitial<value> Set initial space 0.05 -Xloaminimum<value> Set minimum space 0.01 -Xloamaximum<value> Set minimum space 0.5",
"title": "Syntax"
},
{
"location": "/xloaminimum/#see-also",
"text": "-Xloa / Xnoloa",
"title": "See also"
},
{
"location": "/xloaminimum/",
"text": "-Xloainitial / -Xloaminimum / -Xloamaximum\n\n\nSpecifies the initial, minimum, and maximum proportion of the current tenure space allocated to the large object area (LOA). \n\n\nThe LOA does not shrink to less than the minimum value. \n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xloainitial<value>\n\n\nSet initial space\n\n\n0.05\n\n\n\n\n\n\n-Xloaminimum<value>\n\n\nSet minimum space\n\n\n0.01\n\n\n\n\n\n\n-Xloamaximum<value>\n\n\nSet minimum space\n\n\n0.5\n\n\n\n\n\n\n\n\nSee also\n\n\n\n\n-Xloa / Xnoloa",
"title": "-Xloamaximum"
},
{
"location": "/xloaminimum/#-xloainitial-xloaminimum-xloamaximum",
"text": "Specifies the initial, minimum, and maximum proportion of the current tenure space allocated to the large object area (LOA). The LOA does not shrink to less than the minimum value.",
"title": "-Xloainitial / -Xloaminimum / -Xloamaximum"
},
{
"location": "/xloaminimum/#syntax",
"text": "Setting Effect Default -Xloainitial<value> Set initial space 0.05 -Xloaminimum<value> Set minimum space 0.01 -Xloamaximum<value> Set minimum space 0.5",
"title": "Syntax"
},
{
"location": "/xloaminimum/#see-also",
"text": "-Xloa / Xnoloa",
"title": "See also"
},
{
"location": "/xloaminimum/",
"text": "-Xloainitial / -Xloaminimum / -Xloamaximum\n\n\nSpecifies the initial, minimum, and maximum proportion of the current tenure space allocated to the large object area (LOA). \n\n\nThe LOA does not shrink to less than the minimum value. \n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xloainitial<value>\n\n\nSet initial space\n\n\n0.05\n\n\n\n\n\n\n-Xloaminimum<value>\n\n\nSet minimum space\n\n\n0.01\n\n\n\n\n\n\n-Xloamaximum<value>\n\n\nSet minimum space\n\n\n0.5\n\n\n\n\n\n\n\n\nSee also\n\n\n\n\n-Xloa / Xnoloa",
"title": "-Xloaminimum"
},
{
"location": "/xloaminimum/#-xloainitial-xloaminimum-xloamaximum",
"text": "Specifies the initial, minimum, and maximum proportion of the current tenure space allocated to the large object area (LOA). The LOA does not shrink to less than the minimum value.",
"title": "-Xloainitial / -Xloaminimum / -Xloamaximum"
},
{
"location": "/xloaminimum/#syntax",
"text": "Setting Effect Default -Xloainitial<value> Set initial space 0.05 -Xloaminimum<value> Set minimum space 0.01 -Xloamaximum<value> Set minimum space 0.5",
"title": "Syntax"
},
{
"location": "/xloaminimum/#see-also",
"text": "-Xloa / Xnoloa",
"title": "See also"
},
{
"location": "/xlockreservation/",
"text": "-XlockReservation\n\n\nEnables an optimization that presumes a monitor is owned by the thread that last acquired it.\n\n\nThis optimization minimizes the runtime cost of acquiring and releasing a monitor for a single thread if the monitor is rarely acquired by multiple threads.\n\n\nSyntax\n\n\n -XlockReservation",
"title": "-XlockReservation"
},
{
"location": "/xlockreservation/#-xlockreservation",
"text": "Enables an optimization that presumes a monitor is owned by the thread that last acquired it. This optimization minimizes the runtime cost of acquiring and releasing a monitor for a single thread if the monitor is rarely acquired by multiple threads.",
"title": "-XlockReservation"
},
{
"location": "/xlockreservation/#syntax",
"text": "-XlockReservation",
"title": "Syntax"
},
{
"location": "/xlockword/",
"text": "-Xlockword\n\n\nTest whether performance optimizations are negatively impacting an application.\n\n\nSyntax\n\n\n -Xlockword:<parameters>\n\n\n\n\n\nParameters\n\n\nmode\n\n\n -Xlockword:mode=all\n -Xlockword:mode=default\n\n\n\n\n\nLocking optimizations typically reduce memory usage and improve performance. However, there might be some situations where a smaller heap size is achieved for an application, but overall application performance decreases.\n\n\nFor example, if your application synchronizes on objects that are not typically synchronized on, such as \nJava.lang.String\n, run the following test:\n\nUse the following command-line option to revert to behavior that is closer to earlier versions and monitor application performance:\n\n\n-Xlockword:mode=all\n\n\n\n\n\nIf performance does not improve, remove the previous command-line options or use the following command-line option to reestablish the new behavior:\n\n\n-Xlockword:mode=default\n\n\n\n\n\nnolockword\n\n\n -Xlockword:nolockword=<class_name>\n\n\n\n\n\n\n\n\n\nRemoves the lockword from object instances of the class \n<class_name>\n, reducing the space required for these objects. However, this action might have an adverse effect on synchronization for those objects.\n\n\nYou should only use this option for troubleshooting.\n\n\n\n\n\n\nwhat\n\n\n -Xlockword:what\n\n\n\n\n\n\n\nShows the current lockword configuration.",
"title": "-Xlockword"
},
{
"location": "/xlockword/#-xlockword",
"text": "Test whether performance optimizations are negatively impacting an application.",
"title": "-Xlockword"
},
{
"location": "/xlockword/#syntax",
"text": "-Xlockword:<parameters>",
"title": "Syntax"
},
{
"location": "/xlockword/#parameters",
"text": "",
"title": "Parameters"
},
{
"location": "/xlockword/#mode",
"text": "-Xlockword:mode=all\n -Xlockword:mode=default Locking optimizations typically reduce memory usage and improve performance. However, there might be some situations where a smaller heap size is achieved for an application, but overall application performance decreases. For example, if your application synchronizes on objects that are not typically synchronized on, such as Java.lang.String , run the following test: \nUse the following command-line option to revert to behavior that is closer to earlier versions and monitor application performance: -Xlockword:mode=all If performance does not improve, remove the previous command-line options or use the following command-line option to reestablish the new behavior: -Xlockword:mode=default",
"title": "mode"
},
{
"location": "/xlockword/#nolockword",
"text": "-Xlockword:nolockword=<class_name> Removes the lockword from object instances of the class <class_name> , reducing the space required for these objects. However, this action might have an adverse effect on synchronization for those objects. You should only use this option for troubleshooting.",
"title": "nolockword"
},
{
"location": "/xlockword/#what",
"text": "-Xlockword:what Shows the current lockword configuration.",
"title": "what"
},
{
"location": "/xlog/",
"text": "-Xlog\n\n\nEnables message logging. \n\n\n \nNote:\n Changes made to message logging using the \n-Xlog\n option do not affect messages written to the standard error stream (\nstderr\n).\n\n\nSyntax\n\n\n -Xlog:<parameter>{,<parameter>}\n\n\n\n\n\nParameters\n\n\n \nRestriction:\n The parameters \nall\n, \nnone\n and \nhelp\n must be used on their own and cannot be combined. However, the other parameters can be grouped. For example, to include error, vital and warning messages use \n-Xlog:error,vital,warn\n. \n\n\nFor message details see \nOpenJ9 VM messages\n.\n\n\nhelp\n\n\n -Xlog:help\n\n\n\n\n\n\n\nGives details the available parameters. (This parameter cannot be combined with others.)\n\n\n\n\nerror\n\n\n -Xlog:error\n\n\n\n\n\n\n\nTurns on logging for all OpenJ9 VM error messages (default).\n\n\n\n\nvital\n\n\n -Xlog:vital\n\n\n\n\n\n\n\nTurns on logging for selected information messages \nJVMDUMP006I\n, \nJVMDUMP032I\n, and \nJVMDUMP033I\n, which provide valuable additional information about dumps produced by the OpenJ9 VM (default).\n\n\n\n\ninfo\n\n\n -Xlog:info\n\n\n\n\n\n\n\nTurns on logging for all OpenJ9 VM information messages.\n\n\n\n\nwarn\n\n\n -Xlog:warn\n\n\n\n\n\n\n\nTurns on logging for all OpenJ9 VM warning messages.\n\n\n\n\nconfig\n\n\n -Xlog:config\n\n\n\n\n\n\n\nTurns on logging for all OpenJ9 VM configuration messages.\n\n\n\n\nall\n\n\n -Xlog:all\n\n\n\n\n\n\n\nTurns on logging for all OpenJ9 VM messages. (This parameter cannot be combined with others.)\n\n\n\n\nnone\n\n\n -Xlog:none\n\n\n\n\n\n\n\nTurns off logging for all OpenJ9 VM messages. (This parameter cannot be combined with others.)",
"title": "-Xlog"
},
{
"location": "/xlog/#-xlog",
"text": "Enables message logging. Note: Changes made to message logging using the -Xlog option do not affect messages written to the standard error stream ( stderr ).",
"title": "-Xlog"
},
{
"location": "/xlog/#syntax",
"text": "-Xlog:<parameter>{,<parameter>}",
"title": "Syntax"
},
{
"location": "/xlog/#parameters",
"text": "Restriction: The parameters all , none and help must be used on their own and cannot be combined. However, the other parameters can be grouped. For example, to include error, vital and warning messages use -Xlog:error,vital,warn . For message details see OpenJ9 VM messages .",
"title": "Parameters"
},
{
"location": "/xlog/#help",
"text": "-Xlog:help Gives details the available parameters. (This parameter cannot be combined with others.)",
"title": "help"
},
{
"location": "/xlog/#error",
"text": "-Xlog:error Turns on logging for all OpenJ9 VM error messages (default).",
"title": "error"
},
{
"location": "/xlog/#vital",
"text": "-Xlog:vital Turns on logging for selected information messages JVMDUMP006I , JVMDUMP032I , and JVMDUMP033I , which provide valuable additional information about dumps produced by the OpenJ9 VM (default).",
"title": "vital"
},
{
"location": "/xlog/#info",
"text": "-Xlog:info Turns on logging for all OpenJ9 VM information messages.",
"title": "info"
},
{
"location": "/xlog/#warn",
"text": "-Xlog:warn Turns on logging for all OpenJ9 VM warning messages.",
"title": "warn"
},
{
"location": "/xlog/#config",
"text": "-Xlog:config Turns on logging for all OpenJ9 VM configuration messages.",
"title": "config"
},
{
"location": "/xlog/#all",
"text": "-Xlog:all Turns on logging for all OpenJ9 VM messages. (This parameter cannot be combined with others.)",
"title": "all"
},
{
"location": "/xlog/#none",
"text": "-Xlog:none Turns off logging for all OpenJ9 VM messages. (This parameter cannot be combined with others.)",
"title": "none"
},
{
"location": "/xlp/",
"text": "-Xlp\n\n\nRequests the OpenJ9 VM to allocate the Java\u2122 object heap and JIT code cache memory with large pages.\n\n\nNote:\n This option is deprecated in all versions later than Java 8. Use the \n-Xlp:codecache\n and \n-Xlp:objectheap\n options instead.\n\n\nIf you use the \n-Xgc:preferredHeapBase\n option with \n-Xlp\n, the preferredHeapBase 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\nTo find out the large page sizes available and the current setting, use the \n-verbose:sizes\n option. Note that the current settings are the requested sizes and not the sizes obtained. For object heap size information, check the \n-verbose:gc\n output.\n\n\nSyntax\n\n\n -Xlp[<size>]\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\n\nExplanation\n\n\nAIX\u00ae\n\n\n\n\n\n\nIf \n<size>\n is specified, the VM attempts to allocate the JIT code cache memory by using pages of that size. Allocating large pages by using \n-Xlp\n is supported only on the 64-bit VM, not the 32-bit VM.\n\n\nIf a size is not specified, this option requests the VM to allocate the Java object heap (the heap from which Java objects are allocated) with large (16 MB) pages.\n\n\nIf large pages are not available, the Java object heap is allocated with the next smaller page size that is supported by the system. AIX requires special configuration to enable large pages.\n\n\nThe VM supports the use of large pages only to back the Java object heap shared memory segments. The VM uses \nshmget()\n with the SHM_LGPG and SHM_PIN flags to allocate large pages. The \n-Xlp\n option replaces the environment variable \nIBM_JAVA_LARGE_PAGE_SIZE\n, which is now ignored if set.\n\n\nFor more information about configuring AIX support for large pages, see \nLarge pages\n in the AIX product documentation.\n\n\n\n\n\n\nLinux\u2122\n\n\n\n\n\n\nIf \n<size>\n is specified, the VM attempts to allocate the JIT code cache memory by using pages of that size. Allocating large pages by using \n-Xlp\n is supported only on the 64-bit VM, not the 32-bit VM.\n\n\nIf large pages are not available, the VM does not start and produces an error message. The VM uses \nshmget()\n to allocate large pages for the heap. Large pages are supported by systems that have Linux kernels v2.6 or higher.\n\n\n \nNote:\n Linux for IBM Z\u00ae supports only a large page size of 1 M.\n\n\nDepending on the architecture, 1 MB or 2 MB large pages, when available, are the default size for the object heap and the code cache. The options that control these sizes are \nXlp:codecache\n and \n-Xlp:objectheap\n.\n\n\n\n\n\n\nWindows\u2122\n\n\n\n\n\n\nIf \n<size>\n is specified, the VM attempts to allocate the JIT code cache memory by using pages of that size.\n\n\nAllocating large pages by using \n-Xlp\n is supported only on the 64-bit VM, not the 32-bit VM.\n\n\n\n\n\n\nz/OS\u00ae\n\n\n\n\n\n\nIf \n<size>\n is specified but unsuccessful, or if executable pages of that size are not supported, 1 M pageable is attempted. If 1 M pageable is not available, the JIT code cache memory is allocated by using the default or smallest available executable page size.\n\n\nIf \n<size>\n is not specified, the 1 M nonpageable size is used. If large pages are not supported by the hardware, or enabled in RACF\u00ae, the VM does not start and produces an error message.\n\n\nAllocating large pages by using \n-Xlp\n is supported only on the 64-bit VM, not the 31-bit VM. The \n-Xlp[<size>]\n option supports only a large page size of 2 G and 1 M (nonpageable).\n\n\n1 M pageable pages, when available, are the default size for the object heap and the code cache. The options that control these sizes are \nXlp:codecache\n and \n-Xlp:objectheap\n.\n\n\nSpecifying \n-Xlp1M\n uses a 1 M pageable size for the code cache, when available. Specifying \n-Xlp2G\n sets the object heap size, but generates a warning that 2 G nonpageable pages cannot be used for the code cache. Use the \n-Xlp:objectheap:pagesize=2G,nonpageable\n option to avoid the warning.\n\n\n\n\n\n\nLimitation and workaround\n\n\nThe VM ends if insufficient operating system resources are available to satisfy the request. However, an error message is not issued. There are a number of reasons why the VM cannot honor a large page request. For example, there might be insufficient large pages available on the system at the time of the request. To check whether the \n-Xlp\n request was honored, you can review the output from \n-verbose:gc\n. Look for the attributes \nrequestedPageSize\n and \npageSize\n in the \n-verbose:gc\n log file. The attribute \nrequestedPageSize\n contains the value specified by \n-Xlp\n. The attribute \npageSize\n is the actual page size used by the VM.\n\n\nSee also\n\n\n\n\nConfiguring large page memory allocation\n.",
"title": "-Xlp"
},
{
"location": "/xlp/#-xlp",
"text": "Requests the OpenJ9 VM to allocate the Java\u2122 object heap and JIT code cache memory with large pages. Note: This option is deprecated in all versions later than Java 8. Use the -Xlp:codecache and -Xlp:objectheap options instead. If you use the -Xgc:preferredHeapBase option with -Xlp , the preferredHeapBase 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. To find out the large page sizes available and the current setting, use the -verbose:sizes option. Note that the current settings are the requested sizes and not the sizes obtained. For object heap size information, check the -verbose:gc output.",
"title": "-Xlp"
},
{
"location": "/xlp/#syntax",
"text": "-Xlp[<size>] See Using -X command-line options for more information about the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xlp/#explanation",
"text": "",
"title": "Explanation"
},
{
"location": "/xlp/#aix",
"text": "If <size> is specified, the VM attempts to allocate the JIT code cache memory by using pages of that size. Allocating large pages by using -Xlp is supported only on the 64-bit VM, not the 32-bit VM. If a size is not specified, this option requests the VM to allocate the Java object heap (the heap from which Java objects are allocated) with large (16 MB) pages. If large pages are not available, the Java object heap is allocated with the next smaller page size that is supported by the system. AIX requires special configuration to enable large pages. The VM supports the use of large pages only to back the Java object heap shared memory segments. The VM uses shmget() with the SHM_LGPG and SHM_PIN flags to allocate large pages. The -Xlp option replaces the environment variable IBM_JAVA_LARGE_PAGE_SIZE , which is now ignored if set. For more information about configuring AIX support for large pages, see Large pages in the AIX product documentation.",
"title": "AIX&reg;"
},
{
"location": "/xlp/#linux",
"text": "If <size> is specified, the VM attempts to allocate the JIT code cache memory by using pages of that size. Allocating large pages by using -Xlp is supported only on the 64-bit VM, not the 32-bit VM. If large pages are not available, the VM does not start and produces an error message. The VM uses shmget() to allocate large pages for the heap. Large pages are supported by systems that have Linux kernels v2.6 or higher. Note: Linux for IBM Z\u00ae supports only a large page size of 1 M. Depending on the architecture, 1 MB or 2 MB large pages, when available, are the default size for the object heap and the code cache. The options that control these sizes are Xlp:codecache and -Xlp:objectheap .",
"title": "Linux&trade;"
},
{
"location": "/xlp/#windows",
"text": "If <size> is specified, the VM attempts to allocate the JIT code cache memory by using pages of that size. Allocating large pages by using -Xlp is supported only on the 64-bit VM, not the 32-bit VM.",
"title": "Windows&trade;"
},
{
"location": "/xlp/#zos",
"text": "If <size> is specified but unsuccessful, or if executable pages of that size are not supported, 1 M pageable is attempted. If 1 M pageable is not available, the JIT code cache memory is allocated by using the default or smallest available executable page size. If <size> is not specified, the 1 M nonpageable size is used. If large pages are not supported by the hardware, or enabled in RACF\u00ae, the VM does not start and produces an error message. Allocating large pages by using -Xlp is supported only on the 64-bit VM, not the 31-bit VM. The -Xlp[<size>] option supports only a large page size of 2 G and 1 M (nonpageable). 1 M pageable pages, when available, are the default size for the object heap and the code cache. The options that control these sizes are Xlp:codecache and -Xlp:objectheap . Specifying -Xlp1M uses a 1 M pageable size for the code cache, when available. Specifying -Xlp2G sets the object heap size, but generates a warning that 2 G nonpageable pages cannot be used for the code cache. Use the -Xlp:objectheap:pagesize=2G,nonpageable option to avoid the warning.",
"title": "z/OS&reg;"
},
{
"location": "/xlp/#limitation-and-workaround",
"text": "The VM ends if insufficient operating system resources are available to satisfy the request. However, an error message is not issued. There are a number of reasons why the VM cannot honor a large page request. For example, there might be insufficient large pages available on the system at the time of the request. To check whether the -Xlp request was honored, you can review the output from -verbose:gc . Look for the attributes requestedPageSize and pageSize in the -verbose:gc log file. The attribute requestedPageSize contains the value specified by -Xlp . The attribute pageSize is the actual page size used by the VM.",
"title": "Limitation and workaround"
},
{
"location": "/xlp/#see-also",
"text": "Configuring large page memory allocation .",
"title": "See also"
},
{
"location": "/xlpcodecache/",
"text": "-Xlp:codecache\n\n\nRequests the OpenJ9 VM to allocate the JIT code cache by using large page sizes.\n\n\nIf the requested large page size is not available, the VM starts, but the JIT code cache is allocated by using a platform-defined size. A warning is displayed when the requested page size is not available.\n\n\nTo find out the large page sizes available and the current setting, use the \n-verbose:sizes\n option. Note that the current settings are the requested sizes and not the sizes obtained. For object heap size information, check the \n-verbose:gc\n output.\n\n\nSyntax\n\n\nAIX\u00ae, Linux\u2122, and Windows\u2122:\n\n\n -Xlp:codecache:pagesize=<size>\n\n\n\n\n\nz/OS\u00ae:\n\n\n -Xlp:codecache:pagesize=<size>,pageable\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\n\nDefault values\n\n\nAIX\n\n\n\n\n\n\nThe code cache page size is controlled by the \nDATAPSIZE\n setting of the \nLDR_CNTRL\n environment variable. The page size cannot be controlled by the \n-Xlp:codecache:pagesize=<size>\n option. Specifying any other page size results in a warning that the page size is not available. The \n-verbose:sizes\n output reflects the current operating system setting.\n\n\nFor more information about the \nLDR_CNTRL\n environment variable, see \nWorking with the LDR_CNTRL environment variable\n.\n\n\n\n\n\n\nLinux\n\n\n\n\n\n\nThe default size for the code cache depends on the architecture:\n\n\n\n\nLinux on x86 and AMD64/EM64T systems: 2 MB large pages\n\n\nLinux on IBM Z\u00ae: 1 MB large pages\n\n\nLinux on Power Systems\u2122: The code cache page size cannot be controlled by the \n-Xlp:codecache:pagesize=<size>\n option. Specifying any other page size results in a warning that the page size is not available. The \n-verbose:sizes\n output reflects the current operating system setting.\n\n\nOn other architectures, the VM uses the default operating system page size.\n\n\n\n\n\n\n\n\nz/OS\n\n\n\n\n\n\n1 M pageable pages, when available, are the default size for the code cache.\n\n\nThe \n-Xlp:codecache:pagesize=<size>,pageable\n option supports only a large page size of 1 M pageable large pages. The use of 1 M pageable large pages for the JIT code cache can improve the runtime performance of some Java\u2122 applications. A page size of 4 K can also be used.\n\n\n\n\n\n\nSee also\n\n\n\n\nConfiguring large page memory allocation\n.",
"title": "-Xlp:codecache"
},
{
"location": "/xlpcodecache/#-xlpcodecache",
"text": "Requests the OpenJ9 VM to allocate the JIT code cache by using large page sizes. If the requested large page size is not available, the VM starts, but the JIT code cache is allocated by using a platform-defined size. A warning is displayed when the requested page size is not available. To find out the large page sizes available and the current setting, use the -verbose:sizes option. Note that the current settings are the requested sizes and not the sizes obtained. For object heap size information, check the -verbose:gc output.",
"title": "-Xlp:codecache"
},
{
"location": "/xlpcodecache/#syntax",
"text": "AIX\u00ae, Linux\u2122, and Windows\u2122: -Xlp:codecache:pagesize=<size> z/OS\u00ae: -Xlp:codecache:pagesize=<size>,pageable See Using -X command-line options for more information about the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xlpcodecache/#default-values",
"text": "",
"title": "Default values"
},
{
"location": "/xlpcodecache/#aix",
"text": "The code cache page size is controlled by the DATAPSIZE setting of the LDR_CNTRL environment variable. The page size cannot be controlled by the -Xlp:codecache:pagesize=<size> option. Specifying any other page size results in a warning that the page size is not available. The -verbose:sizes output reflects the current operating system setting. For more information about the LDR_CNTRL environment variable, see Working with the LDR_CNTRL environment variable .",
"title": "AIX"
},
{
"location": "/xlpcodecache/#linux",
"text": "The default size for the code cache depends on the architecture: Linux on x86 and AMD64/EM64T systems: 2 MB large pages Linux on IBM Z\u00ae: 1 MB large pages Linux on Power Systems\u2122: The code cache page size cannot be controlled by the -Xlp:codecache:pagesize=<size> option. Specifying any other page size results in a warning that the page size is not available. The -verbose:sizes output reflects the current operating system setting. On other architectures, the VM uses the default operating system page size.",
"title": "Linux"
},
{
"location": "/xlpcodecache/#zos",
"text": "1 M pageable pages, when available, are the default size for the code cache. The -Xlp:codecache:pagesize=<size>,pageable option supports only a large page size of 1 M pageable large pages. The use of 1 M pageable large pages for the JIT code cache can improve the runtime performance of some Java\u2122 applications. A page size of 4 K can also be used.",
"title": "z/OS"
},
{
"location": "/xlpcodecache/#see-also",
"text": "Configuring large page memory allocation .",
"title": "See also"
},
{
"location": "/xlpobjectheap/",
"text": "-Xlp:objectheap\n\n\nRequests the OpenJ9 VM to allocate the Java\u2122 object heap by using large page sizes.\n\n\nTo find out the large page sizes available and the current setting, use the \n-verbose:sizes\n option. Note that the current settings are the requested sizes and not the sizes obtained. For object heap size information, check the \n-verbose:gc\n output.\n\n\nSyntax\n\n\nAIX\u00ae, Linux\u2122, and Windows\u2122:\n\n\n -Xlp:objectheap:pagesize=<size>[,strict|warn]\n\n\n\n\n\nz/OS\u00ae:\n\n\n -Xlp:objectheap:pagesize=<size>[,strict|warn][,pageable|nonpageable]\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\n\nParameters\n\n\npagesize\n\n\n -Xlp:objectheap:pagesize=<size>\n\n\n\n\n\n\n\n\n\nThe large page size that you require.\n\n\nIf the operating system does not have sufficient resources to satisfy the request, the page size you requested might not be available when the VM starts up. By default, the VM starts and the Java object heap is allocated by using a different platform-defined page size. Alternatively, you can use the \nstrict\n or \nwarn\n suboptions to customize behavior.\n\n\n\n\n\n\nDefault page sizes\n\n\n\n\n\n\nOn Linux systems, the default size for the object heap depends on the architecture:\n\n\n\n\nLinux on x86 and AMD64/EM64T systems: 2 MB large pages\n\n\nLinux on IBM Z\u00ae: 1 MB large pages\n\n\nOn other architectures, the VM uses the default operating system page size.\n\n\n\n\n\n\n\n\nstrict\n | \nwarn\n\n\n -Xlp:objectheap:strict\n -Xlp:objectheap:warn\n\n\n\n\n\n\n\n\n\n\n\nstrict\n causes an error message to be generated if large pages are requested but cannot be obtained. This option causes the VM to end.\n\n\nwarn\n causes a warning message to be generated if large pages are requested but cannot be obtained. This option allows the VM to continue.\n\n\n\n\n \nNote:\n If both \nstrict\n and \nwarn\n are specified, \nstrict\n takes precedence.\n\n\n\n\n\n\npageable\n|\nnonpageable\n\n\n -Xlp:objectheap:pageable\n -Xlp:objectheap:nonpageable\n\n\n\n\n\n\n\n\n\nOn z/OS systems, defines the type of memory to allocate for the Java object heap.\n\n\n1 M pageable pages, when available, are the default size for the object heap.\n\nSupported large page sizes are 2 G nonpageable, 1 M nonpageable, and 1 M pageable. A page size of 4 K can also be used.\n\n\n\n\n\n\nSee also\n\n\n\n\nConfiguring large page memory allocation\n.",
"title": "-Xlp:objectheap"
},
{
"location": "/xlpobjectheap/#-xlpobjectheap",
"text": "Requests the OpenJ9 VM to allocate the Java\u2122 object heap by using large page sizes. To find out the large page sizes available and the current setting, use the -verbose:sizes option. Note that the current settings are the requested sizes and not the sizes obtained. For object heap size information, check the -verbose:gc output.",
"title": "-Xlp:objectheap"
},
{
"location": "/xlpobjectheap/#syntax",
"text": "AIX\u00ae, Linux\u2122, and Windows\u2122: -Xlp:objectheap:pagesize=<size>[,strict|warn] z/OS\u00ae: -Xlp:objectheap:pagesize=<size>[,strict|warn][,pageable|nonpageable] See Using -X command-line options for more information about the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xlpobjectheap/#parameters",
"text": "",
"title": "Parameters"
},
{
"location": "/xlpobjectheap/#pagesize",
"text": "-Xlp:objectheap:pagesize=<size> The large page size that you require. If the operating system does not have sufficient resources to satisfy the request, the page size you requested might not be available when the VM starts up. By default, the VM starts and the Java object heap is allocated by using a different platform-defined page size. Alternatively, you can use the strict or warn suboptions to customize behavior.",
"title": "pagesize"
},
{
"location": "/xlpobjectheap/#default-page-sizes",
"text": "On Linux systems, the default size for the object heap depends on the architecture: Linux on x86 and AMD64/EM64T systems: 2 MB large pages Linux on IBM Z\u00ae: 1 MB large pages On other architectures, the VM uses the default operating system page size.",
"title": "Default page sizes"
},
{
"location": "/xlpobjectheap/#strict-warn",
"text": "-Xlp:objectheap:strict\n -Xlp:objectheap:warn strict causes an error message to be generated if large pages are requested but cannot be obtained. This option causes the VM to end. warn causes a warning message to be generated if large pages are requested but cannot be obtained. This option allows the VM to continue. Note: If both strict and warn are specified, strict takes precedence.",
"title": "strict | warn"
},
{
"location": "/xlpobjectheap/#pageablenonpageable",
"text": "-Xlp:objectheap:pageable\n -Xlp:objectheap:nonpageable On z/OS systems, defines the type of memory to allocate for the Java object heap. 1 M pageable pages, when available, are the default size for the object heap. \nSupported large page sizes are 2 G nonpageable, 1 M nonpageable, and 1 M pageable. A page size of 4 K can also be used.",
"title": "pageable|nonpageable"
},
{
"location": "/xlpobjectheap/#see-also",
"text": "Configuring large page memory allocation .",
"title": "See also"
},
{
"location": "/xmine/",
"text": "-Xmine / -Xmaxe\n\n\nSet the minimum and maximum amounts by which the garbage collector expands the heap.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xmine<size>\n\n\n1 MB\n\n\n\n\n\n\n-Xmaxe<size>\n\n\n0 (unlimited expansion)\n\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\n\nExplanation\n\n\nTypically, the garbage collector expands the heap by the amount required to restore the free space to 30% (or the amount specified by \n-Xminf\n).\n\n\nIf heap expansion is required:\n\n\n\n\n-Xmine\n forces the expansion to be at least the specified value. For example, \n-Xmine10M\n sets the expansion size to a minimum of 10 MB. \n\n\n-Xmaxe\n limits the expansion to the specified value. For example \n-Xmaxe50M\n prevents expansion by more than 50 MB. (\n-Xmaxe0\n allows unlimited expansion.)\n\n\n\n\nSee also\n\n\n\n\nHeap shrinkage\n\n\nHeap expansion",
"title": "-Xmaxe"
},
{
"location": "/xmine/#-xmine-xmaxe",
"text": "Set the minimum and maximum amounts by which the garbage collector expands the heap.",
"title": "-Xmine / -Xmaxe"
},
{
"location": "/xmine/#syntax",
"text": "Setting Default -Xmine<size> 1 MB -Xmaxe<size> 0 (unlimited expansion) See Using -X command-line options for more information about the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xmine/#explanation",
"text": "Typically, the garbage collector expands the heap by the amount required to restore the free space to 30% (or the amount specified by -Xminf ). If heap expansion is required: -Xmine forces the expansion to be at least the specified value. For example, -Xmine10M sets the expansion size to a minimum of 10 MB. -Xmaxe limits the expansion to the specified value. For example -Xmaxe50M prevents expansion by more than 50 MB. ( -Xmaxe0 allows unlimited expansion.)",
"title": "Explanation"
},
{
"location": "/xmine/#see-also",
"text": "Heap shrinkage Heap expansion",
"title": "See also"
},
{
"location": "/xminf/",
"text": "-Xminf\n / \n-Xmaxf\n\n\nSpecifies the minimum and maximum proportion of the heap that must remain free after a global garbage collection cycle.\n\n\nIf the free space is above or below these limits, the OpenJ9 VM attempts to adjust the heap size so that: \n-Xminf\n \u2264 free space \u2264 \n-Xmaxf\n.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xminf<value>\n\n\nSet minimum free space\n\n\n30\n\n\n\n\n\n\n-Xmaxf<value>\n\n\nSet maximum free space\n\n\n60\n\n\n\n\n\n\n\n\nSee also\n\n\n\n\nHeap shrinkage\n\n\nHeap expansion",
"title": "-Xmaxf"
},
{
"location": "/xminf/#-xminf-xmaxf",
"text": "Specifies the minimum and maximum proportion of the heap that must remain free after a global garbage collection cycle. If the free space is above or below these limits, the OpenJ9 VM attempts to adjust the heap size so that: -Xminf \u2264 free space \u2264 -Xmaxf .",
"title": "-Xminf / -Xmaxf"
},
{
"location": "/xminf/#syntax",
"text": "Setting Effect Default -Xminf<value> Set minimum free space 30 -Xmaxf<value> Set maximum free space 60",
"title": "Syntax"
},
{
"location": "/xminf/#see-also",
"text": "Heap shrinkage Heap expansion",
"title": "See also"
},
{
"location": "/xmint/",
"text": "-Xmint / -Xmaxt\n\n\nSets the minimum and maximum proportion of time to spend in the garbage collection (GC) process as a percentage of the overall running time that included the last three GC runs.\n\n\n\n\nIf the percentage of time drops to less than the minimum, the OpenJ9 VM tries to shrink the heap.\n\n\nIf the percentage of time exceeds the maximum, the OpenJ9 VM tries to expand the heap.\n\n\n\n\n \nRestrictions:\n\n\n\n\nThis option applies only to GC policies that include stop-the-world (STW) operations, such as \n-Xgcpolicy:optthruput\n. \n\n\nThis option is ignored by the default policy \n-Xgcpolicy:gencon\n.\n\n\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xmint<value>\n\n\nSet minimum time in GC\n\n\n5\n\n\n\n\n\n\n-Xmaxt<value>\n\n\nSet maximum time in GC\n\n\n13",
"title": "-Xmaxt"
},
{
"location": "/xmint/#-xmint-xmaxt",
"text": "Sets the minimum and maximum proportion of time to spend in the garbage collection (GC) process as a percentage of the overall running time that included the last three GC runs. If the percentage of time drops to less than the minimum, the OpenJ9 VM tries to shrink the heap. If the percentage of time exceeds the maximum, the OpenJ9 VM tries to expand the heap. Restrictions: This option applies only to GC policies that include stop-the-world (STW) operations, such as -Xgcpolicy:optthruput . This option is ignored by the default policy -Xgcpolicy:gencon .",
"title": "-Xmint / -Xmaxt"
},
{
"location": "/xmint/#syntax",
"text": "Setting Effect Default -Xmint<value> Set minimum time in GC 5 -Xmaxt<value> Set maximum time in GC 13",
"title": "Syntax"
},
{
"location": "/xmca/",
"text": "-Xmca / -Xmco\n\n\nSets the expansion step for the memory allocated to store the RAM (\n-Xmca\n) and ROM (\n-Xmco\n) portions of loaded classes.\n\n\nEach time more memory is required to store classes in RAM or ROM, the allocated memory is increased by the amount set. \n\n\nIf the expansion step size you choose is too large, \nOutOfMemoryError\n is reported. The exact value of a \n\"too large\"\n expansion step size varies according to the platform and the specific machine configuration.\n\n\nYou can use the \n-verbose:sizes\n option to find out the value that is being used by the VM.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xmca<size>\n\n\nSet expansion step for RAM\n\n\n32 KB\n\n\n\n\n\n\n-Xmco<size>\n\n\nSet expansion step for ROM\n\n\n128 KB\n\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.",
"title": "-Xmca"
},
{
"location": "/xmca/#-xmca-xmco",
"text": "Sets the expansion step for the memory allocated to store the RAM ( -Xmca ) and ROM ( -Xmco ) portions of loaded classes. Each time more memory is required to store classes in RAM or ROM, the allocated memory is increased by the amount set. If the expansion step size you choose is too large, OutOfMemoryError is reported. The exact value of a \"too large\" expansion step size varies according to the platform and the specific machine configuration. You can use the -verbose:sizes option to find out the value that is being used by the VM.",
"title": "-Xmca / -Xmco"
},
{
"location": "/xmca/#syntax",
"text": "Setting Effect Default -Xmca<size> Set expansion step for RAM 32 KB -Xmco<size> Set expansion step for ROM 128 KB See Using -X command-line options for more information about the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xmca/",
"text": "-Xmca / -Xmco\n\n\nSets the expansion step for the memory allocated to store the RAM (\n-Xmca\n) and ROM (\n-Xmco\n) portions of loaded classes.\n\n\nEach time more memory is required to store classes in RAM or ROM, the allocated memory is increased by the amount set. \n\n\nIf the expansion step size you choose is too large, \nOutOfMemoryError\n is reported. The exact value of a \n\"too large\"\n expansion step size varies according to the platform and the specific machine configuration.\n\n\nYou can use the \n-verbose:sizes\n option to find out the value that is being used by the VM.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xmca<size>\n\n\nSet expansion step for RAM\n\n\n32 KB\n\n\n\n\n\n\n-Xmco<size>\n\n\nSet expansion step for ROM\n\n\n128 KB\n\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.",
"title": "-Xmco"
},
{
"location": "/xmca/#-xmca-xmco",
"text": "Sets the expansion step for the memory allocated to store the RAM ( -Xmca ) and ROM ( -Xmco ) portions of loaded classes. Each time more memory is required to store classes in RAM or ROM, the allocated memory is increased by the amount set. If the expansion step size you choose is too large, OutOfMemoryError is reported. The exact value of a \"too large\" expansion step size varies according to the platform and the specific machine configuration. You can use the -verbose:sizes option to find out the value that is being used by the VM.",
"title": "-Xmca / -Xmco"
},
{
"location": "/xmca/#syntax",
"text": "Setting Effect Default -Xmca<size> Set expansion step for RAM 32 KB -Xmco<size> Set expansion step for ROM 128 KB See Using -X command-line options for more information about the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xmcrs/",
"text": "-Xmcrs\n\n\nSets an initial size for an area in memory that is reserved for any native classes, monitors, and threads that are used by compressed references within the lowest 4 GB memory area.\n\n\nYou can use the \n-verbose:sizes\n option to find out the value that is being used by the VM.\n\n\n \nNotes:\n \n\n\n\n\nNative memory \nOutOfMemoryError\n exceptions might occur when using compressed references if the lowest 4 GB of address space becomes full, particularly when loading classes, starting threads, or using monitors. \n\n\nIf you are not using compressed references and this option is set, the option is ignored and the output of \n-verbose:sizes\n shows \n-Xmcrs0\n.\n\n\n\n\nSyntax\n\n\n -Xmcrs<size>\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.",
"title": "-Xmcrs"
},
{
"location": "/xmcrs/#-xmcrs",
"text": "Sets an initial size for an area in memory that is reserved for any native classes, monitors, and threads that are used by compressed references within the lowest 4 GB memory area. You can use the -verbose:sizes option to find out the value that is being used by the VM. Notes: Native memory OutOfMemoryError exceptions might occur when using compressed references if the lowest 4 GB of address space becomes full, particularly when loading classes, starting threads, or using monitors. If you are not using compressed references and this option is set, the option is ignored and the output of -verbose:sizes shows -Xmcrs0 .",
"title": "-Xmcrs"
},
{
"location": "/xmcrs/#syntax",
"text": "-Xmcrs<size> See Using -X command-line options for more information about the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xmine/",
"text": "-Xmine / -Xmaxe\n\n\nSet the minimum and maximum amounts by which the garbage collector expands the heap.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xmine<size>\n\n\n1 MB\n\n\n\n\n\n\n-Xmaxe<size>\n\n\n0 (unlimited expansion)\n\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\n\nExplanation\n\n\nTypically, the garbage collector expands the heap by the amount required to restore the free space to 30% (or the amount specified by \n-Xminf\n).\n\n\nIf heap expansion is required:\n\n\n\n\n-Xmine\n forces the expansion to be at least the specified value. For example, \n-Xmine10M\n sets the expansion size to a minimum of 10 MB. \n\n\n-Xmaxe\n limits the expansion to the specified value. For example \n-Xmaxe50M\n prevents expansion by more than 50 MB. (\n-Xmaxe0\n allows unlimited expansion.)\n\n\n\n\nSee also\n\n\n\n\nHeap shrinkage\n\n\nHeap expansion",
"title": "-Xmine"
},
{
"location": "/xmine/#-xmine-xmaxe",
"text": "Set the minimum and maximum amounts by which the garbage collector expands the heap.",
"title": "-Xmine / -Xmaxe"
},
{
"location": "/xmine/#syntax",
"text": "Setting Default -Xmine<size> 1 MB -Xmaxe<size> 0 (unlimited expansion) See Using -X command-line options for more information about the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xmine/#explanation",
"text": "Typically, the garbage collector expands the heap by the amount required to restore the free space to 30% (or the amount specified by -Xminf ). If heap expansion is required: -Xmine forces the expansion to be at least the specified value. For example, -Xmine10M sets the expansion size to a minimum of 10 MB. -Xmaxe limits the expansion to the specified value. For example -Xmaxe50M prevents expansion by more than 50 MB. ( -Xmaxe0 allows unlimited expansion.)",
"title": "Explanation"
},
{
"location": "/xmine/#see-also",
"text": "Heap shrinkage Heap expansion",
"title": "See also"
},
{
"location": "/xminf/",
"text": "-Xminf\n / \n-Xmaxf\n\n\nSpecifies the minimum and maximum proportion of the heap that must remain free after a global garbage collection cycle.\n\n\nIf the free space is above or below these limits, the OpenJ9 VM attempts to adjust the heap size so that: \n-Xminf\n \u2264 free space \u2264 \n-Xmaxf\n.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xminf<value>\n\n\nSet minimum free space\n\n\n30\n\n\n\n\n\n\n-Xmaxf<value>\n\n\nSet maximum free space\n\n\n60\n\n\n\n\n\n\n\n\nSee also\n\n\n\n\nHeap shrinkage\n\n\nHeap expansion",
"title": "-Xminf"
},
{
"location": "/xminf/#-xminf-xmaxf",
"text": "Specifies the minimum and maximum proportion of the heap that must remain free after a global garbage collection cycle. If the free space is above or below these limits, the OpenJ9 VM attempts to adjust the heap size so that: -Xminf \u2264 free space \u2264 -Xmaxf .",
"title": "-Xminf / -Xmaxf"
},
{
"location": "/xminf/#syntax",
"text": "Setting Effect Default -Xminf<value> Set minimum free space 30 -Xmaxf<value> Set maximum free space 60",
"title": "Syntax"
},
{
"location": "/xminf/#see-also",
"text": "Heap shrinkage Heap expansion",
"title": "See also"
},
{
"location": "/xmint/",
"text": "-Xmint / -Xmaxt\n\n\nSets the minimum and maximum proportion of time to spend in the garbage collection (GC) process as a percentage of the overall running time that included the last three GC runs.\n\n\n\n\nIf the percentage of time drops to less than the minimum, the OpenJ9 VM tries to shrink the heap.\n\n\nIf the percentage of time exceeds the maximum, the OpenJ9 VM tries to expand the heap.\n\n\n\n\n \nRestrictions:\n\n\n\n\nThis option applies only to GC policies that include stop-the-world (STW) operations, such as \n-Xgcpolicy:optthruput\n. \n\n\nThis option is ignored by the default policy \n-Xgcpolicy:gencon\n.\n\n\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xmint<value>\n\n\nSet minimum time in GC\n\n\n5\n\n\n\n\n\n\n-Xmaxt<value>\n\n\nSet maximum time in GC\n\n\n13",
"title": "-Xmint"
},
{
"location": "/xmint/#-xmint-xmaxt",
"text": "Sets the minimum and maximum proportion of time to spend in the garbage collection (GC) process as a percentage of the overall running time that included the last three GC runs. If the percentage of time drops to less than the minimum, the OpenJ9 VM tries to shrink the heap. If the percentage of time exceeds the maximum, the OpenJ9 VM tries to expand the heap. Restrictions: This option applies only to GC policies that include stop-the-world (STW) operations, such as -Xgcpolicy:optthruput . This option is ignored by the default policy -Xgcpolicy:gencon .",
"title": "-Xmint / -Xmaxt"
},
{
"location": "/xmint/#syntax",
"text": "Setting Effect Default -Xmint<value> Set minimum time in GC 5 -Xmaxt<value> Set maximum time in GC 13",
"title": "Syntax"
},
{
"location": "/xmn/",
"text": "-Xmn / -Xmns / -Xmnx\n\n\nSets the initial and maximum size of the new area when using \n-Xgcpolicy:gencon\n.\n\n\nIf the scavenger is disabled, this option is ignored.\n\n\nYou can use the \n-verbose:sizes\n option to find out the value that is being used by the VM.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xmn<size>\n\n\nEquivalent to setting both \n-Xmns\n and \n-Xmnx\n\n\nNot set\n\n\n\n\n\n\n-Xmns<size>\n\n\nSet initial size\n\n\n25% of \n-Xms\n\n\n\n\n\n\n-Xmnx<size>\n\n\nSet maximum size\n\n\n25% of \n-Xmx\n\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\n\n \nRestriction:\n If you try to set \n-Xmn\n with either \n-Xmns\n or \n-Xmnx\n, the VM does not start, returning an error.",
"title": "-Xmn"
},
{
"location": "/xmn/#-xmn-xmns-xmnx",
"text": "Sets the initial and maximum size of the new area when using -Xgcpolicy:gencon . If the scavenger is disabled, this option is ignored. You can use the -verbose:sizes option to find out the value that is being used by the VM.",
"title": "-Xmn / -Xmns / -Xmnx"
},
{
"location": "/xmn/#syntax",
"text": "Setting Effect Default -Xmn<size> Equivalent to setting both -Xmns and -Xmnx Not set -Xmns<size> Set initial size 25% of -Xms -Xmnx<size> Set maximum size 25% of -Xmx See Using -X command-line options for more information about the <size> parameter. Restriction: If you try to set -Xmn with either -Xmns or -Xmnx , the VM does not start, returning an error.",
"title": "Syntax"
},
{
"location": "/xmn/",
"text": "-Xmn / -Xmns / -Xmnx\n\n\nSets the initial and maximum size of the new area when using \n-Xgcpolicy:gencon\n.\n\n\nIf the scavenger is disabled, this option is ignored.\n\n\nYou can use the \n-verbose:sizes\n option to find out the value that is being used by the VM.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xmn<size>\n\n\nEquivalent to setting both \n-Xmns\n and \n-Xmnx\n\n\nNot set\n\n\n\n\n\n\n-Xmns<size>\n\n\nSet initial size\n\n\n25% of \n-Xms\n\n\n\n\n\n\n-Xmnx<size>\n\n\nSet maximum size\n\n\n25% of \n-Xmx\n\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\n\n \nRestriction:\n If you try to set \n-Xmn\n with either \n-Xmns\n or \n-Xmnx\n, the VM does not start, returning an error.",
"title": "-Xmns"
},
{
"location": "/xmn/#-xmn-xmns-xmnx",
"text": "Sets the initial and maximum size of the new area when using -Xgcpolicy:gencon . If the scavenger is disabled, this option is ignored. You can use the -verbose:sizes option to find out the value that is being used by the VM.",
"title": "-Xmn / -Xmns / -Xmnx"
},
{
"location": "/xmn/#syntax",
"text": "Setting Effect Default -Xmn<size> Equivalent to setting both -Xmns and -Xmnx Not set -Xmns<size> Set initial size 25% of -Xms -Xmnx<size> Set maximum size 25% of -Xmx See Using -X command-line options for more information about the <size> parameter. Restriction: If you try to set -Xmn with either -Xmns or -Xmnx , the VM does not start, returning an error.",
"title": "Syntax"
},
{
"location": "/xmn/",
"text": "-Xmn / -Xmns / -Xmnx\n\n\nSets the initial and maximum size of the new area when using \n-Xgcpolicy:gencon\n.\n\n\nIf the scavenger is disabled, this option is ignored.\n\n\nYou can use the \n-verbose:sizes\n option to find out the value that is being used by the VM.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xmn<size>\n\n\nEquivalent to setting both \n-Xmns\n and \n-Xmnx\n\n\nNot set\n\n\n\n\n\n\n-Xmns<size>\n\n\nSet initial size\n\n\n25% of \n-Xms\n\n\n\n\n\n\n-Xmnx<size>\n\n\nSet maximum size\n\n\n25% of \n-Xmx\n\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\n\n \nRestriction:\n If you try to set \n-Xmn\n with either \n-Xmns\n or \n-Xmnx\n, the VM does not start, returning an error.",
"title": "-Xmnx"
},
{
"location": "/xmn/#-xmn-xmns-xmnx",
"text": "Sets the initial and maximum size of the new area when using -Xgcpolicy:gencon . If the scavenger is disabled, this option is ignored. You can use the -verbose:sizes option to find out the value that is being used by the VM.",
"title": "-Xmn / -Xmns / -Xmnx"
},
{
"location": "/xmn/#syntax",
"text": "Setting Effect Default -Xmn<size> Equivalent to setting both -Xmns and -Xmnx Not set -Xmns<size> Set initial size 25% of -Xms -Xmnx<size> Set maximum size 25% of -Xmx See Using -X command-line options for more information about the <size> parameter. Restriction: If you try to set -Xmn with either -Xmns or -Xmnx , the VM does not start, returning an error.",
"title": "Syntax"
},
{
"location": "/xmo/",
"text": "-Xmo / -Xmoi / -Xmos / -Xmox\n\n\nSets the size and behavior of the old (tenure) heap when using \n-Xgcpolicy:gencon\n.\n\n\nYou can use the \n-verbose:sizes\n option to find out the values that the VM is currently using.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xmo<size>\n\n\nEquivalent to setting both \n-Xmos\n and \n-Xmox\n\n\nnot set\n\n\n\n\n\n\n-Xmoi<size>\n\n\nSet increment size of old (tenure) heap\n\n\nSee \nNote\n\n\n\n\n\n\n-Xmos<size>\n\n\nSet initial size of old (tenure) heap\n\n\n75% of \n-Xms\n\n\n\n\n\n\n-Xmox<size>\n\n\nSet maximum size of old (tenure) heap\n\n\nSame as \n-Xmx\n\n\n\n\n\n\n\n\n \nNote:\n By default, the increment size (\n-Xmoi\n) is calculated on the expansion size, set by \n-Xmine\n and \n-Xminf\n. If you set \n-Xmoi\n to zero, no expansion is allowed.\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\n\n \nRestriction:\n If you try to set \n-Xmo\n with either \n-Xmos\n or \n-Xmox\n, the VM does not start, returning an error.",
"title": "-Xmo"
},
{
"location": "/xmo/#-xmo-xmoi-xmos-xmox",
"text": "Sets the size and behavior of the old (tenure) heap when using -Xgcpolicy:gencon . You can use the -verbose:sizes option to find out the values that the VM is currently using.",
"title": "-Xmo / -Xmoi / -Xmos / -Xmox"
},
{
"location": "/xmo/#syntax",
"text": "Setting Effect Default -Xmo<size> Equivalent to setting both -Xmos and -Xmox not set -Xmoi<size> Set increment size of old (tenure) heap See Note -Xmos<size> Set initial size of old (tenure) heap 75% of -Xms -Xmox<size> Set maximum size of old (tenure) heap Same as -Xmx Note: By default, the increment size ( -Xmoi ) is calculated on the expansion size, set by -Xmine and -Xminf . If you set -Xmoi to zero, no expansion is allowed. See Using -X command-line options for more information about the <size> parameter. Restriction: If you try to set -Xmo with either -Xmos or -Xmox , the VM does not start, returning an error.",
"title": "Syntax"
},
{
"location": "/xmo/",
"text": "-Xmo / -Xmoi / -Xmos / -Xmox\n\n\nSets the size and behavior of the old (tenure) heap when using \n-Xgcpolicy:gencon\n.\n\n\nYou can use the \n-verbose:sizes\n option to find out the values that the VM is currently using.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xmo<size>\n\n\nEquivalent to setting both \n-Xmos\n and \n-Xmox\n\n\nnot set\n\n\n\n\n\n\n-Xmoi<size>\n\n\nSet increment size of old (tenure) heap\n\n\nSee \nNote\n\n\n\n\n\n\n-Xmos<size>\n\n\nSet initial size of old (tenure) heap\n\n\n75% of \n-Xms\n\n\n\n\n\n\n-Xmox<size>\n\n\nSet maximum size of old (tenure) heap\n\n\nSame as \n-Xmx\n\n\n\n\n\n\n\n\n \nNote:\n By default, the increment size (\n-Xmoi\n) is calculated on the expansion size, set by \n-Xmine\n and \n-Xminf\n. If you set \n-Xmoi\n to zero, no expansion is allowed.\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\n\n \nRestriction:\n If you try to set \n-Xmo\n with either \n-Xmos\n or \n-Xmox\n, the VM does not start, returning an error.",
"title": "-Xmoi"
},
{
"location": "/xmo/#-xmo-xmoi-xmos-xmox",
"text": "Sets the size and behavior of the old (tenure) heap when using -Xgcpolicy:gencon . You can use the -verbose:sizes option to find out the values that the VM is currently using.",
"title": "-Xmo / -Xmoi / -Xmos / -Xmox"
},
{
"location": "/xmo/#syntax",
"text": "Setting Effect Default -Xmo<size> Equivalent to setting both -Xmos and -Xmox not set -Xmoi<size> Set increment size of old (tenure) heap See Note -Xmos<size> Set initial size of old (tenure) heap 75% of -Xms -Xmox<size> Set maximum size of old (tenure) heap Same as -Xmx Note: By default, the increment size ( -Xmoi ) is calculated on the expansion size, set by -Xmine and -Xminf . If you set -Xmoi to zero, no expansion is allowed. See Using -X command-line options for more information about the <size> parameter. Restriction: If you try to set -Xmo with either -Xmos or -Xmox , the VM does not start, returning an error.",
"title": "Syntax"
},
{
"location": "/xmo/",
"text": "-Xmo / -Xmoi / -Xmos / -Xmox\n\n\nSets the size and behavior of the old (tenure) heap when using \n-Xgcpolicy:gencon\n.\n\n\nYou can use the \n-verbose:sizes\n option to find out the values that the VM is currently using.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xmo<size>\n\n\nEquivalent to setting both \n-Xmos\n and \n-Xmox\n\n\nnot set\n\n\n\n\n\n\n-Xmoi<size>\n\n\nSet increment size of old (tenure) heap\n\n\nSee \nNote\n\n\n\n\n\n\n-Xmos<size>\n\n\nSet initial size of old (tenure) heap\n\n\n75% of \n-Xms\n\n\n\n\n\n\n-Xmox<size>\n\n\nSet maximum size of old (tenure) heap\n\n\nSame as \n-Xmx\n\n\n\n\n\n\n\n\n \nNote:\n By default, the increment size (\n-Xmoi\n) is calculated on the expansion size, set by \n-Xmine\n and \n-Xminf\n. If you set \n-Xmoi\n to zero, no expansion is allowed.\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\n\n \nRestriction:\n If you try to set \n-Xmo\n with either \n-Xmos\n or \n-Xmox\n, the VM does not start, returning an error.",
"title": "-Xmos"
},
{
"location": "/xmo/#-xmo-xmoi-xmos-xmox",
"text": "Sets the size and behavior of the old (tenure) heap when using -Xgcpolicy:gencon . You can use the -verbose:sizes option to find out the values that the VM is currently using.",
"title": "-Xmo / -Xmoi / -Xmos / -Xmox"
},
{
"location": "/xmo/#syntax",
"text": "Setting Effect Default -Xmo<size> Equivalent to setting both -Xmos and -Xmox not set -Xmoi<size> Set increment size of old (tenure) heap See Note -Xmos<size> Set initial size of old (tenure) heap 75% of -Xms -Xmox<size> Set maximum size of old (tenure) heap Same as -Xmx Note: By default, the increment size ( -Xmoi ) is calculated on the expansion size, set by -Xmine and -Xminf . If you set -Xmoi to zero, no expansion is allowed. See Using -X command-line options for more information about the <size> parameter. Restriction: If you try to set -Xmo with either -Xmos or -Xmox , the VM does not start, returning an error.",
"title": "Syntax"
},
{
"location": "/xmo/",
"text": "-Xmo / -Xmoi / -Xmos / -Xmox\n\n\nSets the size and behavior of the old (tenure) heap when using \n-Xgcpolicy:gencon\n.\n\n\nYou can use the \n-verbose:sizes\n option to find out the values that the VM is currently using.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xmo<size>\n\n\nEquivalent to setting both \n-Xmos\n and \n-Xmox\n\n\nnot set\n\n\n\n\n\n\n-Xmoi<size>\n\n\nSet increment size of old (tenure) heap\n\n\nSee \nNote\n\n\n\n\n\n\n-Xmos<size>\n\n\nSet initial size of old (tenure) heap\n\n\n75% of \n-Xms\n\n\n\n\n\n\n-Xmox<size>\n\n\nSet maximum size of old (tenure) heap\n\n\nSame as \n-Xmx\n\n\n\n\n\n\n\n\n \nNote:\n By default, the increment size (\n-Xmoi\n) is calculated on the expansion size, set by \n-Xmine\n and \n-Xminf\n. If you set \n-Xmoi\n to zero, no expansion is allowed.\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\n\n \nRestriction:\n If you try to set \n-Xmo\n with either \n-Xmos\n or \n-Xmox\n, the VM does not start, returning an error.",
"title": "-Xmox"
},
{
"location": "/xmo/#-xmo-xmoi-xmos-xmox",
"text": "Sets the size and behavior of the old (tenure) heap when using -Xgcpolicy:gencon . You can use the -verbose:sizes option to find out the values that the VM is currently using.",
"title": "-Xmo / -Xmoi / -Xmos / -Xmox"
},
{
"location": "/xmo/#syntax",
"text": "Setting Effect Default -Xmo<size> Equivalent to setting both -Xmos and -Xmox not set -Xmoi<size> Set increment size of old (tenure) heap See Note -Xmos<size> Set initial size of old (tenure) heap 75% of -Xms -Xmox<size> Set maximum size of old (tenure) heap Same as -Xmx Note: By default, the increment size ( -Xmoi ) is calculated on the expansion size, set by -Xmine and -Xminf . If you set -Xmoi to zero, no expansion is allowed. See Using -X command-line options for more information about the <size> parameter. Restriction: If you try to set -Xmo with either -Xmos or -Xmox , the VM does not start, returning an error.",
"title": "Syntax"
},
{
"location": "/xmr/",
"text": "-Xmr / \u00a0 -Xmrx\n\n\nSets the initial and maximum size of the the garbage collection \"remembered set\", which is a list of objects in the old (tenured) heap that have references to objects in the new area. \n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xmr<size>\n\n\nSet initial size\n\n\n16 K\n\n\n\n\n\n\n-Xmrx<size>\n\n\nSet maximium size\n\n\n\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.",
"title": "-Xmr"
},
{
"location": "/xmr/#-xmr-xmrx",
"text": "Sets the initial and maximum size of the the garbage collection \"remembered set\", which is a list of objects in the old (tenured) heap that have references to objects in the new area.",
"title": "-Xmr / &nbsp; -Xmrx"
},
{
"location": "/xmr/#syntax",
"text": "Setting Effect Default -Xmr<size> Set initial size 16 K -Xmrx<size> Set maximium size See Using -X command-line options for more information about the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xmr/",
"text": "-Xmr / \u00a0 -Xmrx\n\n\nSets the initial and maximum size of the the garbage collection \"remembered set\", which is a list of objects in the old (tenured) heap that have references to objects in the new area. \n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xmr<size>\n\n\nSet initial size\n\n\n16 K\n\n\n\n\n\n\n-Xmrx<size>\n\n\nSet maximium size\n\n\n\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.",
"title": "-Xmrx"
},
{
"location": "/xmr/#-xmr-xmrx",
"text": "Sets the initial and maximum size of the the garbage collection \"remembered set\", which is a list of objects in the old (tenured) heap that have references to objects in the new area.",
"title": "-Xmr / &nbsp; -Xmrx"
},
{
"location": "/xmr/#syntax",
"text": "Setting Effect Default -Xmr<size> Set initial size 16 K -Xmrx<size> Set maximium size See Using -X command-line options for more information about the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xms/",
"text": "-Xms / -Xmx\n\n\nThese Oracle\u00ae Hotspot\u2122 options set the initial/minimum Java\u2122 heap size, and the maximum heap size respectively. These options are recognized by the OpenJ9 VM.\n\n\n \nNotes:\n\n\n\n\nIf you set \n-Xms\n > \n-Xmx\n, the OpenJ9 VM fails with the message \n-Xms too large for -Xmx\n.\n\n\nIf you exceed the limit set by the \n-Xmx\n option, the OpenJ9 VM generates an \nOutofMemoryError\n.\n\n\n\n\nIf you are allocating the Java heap with large pages, see also \n-Xlp\n and\n\nMore effective heap usage using compressed references\n.\n\n\nYou can also use the \n-Xmo\n option (not supported by the balanced garbage collection policy):\n\nIf the scavenger is enabled, \n-Xms\n \u2265 \n-Xmn\n + \n-Xmo\n\nIf the scavenger is disabled, \n-Xms\n \u2265 \n-Xmo\n \n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xms<size>\n\n\nSet initial heap size\n\n\n8 MB\n\n\n\n\n\n\n-Xmx<size>\n\n\nSet maximum heap size\n\n\n25% of available memory (25 GB maximum)\n\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\nSee \nDefault settings for the OpenJ9 VM\n for more about default values.\n\n\nExamples\n\n\n\n\n-Xms2m -Xmx64m\n\n\nHeap starts at 2 MB and grows to a maximum of 64 MB.\n\n\n-Xms100m -Xmx100m\n\n\nHeap starts at 100 MB and never grows.\n\n\n-Xms50m\n\n\nHeap starts at 50 MB and grows to the default maximum.\n\n\n-Xmx256m\n\n\nHeap starts at default initial value and grows to a maximum of 256 MB.\n\n\n\n\nSee also\n\n\n\n\n-Xsoftmx (Set \"soft\" maximum Java heap size)",
"title": "-Xms"
},
{
"location": "/xms/#-xms-xmx",
"text": "These Oracle\u00ae Hotspot\u2122 options set the initial/minimum Java\u2122 heap size, and the maximum heap size respectively. These options are recognized by the OpenJ9 VM. Notes: If you set -Xms > -Xmx , the OpenJ9 VM fails with the message -Xms too large for -Xmx . If you exceed the limit set by the -Xmx option, the OpenJ9 VM generates an OutofMemoryError . If you are allocating the Java heap with large pages, see also -Xlp and More effective heap usage using compressed references . You can also use the -Xmo option (not supported by the balanced garbage collection policy): \nIf the scavenger is enabled, -Xms \u2265 -Xmn + -Xmo \nIf the scavenger is disabled, -Xms \u2265 -Xmo",
"title": "-Xms / -Xmx"
},
{
"location": "/xms/#syntax",
"text": "Setting Effect Default -Xms<size> Set initial heap size 8 MB -Xmx<size> Set maximum heap size 25% of available memory (25 GB maximum) See Using -X command-line options for more information about the <size> parameter. \nSee Default settings for the OpenJ9 VM for more about default values.",
"title": "Syntax"
},
{
"location": "/xms/#examples",
"text": "-Xms2m -Xmx64m Heap starts at 2 MB and grows to a maximum of 64 MB. -Xms100m -Xmx100m Heap starts at 100 MB and never grows. -Xms50m Heap starts at 50 MB and grows to the default maximum. -Xmx256m Heap starts at default initial value and grows to a maximum of 256 MB.",
"title": "Examples"
},
{
"location": "/xms/#see-also",
"text": "-Xsoftmx (Set \"soft\" maximum Java heap size)",
"title": "See also"
},
{
"location": "/xmso/",
"text": "-Xmso\n\n\nSets the initial stack size for operating system threads.\n\n\nYou can use the \n-verbose:sizes\n option to find out the values that the VM is currently using.\n\n\nIf you exceed the maximum value, a \njava/lang/StackOverflowError\n message is reported.\n\n\nSyntax\n\n\n -Xmso<size>\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter. \n\n\nDefault setting\n\n\nBy default, the stack size is set to 256 KB. \n\n\nSee \nDefault settings for the OpenJ9 VM\n for information about default values.\n\n\nSee also\n\n\n\n\n-Xiss/-Xss/-Xssi\n (Stack size and behavior of Java\u2122 threads)",
"title": "-Xmso"
},
{
"location": "/xmso/#-xmso",
"text": "Sets the initial stack size for operating system threads. You can use the -verbose:sizes option to find out the values that the VM is currently using. If you exceed the maximum value, a java/lang/StackOverflowError message is reported.",
"title": "-Xmso"
},
{
"location": "/xmso/#syntax",
"text": "-Xmso<size> See Using -X command-line options for more information about the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xmso/#default-setting",
"text": "By default, the stack size is set to 256 KB. See Default settings for the OpenJ9 VM for information about default values.",
"title": "Default setting"
},
{
"location": "/xmso/#see-also",
"text": "-Xiss/-Xss/-Xssi (Stack size and behavior of Java\u2122 threads)",
"title": "See also"
},
{
"location": "/xms/",
"text": "-Xms / -Xmx\n\n\nThese Oracle\u00ae Hotspot\u2122 options set the initial/minimum Java\u2122 heap size, and the maximum heap size respectively. These options are recognized by the OpenJ9 VM.\n\n\n \nNotes:\n\n\n\n\nIf you set \n-Xms\n > \n-Xmx\n, the OpenJ9 VM fails with the message \n-Xms too large for -Xmx\n.\n\n\nIf you exceed the limit set by the \n-Xmx\n option, the OpenJ9 VM generates an \nOutofMemoryError\n.\n\n\n\n\nIf you are allocating the Java heap with large pages, see also \n-Xlp\n and\n\nMore effective heap usage using compressed references\n.\n\n\nYou can also use the \n-Xmo\n option (not supported by the balanced garbage collection policy):\n\nIf the scavenger is enabled, \n-Xms\n \u2265 \n-Xmn\n + \n-Xmo\n\nIf the scavenger is disabled, \n-Xms\n \u2265 \n-Xmo\n \n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xms<size>\n\n\nSet initial heap size\n\n\n8 MB\n\n\n\n\n\n\n-Xmx<size>\n\n\nSet maximum heap size\n\n\n25% of available memory (25 GB maximum)\n\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\nSee \nDefault settings for the OpenJ9 VM\n for more about default values.\n\n\nExamples\n\n\n\n\n-Xms2m -Xmx64m\n\n\nHeap starts at 2 MB and grows to a maximum of 64 MB.\n\n\n-Xms100m -Xmx100m\n\n\nHeap starts at 100 MB and never grows.\n\n\n-Xms50m\n\n\nHeap starts at 50 MB and grows to the default maximum.\n\n\n-Xmx256m\n\n\nHeap starts at default initial value and grows to a maximum of 256 MB.\n\n\n\n\nSee also\n\n\n\n\n-Xsoftmx (Set \"soft\" maximum Java heap size)",
"title": "-Xmx"
},
{
"location": "/xms/#-xms-xmx",
"text": "These Oracle\u00ae Hotspot\u2122 options set the initial/minimum Java\u2122 heap size, and the maximum heap size respectively. These options are recognized by the OpenJ9 VM. Notes: If you set -Xms > -Xmx , the OpenJ9 VM fails with the message -Xms too large for -Xmx . If you exceed the limit set by the -Xmx option, the OpenJ9 VM generates an OutofMemoryError . If you are allocating the Java heap with large pages, see also -Xlp and More effective heap usage using compressed references . You can also use the -Xmo option (not supported by the balanced garbage collection policy): \nIf the scavenger is enabled, -Xms \u2265 -Xmn + -Xmo \nIf the scavenger is disabled, -Xms \u2265 -Xmo",
"title": "-Xms / -Xmx"
},
{
"location": "/xms/#syntax",
"text": "Setting Effect Default -Xms<size> Set initial heap size 8 MB -Xmx<size> Set maximum heap size 25% of available memory (25 GB maximum) See Using -X command-line options for more information about the <size> parameter. \nSee Default settings for the OpenJ9 VM for more about default values.",
"title": "Syntax"
},
{
"location": "/xms/#examples",
"text": "-Xms2m -Xmx64m Heap starts at 2 MB and grows to a maximum of 64 MB. -Xms100m -Xmx100m Heap starts at 100 MB and never grows. -Xms50m Heap starts at 50 MB and grows to the default maximum. -Xmx256m Heap starts at default initial value and grows to a maximum of 256 MB.",
"title": "Examples"
},
{
"location": "/xms/#see-also",
"text": "-Xsoftmx (Set \"soft\" maximum Java heap size)",
"title": "See also"
},
{
"location": "/xaot/",
"text": "-Xaot / -Xnoaot\n\n\nUse this option to control the behavior of the ahead-of-time (AOT) compiler.\n\n\nAOT compilation allows the compilation of Java\u2122 classes into native code for subsequent executions of the same program. The AOT compiler works with the class data sharing framework.\n\n\nThe AOT compiler generates native code dynamically while an application runs and caches any generated AOT code in the shared data cache. Subsequent VMs that execute the method can load and use the AOT code from the shared data cache without incurring the performance decrease experienced with JIT-compiled native code.\n\n\nPerformance\n\n\nBecause AOT code must persist over different program executions, AOT-generated code does not perform as well as JIT-generated code. AOT code usually performs better than interpreted code.\n\n\nIn a VM without an AOT compiler or with the AOT compiler disabled, the JIT compiler selectively compiles frequently used methods into optimized native code. There is a time cost associated with compiling methods because the JIT compiler operates while the application is running. Because methods begin by being interpreted and most JIT compilations occur during startup, startup times can be increased.\n\n\nStartup performance can be improved by using the shared AOT code to provide native code without compiling. There is a small time cost to load the AOT code for a method from the shared data cache and bind it into a running program. The time cost is low compared to the time it takes the JIT compiler to compile that method.\n\n\nDefault behavior\n\n\nThe AOT compiler is enabled by default, but is only active when \nshared classes\n are enabled. By default, shared classes are disabled so that no AOT activity occurs.\n\n\nWhen the AOT compiler is active, the compiler selects the methods to be AOT compiled with the primary goal of improving startup time.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nAction\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xaot\n\n\nEnable AOT\n\n\nyes\n\n\n\n\n\n\n-Xaot:<parameter>[=<value>]{,<parameter>[=<value>]}\n\n\nEnable AOT with modifications\n\n\n\n\n\n\n\n\n-Xnoaot\n\n\nDisable AOT\n\n\n\n\n\n\n\n\n\n\nParameters for \n-Xaot\n\n\n\n\n\n\n \nNote:\n Although the AOT compiler is enabled by default, it is not active unless shared classes are enabled. Using this option on its own therefore has no effect. Use the \n-Xshareclasses\n option to enable shared classes.\n\n\nYou can concatenate several parameters by using commas.\n\n\n\n\n\n\n\n\n\n\n\n\nParameter\n\n\nEffect\n\n\n\n\n\n\n\n\n\n\ncount\n\n\nThe number of times a method is called before it is compiled or loaded from an existing shared class cache.\n\n\n\n\n\n\nexclude\n\n\nThe method you want to exclude when AOT code is compiled or loaded from the shared classes cache.\n\n\n\n\n\n\nlimitFile\n\n\nCompile or load only the methods listed in the specified limit file.\n\n\n\n\n\n\nloadExclude\n\n\nDo not load specified methods.\n\n\n\n\n\n\nloadLimit\n\n\nLoad specified methods only.\n\n\n\n\n\n\nloadLimitFile\n\n\nLoad only the methods listed in the specified limit file).\n\n\n\n\n\n\nverbose\n\n\nReports information about the AOT and JIT compiler configuration and method compilation.\n\n\n\n\n\n\n\n\ncount\n\n\n -Xaot:count=<n>\n\n\n\n\n\n\n\nwhere \n<n>\n is the number of times a method is called before it is compiled or loaded from an existing shared class cache. For example, setting \n-Xaot:count=0\n forces the AOT compiler to compile everything on first execution.\n\n\n\n\nexclude\n\n\n -Xaot:exclude=<method>\n\n\n\n\n\n\n\n\n\nwhere \n<method>\n is the Java method you want to exclude when AOT code is compiled or loaded from the shared classes cache.\n\n\nUse this option if the method causes the program to fail.\n\n\n\n\n\n\nlimitFile\n\n\n -Xaot:limitFile=(<filename>,<m>,<n>)\n\n\n\n\n\n\n\nCompile or load only the methods listed on lines \n<m>\n to \n<n>\n in the specified limit file (\n<filename>\n). Methods not listed in the limit file and methods listed on lines outside the range are not compiled or loaded.\n\n\n\n\nloadExclude\n\n\n -Xaot:loadExclude=<method_prefix>\n\n\n\n\n\n\n\nDo not load methods beginning with \n<method_prefix>\n.\n\n\n\n\nloadLimit\n\n\n -Xaot:loadLimit=<method_prefix>\n\n\n\n\n\n\n\nLoad methods beginning with \n<method_prefix>\n only.\n\n\n\n\nloadLimitFile\n\n\n -Xaot:loadLimitFile=(<filename>,<m>,<n>)\n\n\n\n\n\n\n\nLoad only the methods listed on lines \n<m>\n to \n<n>\n in the specified limit file (\n<filename>\n). Methods not listed in the limit file and methods listed on lines outside the range are not loaded.\n\n\n\n\nverbose\n\n\n -Xaot:verbose\n\n\n\n\n\n\n\nReports information about the AOT and JIT compiler configuration and method compilation.\n\n\n\n\nSee also\n\n\n\n\n-Xquickstart",
"title": "-Xnoaot"
},
{
"location": "/xaot/#-xaot-xnoaot",
"text": "Use this option to control the behavior of the ahead-of-time (AOT) compiler. AOT compilation allows the compilation of Java\u2122 classes into native code for subsequent executions of the same program. The AOT compiler works with the class data sharing framework. The AOT compiler generates native code dynamically while an application runs and caches any generated AOT code in the shared data cache. Subsequent VMs that execute the method can load and use the AOT code from the shared data cache without incurring the performance decrease experienced with JIT-compiled native code.",
"title": "-Xaot / -Xnoaot"
},
{
"location": "/xaot/#performance",
"text": "Because AOT code must persist over different program executions, AOT-generated code does not perform as well as JIT-generated code. AOT code usually performs better than interpreted code. In a VM without an AOT compiler or with the AOT compiler disabled, the JIT compiler selectively compiles frequently used methods into optimized native code. There is a time cost associated with compiling methods because the JIT compiler operates while the application is running. Because methods begin by being interpreted and most JIT compilations occur during startup, startup times can be increased. Startup performance can be improved by using the shared AOT code to provide native code without compiling. There is a small time cost to load the AOT code for a method from the shared data cache and bind it into a running program. The time cost is low compared to the time it takes the JIT compiler to compile that method.",
"title": "Performance"
},
{
"location": "/xaot/#default-behavior",
"text": "The AOT compiler is enabled by default, but is only active when shared classes are enabled. By default, shared classes are disabled so that no AOT activity occurs. When the AOT compiler is active, the compiler selects the methods to be AOT compiled with the primary goal of improving startup time.",
"title": "Default behavior"
},
{
"location": "/xaot/#syntax",
"text": "Setting Action Default -Xaot Enable AOT yes -Xaot:<parameter>[=<value>]{,<parameter>[=<value>]} Enable AOT with modifications -Xnoaot Disable AOT",
"title": "Syntax"
},
{
"location": "/xaot/#parameters-for-xaot",
"text": "Note: Although the AOT compiler is enabled by default, it is not active unless shared classes are enabled. Using this option on its own therefore has no effect. Use the -Xshareclasses option to enable shared classes. You can concatenate several parameters by using commas. Parameter Effect count The number of times a method is called before it is compiled or loaded from an existing shared class cache. exclude The method you want to exclude when AOT code is compiled or loaded from the shared classes cache. limitFile Compile or load only the methods listed in the specified limit file. loadExclude Do not load specified methods. loadLimit Load specified methods only. loadLimitFile Load only the methods listed in the specified limit file). verbose Reports information about the AOT and JIT compiler configuration and method compilation.",
"title": "Parameters for -Xaot"
},
{
"location": "/xaot/#count",
"text": "-Xaot:count=<n> where <n> is the number of times a method is called before it is compiled or loaded from an existing shared class cache. For example, setting -Xaot:count=0 forces the AOT compiler to compile everything on first execution.",
"title": "count"
},
{
"location": "/xaot/#exclude",
"text": "-Xaot:exclude=<method> where <method> is the Java method you want to exclude when AOT code is compiled or loaded from the shared classes cache. Use this option if the method causes the program to fail.",
"title": "exclude"
},
{
"location": "/xaot/#limitfile",
"text": "-Xaot:limitFile=(<filename>,<m>,<n>) Compile or load only the methods listed on lines <m> to <n> in the specified limit file ( <filename> ). Methods not listed in the limit file and methods listed on lines outside the range are not compiled or loaded.",
"title": "limitFile"
},
{
"location": "/xaot/#loadexclude",
"text": "-Xaot:loadExclude=<method_prefix> Do not load methods beginning with <method_prefix> .",
"title": "loadExclude"
},
{
"location": "/xaot/#loadlimit",
"text": "-Xaot:loadLimit=<method_prefix> Load methods beginning with <method_prefix> only.",
"title": "loadLimit"
},
{
"location": "/xaot/#loadlimitfile",
"text": "-Xaot:loadLimitFile=(<filename>,<m>,<n>) Load only the methods listed on lines <m> to <n> in the specified limit file ( <filename> ). Methods not listed in the limit file and methods listed on lines outside the range are not loaded.",
"title": "loadLimitFile"
},
{
"location": "/xaot/#verbose",
"text": "-Xaot:verbose Reports information about the AOT and JIT compiler configuration and method compilation.",
"title": "verbose"
},
{
"location": "/xaot/#see-also",
"text": "-Xquickstart",
"title": "See also"
},
{
"location": "/xclassgc/",
"text": "-Xclassgc / -Xnoclassgc\n\n\nEnables and disables class garbage collection (the dynamic unloading of class objects by the VM). \n\n\nWhen enabled, garbage collection, occurs only on class loader changes. This is the default behavior.\n\n\n \nNote:\n Disabling class garbage collection is not recommended as this causes unlimited native memory growth, leading to out-of-memory errors.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nAction\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xclassgc\n\n\nEnable GC\n\n\nyes\n\n\n\n\n\n\n-Xnoclassgc\n\n\nDisable GC",
"title": "-Xnoclassgc"
},
{
"location": "/xclassgc/#-xclassgc-xnoclassgc",
"text": "Enables and disables class garbage collection (the dynamic unloading of class objects by the VM). When enabled, garbage collection, occurs only on class loader changes. This is the default behavior. Note: Disabling class garbage collection is not recommended as this causes unlimited native memory growth, leading to out-of-memory errors.",
"title": "-Xclassgc / -Xnoclassgc"
},
{
"location": "/xclassgc/#syntax",
"text": "Setting Action Default -Xclassgc Enable GC yes -Xnoclassgc Disable GC",
"title": "Syntax"
},
{
"location": "/xcompactexplicitgc/",
"text": "\u2011Xcompactexplicitgc / \u2011Xnocompactexplicitgc\n\n\nEnables or disables full compaction each time \nSystem.gc()\n is called. \n\n\nCompaction takes place on global garbage collections if you specify \n-Xcompactgc\n or if compaction triggers are met. \n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nAction\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xcompactexplicitgc\n\n\nEnable compaction\n\n\nyes\n\n\n\n\n\n\n-Xnocompactexplicitgc\n\n\nDisable compaction\n\n\n\n\n\n\n\n\n\n\nSee also\n\n\n\n\nGlobal garbage collection: Compaction phase",
"title": "-Xnocompactexplicitgc"
},
{
"location": "/xcompactexplicitgc/#xcompactexplicitgc-xnocompactexplicitgc",
"text": "Enables or disables full compaction each time System.gc() is called. Compaction takes place on global garbage collections if you specify -Xcompactgc or if compaction triggers are met.",
"title": "\u2011Xcompactexplicitgc / \u2011Xnocompactexplicitgc"
},
{
"location": "/xcompactexplicitgc/#syntax",
"text": "Setting Action Default -Xcompactexplicitgc Enable compaction yes -Xnocompactexplicitgc Disable compaction",
"title": "Syntax"
},
{
"location": "/xcompactexplicitgc/#see-also",
"text": "Global garbage collection: Compaction phase",
"title": "See also"
},
{
"location": "/xcompactgc/",
"text": "-Xcompactgc / -Xnocompactgc\n\n\nEnables or disables full compaction on all garbage collections (system and global).\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nAction\n\n\n\n\n\n\n\n\n\n\n-Xcompactgc\n\n\nEnable full compaction\n\n\n\n\n\n\n-Xnocompactgc\n\n\nDisable full compaction\n\n\n\n\n\n\n\n\nDefault behavior\n\n\nIf no compaction option is specified, the garbage collector compacts based on a series of triggers that attempt to compact only when it is beneficial to the future performance of the OpenJ9 VM.\n\n\nSee also\n\n\n\n\nGlobal garbage collection: Compaction phase",
"title": "-Xnocompactgc"
},
{
"location": "/xcompactgc/#-xcompactgc-xnocompactgc",
"text": "Enables or disables full compaction on all garbage collections (system and global).",
"title": "-Xcompactgc / -Xnocompactgc"
},
{
"location": "/xcompactgc/#syntax",
"text": "Setting Action -Xcompactgc Enable full compaction -Xnocompactgc Disable full compaction",
"title": "Syntax"
},
{
"location": "/xcompactgc/#default-behavior",
"text": "If no compaction option is specified, the garbage collector compacts based on a series of triggers that attempt to compact only when it is beneficial to the future performance of the OpenJ9 VM.",
"title": "Default behavior"
},
{
"location": "/xcompactgc/#see-also",
"text": "Global garbage collection: Compaction phase",
"title": "See also"
},
{
"location": "/xcompressedrefs/",
"text": "-Xcompressedrefs / -Xnocompressedrefs\n\n\n(64-bit only)\n\n\nEnables or disables the use of compressed references.\n\n\n \nRestriction:\n You cannot include \n-Xcompressedrefs\n in the options file (see \n-Xoptionsfile\n).\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nAction\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xcompressedrefs\n\n\nEnable compression\n\n\nyes\n (see \nDefault behavior\n)\n\n\n\n\n\n\n-Xnocompressedrefs\n\n\nDisable compression\n\n\n\n\n\n\n\n\n\n\nDefault behavior\n\n\nCompressed references are enabled by default when \n-Xmx\n \u2264 57 GB.\n\n\nz/OS\u00ae:\n This threshold value assumes that you have \nAPAR OA49416\n installed. If you do not have the APAR installed, the threshold value is 25 GB.\n\n\nAIX\u00ae and Linux\u2122:\n For the metronome garbage collection policy, the threshold is 25 GB.\n\n\nSee also\n\n\n\n\nCompressed references",
"title": "-Xnocompressedrefs"
},
{
"location": "/xcompressedrefs/#-xcompressedrefs-xnocompressedrefs",
"text": "(64-bit only) Enables or disables the use of compressed references. Restriction: You cannot include -Xcompressedrefs in the options file (see -Xoptionsfile ).",
"title": "-Xcompressedrefs / -Xnocompressedrefs"
},
{
"location": "/xcompressedrefs/#syntax",
"text": "Setting Action Default -Xcompressedrefs Enable compression yes (see Default behavior ) -Xnocompressedrefs Disable compression",
"title": "Syntax"
},
{
"location": "/xcompressedrefs/#default-behavior",
"text": "Compressed references are enabled by default when -Xmx \u2264 57 GB. z/OS\u00ae: This threshold value assumes that you have APAR OA49416 installed. If you do not have the APAR installed, the threshold value is 25 GB. AIX\u00ae and Linux\u2122: For the metronome garbage collection policy, the threshold is 25 GB.",
"title": "Default behavior"
},
{
"location": "/xcompressedrefs/#see-also",
"text": "Compressed references",
"title": "See also"
},
{
"location": "/xjit/",
"text": "-Xjit / -Xnojit\n\n\nUse this option to control the behavior of the JIT compiler.\n\n\nSpecifying \n-Xjit\n with no parameters, has no effect as the JIT compiler is enabled by default.\n\n\n-Xnojit\n turns off the JIT compiler but does not affect the AOT compiler.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nAction\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xjit\n\n\nEnable JIT\n\n\nyes\n\n\n\n\n\n\n-Xjit[:<parameter>=<value>{,<parameter>=<value>}]\n\n\nEnable JIT with options\n\n\n\n\n\n\n\n\n-Xnojit\n\n\nDisable JIT\n\n\n\n\n\n\n\n\n\n\nParameters\n\n\nThese parameters can be used to modify the behavior of \n-Xjit\n:\n\n\n\n\n\n\n\n\nParameter\n\n\nEffect\n\n\n\n\n\n\n\n\n\n\ncount\n \n\n\nForces compilation of methods on first invocation.\n\n\n\n\n\n\ndisableRMODE64\n\n\nAllows the JIT to allocate executable code caches above the 2 GB memory bar.\n\n\n\n\n\n\nexclude\n \n\n\nExcludes the specified method from compilation.\n\n\n\n\n\n\n<limitFile>\n \n\n\nCompile methods that are listed in the limit file.\n\n\n\n\n\n\noptlevel\n \n\n\nForces the JIT compiler to compile all methods at a specific optimization level.\n\n\n\n\n\n\nverbose\n \n\n\nReports information about the JIT and AOT compiler configuration and method compilation.\n\n\n\n\n\n\nvlog\n \n\n\nSends verbose output to a file.\n\n\n\n\n\n\n\n\ncount\n\n\n -Xjit:count=<n>\n\n\n\n\n\n\n\nwhere \n<n>\n is the number of times a method is called before it is compiled. For example, setting \ncount=0\n forces the JIT compiler to compile everything on first execution, which is useful for problem determination.\n\n\n\n\ndisableRMODE64\n\n\n(z/OS\u00ae only)\n\n\n -Xjit:disableRMODE64\n\n\n\n\n\n\n\nFrom z/OS V2R3, residency mode for 64-bit applications (RMODE64) is enabled by default. This feature allows the JIT to allocate executable code caches above the 2 GB memory bar, which is the default behavior. Use this option to turn off this JIT behavior.\n\n\n\n\nexclude\n\n\n -Xjit:exclude=<method>\n\n\n\n\n\n\n\nExcludes the specified method from compilation.\n\n\n\n\nlimitFile\n\n\n -Xjit:limitFile=(<vlog_filename>, <m>, <n>)\n\n\n\n\n\n\n\nCompile only the methods that are listed on lines \n<m>\n to \n<n>\n in the specified limit file, where the limit file is a verbose log that you generated with the \n-Xjit:verbose,vlog=<vlog_filename>\n option. Methods that are not listed in the limit file and methods that are listed on lines outside the range are not compiled.\n\n\n\n\noptlevel\n\n\n -Xjit:optlevel=[noOpt|cold|warm|hot|veryHot|scorching]\n\n\n\n\n\n\n\nForces the JIT compiler to compile all methods at a specific optimization level. Specifying \noptlevel\n might have an unexpected effect on performance, including reduced overall performance.\n\n\n\n\nverbose\n\n\n -Xjit:verbose\n\n\n\n\n\n\n\nGenerates a JIT verbose log. The log provides a summary of which methods were compiled by the JIT and some of the compilation heurisic decisions that were taken while the JIT operates inside the OpenJ9 VM.\n-Xjit:verbose={compileStart}\n\n\n\n\n\n\n\n\n\nPrints out a line when the JIT is about to start compiling a method.\n\n\n-Xjit:verbose={compileEnd}\n\n\n\n\n\n\n\n\n\nPrints out a line when the JIT stops compiling a method.\n\n\n-Xjit:verbose={compilePerformance}\n\n\n\n\n\n\n\n\n\nAdds the values \ntime\n (time taken to do the compilation) and \nmem\n (the amount of memory that was allocated during the compilation) into each line. This option includes the \ncompileStart\n and \ncompileEnd\n suboptions by default.\n\n\n-Xjit:verbose={disableInlining}\n\n\n\n\n\n\n\n\n\nTurns off inlining operations.\n\n\n-Xjit:verbose={inlining}\n\n\n\n\n\n\n\n\n\nShows the methods that are inlined.\n\n\n\n\n\n\n \nNote:\n Suboptions can be chained together by using a \n|\n character. When used, you must enclose the full option name in single quotes (') to avoid the shell misinterpreting these characters as pipe commands. For example:\n\n\njava '-Xjit:verbose={compileStart|compileEnd|inlining}' -version\n\n\n\n\n\nvlog\n\n\n -Xjit:vlog=<vlog_filename>\n\n\n\n\n\n\n\nSends verbose output to a file, of the format \n<vlog_filename>.<date>.<time>.<JVM_process_ID>\n, which is created in your current directory. Running the command multiple times produces multiple distinct versions of this file. If you do not specify this parameter, the output is sent to the standard error output stream (STDERR). This type of log file can be used with the \nlimitFile\n suboption to target the compilation of specific methods.\n\n\n\n\nExamples\n\n\nGenerating a JIT verbose log\n\n\nThe following example requests a JIT verbose log of the \njava -version\n command:\n\n\njava -Xjit:verbose,vlog=vlogfile -version\n\n\n\n\n\nAnalyzing JIT performance\n\n\nThe following example requests information about the performance of JIT compiler threads, with output written to \nvlogfile\n.\n\n\njava -Xjit:verbose={compilePerformance},vlog=vlogfile -version\n\n\n\n\n\nThe output generated by using this command adds the following information to compilation entry:\n\n\n\n\nthe amount of time taken to do the compilation.\n\n\nthe amount of memory that was allocated during the compilation.\n\n\n\n\nAnalyzing inlining operations\n\n\nThe following example generates output that contains performance data and inlining operations. The suboptions \ncount\n and \n-XcompilationThreads1\n are used only to simplify the output. These options are not recommended for production because performance will be affected.\n\n\njava '-Xjit:verbose={compileStart|compileEnd|inlining},count=5,vlog=vlogfile' -XcompilationThreads1 -version\n\n\n\n\n\n\n\n\nSee also\n\n\n\n\nDiagnosing a JIT or AOT problem",
"title": "-Xnojit"
},
{
"location": "/xjit/#-xjit-xnojit",
"text": "Use this option to control the behavior of the JIT compiler. Specifying -Xjit with no parameters, has no effect as the JIT compiler is enabled by default. -Xnojit turns off the JIT compiler but does not affect the AOT compiler.",
"title": "-Xjit / -Xnojit"
},
{
"location": "/xjit/#syntax",
"text": "Setting Action Default -Xjit Enable JIT yes -Xjit[:<parameter>=<value>{,<parameter>=<value>}] Enable JIT with options -Xnojit Disable JIT",
"title": "Syntax"
},
{
"location": "/xjit/#parameters",
"text": "These parameters can be used to modify the behavior of -Xjit : Parameter Effect count Forces compilation of methods on first invocation. disableRMODE64 Allows the JIT to allocate executable code caches above the 2 GB memory bar. exclude Excludes the specified method from compilation. <limitFile> Compile methods that are listed in the limit file. optlevel Forces the JIT compiler to compile all methods at a specific optimization level. verbose Reports information about the JIT and AOT compiler configuration and method compilation. vlog Sends verbose output to a file.",
"title": "Parameters"
},
{
"location": "/xjit/#count",
"text": "-Xjit:count=<n> where <n> is the number of times a method is called before it is compiled. For example, setting count=0 forces the JIT compiler to compile everything on first execution, which is useful for problem determination.",
"title": "count"
},
{
"location": "/xjit/#disablermode64",
"text": "(z/OS\u00ae only) -Xjit:disableRMODE64 From z/OS V2R3, residency mode for 64-bit applications (RMODE64) is enabled by default. This feature allows the JIT to allocate executable code caches above the 2 GB memory bar, which is the default behavior. Use this option to turn off this JIT behavior.",
"title": "disableRMODE64"
},
{
"location": "/xjit/#exclude",
"text": "-Xjit:exclude=<method> Excludes the specified method from compilation.",
"title": "exclude"
},
{
"location": "/xjit/#limitfile",
"text": "-Xjit:limitFile=(<vlog_filename>, <m>, <n>) Compile only the methods that are listed on lines <m> to <n> in the specified limit file, where the limit file is a verbose log that you generated with the -Xjit:verbose,vlog=<vlog_filename> option. Methods that are not listed in the limit file and methods that are listed on lines outside the range are not compiled.",
"title": "limitFile"
},
{
"location": "/xjit/#optlevel",
"text": "-Xjit:optlevel=[noOpt|cold|warm|hot|veryHot|scorching] Forces the JIT compiler to compile all methods at a specific optimization level. Specifying optlevel might have an unexpected effect on performance, including reduced overall performance.",
"title": "optlevel"
},
{
"location": "/xjit/#verbose",
"text": "-Xjit:verbose Generates a JIT verbose log. The log provides a summary of which methods were compiled by the JIT and some of the compilation heurisic decisions that were taken while the JIT operates inside the OpenJ9 VM. -Xjit:verbose={compileStart} Prints out a line when the JIT is about to start compiling a method. -Xjit:verbose={compileEnd} Prints out a line when the JIT stops compiling a method. -Xjit:verbose={compilePerformance} Adds the values time (time taken to do the compilation) and mem (the amount of memory that was allocated during the compilation) into each line. This option includes the compileStart and compileEnd suboptions by default. -Xjit:verbose={disableInlining} Turns off inlining operations. -Xjit:verbose={inlining} Shows the methods that are inlined. Note: Suboptions can be chained together by using a | character. When used, you must enclose the full option name in single quotes (') to avoid the shell misinterpreting these characters as pipe commands. For example: java '-Xjit:verbose={compileStart|compileEnd|inlining}' -version",
"title": "verbose"
},
{
"location": "/xjit/#vlog",
"text": "-Xjit:vlog=<vlog_filename> Sends verbose output to a file, of the format <vlog_filename>.<date>.<time>.<JVM_process_ID> , which is created in your current directory. Running the command multiple times produces multiple distinct versions of this file. If you do not specify this parameter, the output is sent to the standard error output stream (STDERR). This type of log file can be used with the limitFile suboption to target the compilation of specific methods.",
"title": "vlog"
},
{
"location": "/xjit/#examples",
"text": "",
"title": "Examples"
},
{
"location": "/xjit/#generating-a-jit-verbose-log",
"text": "The following example requests a JIT verbose log of the java -version command: java -Xjit:verbose,vlog=vlogfile -version",
"title": "Generating a JIT verbose log"
},
{
"location": "/xjit/#analyzing-jit-performance",
"text": "The following example requests information about the performance of JIT compiler threads, with output written to vlogfile . java -Xjit:verbose={compilePerformance},vlog=vlogfile -version The output generated by using this command adds the following information to compilation entry: the amount of time taken to do the compilation. the amount of memory that was allocated during the compilation.",
"title": "Analyzing JIT performance"
},
{
"location": "/xjit/#analyzing-inlining-operations",
"text": "The following example generates output that contains performance data and inlining operations. The suboptions count and -XcompilationThreads1 are used only to simplify the output. These options are not recommended for production because performance will be affected. java '-Xjit:verbose={compileStart|compileEnd|inlining},count=5,vlog=vlogfile' -XcompilationThreads1 -version",
"title": "Analyzing inlining operations"
},
{
"location": "/xjit/#see-also",
"text": "Diagnosing a JIT or AOT problem",
"title": "See also"
},
{
"location": "/xlinenumbers/",
"text": "-Xlinenumbers / -Xnolinenumbers\n\n\nEnables or disables line numbers in stack traces for debugging.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xlinenumbers\n\n\nEnable\n\n\nyes\n\n\n\n\n\n\n-Xnolinenumbers\n\n\nDisable\n\n\n\n\n\n\n\n\n\n\nExplanation\n\n\nIf you start the OpenJ9 VM with \n-Xnolinenumbers\n when creating a new shared classes cache, the Class Debug Area is not created. The option \n-Xnolinenumbers\n advises the VM not to load any class debug information, so there is no need for this region. If \n-Xscdmx\n is also used on the command line to specify a non zero debug area size, then a debug area is created despite the use of \n-Xnolinenumbers\n.",
"title": "-Xnolinenumbers"
},
{
"location": "/xlinenumbers/#-xlinenumbers-xnolinenumbers",
"text": "Enables or disables line numbers in stack traces for debugging.",
"title": "-Xlinenumbers / -Xnolinenumbers"
},
{
"location": "/xlinenumbers/#syntax",
"text": "Setting Effect Default -Xlinenumbers Enable yes -Xnolinenumbers Disable",
"title": "Syntax"
},
{
"location": "/xlinenumbers/#explanation",
"text": "If you start the OpenJ9 VM with -Xnolinenumbers when creating a new shared classes cache, the Class Debug Area is not created. The option -Xnolinenumbers advises the VM not to load any class debug information, so there is no need for this region. If -Xscdmx is also used on the command line to specify a non zero debug area size, then a debug area is created despite the use of -Xnolinenumbers .",
"title": "Explanation"
},
{
"location": "/xloa/",
"text": "-Xloa / -Xnoloa\n\n\nThis option enables or prevents allocation of a large object area (LOA) during garbage collection.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xloa\n\n\nEnable LOA\n\n\nyes\n (see \nDefault behavior)\n\n\n\n\n\n\n-Xnoloa\n\n\nDisable LOA\n\n\n\n\n\n\n\n\n\n\nDefault behavior\n\n\nBy default, allocations are made in the small object area (SOA). If there is no room in the SOA, and an object is larger than 64KB, the object is allocated in the LOA.\n\n\nIf the LOA is not used, it is shrunk to zero after a few collections. You can disable it explicitly by specifying the \n-Xnoloa\n option.\n\n\nExplanation\n\n\nThe LOA is an area of the tenure area of the heap set used solely to satisfy allocations for large objects. The LOA is used when the allocation request cannot be satisfied in the main area (the SOA of the tenure heap.\n\n\nAs objects are allocated and freed, the heap can become fragmented in such a way that allocation can be met only by time-consuming compactions. This problem is more pronounced if an application allocates large objects. In an attempt to alleviate this problem, the LOA is allocated. A large object in this context is considered to be any object 64 KB or greater in size. Allocations for new TLH objects are not considered to be large objects.\n\n\n \nNote:\n The Balanced Garbage Collection policy does not use the LOA. Therefore, when specifying -\nXgcpolicy:balanced\n, any LOA options passed on the command line are ignored. The policy addresses the issues of LOA by reorganizing object layout with the VM to reduce heap fragmentation and compaction requirements. \n\n\nSee also\n\n\n\n\n-Xloainitial / -Xloaminimum / -Xloamaximum",
"title": "-Xnoloa"
},
{
"location": "/xloa/#-xloa-xnoloa",
"text": "This option enables or prevents allocation of a large object area (LOA) during garbage collection.",
"title": "-Xloa / -Xnoloa"
},
{
"location": "/xloa/#syntax",
"text": "Setting Effect Default -Xloa Enable LOA yes (see Default behavior) -Xnoloa Disable LOA",
"title": "Syntax"
},
{
"location": "/xloa/#default-behavior",
"text": "By default, allocations are made in the small object area (SOA). If there is no room in the SOA, and an object is larger than 64KB, the object is allocated in the LOA. If the LOA is not used, it is shrunk to zero after a few collections. You can disable it explicitly by specifying the -Xnoloa option.",
"title": "Default behavior"
},
{
"location": "/xloa/#explanation",
"text": "The LOA is an area of the tenure area of the heap set used solely to satisfy allocations for large objects. The LOA is used when the allocation request cannot be satisfied in the main area (the SOA of the tenure heap. As objects are allocated and freed, the heap can become fragmented in such a way that allocation can be met only by time-consuming compactions. This problem is more pronounced if an application allocates large objects. In an attempt to alleviate this problem, the LOA is allocated. A large object in this context is considered to be any object 64 KB or greater in size. Allocations for new TLH objects are not considered to be large objects. Note: The Balanced Garbage Collection policy does not use the LOA. Therefore, when specifying - Xgcpolicy:balanced , any LOA options passed on the command line are ignored. The policy addresses the issues of LOA by reorganizing object layout with the VM to reduce heap fragmentation and compaction requirements.",
"title": "Explanation"
},
{
"location": "/xloa/#see-also",
"text": "-Xloainitial / -Xloaminimum / -Xloamaximum",
"title": "See also"
},
{
"location": "/xsigcatch/",
"text": "-Xsigcatch / -Xnosigcatch\n\n\nEnables and disables VM signal handling code.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xsigcatch\n\n\nEnable\n\n\nyes\n\n\n\n\n\n\n-Xnosigcatch\n\n\nDisable",
"title": "-Xnosigcatch"
},
{
"location": "/xsigcatch/#-xsigcatch-xnosigcatch",
"text": "Enables and disables VM signal handling code.",
"title": "-Xsigcatch / -Xnosigcatch"
},
{
"location": "/xsigcatch/#syntax",
"text": "Setting Effect Default -Xsigcatch Enable yes -Xnosigcatch Disable",
"title": "Syntax"
},
{
"location": "/xsigchain/",
"text": "-Xsigchain / -Xnosigchain\n\n\nEnables and disables signal handler chaining.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xsigchain\n\n\nEnable\n\n\nyes\n (except on z/OS\u00ae)\n\n\n\n\n\n\n-Xnosigchain\n\n\nDisable",
"title": "-Xnosigchain"
},
{
"location": "/xsigchain/#-xsigchain-xnosigchain",
"text": "Enables and disables signal handler chaining.",
"title": "-Xsigchain / -Xnosigchain"
},
{
"location": "/xsigchain/#syntax",
"text": "Setting Effect Default -Xsigchain Enable yes (except on z/OS\u00ae) -Xnosigchain Disable",
"title": "Syntax"
},
{
"location": "/xnumanone/",
"text": "-Xnuma:none\n\n\n(AIX\u00ae, Linux\u2122, and Windows\u2122 only)\n\n\nUse this option to turn off non-uniform memory architecture (NUMA) awareness when using the balanced garbage collection policy.\n\n\nFor workloads that do most of their work in one thread, or workloads that maintain a full heap, turning off NUMA awareness can improve performance.\n\n\nSyntax\n\n\n -Xnuma:none\n\n\n\n\n\nDefault behavior\n\n\nNUMA awareness is enabled by default.",
"title": "-Xnuma:none"
},
{
"location": "/xnumanone/#-xnumanone",
"text": "(AIX\u00ae, Linux\u2122, and Windows\u2122 only) Use this option to turn off non-uniform memory architecture (NUMA) awareness when using the balanced garbage collection policy. For workloads that do most of their work in one thread, or workloads that maintain a full heap, turning off NUMA awareness can improve performance.",
"title": "-Xnuma:none"
},
{
"location": "/xnumanone/#syntax",
"text": "-Xnuma:none",
"title": "Syntax"
},
{
"location": "/xnumanone/#default-behavior",
"text": "NUMA awareness is enabled by default.",
"title": "Default behavior"
},
{
"location": "/xoptionsfile/",
"text": "-Xoptionsfile\n\n\nSpecifies a file that contains VM options and definitions.\n\n\nThe contents of the options file are recorded in the \nENVINFO\n section of a Java\u2122 dump.\n\n\nSyntax\n\n\n -Xoptionsfile=<file_name>\n\n\n\n\n\n\n\nwhere \n<file_name>\n specifies a file that contains options that are processed as if they had been entered directly as command-line options.\n\n\n\n\nExplanation\n\n\nAt startup, the VM automatically adds \n-Xoptionsfile=<path>/options.default\n at the beginning of the command line, where \n<path>\n is the path to the VM directory.\n\n\n \n<path>\n is the VM directory, as show in \nDirectory conventions\n.\n\n\n \n<path>\n is the \n<java_home>/lib\n directory, where \n<java_home>\n is the directory for your runtime environment.\n\n\nThe file \noptions.default\n is empty but can be updated with any options that you want to specify at run time.\n\n\nThe options file does not support these options:\n\n\n\n\n-assert\n\n\n-fullversion\n\n\n-help\n\n\n-showversion\n\n\n-version\n\n\n-Xcompressedrefs\n\n\n-Xcheck:memory\n\n\n-Xoptionsfile\n\n\n\n\nAlthough you cannot use \n-Xoptionsfile\n recursively within an options file, you can use \n-Xoptionsfile\n multiple times on the same command line to load more than one options files.\n\n\nSome options use quoted strings as parameters. Do not split quoted strings over multiple lines using the forward slash line continuation character (\\). The Yen symbol (\u00a5) is not supported as a line continuation character. For example, the following example is not valid in an options file:\n\n\n-\nXevents\n=\nvmstop\n,\nexec\n=\n\"cmd /c \\\n\n\necho %pid has finished.\"\n\n\n\n\n\n\nThe following example is valid in an options file:\n\n\n-\nXevents\n=\nvmstop\n,\n \n\\\n\n\nexec\n=\n\"cmd /c echo %pid has finished.\"\n\n\n\n\n\n\nExample\n\n\nHere is an example of an options file:\n\n\n#\nMy\n \noptions\n \nfile\n\n\n-\nX\n<\noption1\n>\n\n\n-\nX\n<\noption2\n>=\n\\\n\n\n<\nvalue1\n>,\n\\\n\n\n<\nvalue2\n>\n\n\n-\nD\n<\nsysprop1\n>=<\nvalue1\n>\n\n\n\n\n\n\nSee also\n\n\n\n\nSpecifying command-line options\n\n\nJavadump: TITLE, GPINFO, and ENVINFO sections",
"title": "-Xoptionsfile"
},
{
"location": "/xoptionsfile/#-xoptionsfile",
"text": "Specifies a file that contains VM options and definitions. The contents of the options file are recorded in the ENVINFO section of a Java\u2122 dump.",
"title": "-Xoptionsfile"
},
{
"location": "/xoptionsfile/#syntax",
"text": "-Xoptionsfile=<file_name> where <file_name> specifies a file that contains options that are processed as if they had been entered directly as command-line options.",
"title": "Syntax"
},
{
"location": "/xoptionsfile/#explanation",
"text": "At startup, the VM automatically adds -Xoptionsfile=<path>/options.default at the beginning of the command line, where <path> is the path to the VM directory. <path> is the VM directory, as show in Directory conventions . <path> is the <java_home>/lib directory, where <java_home> is the directory for your runtime environment. The file options.default is empty but can be updated with any options that you want to specify at run time. The options file does not support these options: -assert -fullversion -help -showversion -version -Xcompressedrefs -Xcheck:memory -Xoptionsfile Although you cannot use -Xoptionsfile recursively within an options file, you can use -Xoptionsfile multiple times on the same command line to load more than one options files. Some options use quoted strings as parameters. Do not split quoted strings over multiple lines using the forward slash line continuation character (\\). The Yen symbol (\u00a5) is not supported as a line continuation character. For example, the following example is not valid in an options file: - Xevents = vmstop , exec = \"cmd /c \\ echo %pid has finished.\" The following example is valid in an options file: - Xevents = vmstop , \\ exec = \"cmd /c echo %pid has finished.\"",
"title": "Explanation"
},
{
"location": "/xoptionsfile/#example",
"text": "Here is an example of an options file: # My options file - X < option1 > - X < option2 >= \\ < value1 >, \\ < value2 > - D < sysprop1 >=< value1 >",
"title": "Example"
},
{
"location": "/xoptionsfile/#see-also",
"text": "Specifying command-line options Javadump: TITLE, GPINFO, and ENVINFO sections",
"title": "See also"
},
{
"location": "/xquickstart/",
"text": "-Xquickstart\n\n\nThis option causes the JIT compiler to run with a subset of optimizations, which can improve the performance of short-running applications.\n\n\n \nNote:\n For compatibility with other Java\u2122 virtual machines, you can also specify the \n-client\n option, which results in identical behavior to \n-Xquickstart\n.\n\n\nSyntax\n\n\n -Xquickstart\n\n\n\n\n\nDefault behavior\n\n\nBy default, \n-Xquickstart\n is disabled.\n\n\nExplanation\n\n\nThe JIT compiler is tuned for long-running applications typically used on a server. When you specify this option, the compiler uses a subset of optimizations, which results in faster compilation times that improve startup time. However, longer running applications might run more slowly, especially applications that contain hot methods and other methods using a large amount of processing resource. \n\n\nWhen the AOT compiler is active (both shared classes and AOT compilation enabled), \n-Xquickstart\n causes all methods to be AOT compiled. The AOT compilation improves the startup time of subsequent runs, but might reduce performance for longer running applications, especially those that contain hot methods.\n\n\n \nNote:\n The implementation of \n-Xquickstart\n is subject to change in future releases.",
"title": "-Xquickstart"
},
{
"location": "/xquickstart/#-xquickstart",
"text": "This option causes the JIT compiler to run with a subset of optimizations, which can improve the performance of short-running applications. Note: For compatibility with other Java\u2122 virtual machines, you can also specify the -client option, which results in identical behavior to -Xquickstart .",
"title": "-Xquickstart"
},
{
"location": "/xquickstart/#syntax",
"text": "-Xquickstart",
"title": "Syntax"
},
{
"location": "/xquickstart/#default-behavior",
"text": "By default, -Xquickstart is disabled.",
"title": "Default behavior"
},
{
"location": "/xquickstart/#explanation",
"text": "The JIT compiler is tuned for long-running applications typically used on a server. When you specify this option, the compiler uses a subset of optimizations, which results in faster compilation times that improve startup time. However, longer running applications might run more slowly, especially applications that contain hot methods and other methods using a large amount of processing resource. When the AOT compiler is active (both shared classes and AOT compilation enabled), -Xquickstart causes all methods to be AOT compiled. The AOT compilation improves the startup time of subsequent runs, but might reduce performance for longer running applications, especially those that contain hot methods. Note: The implementation of -Xquickstart is subject to change in future releases.",
"title": "Explanation"
},
{
"location": "/xrdbginfo/",
"text": "-Xrdbginfo\n\n\nLoads the remote debug information server with the specified host and port.\n\n\nSyntax\n\n\n -Xrdbginfo:<host>:<port>\n\n\n\n\n\ndefault behavior\n\n\nBy default, the remote debug information server is disabled.",
"title": "-Xrdbginfo"
},
{
"location": "/xrdbginfo/#-xrdbginfo",
"text": "Loads the remote debug information server with the specified host and port.",
"title": "-Xrdbginfo"
},
{
"location": "/xrdbginfo/#syntax",
"text": "-Xrdbginfo:<host>:<port>",
"title": "Syntax"
},
{
"location": "/xrdbginfo/#default-behavior",
"text": "By default, the remote debug information server is disabled.",
"title": "default behavior"
},
{
"location": "/xrs/",
"text": "-Xrs\n\n\nPrevents the OpenJ9 run time environment from handling any internally or externally generated signals such as \nSIGSEGV\n and \nSIGABRT\n. Any signals that are raised are handled by the default operating system handlers.\n\n\nDisabling signal handling in the OpenJ9 VM reduces performance by approximately 2-4%, depending on the application.\n\n\n \nNote:\n Setting this option prevents dumps being generated by the OpenJ9 VM for signals such as \nSIGSEGV\n and \nSIGABRT\n, because the VM is no longer intercepting these signals.\n\n\nSyntax\n\n\n -Xrs\n -Xrs:sync\n\n\n\n\n\nParameters\n\n\n\n\n\n\nIf you specify the \nsync\n parameter:\n\n\n\n\nOn AIX\u00ae systems:\n Disables signal handling in the VM for \nSIGSEGV\n, \nSIGFPE\n, \nSIGBUS\n, \nSIGILL\n, \nSIGTRAP\n, and \nSIGABRT\n signals. However, the VM still handles the \nSIGQUIT\n and \nSIGTERM\n signals, among others.\n\n\nOn Windows\u2122 systems:\n Hardware exceptions are not handled by the OpenJ9 VM when this option is specified. However, the Windows CTRL_BREAK_EVENT signal, triggered by the Ctrl-Break key combination, is still handled by the VM.\n\n\nLinux\u2122 systems\n always use the \nSIGUSR1\n signal.",
"title": "-Xrs"
},
{
"location": "/xrs/#-xrs",
"text": "Prevents the OpenJ9 run time environment from handling any internally or externally generated signals such as SIGSEGV and SIGABRT . Any signals that are raised are handled by the default operating system handlers. Disabling signal handling in the OpenJ9 VM reduces performance by approximately 2-4%, depending on the application. Note: Setting this option prevents dumps being generated by the OpenJ9 VM for signals such as SIGSEGV and SIGABRT , because the VM is no longer intercepting these signals.",
"title": "-Xrs"
},
{
"location": "/xrs/#syntax",
"text": "-Xrs\n -Xrs:sync",
"title": "Syntax"
},
{
"location": "/xrs/#parameters",
"text": "If you specify the sync parameter: On AIX\u00ae systems: Disables signal handling in the VM for SIGSEGV , SIGFPE , SIGBUS , SIGILL , SIGTRAP , and SIGABRT signals. However, the VM still handles the SIGQUIT and SIGTERM signals, among others. On Windows\u2122 systems: Hardware exceptions are not handled by the OpenJ9 VM when this option is specified. However, the Windows CTRL_BREAK_EVENT signal, triggered by the Ctrl-Break key combination, is still handled by the VM. Linux\u2122 systems always use the SIGUSR1 signal.",
"title": "Parameters"
},
{
"location": "/xsamplingexpirationtime/",
"text": "-XsamplingExpirationTime\n\n\nDisables JIT sampling after a specified amount of time. \n\n\nWhen the JIT sampling thread is disabled, no processor cycles are used by an idle OpenJ9 VM.\n\n\nUse this option with care; after the sampling thread is disabled, you cannot reactivate it. However, because the profiling frequency is automatically reduced, you should not have to use this option. \n\n\nAllow the sampling thread to run for long enough to identify important optimizations.\n\n\nSyntax\n\n\n -XsamplingExpirationTime<time>\n\n\n\n\n\n\n\nwhere \n<time>\n is specified in seconds.\n\n\n\n\nExplanation\n\n\nThe JIT sampling thread profiles the running Java\u2122 application to discover commonly used methods. The memory and processor usage of the sampling thread is negligible, and the frequency of profiling is automatically reduced when the OpenJ9 VM is idle, to once per second instead of once every 10ms, or once every 100 seconds if the idle state lasts more than 50 seconds.",
"title": "-XsamplingExpirationTime"
},
{
"location": "/xsamplingexpirationtime/#-xsamplingexpirationtime",
"text": "Disables JIT sampling after a specified amount of time. When the JIT sampling thread is disabled, no processor cycles are used by an idle OpenJ9 VM. Use this option with care; after the sampling thread is disabled, you cannot reactivate it. However, because the profiling frequency is automatically reduced, you should not have to use this option. Allow the sampling thread to run for long enough to identify important optimizations.",
"title": "-XsamplingExpirationTime"
},
{
"location": "/xsamplingexpirationtime/#syntax",
"text": "-XsamplingExpirationTime<time> where <time> is specified in seconds.",
"title": "Syntax"
},
{
"location": "/xsamplingexpirationtime/#explanation",
"text": "The JIT sampling thread profiles the running Java\u2122 application to discover commonly used methods. The memory and processor usage of the sampling thread is negligible, and the frequency of profiling is automatically reduced when the OpenJ9 VM is idle, to once per second instead of once every 10ms, or once every 100 seconds if the idle state lasts more than 50 seconds.",
"title": "Explanation"
},
{
"location": "/xscdmx/",
"text": "-Xscdmx\n\n\nUse the \n-Xscdmx\n option to control the size of the class debug area when you create a shared class cache.\n\n\nSyntax\n\n\n -Xscdmx<size>\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\n\nExplanation\n\n\nThe \n-Xscdmx\n option works in a similar way to the \n-Xscmx\n option, which is used to control the overall size of the shared class cache. The size of \n-Xscdmx\n must be smaller than the size of \n-Xscmx\n. By default, the size of the class debug area is a percentage of the free class data bytes in a newly created or empty cache.\n\n\nA class debug area is still created if you use the \n-Xnolinenumbers\n option with the \n-Xscdmx\n option on the command line.",
"title": "-Xscdmx"
},
{
"location": "/xscdmx/#-xscdmx",
"text": "Use the -Xscdmx option to control the size of the class debug area when you create a shared class cache.",
"title": "-Xscdmx"
},
{
"location": "/xscdmx/#syntax",
"text": "-Xscdmx<size> See Using -X command-line options for more information about the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xscdmx/#explanation",
"text": "The -Xscdmx option works in a similar way to the -Xscmx option, which is used to control the overall size of the shared class cache. The size of -Xscdmx must be smaller than the size of -Xscmx . By default, the size of the class debug area is a percentage of the free class data bytes in a newly created or empty cache. A class debug area is still created if you use the -Xnolinenumbers option with the -Xscdmx option on the command line.",
"title": "Explanation"
},
{
"location": "/xscminaot/",
"text": "-Xscminaot / -Xscmaxaot\n\n\nWhen you create a shared classes cache, you can use these options to set the minimum and maximum number of bytes in the class cache to reserve for AOT data.\n\n\nSetting \n-Xscmaxaot\n is useful if you want a certain amount of cache space guaranteed for non-AOT data.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xscminaot<size>\n\n\nSet minimum size for AOT class cache\n\n\n0\n\n\n\n\n\n\n-Xscmaxaot<size>\n\n\nSet maximum size for AOT class cache\n\n\nThe amount of free space in the cache\n\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\n\n-Xscminaot\n\n\nIf \n-Xscminaot\n is not specified, no space is reserved for AOT data. However, AOT data is still written to the cache until the cache is full or the \n-Xscmaxaot\n limit is reached. \n\n\nThe value of \n-Xscminaot\n must not exceed the value of \n-Xscmx\n or \n-Xscmaxaot\n and should be considerably less than the total cache size, because AOT data can be created only for cached classes. If the value of \n-Xscminaot\n equals the value of \n-Xscmx\n, no class data or AOT data can be stored.\n\n\n\n\nYou can also adjust the \n-Xscminaot\n value by using:\n\n\n-Xshareclasses:adjustminaot=<size>\n option\n\n\nMemoryMXBean.setSharedClassCacheMinAotBytes()\n method in the \ncom.ibm.lang.management\n API\n\n\n\n\n\n\nYou can also adjust the \n-Xscmaxaot\n value by using:\n\n\n-Xshareclasses:adjustmaxaot=<size>\n option\n\n\nMemoryMXBean.setSharedClassCacheMaxAotBytes()\n method in the \ncom.ibm.lang.management\n API.\n\n\n\n\n\n\n\n\n-Xscmaxaot\n\n\nThe value of this option must not be smaller than the value of \n-Xscminaot\n and must not be larger than the value of \n-Xscmx\n.\n\n\nWhen you run an application with the \n-Xshareclasses:verbose\n option, the VM writes to the console the amount of AOT data that is not stored due to the current setting of the maximum AOT data space. You can also get this information by using the \nMemoryMXBean.getSharedClassCacheMaxAotUnstoredBytes()\n method in the \ncom.ibm.lang.management\n API. You can increase the maximum AOT data space size accordingly if you want to add the unstored AOT data to the shared cache.\n\n\nSee also\n\n\n\n\n-Xshareclasses",
"title": "-Xscmaxaot"
},
{
"location": "/xscminaot/#-xscminaot-xscmaxaot",
"text": "When you create a shared classes cache, you can use these options to set the minimum and maximum number of bytes in the class cache to reserve for AOT data. Setting -Xscmaxaot is useful if you want a certain amount of cache space guaranteed for non-AOT data.",
"title": "-Xscminaot / -Xscmaxaot"
},
{
"location": "/xscminaot/#syntax",
"text": "Setting Effect Default -Xscminaot<size> Set minimum size for AOT class cache 0 -Xscmaxaot<size> Set maximum size for AOT class cache The amount of free space in the cache See Using -X command-line options for more information about the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xscminaot/#-xscminaot",
"text": "If -Xscminaot is not specified, no space is reserved for AOT data. However, AOT data is still written to the cache until the cache is full or the -Xscmaxaot limit is reached. The value of -Xscminaot must not exceed the value of -Xscmx or -Xscmaxaot and should be considerably less than the total cache size, because AOT data can be created only for cached classes. If the value of -Xscminaot equals the value of -Xscmx , no class data or AOT data can be stored. You can also adjust the -Xscminaot value by using: -Xshareclasses:adjustminaot=<size> option MemoryMXBean.setSharedClassCacheMinAotBytes() method in the com.ibm.lang.management API You can also adjust the -Xscmaxaot value by using: -Xshareclasses:adjustmaxaot=<size> option MemoryMXBean.setSharedClassCacheMaxAotBytes() method in the com.ibm.lang.management API.",
"title": "-Xscminaot"
},
{
"location": "/xscminaot/#-xscmaxaot",
"text": "The value of this option must not be smaller than the value of -Xscminaot and must not be larger than the value of -Xscmx . When you run an application with the -Xshareclasses:verbose option, the VM writes to the console the amount of AOT data that is not stored due to the current setting of the maximum AOT data space. You can also get this information by using the MemoryMXBean.getSharedClassCacheMaxAotUnstoredBytes() method in the com.ibm.lang.management API. You can increase the maximum AOT data space size accordingly if you want to add the unstored AOT data to the shared cache.",
"title": "-Xscmaxaot"
},
{
"location": "/xscminaot/#see-also",
"text": "-Xshareclasses",
"title": "See also"
},
{
"location": "/xscminjitdata/",
"text": "-Xscminjitdata / -Xscmaxjitdata\n\n\nWhen you create a shared classes cache, you can use these options to set a minimum and maximum number of bytes in the class cache that can be used for JIT data.\n\n\nWhen you run an application with the \n-Xshareclasses:verbose\n option, the VM writes to the console the amount of JIT data that is not stored due to the current setting of the the maximum JIT data space. You can also get this information by using the \nMemoryMXBean.getSharedClassCacheMaxJitDataUnstoredBytes()\n method in the \ncom.ibm.lang.management\n API. \n\n\nYou can increase the maximum JIT data space size accordingly if you want to add the unstored data to the shared cache. However, the VM that provided the information no longer has the opportunity to store the JIT data. Subsequent VMs can store JIT data in the shared cache.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xscminjitdata<size>\n\n\nSet minimum size for JIT data\n\n\n0 (See \nDefault behavior\n)\n\n\n\n\n\n\n-Xscmaxjitdata<size>\n\n\nSet maximum size for JIT data\n\n\nThe amount of free space in the cache\n\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\n\nDefault behavior\n\n\nIf \n-Xscminjitdata\n is not specified, no space is reserved for JIT data, although JIT data is still written to the cache until the cache is full or the \n-Xscmaxjitdata\n limit is reached. \n\n\nExplanation\n\n\n-Xscminjitdata\n\n\nThe value of \n-Xscminjitdata\n must not exceed the value of \n-Xscmx\n or \n-Xscmaxjitdata\n. The value of \n-Xscminjitdata\n must always be considerably less than the total cache size, because JIT data can be created only for cached classes. If the value of \n-Xscminjitdata\n equals the value of \n-Xscmx\n, no class data or JIT data can be stored.\n\n\n\n\nYou can also adjust the \n-Xscminjitdata\n value by using:\n\n\n-Xshareclasses:adjustminjitdata=<size>\n option\n\n\nMemoryMXBean.setSharedClassCacheMinJitDataBytes()\n method in the \ncom.ibm.lang.management\n API.\n\n\n\n\n\n\n\n\n-Xscmaxjitdata\n\n\nSetting \n-Xscmaxjitdata\n is useful if you want a certain amount of cache space guaranteed for non-JIT data. If this option is not specified, the maximum limit for JIT data is the amount of free space in the cache. The value of this option must not be smaller than the value of \n-Xscminjitdata\n, and must not be larger than the value of \n-Xscmx\n.\n\n\n\n\nYou can also adjust the \n-Xscmaxjitdata\n value by using:\n\n\n-Xshareclasses:adjustmaxjitdata=<size>\n option\n\n\nMemoryMXBean.setSharedClassCacheMinJitDataBytes()\n method in the \ncom.ibm.lang.management\n API.\n\n\n\n\n\n\n\n\nSee also\n\n\n\n\n-Xscmx",
"title": "-Xscmaxjitdata"
},
{
"location": "/xscminjitdata/#-xscminjitdata-xscmaxjitdata",
"text": "When you create a shared classes cache, you can use these options to set a minimum and maximum number of bytes in the class cache that can be used for JIT data. When you run an application with the -Xshareclasses:verbose option, the VM writes to the console the amount of JIT data that is not stored due to the current setting of the the maximum JIT data space. You can also get this information by using the MemoryMXBean.getSharedClassCacheMaxJitDataUnstoredBytes() method in the com.ibm.lang.management API. You can increase the maximum JIT data space size accordingly if you want to add the unstored data to the shared cache. However, the VM that provided the information no longer has the opportunity to store the JIT data. Subsequent VMs can store JIT data in the shared cache.",
"title": "-Xscminjitdata / -Xscmaxjitdata"
},
{
"location": "/xscminjitdata/#syntax",
"text": "Setting Effect Default -Xscminjitdata<size> Set minimum size for JIT data 0 (See Default behavior ) -Xscmaxjitdata<size> Set maximum size for JIT data The amount of free space in the cache See Using -X command-line options for more information about the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xscminjitdata/#default-behavior",
"text": "If -Xscminjitdata is not specified, no space is reserved for JIT data, although JIT data is still written to the cache until the cache is full or the -Xscmaxjitdata limit is reached.",
"title": "Default behavior"
},
{
"location": "/xscminjitdata/#explanation",
"text": "",
"title": "Explanation"
},
{
"location": "/xscminjitdata/#-xscminjitdata",
"text": "The value of -Xscminjitdata must not exceed the value of -Xscmx or -Xscmaxjitdata . The value of -Xscminjitdata must always be considerably less than the total cache size, because JIT data can be created only for cached classes. If the value of -Xscminjitdata equals the value of -Xscmx , no class data or JIT data can be stored. You can also adjust the -Xscminjitdata value by using: -Xshareclasses:adjustminjitdata=<size> option MemoryMXBean.setSharedClassCacheMinJitDataBytes() method in the com.ibm.lang.management API.",
"title": "-Xscminjitdata"
},
{
"location": "/xscminjitdata/#-xscmaxjitdata",
"text": "Setting -Xscmaxjitdata is useful if you want a certain amount of cache space guaranteed for non-JIT data. If this option is not specified, the maximum limit for JIT data is the amount of free space in the cache. The value of this option must not be smaller than the value of -Xscminjitdata , and must not be larger than the value of -Xscmx . You can also adjust the -Xscmaxjitdata value by using: -Xshareclasses:adjustmaxjitdata=<size> option MemoryMXBean.setSharedClassCacheMinJitDataBytes() method in the com.ibm.lang.management API.",
"title": "-Xscmaxjitdata"
},
{
"location": "/xscminjitdata/#see-also",
"text": "-Xscmx",
"title": "See also"
},
{
"location": "/xscminaot/",
"text": "-Xscminaot / -Xscmaxaot\n\n\nWhen you create a shared classes cache, you can use these options to set the minimum and maximum number of bytes in the class cache to reserve for AOT data.\n\n\nSetting \n-Xscmaxaot\n is useful if you want a certain amount of cache space guaranteed for non-AOT data.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xscminaot<size>\n\n\nSet minimum size for AOT class cache\n\n\n0\n\n\n\n\n\n\n-Xscmaxaot<size>\n\n\nSet maximum size for AOT class cache\n\n\nThe amount of free space in the cache\n\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\n\n-Xscminaot\n\n\nIf \n-Xscminaot\n is not specified, no space is reserved for AOT data. However, AOT data is still written to the cache until the cache is full or the \n-Xscmaxaot\n limit is reached. \n\n\nThe value of \n-Xscminaot\n must not exceed the value of \n-Xscmx\n or \n-Xscmaxaot\n and should be considerably less than the total cache size, because AOT data can be created only for cached classes. If the value of \n-Xscminaot\n equals the value of \n-Xscmx\n, no class data or AOT data can be stored.\n\n\n\n\nYou can also adjust the \n-Xscminaot\n value by using:\n\n\n-Xshareclasses:adjustminaot=<size>\n option\n\n\nMemoryMXBean.setSharedClassCacheMinAotBytes()\n method in the \ncom.ibm.lang.management\n API\n\n\n\n\n\n\nYou can also adjust the \n-Xscmaxaot\n value by using:\n\n\n-Xshareclasses:adjustmaxaot=<size>\n option\n\n\nMemoryMXBean.setSharedClassCacheMaxAotBytes()\n method in the \ncom.ibm.lang.management\n API.\n\n\n\n\n\n\n\n\n-Xscmaxaot\n\n\nThe value of this option must not be smaller than the value of \n-Xscminaot\n and must not be larger than the value of \n-Xscmx\n.\n\n\nWhen you run an application with the \n-Xshareclasses:verbose\n option, the VM writes to the console the amount of AOT data that is not stored due to the current setting of the maximum AOT data space. You can also get this information by using the \nMemoryMXBean.getSharedClassCacheMaxAotUnstoredBytes()\n method in the \ncom.ibm.lang.management\n API. You can increase the maximum AOT data space size accordingly if you want to add the unstored AOT data to the shared cache.\n\n\nSee also\n\n\n\n\n-Xshareclasses",
"title": "-Xscminaot"
},
{
"location": "/xscminaot/#-xscminaot-xscmaxaot",
"text": "When you create a shared classes cache, you can use these options to set the minimum and maximum number of bytes in the class cache to reserve for AOT data. Setting -Xscmaxaot is useful if you want a certain amount of cache space guaranteed for non-AOT data.",
"title": "-Xscminaot / -Xscmaxaot"
},
{
"location": "/xscminaot/#syntax",
"text": "Setting Effect Default -Xscminaot<size> Set minimum size for AOT class cache 0 -Xscmaxaot<size> Set maximum size for AOT class cache The amount of free space in the cache See Using -X command-line options for more information about the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xscminaot/#-xscminaot",
"text": "If -Xscminaot is not specified, no space is reserved for AOT data. However, AOT data is still written to the cache until the cache is full or the -Xscmaxaot limit is reached. The value of -Xscminaot must not exceed the value of -Xscmx or -Xscmaxaot and should be considerably less than the total cache size, because AOT data can be created only for cached classes. If the value of -Xscminaot equals the value of -Xscmx , no class data or AOT data can be stored. You can also adjust the -Xscminaot value by using: -Xshareclasses:adjustminaot=<size> option MemoryMXBean.setSharedClassCacheMinAotBytes() method in the com.ibm.lang.management API You can also adjust the -Xscmaxaot value by using: -Xshareclasses:adjustmaxaot=<size> option MemoryMXBean.setSharedClassCacheMaxAotBytes() method in the com.ibm.lang.management API.",
"title": "-Xscminaot"
},
{
"location": "/xscminaot/#-xscmaxaot",
"text": "The value of this option must not be smaller than the value of -Xscminaot and must not be larger than the value of -Xscmx . When you run an application with the -Xshareclasses:verbose option, the VM writes to the console the amount of AOT data that is not stored due to the current setting of the maximum AOT data space. You can also get this information by using the MemoryMXBean.getSharedClassCacheMaxAotUnstoredBytes() method in the com.ibm.lang.management API. You can increase the maximum AOT data space size accordingly if you want to add the unstored AOT data to the shared cache.",
"title": "-Xscmaxaot"
},
{
"location": "/xscminaot/#see-also",
"text": "-Xshareclasses",
"title": "See also"
},
{
"location": "/xscminjitdata/",
"text": "-Xscminjitdata / -Xscmaxjitdata\n\n\nWhen you create a shared classes cache, you can use these options to set a minimum and maximum number of bytes in the class cache that can be used for JIT data.\n\n\nWhen you run an application with the \n-Xshareclasses:verbose\n option, the VM writes to the console the amount of JIT data that is not stored due to the current setting of the the maximum JIT data space. You can also get this information by using the \nMemoryMXBean.getSharedClassCacheMaxJitDataUnstoredBytes()\n method in the \ncom.ibm.lang.management\n API. \n\n\nYou can increase the maximum JIT data space size accordingly if you want to add the unstored data to the shared cache. However, the VM that provided the information no longer has the opportunity to store the JIT data. Subsequent VMs can store JIT data in the shared cache.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xscminjitdata<size>\n\n\nSet minimum size for JIT data\n\n\n0 (See \nDefault behavior\n)\n\n\n\n\n\n\n-Xscmaxjitdata<size>\n\n\nSet maximum size for JIT data\n\n\nThe amount of free space in the cache\n\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\n\nDefault behavior\n\n\nIf \n-Xscminjitdata\n is not specified, no space is reserved for JIT data, although JIT data is still written to the cache until the cache is full or the \n-Xscmaxjitdata\n limit is reached. \n\n\nExplanation\n\n\n-Xscminjitdata\n\n\nThe value of \n-Xscminjitdata\n must not exceed the value of \n-Xscmx\n or \n-Xscmaxjitdata\n. The value of \n-Xscminjitdata\n must always be considerably less than the total cache size, because JIT data can be created only for cached classes. If the value of \n-Xscminjitdata\n equals the value of \n-Xscmx\n, no class data or JIT data can be stored.\n\n\n\n\nYou can also adjust the \n-Xscminjitdata\n value by using:\n\n\n-Xshareclasses:adjustminjitdata=<size>\n option\n\n\nMemoryMXBean.setSharedClassCacheMinJitDataBytes()\n method in the \ncom.ibm.lang.management\n API.\n\n\n\n\n\n\n\n\n-Xscmaxjitdata\n\n\nSetting \n-Xscmaxjitdata\n is useful if you want a certain amount of cache space guaranteed for non-JIT data. If this option is not specified, the maximum limit for JIT data is the amount of free space in the cache. The value of this option must not be smaller than the value of \n-Xscminjitdata\n, and must not be larger than the value of \n-Xscmx\n.\n\n\n\n\nYou can also adjust the \n-Xscmaxjitdata\n value by using:\n\n\n-Xshareclasses:adjustmaxjitdata=<size>\n option\n\n\nMemoryMXBean.setSharedClassCacheMinJitDataBytes()\n method in the \ncom.ibm.lang.management\n API.\n\n\n\n\n\n\n\n\nSee also\n\n\n\n\n-Xscmx",
"title": "-Xscminjitdata"
},
{
"location": "/xscminjitdata/#-xscminjitdata-xscmaxjitdata",
"text": "When you create a shared classes cache, you can use these options to set a minimum and maximum number of bytes in the class cache that can be used for JIT data. When you run an application with the -Xshareclasses:verbose option, the VM writes to the console the amount of JIT data that is not stored due to the current setting of the the maximum JIT data space. You can also get this information by using the MemoryMXBean.getSharedClassCacheMaxJitDataUnstoredBytes() method in the com.ibm.lang.management API. You can increase the maximum JIT data space size accordingly if you want to add the unstored data to the shared cache. However, the VM that provided the information no longer has the opportunity to store the JIT data. Subsequent VMs can store JIT data in the shared cache.",
"title": "-Xscminjitdata / -Xscmaxjitdata"
},
{
"location": "/xscminjitdata/#syntax",
"text": "Setting Effect Default -Xscminjitdata<size> Set minimum size for JIT data 0 (See Default behavior ) -Xscmaxjitdata<size> Set maximum size for JIT data The amount of free space in the cache See Using -X command-line options for more information about the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xscminjitdata/#default-behavior",
"text": "If -Xscminjitdata is not specified, no space is reserved for JIT data, although JIT data is still written to the cache until the cache is full or the -Xscmaxjitdata limit is reached.",
"title": "Default behavior"
},
{
"location": "/xscminjitdata/#explanation",
"text": "",
"title": "Explanation"
},
{
"location": "/xscminjitdata/#-xscminjitdata",
"text": "The value of -Xscminjitdata must not exceed the value of -Xscmx or -Xscmaxjitdata . The value of -Xscminjitdata must always be considerably less than the total cache size, because JIT data can be created only for cached classes. If the value of -Xscminjitdata equals the value of -Xscmx , no class data or JIT data can be stored. You can also adjust the -Xscminjitdata value by using: -Xshareclasses:adjustminjitdata=<size> option MemoryMXBean.setSharedClassCacheMinJitDataBytes() method in the com.ibm.lang.management API.",
"title": "-Xscminjitdata"
},
{
"location": "/xscminjitdata/#-xscmaxjitdata",
"text": "Setting -Xscmaxjitdata is useful if you want a certain amount of cache space guaranteed for non-JIT data. If this option is not specified, the maximum limit for JIT data is the amount of free space in the cache. The value of this option must not be smaller than the value of -Xscminjitdata , and must not be larger than the value of -Xscmx . You can also adjust the -Xscmaxjitdata value by using: -Xshareclasses:adjustmaxjitdata=<size> option MemoryMXBean.setSharedClassCacheMinJitDataBytes() method in the com.ibm.lang.management API.",
"title": "-Xscmaxjitdata"
},
{
"location": "/xscminjitdata/#see-also",
"text": "-Xscmx",
"title": "See also"
},
{
"location": "/xscmx/",
"text": "-Xscmx\n\n\nFor a new shared class cache, specifies either:\n\n\n\n\nthe actual size of the cache, if the \n-XX:SharedCacheHardLimit\n option is not present\n\n\nthe soft maximum size of the cache, if used with the \n-XX:SharedCacheHardLimit\n option\n(See \n-XX:SharedCacheHardLimit\n)\n\n\n\n\nThis option applies only if a cache is being created and no cache of the same name exists.\n\n\nWhen you run an application with the \n-Xshareclasses:verbose\n option, the VM writes to the console the number of bytes that are not stored due to the current setting of the soft maximum size. You can also get this information by using the \nMemoryMXBean.getSharedClassCacheSoftmxUnstoredBytes()\n method in the \ncom.ibm.lang.management\n API.\n\n\nYou can increase the soft maximum size accordingly if you want to add the unstored data to the shared cache. However, the VM that provided the information no longer has the opportunity to store that data. Therefore, increasing the soft maximum size does not necessarily cause any more data to be stored in the shared cache by the current VM, but subsequent VMs can add data to the shared cache.\n\n\nSyntax\n\n\n -Xscmx<size>\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\n\nExplanation\n\n\nSetting a soft maximum size\n\n\nIf you specify the \n-Xscmx\n option with the \n-XX:SharedCacheHardLimit\n option, the \n-Xscmx\n option sets the \nsoft maximum size\n of a new shared class cache, and the \n-XX:SharedCacheHardLimit\n option sets the actual maximum size. The value of the \n-Xscmx\n option must therefore not exceed the value of \n-XX:SharedCacheHardLimit\n.\n\n\nWhen the soft maximum limit is reached, no more data can be added into the shared cache, unless there is reserved AOT or JIT data space. If such reserved space exists, AOT or JIT data can still be added into the reserved space. The reserved AOT and JIT data spaces are counted as used space within the soft maximum size, so the soft maximum size should not be less than the minimum reserved space for AOT and JIT data if you specify the \n-Xscminaot\n or \n-Xscminjitdata\n options.\n\n\nYou can change the soft maximum size by using the \n-Xshareclasses:adjustsoftmx=<size>\n option or the \nMemoryMXBean.setSharedClassCacheSoftmxBytes()\n method in the \ncom.ibm.lang.management\n API. By using this API, Java\u2122 applications can dynamically monitor and adjust the cache soft maximum size as required. This function can be useful in virtualized or cloud environments, for example, where the shared cache size might change dynamically to meet business needs.\n\n\nFor example, you might create a 64 MB shared cache and set a smaller value, such as 16 MB, for the \n-Xscmx\n option, to limit the data stored in the cache:\n\n\n-\nXX\n:\nSharedCacheHardLimit\n=\n64\nm\n \n-\nXscmx16m\n\n\n\n\n\n\nYou can then use the \ncom.ibm.lang.management\n API from within a Java application to increase the soft maximum value during run time, as load increases. This change allows the application to use more shared cache space than you specified initially.\n\n\nYou can increase the soft maximum size if it is currently less than the actual cache size. If you attempt to reduce the soft maximum size to a value that is less than the number of bytes already used in the cache, the number of used bytes is set as the new soft maximum size.\n\n\nFor more information about cache sizes, see \nCache size limits\n.\n\n\nSee also\n\n\n\n\n-Xscdmx\n (control the size of the class debug area)",
"title": "-Xscmx"
},
{
"location": "/xscmx/#-xscmx",
"text": "For a new shared class cache, specifies either: the actual size of the cache, if the -XX:SharedCacheHardLimit option is not present the soft maximum size of the cache, if used with the -XX:SharedCacheHardLimit option\n(See -XX:SharedCacheHardLimit ) This option applies only if a cache is being created and no cache of the same name exists. When you run an application with the -Xshareclasses:verbose option, the VM writes to the console the number of bytes that are not stored due to the current setting of the soft maximum size. You can also get this information by using the MemoryMXBean.getSharedClassCacheSoftmxUnstoredBytes() method in the com.ibm.lang.management API. You can increase the soft maximum size accordingly if you want to add the unstored data to the shared cache. However, the VM that provided the information no longer has the opportunity to store that data. Therefore, increasing the soft maximum size does not necessarily cause any more data to be stored in the shared cache by the current VM, but subsequent VMs can add data to the shared cache.",
"title": "-Xscmx"
},
{
"location": "/xscmx/#syntax",
"text": "-Xscmx<size> See Using -X command-line options for more information about the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xscmx/#explanation",
"text": "",
"title": "Explanation"
},
{
"location": "/xscmx/#setting-a-soft-maximum-size",
"text": "If you specify the -Xscmx option with the -XX:SharedCacheHardLimit option, the -Xscmx option sets the soft maximum size of a new shared class cache, and the -XX:SharedCacheHardLimit option sets the actual maximum size. The value of the -Xscmx option must therefore not exceed the value of -XX:SharedCacheHardLimit . When the soft maximum limit is reached, no more data can be added into the shared cache, unless there is reserved AOT or JIT data space. If such reserved space exists, AOT or JIT data can still be added into the reserved space. The reserved AOT and JIT data spaces are counted as used space within the soft maximum size, so the soft maximum size should not be less than the minimum reserved space for AOT and JIT data if you specify the -Xscminaot or -Xscminjitdata options. You can change the soft maximum size by using the -Xshareclasses:adjustsoftmx=<size> option or the MemoryMXBean.setSharedClassCacheSoftmxBytes() method in the com.ibm.lang.management API. By using this API, Java\u2122 applications can dynamically monitor and adjust the cache soft maximum size as required. This function can be useful in virtualized or cloud environments, for example, where the shared cache size might change dynamically to meet business needs. For example, you might create a 64 MB shared cache and set a smaller value, such as 16 MB, for the -Xscmx option, to limit the data stored in the cache: - XX : SharedCacheHardLimit = 64 m - Xscmx16m You can then use the com.ibm.lang.management API from within a Java application to increase the soft maximum value during run time, as load increases. This change allows the application to use more shared cache space than you specified initially. You can increase the soft maximum size if it is currently less than the actual cache size. If you attempt to reduce the soft maximum size to a value that is less than the number of bytes already used in the cache, the number of used bytes is set as the new soft maximum size. For more information about cache sizes, see Cache size limits .",
"title": "Setting a soft maximum size"
},
{
"location": "/xscmx/#see-also",
"text": "-Xscdmx (control the size of the class debug area)",
"title": "See also"
},
{
"location": "/xshareclasses/",
"text": "-Xshareclasses\n\n\nYou can use the \n-Xshareclasses\n option to enable class sharing. This option can take a number of parameters, some of which are cache utilities.\n\n\nCache utilities perform the required operation on the specified cache, without starting the VM. You can combine multiple suboptions, which are separated by commas, but the cache utilities are mutually exclusive.\n\n\nWhen you are running cache utilities, the message \nCould not create the Java virtual machine\n is expected. Cache utilities do not create the virtual machine.\n\n\nSome cache utilities can work with caches from previous Java\u2122 versions or caches that are created by virtual machines (VMs) with different bit-widths. These caches are referred to as \n\"incompatible\"\n caches.\n\n\nSyntax\n\n\n -Xshareclasses:<parameter>\n\n\n\n\n\nWhen you specify \n-Xshareclasses\n without any parameters and without specifying either the \n-Xscmx\n or \n-XX:SharedCacheHardLimit\n options, a shared classes cache is created with a default size of 300 MB, with a \"soft\" maximum limit for the initial size of the cache (\n-Xscmx\n) set to 64MB. The following exceptions apply:\n\n\n\n\nFor a persistent cache, if the free disk space is less than 6 GB, the default size is set to 64 MB and an \n-Xscmx\n size is not set.\n\n\nFor a non-persistent cache on Linux, the cache size is limited by the maximum amount of memory that can be reserved by a process (\nSHMMAX\n). If \nSHMMAX\n is less than 300MB, the default shared cache size is set to equal \nSHMMAX\n. If \nSHMMAX\n is greater than 80 MB, \n-Xscmx\n is set to 64 MB. If \nSHMMAX\n is less than 80MB an \n-Xscmx\n size is not set.\n\n\n\n\nParameters\n\n\nadjustmaxaot\n (Cache utility)\n\n\n -Xshareclasses:adjustmaxaot=<size>\n\n\n\n\n\n\n\nAdjusts the maximum shared classes cache space that is allowed for AOT data. When you use the \n-Xshareclasses:verbose\n option, the VM writes to the console the number of bytes that are not stored due to the current setting of the \n-Xscmaxaot\n option.\n\n\n\n\nadjustminaot\n (Cache utility)\n\n\n -Xshareclasses:adjustminaot=<size>\n\n\n\n\n\n\n\nAdjusts the minimum shared classes cache space that is reserved for AOT data. Use the \n-Xscminaot\n option to set the initial minimum size.\n\n\n\n\nadjustmaxjitdata\n (Cache utility)\n\n\n -Xshareclasses:adjustmaxjitdata=<size>\n\n\n\n\n\n\n\nAdjusts the maximum shared classes cache space that is allowed for JIT data. When you use the \n-Xshareclasses:verbose\n option, the VM writes to the console the number of bytes that are not stored due to the current setting of the \n-Xscmaxjitdata\n option.\n\n\n\n\nadjustminjitdata\n (Cache utility)\n\n\n -Xshareclasses:adjustminjitdata=<size>\n\n\n\n\n\n\n\nAdjusts the minimum shared classes cache space that is reserved for JIT data. Use the \n-Xscminjitdata\n option to set the initial minimum size.\n\n\n\n\nadjustsoftmx\n (Cache utility)\n\n\n -Xshareclasses:adjustsoftmx=<size>\n\n\n\n\n\n\n\nAdjusts the soft maximum size of the cache. When you use the \n-Xshareclasses:verbose\n option, the VM writes to the console the number of bytes that are not stored due to the current setting of the soft maximum size. For more information about the soft maximum size, see \n-Xscmx\n.\n\n\n\n\nallowClasspaths\n\n\n -Xshareclasses:allowClasspaths\n\n\n\n\n\n\n\nAllows a VM to store classpaths into an existing shared cache that was created by using the \nrestrictClasspaths\n option.\n\n\n\n\ncacheDir\n\n\n -Xshareclasses:cacheDir=<directory>\n\n\n\n\n\n\n\n\n\nSets the directory in which cache data is read and written. The following defaults apply:\n\n\n\n\nOn Windows\u2122 systems, \n<directory>\n is the user's \nC:\\\\Documents and Settings\\<username>\\Local Settings\\Application Data\\javasharedresources\n directory.\n\n\nOn AIX\u00ae, Linux\u2122, and z/OS\u00ae systems, \n<directory>\n is \n/tmp/javasharedresources\n. You must have sufficient permissions in \n<directory>\n. For AIX, the directory must not be on an NFS mount for persistent caches.\n\n\n\n\n\n\n\n\nOn AIX, Linux, and Windows systems, the VM writes persistent cache files directly into the directory specified. Persistent cache files can be safely moved and deleted from the file system.\n\n\n\n\n\n\nNonpersistent caches are stored in shared memory and have control files that describe the location of the memory. Control files are stored in a \njavasharedresources\n subdirectory of the \ncacheDir\n specified. Do not move or delete control files in this directory. The \nlistAllCaches\n utility, the \ndestroyAll\n utility, and the \nexpire\n suboption work only in the scope of a given \ncacheDir\n.\n\n\n\n\n\n\nOn AIX and Linux systems, if you specify the \ncacheDir=<directory>\n option, persistent caches are created with the following permissions (\n-rw-r--r--\n):\n\n\n\n\nUser: read/write\n\n\nGroup: read (read/write if you also specify \n-Xshareclasses:groupAccess\n)\n\n\nOther: read only\n\n\n\n\n\n\n\n\nOtherwise, persistent caches are created with the same permissions as non-persistent caches. The permissions for non-persistent caches are \n-rw-r-----\n, or \n-rw-rw----\n if you also specify \n-Xshareclasses:groupAccess\n.\n\n\n\n\n\n\ncacheDirPerm\n\n\n\n\n(AIX, Linux, z/OS only)\n-Xshareclasses:cacheDirPerm=<permission>\n\n\n\n\n\n\n\n\n\nSets Unix-style permissions when you are creating a cache directory. \n<permission>\n must be an octal number in the ranges 0700 - 0777 or 1700 - 1777. If \n<permission>\n is not valid, the VM ends with an appropriate error message.\n\n\n\n\n\n\nThe permissions that are specified by this suboption are used only when you are creating a new cache directory. If the cache directory already exists, this suboption is ignored and the cache directory permissions are not changed.\n\n\n\n\n\n\nIf you set this suboption to 0000, the default directory permissions are used. If you set this suboption to 1000, the machine default directory permissions are used, but the sticky bit is enabled.\n\n\n\n\n\n\nIf the cache directory is the platform default directory, \n/tmp/javasharedresources\n, this suboption is ignored and the cache directory permissions are set to 777. If you do not set this suboption, the cache directory permissions are set to 777, for compatibility with earlier Java versions.\n\n\n\n\n\n\nOn z/OS systems, permissions for existing cache directories are unchanged, to avoid generating RACF\u00ae errors, which generate log messages.\n\n\n\n\n\n\ncacheRetransformed\n\n\n -Xshareclasses:cacheRetransformed\n\n\n\n\n\n\n\nEnables caching of classes that are transformed by using the JVMTI \nRetransformClasses\n function. For more information, see \nJVMTI redefinition and retransformation of classes\n.\n\n\n\n\nThe option \nenableBCI\n is enabled by default. However, if you use the \ncacheRetransformed\n option, this option forces cache creation into \n-Xshareclasses:disableBCI\n mode.\n\n\ndestroy\n (Cache utility)\n\n\n -Xshareclasses:destroy\n\n\n\n\n\n\n\nDestroys a cache that is specified by the \nname\n, \ncacheDir\n, and \nnonpersistent\n suboptions. A cache can be destroyed only if all VMs that are using it have ended and the user has sufficient permissions.\n\n\n\n\ndestroyAll\n (Cache utility)\n\n\n -Xshareclasses:destroyAll\n\n\n\n\n\n\n\nTries to destroy all the caches that are specified by the \ncacheDir\n and \nnonpersistent\n suboptions.\n\n\nOn Windows and z/OS systems, a cache can be destroyed only if all VMs that are using it have shut down and the user has sufficient permissions.\n\n\n \nNote:\n On z/OS, when the \ndestroyAll\n option is invoked from a 31-bit VM, 64-bit caches are not destroyed. Similarly, when the \ndestroyAll\n option is invoked from a 64-bit VM, 31-bit caches are not destroyed. The following message is displayed:\nJVMSHRC735I\n:\n \nUse\n \na\n \nnn\n-\nbit\n \nVM\n \nto\n \nperform\n \nthe\n \nrequested\n \noperation\n \non\n \nthe\n\n\nnn\n-\nbit\n \nshared\n \ncache\n \n\"cachename\"\n \nas\n \nthe\n \nnn\n-\nbit\n \nVM\n\n\ncannot\n \nverify\n \nthat\n \nthe\n \nshared\n \nmemory\n \nwas\n \ncreated\n \nby\n \nthe\n \nVM\n.\n\n\n\n\n\n\n\n\n\n\nOn AIX and Linux systems:\n\n\n\n\n\n\n\n\n\n\nNon-persistent caches can be destroyed only if all VMs that are using it have shut down and the user has sufficient permissions.\n\n\n\n\n\n\nPersistent caches that are still in use continue to exist even when you use this option, but they are unlinked from the file system so they are not visible to new VM invocations. If you update the VM then restart an application for which a persistent shared cache already exists, the VM unlinks the existing cache and creates a new cache. Because the unlinked caches are not visible to new VMs, you cannot find them by using the \n-Xshareclasses:listAllCaches\n option, and you cannot use the \n-Xshareclasses:printStats\n option on them. You can therefore have multiple unlinked caches that consume file system space until they are no longer in use.\n\n\n\n\n\n\ndestroyAllSnapshots\n (Cache utility)\n\n\n\n\n(AIX, Linux, z/OS only)\n-Xshareclasses:destroyAllSnapshots\n\n\n\n\n\n\n\n\n\nDestroys all shared cache snapshots that are available as a result of the specified \ncacheDir\n suboption.\n\n\n\n\n\n\ndestroySnapshot\n (Cache utility)\n\n\n\n\n(AIX, Linux, z/OS only)\n-Xshareclasses:destroySnapshot\n\n\n\n\n\n\n\n\n\nDestroys a snapshot that is specified by the \nname\n and \ncacheDir\n suboptions.\n\n\n\n\n\n\ndisableBCI\n\n\n -Xshareclasses:disableBCI\n\n\n\n\n\n\n\nTurns off BCI support. This option can be used to override \n-XXShareClassesEnableBCI\n.\n\n\n\n\nenableBCI\n\n\n -Xshareclasses:enableBCI\n\n\n\n\n\n\n\nThis option is enabled by default.\n\n\nAllows a JVMTI \nClassFileLoadHook\n event to be triggered every time, for classes that are loaded from the cache. This mode also prevents caching of classes that are modified by JVMTI agents. For more information about this option, see \nUsing the JVMTI ClassFileLoadHook with cached classes\n. This option is incompatible with the \ncacheRetransformed\n option. Using the two options together causes the VM to end with an error message, unless \n-Xshareclasses:nonfatal\n is specified. In this\ncase, the VM continues without using shared classes.\n\n\nA cache that is created without the \nenableBCI\n suboption cannot be reused with the \nenableBCI\n suboption. Attempting to do so causes the VM to end with an error message, unless \n-Xshareclasses:nonfatal\n is specified. In this case, the VM continues without using shared classes. A cache that is created with the \nenableBCI\n suboption can be reused without specifying this suboption. In this case, the VM detects that the cache was created with the \nenableBCI\n suboption and uses the cache in this mode.\n\n\n\n\nexpire\n (Cache utility)\n\n\n -Xshareclasses:expire=<time_in_minutes>\n\n\n\n\n\n\n\nDestroys all caches that are unused for the time that is specified before loading shared classes. This option is not a utility option because it does not cause the VM to exit. On Windows systems, which have NTFS file systems, the \nexpire\n option is accurate to the nearest hour.\n\n\n\n\nfindAotMethods\n (Cache utility)\n\n\n -Xshareclasses:findAotMethods=<method_specification>\n -Xshareclasses:findAotMethods=help\n\n\n\n\n\n\n\nPrint the AOT methods in the shared cache that match the method specifications. Methods that are already invalidated are indicated in the output. Use this suboption to check which AOT methods in the shared class cache would be invalidated by using the same method specifications with the \ninvalidateAotMethods\n suboption. To learn more about the syntax to use for \n<method_specification>\n, including how to specify more than one method, see \nMethod specification syntax\n.\n\n\n\n\ngroupAccess\n\n\n\n\n(AIX, Linux, z/OS only)\n-Xshareclasses:groupAccess\n\n\n\n\n\n\n\n\n\nSets operating system permissions on a new cache to allow group access to the cache. Group access can be set only when permitted by the operating system \numask\n setting. The default is user access only.\n\n\n\n\n\n\nOn AIX and Linux systems, if a user creates a cache by specifying the \ngroupAccess\n suboption, other users in the same group must also specify this suboption to be granted access to the same cache.\n\n\n\n\n\n\nIn certain situations, warning messages might be generated when the \ngroupAccess\n suboption is used.\n\n\n\n\n\n\nThis message can occur when persistent caches are used:\n\n\nJVMSHRC756W Failed to set group access permission on the shared cache\nfile as requested by the 'groupAccess' sub-option\n\n\n\n\n\n\n\n\n\nThese messages can occur when non-persistent caches are used:\n\n\nJVMSHRC759W Failed to set group access permission as requested by the\n'groupAccess' sub-option on the semaphore control file associated\nwith shared class cache.\n\nJVMSHRC760W Failed to set group access permission as requested by the\n'groupAccess' sub-option on the shared memory control file associated\nwith shared class cache.\n\n\n\n\n\n\n\n\n\nThis message can occur in combination with the \nsnapshotCache\n suboption:\n\n\nJVMSHRC761W Failed to set group access permission as requested by the\n'groupAccess' sub-option on the shared cache snapshot file.\n\n\n\n\n\n\n\n\n\nAll of these warning messages mean that the user's \numask\n setting does not allow either, or both, of the group \nread\n and \nwrite\n permission to be set on the file. The typical umask setting restricts only the \nwrite\n permission. To resolve the warning, either change the \numask\n setting or remove the \ngroupAccess\n suboption.\n\n\n\n\n\n\nhelp\n\n\n -Xshareclasses:help\n\n\n\n\n\n\n\nLists all the command-line options.\n\n\n\n\ninvalidateAotMethods\n (Cache utility)\n\n\n -Xshareclasses:invalidateAotMethods=<method_specification>\n -Xshareclasses:invalidateAotMethods=help\n\n\n\n\n\n\n\nModify the existing shared cache to invalidate the AOT methods that match the method specifications. Use this suboption to invalidate AOT methods that cause a failure in the application, without having to destroy the shared cache. Invalidated AOT methods remain in the shared cache, but are then excluded from being loaded. VMs that have not processed the methods, or new VMs that use the cache are not affected by the invalidated methods. The AOT methods are invalidated for the lifetime of the cache, but do not prevent the AOT methods from being compiled again if a new shared cache is created. To prevent AOT method compilation into a new shared cache, use the \n-Xaot:exclude\n option. For more information, see \n-Xaot\n.\n\n\nTo identify AOT problems, see \nDiagnosing a JIT or AOT problem\n.\n\n\nTo revalidate an AOT method, see the \nrevalidateAotMethods\n suboption. Use the \nfindAotMethod\n suboption to determine which AOT methods match the method specifications. To learn more about the syntax to use for \n<method_specification>\n, including how to specify more than one method, see \nMethod specification syntax\n.\n\n\n\n\nlistAllCaches\n (Cache utility)\n\n\n\n\n(AIX, Linux, z/OS only)\n-Xshareclasses:listAllCaches\n\n\n\n\n\n\n\n\n\nLists all the compatible and incompatible caches, and snapshots that exist in the specified cache directory. If you do not specify \ncacheDir\n, the default directory is used. Summary information, such as Java version and current usage, is displayed for each cache.\n\n\n\n\n\n\nmprotect\n\n\n\n\nAIX, z/OS 31-bit:\n-Xshareclasses:mprotect=[default|all|none]\n\n\n\n\n\n\n\n\n\nLinux, Windows:\n\n\n-Xshareclasses:mprotect=[default|all|partialpagesonstartup|onfind|nopartialpages|none]\n\n\n\n\n\n\n\n\n\nwhere:\n\n\n\n\ndefault\n: By default, the memory pages that contain the cache are always protected, unless a specific page is being updated. This protection helps prevent accidental or deliberate corruption to the cache. The cache header is not protected by default because this protection has a performance cost. On Linux and Windows systems, after the startup phase, the Java virtual machine (VM) protects partially filled pages whenever new data is added to the shared class cache in the following sequence:\n\n\nThe VM changes the memory protection of any partially filled pages to read/write.\n\n\nThe VM adds the data to the cache.\n\n\nThe VM changes the memory protection of any partially filled pages to read only.\n\n\n\n\n\n\nall\n: This value ensures that all the cache pages are protected, including the header. See Note.\n\n\npartialpagesonstartup\n: This value causes the VM to protect partially filled pages during startup as well as after the startup phase. This value is available only on Linux and Windows systems.\n\n\nonfind\n: When this option is specified, the VM protects partially filled pages when it reads new data in the cache that is added by another VM. This option is available only on Linux and Windows systems.\n\n\nnopartialpages\n: Use this value to turn off the protection of partially filled pages. This value is available only on Linux and Windows systems.\n\n\nnone\n: Specifying this value disables the page protection.\n\n\n\n\n\n\n\n\n \nNote:\n Specifying \nall\n has a negative impact on performance. You should specify \nall\n only for problem diagnosis and not for production. Specifying values \npartialpagesonstartup\n or \nonfind\n can also have a negative impact on performance when the cache is being populated. There is no further impact when the cache is full or no longer being modified.\n\n\n\n\n\n\nmodified\n\n\n -Xshareclasses:modified=<modified_context>\n\n\n\n\n\n\n\nUsed when a JVMTI agent is installed that might modify bytecode at run time. If you do not specify this suboption and a bytecode modification agent is installed, classes are safely shared with an extra performance cost. The \n<modified context>\n is a descriptor that is chosen by the user; for example, \nmyModification1\n. This option partitions the cache so that only VMs that are using context \nmyModification1\n can share the same classes. So if, for example, you run an application with a modification context and then run it again with a different modification context, all classes are stored twice in the cache.\n\n\nFor more information, see \nDealing with runtime bytecode modification\n.\n\n\nIf you are migrating from IBM\u00ae SDK, Java Technology Edition, Version 7, or earlier releases, you must set \n-Xshareclasses:disableBCI\n when you use this option to retain the same behavior.\n\n\n\n\nname\n\n\n -Xshareclasses:name=<name>\n\n\n\n\n\n\n\nConnects to a cache of a given name, creating the cache if it does not exist. This option is also used to indicate the cache that is to be modified by cache utilities; for example, \ndestroy\n. Use the \nlistAllCaches\n utility to show which named caches are currently available. If you do not specify a name, the default name \n\"sharedcc_%u\"\n is used. \"%u\" in the cache name inserts the current user name. On AIX, Linux, and z/OS systems, you can specify \n\"%g\"\n in the cache name to insert the current group name.\n\n\n\n\nnoaot\n\n\n -Xshareclasses:noaot\n\n\n\n\n\n\n\nDisables caching and loading of AOT code. AOT code already in the shared data cache can be loaded.\n\n\n\n\nnoBootclasspath\n\n\n -Xshareclasses:noBootclasspath\n\n\n\n\n\n\n\nDisables the storage of classes that are loaded by the bootstrap class loader in the shared classes cache. Often used with the \nSharedClassURLFilter\n API to control exactly which classes are cached. For more information about shared class filtering, see \nUsing the SharedClassHelper API\n.\n\n\n\n\nnojitdata\n\n\n -Xshareclasses:nojitdata\n\n\n\n\n\n\n\nDisables caching of JIT data. JIT data already in the shared data cache can be loaded.\n\n\n\n\nnone\n\n\n -Xshareclasses:none\n\n\n\n\n\n\n\nAdded to the end of a command line, disables class data sharing. This suboption overrides class sharing arguments found earlier on the command line. This suboption disables the shared class utility APIs. To disable class data sharing without disabling the utility APIs, use the \nutilities\n suboption. For more information about the shared class utility APIs, see \nObtaining information about shared caches\n.\n\n\n\n\nnonfatal\n\n\n -Xshareclasses:nonfatal\n\n\n\n\n\n\n\nAllows the VM to start even if class data sharing fails. Normal behavior for the VM is to refuse to start if class data sharing fails. If you select \nnonfatal\n and the shared classes cache fails to initialize, the VM attempts to connect to the cache in read-only mode. If this attempt fails, the VM starts without class data sharing.\n\n\n\n\nnonpersistent\n\n\n -Xshareclasses:nonpersistent\n\n\n\n\n\n\n\nUses a nonpersistent cache. The cache is lost when the operating system shuts down. Nonpersistent and persistent caches can have the same name. On Linux and Windows systems, you must always use the \nnonpersistent\n suboption when you run utilities such as \ndestroy\n on a nonpersistent cache. z/OS supports only nonpersistent caches.\n\n\n\n\npersistent\n\n\n -Xshareclasses:persistent\n\n\n\n\n\n\n\nUses a persistent cache. The cache is created on disk, which persists beyond operating system restarts. Nonpersistent and persistent caches can have the same name. On AIX, you must always use the \npersistent\n suboption when you run utilities such as \ndestroy\n on a persistent cache.\n\n\n\n\nprintAllStats\n (Cache utility)\n\n\n -Xshareclasses:printAllStats\n\n\n\n\n\n\n\nDisplays detailed information about the contents of the cache that is specified in the \nname\n suboption. If the name is not specified, statistics are displayed about the default cache. Every class is listed in chronological order with a reference to the location from which it was loaded. For more information, see \nprintAllStats utility\n.\n\n\n\n\nprintStats\n (Cache utility)\n\n\n -Xshareclasses:printStats=<data_type>[+<data_type>]\n\n\n\n\n\n\n\nDisplays summary information for the cache that is specified by the \nname\n, \ncacheDir\n, and \nnonpersistent\n suboptions. The most useful information that is displayed is how full the cache is and how many classes it contains. Stale classes are classes that are updated on the file system and which the cache has therefore marked as \"stale\". Stale classes are not purged from the cache and can be reused. Use the \nprintStats=stale\n option to list all the stale entries and stale bytes.\n\n\nSpecify one or more data types, which are separated by a plus symbol (+), to see more detailed information about the cache content. Data types include AOT data, class paths, and ROMMethods.\n\n\nFor more information and for a full list of data types, see \nprintStats utility\n.\n\n\n\n\nreadonly\n\n\n -Xshareclasses:readonly\n\n\n\n\n\n\n\nOpens an existing cache with read-only permissions. The Java virtual machine does not create a new cache with this suboption. Opening a cache read-only prevents the VM from making any updates to the cache. If you specify this suboption, the VM can connect to caches that were created by other users or groups without requiring write access.\n\n\nOn AIX and Linux systems, this access is permitted only if the cache was created by using the \n-Xshareclasses:cacheDir\n option to specify a directory with appropriate permissions. If you do not use the \n-Xshareclasses:cacheDir\n option, the cache is created with default permissions, which do not permit access by other users or groups.\n\n\nBy default, this suboption is not specified.\n\n\n\n\nreset\n\n\n -Xshareclasses:reset\n\n\n\n\n\n\n\nCauses a cache to be destroyed and then re-created when the VM starts up. This option can be added to the end of a command line as \n-Xshareclasses:reset\n.\n\n\n\n\nrestoreFromSnapshot\n (Cache utility)\n\n\n\n\n(AIX, Linux, z/OS only)\n-Xshareclasses:restoreFromSnapshot\n\n\n\n\n\n\n\n\n\nRestores a new non-persistent shared cache from a snapshot file. The snapshot and shared cache have the same name and location, as specified by the \nname\n and \ncacheDir\n suboptions. The non-persistent cache cannot already exist when the snapshot is restored. Restoring a snapshot does not remove the snapshot file; it can be restored multiple times. On platforms that support persistent caches, the \nnonpersistent\n suboption must be specified in order to restore a snapshot.\n\n\n\n\n\n\nrestrictClasspaths\n\n\n -Xshareclasses:restrictClasspaths\n\n\n\n\n\n\n\nAllows only the first VM that is initializing a shared cache to store classpaths in the cache. Subsequent VMs are not allowed to store classpaths in the cache unless the \nallowClasspaths\n option is specified.\n\n\nUse the \nrestrictClasspaths\n option only if the application is designed to create class loaders of type \njava.net.URLClassloader\n or its subclass, such that their classpaths are unique to the instance of the application, but the classes that are loaded from these classpaths are the same. In such cases application classpaths that are stored by one VM cannot be used by another VM.\n\n\n\n\nFor example, consider two VMs, VM1 and VM2, that are using class paths CP1 and CP2 respectively, where:\n\n\n\n\nCP1: \nurl1;url2;url3;tempurl1;url4;url5\n\n\nCP2: \nurl1;url2;url3;tempurl2;url4;url5\n\n\n\n\n\n\n\n\nThese class paths differ only by one entry, which is the \ntempurl\n. The \nurl1\n, \nurl2\n, \nurl3\n, \nurl4\n, and \nurl5\n entries never change from run to run, whereas the \ntempurl\n entry is always different. This difference means that a class that is loaded from \nurl4\n or \nurl5\n, and stored into the shared cache by VM1, cannot be located by VM2. Therefore, an attempt by VM2 to load a class from \nurl4\n or \nurl5\n would cause it to store its own classpath \nCP2\n into the shared cache, and also add new metadata for classes that are loaded from \nurl4\n or \nurl5\n. Addition of such unique class paths into the shared cache is not useful. Moreover, the additional metadata might adversely affect the performance of other VMs that connect to the shared cache. Because classes loaded from \nurl4\n or \nurl5\n are not loaded from the shared cache when the \ntempurl\n differs from the original, it is good practice to put the \ntempurl\n as the last entry in the class path.\n\n\n\n\n\n\nIn situations such as that described in the example, the \nrestrictClasspaths\n option can be used to restrict the addition of classpaths by ensuring that the first VM initializes the shared cache, and then prevents the addition of unique classpaths by subsequent VMs that attach to the shared cache. Note that use of the \nrestrictClasspaths\n option in any other scenario is likely to negatively impact a VM's performance when it is using an existing cache.\n\n\n\n\n\n\nrevalidateAotMethods\n (Cache utility)\n\n\n -Xshareclasses:revalidateAotMethods=<method_specification>\n -Xshareclasses:revalidateAotMethods=help\n\n\n\n\n\n\n\nModify the shared cache to revalidate the AOT methods that match the method specifications. Use this suboption to revalidate AOT methods that were invalidated by using the \ninvalidateAotMethods\n suboption. Revalidated AOT methods are then eligible for loading into a VM, but do not affect VMs where the methods have already been processed. To learn more about the syntax to use for \n<method_specification>\n, including how to specify more than one method, see \nMethod specification syntax\n.\n\n\n\n\nsilent\n\n\n -Xshareclasses:silent\n\n\n\n\n\n\n\nDisables all shared class messages, including error messages. Unrecoverable error messages, which prevent the VM from initializing, are displayed.\n\n\n\n\nsnapshotCache\n (Cache utility)\n\n\n\n\n(AIX, Linux, z/OS only)\n-Xshareclasses:snapshotCache\n\n\n\n\n\n\n\n\n\nCreates a snapshot file of an existing non-persistent shared cache. The snapshot has the same name and location as the shared cache, as specified by the \nname\n and \ncacheDir\n suboptions. The shared cache can be in use when the snapshot is taken, but VMs are blocked when they try to write to the shared cache, while the cache data is copied to the file.\n\n\n\n\n\n\nTypically, after a system is reinitialized, the snapshot file is used to restore the copy of the non-persistent cache into shared memory, via the \nrestoreFromSnapshot\n suboption. Since this process removes all non-persistent caches from shared memory, restoring the cache from the snapshot file can result in better VM startup performance, because the contents of the shared cache, including classes and AOT code, do not have to be re-created.\n\n\n\n\n\n\nA snapshot can be created only if the user has sufficient permissions to create the destination snapshot file. If a snapshot of the same name exists already, it is overwritten. On platforms that support persistent caches, the \nnonpersistent\n suboption must be specified in order to create a snapshot. For information about removing snapshot files, see the \ndestroySnapshot\n and \ndestroyAllSnapshots\n suboptions.\n\n\n\n\n\n\nutilities\n\n\n -Xshareclasses:utilities\n\n\n\n\n\n\n\nCan be added to the end of a command line to disable class data sharing. This suboption overrides class sharing arguments found earlier on the command line. This suboption is like \nnone\n, but does not disable the shared class utility APIs. For more information about the shared class utility APIs, see \nObtaining information about shared caches\n.\n\n\n\n\nverbose\n\n\n -Xshareclasses:verbose\n\n\n\n\n\n\n\nGives detailed output on the cache I/O activity, listing information about classes that are stored and found. Each class loader is given a unique ID (the bootstrap loader is always 0) and the output shows the class loader hierarchy at work, where class loaders ask their parents for a class if they can't find it themselves. It is typical to see many failed requests; this behavior is expected for the class loader hierarchy. The standard option \n-verbose:class\n also enables class sharing verbose output if class sharing is enabled.\n\n\n\n\nverboseAOT\n\n\n -Xshareclasses:verboseAOT\n\n\n\n\n\n\n\nEnables verbose output when compiled AOT code is being found or stored in the cache. AOT code is generated heuristically. You might not see any AOT code that is generated at all for a small application. You can disable AOT caching by using the \nnoaot\n suboption. See the \nMessages Guide\n for a list of the messages produced.\n\n\n\n\nverboseHelper\n\n\n -Xshareclasses:verboseHelper\n\n\n\n\n\n\n\nEnables verbose output for the Java Helper API. This output shows you how the Helper API is used by your class loader.\n\n\n\n\nverboseIO\n\n\n -Xshareclasses:verboseIO\n\n\n\n\n\n\n\nGives detailed output on the cache I/O activity, listing information about classes that are stored and found. Each class loader is given a unique ID (the bootstrap loader is always 0) and the output shows the class loader hierarchy at work, where class loaders must ask their parents for a class before they can load it themselves. It is typical to see many failed requests; this behavior is expected for the class loader hierarchy.\n\n\n\n\nMethod specification syntax\n\n\nThe following examples show how to specify more than one method specification when you are using the \nfindAotMethods\n, \ninvalidateAotMethods\n, or \nrevalidateAotMethods\n suboptions.\n\n\nEach method specification is defined as follows:\n\n\n<\npackagename\n>/<\nclassname\n>[.<\nmethodname\n>[(<\nparameters\n>)]]\n\n\n\n\n\n\nIf you want to include more than one method specification in a single option, separate the specifications with a comma and enclose all the specifications in {braces}. For example:\n\n\n{<\npackagename\n/\nclassname\n>}[.{<\nmethodname\n>}[({<\nparameters\n>})]]\n\n\n\n\n\n\n\n\n\n\n\nYou can use an asterisk (*) in most places as a wildcard.\n\n\nYou can use an exclamation point (!) before the specification to mean \"everything \nexcept\n this\".\n\n\nParameters are optional, but if specified, should be enclosed in parentheses and the following native signature formats must be used:\n\n\nB\n for byte\n\n\nC\n for char\n\n\nD\n for double\n\n\nF\n for float\n\n\nI\n for int\n\n\nJ\n for long\n\n\nS\n for short\n\n\nZ\n for Boolean\n\n\nL<classname>;\n for objects\n\n\n[\n before the signature means array\n\n\n\n\n\n\n\n\nIf you want to specify parameters to distinguish between methods, you can use \n-Xshareclasses:findAotMethods=*\n (with a wildcard) to list all the parameter variations. Copy the signature for the method that you want from the output. For example, the signature for the parameters\n\n\n(byte[] bytes, int offset, int length, Charset charset)\n\n\n\n\n\nis\n\n\n([BIILjava/nio/charset/Charset;)\n\n\n\n\n\nHere are some examples:\n\n\n\n\n\n\n\n\nMethod signature\n\n\nMatches...\n\n\n\n\n\n\n\n\n\n\n*\n\n\nAll AOT methods.\n\n\n\n\n\n\njava/lang/Object\n\n\nAll AOT methods in the \njava.lang.Object\n class\n\n\n\n\n\n\njava/util/*\n\n\nAll AOT classes and methods in the \njava.util\n package\n\n\n\n\n\n\njava/util/HashMap.putVal\n\n\nAll \nputVal\n methods in the \njava.util.HashMap\n class\n\n\n\n\n\n\njava/util/HashMap.hash(Ljava/lang/Object;)\n\n\nThe private \njava.util.HashMap.hash(java.lang.Object)\n method\n\n\n\n\n\n\n*.equals\n\n\nAll \nequals\n methods in all classes\n\n\n\n\n\n\n{java/lang/Object,!java/lang/Object.clone}\n\n\nAll methods in \njava.lang.Object\n except \nclone\n\n\n\n\n\n\n{java/util/*.*(),java/lang/Object.*(*)}\n\n\nAll classes or methods with no input parameter in the \njava.util\n package, and all methods in \njava.lang.Object\n\n\n\n\n\n\n{java/util/*.*(),!java/util/*.*()}\n\n\nNothing.\n\n\n\n\n\n\n\n\nSee also\n\n\n\n\n-Xscmx\n\n\n-XX\\:SharedCacheHardLimit",
"title": "-Xshareclasses"
},
{
"location": "/xshareclasses/#-xshareclasses",
"text": "You can use the -Xshareclasses option to enable class sharing. This option can take a number of parameters, some of which are cache utilities. Cache utilities perform the required operation on the specified cache, without starting the VM. You can combine multiple suboptions, which are separated by commas, but the cache utilities are mutually exclusive. When you are running cache utilities, the message Could not create the Java virtual machine is expected. Cache utilities do not create the virtual machine. Some cache utilities can work with caches from previous Java\u2122 versions or caches that are created by virtual machines (VMs) with different bit-widths. These caches are referred to as \"incompatible\" caches.",
"title": "-Xshareclasses"
},
{
"location": "/xshareclasses/#syntax",
"text": "-Xshareclasses:<parameter> When you specify -Xshareclasses without any parameters and without specifying either the -Xscmx or -XX:SharedCacheHardLimit options, a shared classes cache is created with a default size of 300 MB, with a \"soft\" maximum limit for the initial size of the cache ( -Xscmx ) set to 64MB. The following exceptions apply: For a persistent cache, if the free disk space is less than 6 GB, the default size is set to 64 MB and an -Xscmx size is not set. For a non-persistent cache on Linux, the cache size is limited by the maximum amount of memory that can be reserved by a process ( SHMMAX ). If SHMMAX is less than 300MB, the default shared cache size is set to equal SHMMAX . If SHMMAX is greater than 80 MB, -Xscmx is set to 64 MB. If SHMMAX is less than 80MB an -Xscmx size is not set.",
"title": "Syntax"
},
{
"location": "/xshareclasses/#parameters",
"text": "",
"title": "Parameters"
},
{
"location": "/xshareclasses/#adjustmaxaot-cache-utility",
"text": "-Xshareclasses:adjustmaxaot=<size> Adjusts the maximum shared classes cache space that is allowed for AOT data. When you use the -Xshareclasses:verbose option, the VM writes to the console the number of bytes that are not stored due to the current setting of the -Xscmaxaot option.",
"title": "adjustmaxaot (Cache utility)"
},
{
"location": "/xshareclasses/#adjustminaot-cache-utility",
"text": "-Xshareclasses:adjustminaot=<size> Adjusts the minimum shared classes cache space that is reserved for AOT data. Use the -Xscminaot option to set the initial minimum size.",
"title": "adjustminaot (Cache utility)"
},
{
"location": "/xshareclasses/#adjustmaxjitdata-cache-utility",
"text": "-Xshareclasses:adjustmaxjitdata=<size> Adjusts the maximum shared classes cache space that is allowed for JIT data. When you use the -Xshareclasses:verbose option, the VM writes to the console the number of bytes that are not stored due to the current setting of the -Xscmaxjitdata option.",
"title": "adjustmaxjitdata (Cache utility)"
},
{
"location": "/xshareclasses/#adjustminjitdata-cache-utility",
"text": "-Xshareclasses:adjustminjitdata=<size> Adjusts the minimum shared classes cache space that is reserved for JIT data. Use the -Xscminjitdata option to set the initial minimum size.",
"title": "adjustminjitdata (Cache utility)"
},
{
"location": "/xshareclasses/#adjustsoftmx-cache-utility",
"text": "-Xshareclasses:adjustsoftmx=<size> Adjusts the soft maximum size of the cache. When you use the -Xshareclasses:verbose option, the VM writes to the console the number of bytes that are not stored due to the current setting of the soft maximum size. For more information about the soft maximum size, see -Xscmx .",
"title": "adjustsoftmx (Cache utility)"
},
{
"location": "/xshareclasses/#allowclasspaths",
"text": "-Xshareclasses:allowClasspaths Allows a VM to store classpaths into an existing shared cache that was created by using the restrictClasspaths option.",
"title": "allowClasspaths"
},
{
"location": "/xshareclasses/#cachedir",
"text": "-Xshareclasses:cacheDir=<directory> Sets the directory in which cache data is read and written. The following defaults apply: On Windows\u2122 systems, <directory> is the user's C:\\\\Documents and Settings\\<username>\\Local Settings\\Application Data\\javasharedresources directory. On AIX\u00ae, Linux\u2122, and z/OS\u00ae systems, <directory> is /tmp/javasharedresources . You must have sufficient permissions in <directory> . For AIX, the directory must not be on an NFS mount for persistent caches. On AIX, Linux, and Windows systems, the VM writes persistent cache files directly into the directory specified. Persistent cache files can be safely moved and deleted from the file system. Nonpersistent caches are stored in shared memory and have control files that describe the location of the memory. Control files are stored in a javasharedresources subdirectory of the cacheDir specified. Do not move or delete control files in this directory. The listAllCaches utility, the destroyAll utility, and the expire suboption work only in the scope of a given cacheDir . On AIX and Linux systems, if you specify the cacheDir=<directory> option, persistent caches are created with the following permissions ( -rw-r--r-- ): User: read/write Group: read (read/write if you also specify -Xshareclasses:groupAccess ) Other: read only Otherwise, persistent caches are created with the same permissions as non-persistent caches. The permissions for non-persistent caches are -rw-r----- , or -rw-rw---- if you also specify -Xshareclasses:groupAccess .",
"title": "cacheDir"
},
{
"location": "/xshareclasses/#cachedirperm",
"text": "(AIX, Linux, z/OS only) -Xshareclasses:cacheDirPerm=<permission> Sets Unix-style permissions when you are creating a cache directory. <permission> must be an octal number in the ranges 0700 - 0777 or 1700 - 1777. If <permission> is not valid, the VM ends with an appropriate error message. The permissions that are specified by this suboption are used only when you are creating a new cache directory. If the cache directory already exists, this suboption is ignored and the cache directory permissions are not changed. If you set this suboption to 0000, the default directory permissions are used. If you set this suboption to 1000, the machine default directory permissions are used, but the sticky bit is enabled. If the cache directory is the platform default directory, /tmp/javasharedresources , this suboption is ignored and the cache directory permissions are set to 777. If you do not set this suboption, the cache directory permissions are set to 777, for compatibility with earlier Java versions. On z/OS systems, permissions for existing cache directories are unchanged, to avoid generating RACF\u00ae errors, which generate log messages.",
"title": "cacheDirPerm"
},
{
"location": "/xshareclasses/#cacheretransformed",
"text": "-Xshareclasses:cacheRetransformed Enables caching of classes that are transformed by using the JVMTI RetransformClasses function. For more information, see JVMTI redefinition and retransformation of classes . The option enableBCI is enabled by default. However, if you use the cacheRetransformed option, this option forces cache creation into -Xshareclasses:disableBCI mode.",
"title": "cacheRetransformed"
},
{
"location": "/xshareclasses/#destroy-cache-utility",
"text": "-Xshareclasses:destroy Destroys a cache that is specified by the name , cacheDir , and nonpersistent suboptions. A cache can be destroyed only if all VMs that are using it have ended and the user has sufficient permissions.",
"title": "destroy (Cache utility)"
},
{
"location": "/xshareclasses/#destroyall-cache-utility",
"text": "-Xshareclasses:destroyAll Tries to destroy all the caches that are specified by the cacheDir and nonpersistent suboptions. On Windows and z/OS systems, a cache can be destroyed only if all VMs that are using it have shut down and the user has sufficient permissions. Note: On z/OS, when the destroyAll option is invoked from a 31-bit VM, 64-bit caches are not destroyed. Similarly, when the destroyAll option is invoked from a 64-bit VM, 31-bit caches are not destroyed. The following message is displayed: JVMSHRC735I : Use a nn - bit VM to perform the requested operation on the nn - bit shared cache \"cachename\" as the nn - bit VM cannot verify that the shared memory was created by the VM . On AIX and Linux systems: Non-persistent caches can be destroyed only if all VMs that are using it have shut down and the user has sufficient permissions. Persistent caches that are still in use continue to exist even when you use this option, but they are unlinked from the file system so they are not visible to new VM invocations. If you update the VM then restart an application for which a persistent shared cache already exists, the VM unlinks the existing cache and creates a new cache. Because the unlinked caches are not visible to new VMs, you cannot find them by using the -Xshareclasses:listAllCaches option, and you cannot use the -Xshareclasses:printStats option on them. You can therefore have multiple unlinked caches that consume file system space until they are no longer in use.",
"title": "destroyAll (Cache utility)"
},
{
"location": "/xshareclasses/#destroyallsnapshots-cache-utility",
"text": "(AIX, Linux, z/OS only) -Xshareclasses:destroyAllSnapshots Destroys all shared cache snapshots that are available as a result of the specified cacheDir suboption.",
"title": "destroyAllSnapshots (Cache utility)"
},
{
"location": "/xshareclasses/#destroysnapshot-cache-utility",
"text": "(AIX, Linux, z/OS only) -Xshareclasses:destroySnapshot Destroys a snapshot that is specified by the name and cacheDir suboptions.",
"title": "destroySnapshot (Cache utility)"
},
{
"location": "/xshareclasses/#disablebci",
"text": "-Xshareclasses:disableBCI Turns off BCI support. This option can be used to override -XXShareClassesEnableBCI .",
"title": "disableBCI"
},
{
"location": "/xshareclasses/#enablebci",
"text": "-Xshareclasses:enableBCI This option is enabled by default. Allows a JVMTI ClassFileLoadHook event to be triggered every time, for classes that are loaded from the cache. This mode also prevents caching of classes that are modified by JVMTI agents. For more information about this option, see Using the JVMTI ClassFileLoadHook with cached classes . This option is incompatible with the cacheRetransformed option. Using the two options together causes the VM to end with an error message, unless -Xshareclasses:nonfatal is specified. In this\ncase, the VM continues without using shared classes. A cache that is created without the enableBCI suboption cannot be reused with the enableBCI suboption. Attempting to do so causes the VM to end with an error message, unless -Xshareclasses:nonfatal is specified. In this case, the VM continues without using shared classes. A cache that is created with the enableBCI suboption can be reused without specifying this suboption. In this case, the VM detects that the cache was created with the enableBCI suboption and uses the cache in this mode.",
"title": "enableBCI"
},
{
"location": "/xshareclasses/#expire-cache-utility",
"text": "-Xshareclasses:expire=<time_in_minutes> Destroys all caches that are unused for the time that is specified before loading shared classes. This option is not a utility option because it does not cause the VM to exit. On Windows systems, which have NTFS file systems, the expire option is accurate to the nearest hour.",
"title": "expire (Cache utility)"
},
{
"location": "/xshareclasses/#findaotmethods-cache-utility",
"text": "-Xshareclasses:findAotMethods=<method_specification>\n -Xshareclasses:findAotMethods=help Print the AOT methods in the shared cache that match the method specifications. Methods that are already invalidated are indicated in the output. Use this suboption to check which AOT methods in the shared class cache would be invalidated by using the same method specifications with the invalidateAotMethods suboption. To learn more about the syntax to use for <method_specification> , including how to specify more than one method, see Method specification syntax .",
"title": "findAotMethods (Cache utility)"
},
{
"location": "/xshareclasses/#groupaccess",
"text": "(AIX, Linux, z/OS only) -Xshareclasses:groupAccess Sets operating system permissions on a new cache to allow group access to the cache. Group access can be set only when permitted by the operating system umask setting. The default is user access only. On AIX and Linux systems, if a user creates a cache by specifying the groupAccess suboption, other users in the same group must also specify this suboption to be granted access to the same cache. In certain situations, warning messages might be generated when the groupAccess suboption is used. This message can occur when persistent caches are used: JVMSHRC756W Failed to set group access permission on the shared cache\nfile as requested by the 'groupAccess' sub-option These messages can occur when non-persistent caches are used: JVMSHRC759W Failed to set group access permission as requested by the\n'groupAccess' sub-option on the semaphore control file associated\nwith shared class cache.\n\nJVMSHRC760W Failed to set group access permission as requested by the\n'groupAccess' sub-option on the shared memory control file associated\nwith shared class cache. This message can occur in combination with the snapshotCache suboption: JVMSHRC761W Failed to set group access permission as requested by the\n'groupAccess' sub-option on the shared cache snapshot file. All of these warning messages mean that the user's umask setting does not allow either, or both, of the group read and write permission to be set on the file. The typical umask setting restricts only the write permission. To resolve the warning, either change the umask setting or remove the groupAccess suboption.",
"title": "groupAccess"
},
{
"location": "/xshareclasses/#help",
"text": "-Xshareclasses:help Lists all the command-line options.",
"title": "help"
},
{
"location": "/xshareclasses/#invalidateaotmethods-cache-utility",
"text": "-Xshareclasses:invalidateAotMethods=<method_specification>\n -Xshareclasses:invalidateAotMethods=help Modify the existing shared cache to invalidate the AOT methods that match the method specifications. Use this suboption to invalidate AOT methods that cause a failure in the application, without having to destroy the shared cache. Invalidated AOT methods remain in the shared cache, but are then excluded from being loaded. VMs that have not processed the methods, or new VMs that use the cache are not affected by the invalidated methods. The AOT methods are invalidated for the lifetime of the cache, but do not prevent the AOT methods from being compiled again if a new shared cache is created. To prevent AOT method compilation into a new shared cache, use the -Xaot:exclude option. For more information, see -Xaot . To identify AOT problems, see Diagnosing a JIT or AOT problem . To revalidate an AOT method, see the revalidateAotMethods suboption. Use the findAotMethod suboption to determine which AOT methods match the method specifications. To learn more about the syntax to use for <method_specification> , including how to specify more than one method, see Method specification syntax .",
"title": "invalidateAotMethods (Cache utility)"
},
{
"location": "/xshareclasses/#listallcaches-cache-utility",
"text": "(AIX, Linux, z/OS only) -Xshareclasses:listAllCaches Lists all the compatible and incompatible caches, and snapshots that exist in the specified cache directory. If you do not specify cacheDir , the default directory is used. Summary information, such as Java version and current usage, is displayed for each cache.",
"title": "listAllCaches (Cache utility)"
},
{
"location": "/xshareclasses/#mprotect",
"text": "AIX, z/OS 31-bit: -Xshareclasses:mprotect=[default|all|none] Linux, Windows: -Xshareclasses:mprotect=[default|all|partialpagesonstartup|onfind|nopartialpages|none] where: default : By default, the memory pages that contain the cache are always protected, unless a specific page is being updated. This protection helps prevent accidental or deliberate corruption to the cache. The cache header is not protected by default because this protection has a performance cost. On Linux and Windows systems, after the startup phase, the Java virtual machine (VM) protects partially filled pages whenever new data is added to the shared class cache in the following sequence: The VM changes the memory protection of any partially filled pages to read/write. The VM adds the data to the cache. The VM changes the memory protection of any partially filled pages to read only. all : This value ensures that all the cache pages are protected, including the header. See Note. partialpagesonstartup : This value causes the VM to protect partially filled pages during startup as well as after the startup phase. This value is available only on Linux and Windows systems. onfind : When this option is specified, the VM protects partially filled pages when it reads new data in the cache that is added by another VM. This option is available only on Linux and Windows systems. nopartialpages : Use this value to turn off the protection of partially filled pages. This value is available only on Linux and Windows systems. none : Specifying this value disables the page protection. Note: Specifying all has a negative impact on performance. You should specify all only for problem diagnosis and not for production. Specifying values partialpagesonstartup or onfind can also have a negative impact on performance when the cache is being populated. There is no further impact when the cache is full or no longer being modified.",
"title": "mprotect"
},
{
"location": "/xshareclasses/#modified",
"text": "-Xshareclasses:modified=<modified_context> Used when a JVMTI agent is installed that might modify bytecode at run time. If you do not specify this suboption and a bytecode modification agent is installed, classes are safely shared with an extra performance cost. The <modified context> is a descriptor that is chosen by the user; for example, myModification1 . This option partitions the cache so that only VMs that are using context myModification1 can share the same classes. So if, for example, you run an application with a modification context and then run it again with a different modification context, all classes are stored twice in the cache. For more information, see Dealing with runtime bytecode modification . If you are migrating from IBM\u00ae SDK, Java Technology Edition, Version 7, or earlier releases, you must set -Xshareclasses:disableBCI when you use this option to retain the same behavior.",
"title": "modified"
},
{
"location": "/xshareclasses/#name",
"text": "-Xshareclasses:name=<name> Connects to a cache of a given name, creating the cache if it does not exist. This option is also used to indicate the cache that is to be modified by cache utilities; for example, destroy . Use the listAllCaches utility to show which named caches are currently available. If you do not specify a name, the default name \"sharedcc_%u\" is used. \"%u\" in the cache name inserts the current user name. On AIX, Linux, and z/OS systems, you can specify \"%g\" in the cache name to insert the current group name.",
"title": "name"
},
{
"location": "/xshareclasses/#noaot",
"text": "-Xshareclasses:noaot Disables caching and loading of AOT code. AOT code already in the shared data cache can be loaded.",
"title": "noaot"
},
{
"location": "/xshareclasses/#nobootclasspath",
"text": "-Xshareclasses:noBootclasspath Disables the storage of classes that are loaded by the bootstrap class loader in the shared classes cache. Often used with the SharedClassURLFilter API to control exactly which classes are cached. For more information about shared class filtering, see Using the SharedClassHelper API .",
"title": "noBootclasspath"
},
{
"location": "/xshareclasses/#nojitdata",
"text": "-Xshareclasses:nojitdata Disables caching of JIT data. JIT data already in the shared data cache can be loaded.",
"title": "nojitdata"
},
{
"location": "/xshareclasses/#none",
"text": "-Xshareclasses:none Added to the end of a command line, disables class data sharing. This suboption overrides class sharing arguments found earlier on the command line. This suboption disables the shared class utility APIs. To disable class data sharing without disabling the utility APIs, use the utilities suboption. For more information about the shared class utility APIs, see Obtaining information about shared caches .",
"title": "none"
},
{
"location": "/xshareclasses/#nonfatal",
"text": "-Xshareclasses:nonfatal Allows the VM to start even if class data sharing fails. Normal behavior for the VM is to refuse to start if class data sharing fails. If you select nonfatal and the shared classes cache fails to initialize, the VM attempts to connect to the cache in read-only mode. If this attempt fails, the VM starts without class data sharing.",
"title": "nonfatal"
},
{
"location": "/xshareclasses/#nonpersistent",
"text": "-Xshareclasses:nonpersistent Uses a nonpersistent cache. The cache is lost when the operating system shuts down. Nonpersistent and persistent caches can have the same name. On Linux and Windows systems, you must always use the nonpersistent suboption when you run utilities such as destroy on a nonpersistent cache. z/OS supports only nonpersistent caches.",
"title": "nonpersistent"
},
{
"location": "/xshareclasses/#persistent",
"text": "-Xshareclasses:persistent Uses a persistent cache. The cache is created on disk, which persists beyond operating system restarts. Nonpersistent and persistent caches can have the same name. On AIX, you must always use the persistent suboption when you run utilities such as destroy on a persistent cache.",
"title": "persistent"
},
{
"location": "/xshareclasses/#printallstats-cache-utility",
"text": "-Xshareclasses:printAllStats Displays detailed information about the contents of the cache that is specified in the name suboption. If the name is not specified, statistics are displayed about the default cache. Every class is listed in chronological order with a reference to the location from which it was loaded. For more information, see printAllStats utility .",
"title": "printAllStats (Cache utility)"
},
{
"location": "/xshareclasses/#printstats-cache-utility",
"text": "-Xshareclasses:printStats=<data_type>[+<data_type>] Displays summary information for the cache that is specified by the name , cacheDir , and nonpersistent suboptions. The most useful information that is displayed is how full the cache is and how many classes it contains. Stale classes are classes that are updated on the file system and which the cache has therefore marked as \"stale\". Stale classes are not purged from the cache and can be reused. Use the printStats=stale option to list all the stale entries and stale bytes. Specify one or more data types, which are separated by a plus symbol (+), to see more detailed information about the cache content. Data types include AOT data, class paths, and ROMMethods. For more information and for a full list of data types, see printStats utility .",
"title": "printStats (Cache utility)"
},
{
"location": "/xshareclasses/#readonly",
"text": "-Xshareclasses:readonly Opens an existing cache with read-only permissions. The Java virtual machine does not create a new cache with this suboption. Opening a cache read-only prevents the VM from making any updates to the cache. If you specify this suboption, the VM can connect to caches that were created by other users or groups without requiring write access. On AIX and Linux systems, this access is permitted only if the cache was created by using the -Xshareclasses:cacheDir option to specify a directory with appropriate permissions. If you do not use the -Xshareclasses:cacheDir option, the cache is created with default permissions, which do not permit access by other users or groups. By default, this suboption is not specified.",
"title": "readonly"
},
{
"location": "/xshareclasses/#reset",
"text": "-Xshareclasses:reset Causes a cache to be destroyed and then re-created when the VM starts up. This option can be added to the end of a command line as -Xshareclasses:reset .",
"title": "reset"
},
{
"location": "/xshareclasses/#restorefromsnapshot-cache-utility",
"text": "(AIX, Linux, z/OS only) -Xshareclasses:restoreFromSnapshot Restores a new non-persistent shared cache from a snapshot file. The snapshot and shared cache have the same name and location, as specified by the name and cacheDir suboptions. The non-persistent cache cannot already exist when the snapshot is restored. Restoring a snapshot does not remove the snapshot file; it can be restored multiple times. On platforms that support persistent caches, the nonpersistent suboption must be specified in order to restore a snapshot.",
"title": "restoreFromSnapshot (Cache utility)"
},
{
"location": "/xshareclasses/#restrictclasspaths",
"text": "-Xshareclasses:restrictClasspaths Allows only the first VM that is initializing a shared cache to store classpaths in the cache. Subsequent VMs are not allowed to store classpaths in the cache unless the allowClasspaths option is specified. Use the restrictClasspaths option only if the application is designed to create class loaders of type java.net.URLClassloader or its subclass, such that their classpaths are unique to the instance of the application, but the classes that are loaded from these classpaths are the same. In such cases application classpaths that are stored by one VM cannot be used by another VM. For example, consider two VMs, VM1 and VM2, that are using class paths CP1 and CP2 respectively, where: CP1: url1;url2;url3;tempurl1;url4;url5 CP2: url1;url2;url3;tempurl2;url4;url5 These class paths differ only by one entry, which is the tempurl . The url1 , url2 , url3 , url4 , and url5 entries never change from run to run, whereas the tempurl entry is always different. This difference means that a class that is loaded from url4 or url5 , and stored into the shared cache by VM1, cannot be located by VM2. Therefore, an attempt by VM2 to load a class from url4 or url5 would cause it to store its own classpath CP2 into the shared cache, and also add new metadata for classes that are loaded from url4 or url5 . Addition of such unique class paths into the shared cache is not useful. Moreover, the additional metadata might adversely affect the performance of other VMs that connect to the shared cache. Because classes loaded from url4 or url5 are not loaded from the shared cache when the tempurl differs from the original, it is good practice to put the tempurl as the last entry in the class path. In situations such as that described in the example, the restrictClasspaths option can be used to restrict the addition of classpaths by ensuring that the first VM initializes the shared cache, and then prevents the addition of unique classpaths by subsequent VMs that attach to the shared cache. Note that use of the restrictClasspaths option in any other scenario is likely to negatively impact a VM's performance when it is using an existing cache.",
"title": "restrictClasspaths"
},
{
"location": "/xshareclasses/#revalidateaotmethods-cache-utility",
"text": "-Xshareclasses:revalidateAotMethods=<method_specification>\n -Xshareclasses:revalidateAotMethods=help Modify the shared cache to revalidate the AOT methods that match the method specifications. Use this suboption to revalidate AOT methods that were invalidated by using the invalidateAotMethods suboption. Revalidated AOT methods are then eligible for loading into a VM, but do not affect VMs where the methods have already been processed. To learn more about the syntax to use for <method_specification> , including how to specify more than one method, see Method specification syntax .",
"title": "revalidateAotMethods (Cache utility)"
},
{
"location": "/xshareclasses/#silent",
"text": "-Xshareclasses:silent Disables all shared class messages, including error messages. Unrecoverable error messages, which prevent the VM from initializing, are displayed.",
"title": "silent"
},
{
"location": "/xshareclasses/#snapshotcache-cache-utility",
"text": "(AIX, Linux, z/OS only) -Xshareclasses:snapshotCache Creates a snapshot file of an existing non-persistent shared cache. The snapshot has the same name and location as the shared cache, as specified by the name and cacheDir suboptions. The shared cache can be in use when the snapshot is taken, but VMs are blocked when they try to write to the shared cache, while the cache data is copied to the file. Typically, after a system is reinitialized, the snapshot file is used to restore the copy of the non-persistent cache into shared memory, via the restoreFromSnapshot suboption. Since this process removes all non-persistent caches from shared memory, restoring the cache from the snapshot file can result in better VM startup performance, because the contents of the shared cache, including classes and AOT code, do not have to be re-created. A snapshot can be created only if the user has sufficient permissions to create the destination snapshot file. If a snapshot of the same name exists already, it is overwritten. On platforms that support persistent caches, the nonpersistent suboption must be specified in order to create a snapshot. For information about removing snapshot files, see the destroySnapshot and destroyAllSnapshots suboptions.",
"title": "snapshotCache (Cache utility)"
},
{
"location": "/xshareclasses/#utilities",
"text": "-Xshareclasses:utilities Can be added to the end of a command line to disable class data sharing. This suboption overrides class sharing arguments found earlier on the command line. This suboption is like none , but does not disable the shared class utility APIs. For more information about the shared class utility APIs, see Obtaining information about shared caches .",
"title": "utilities"
},
{
"location": "/xshareclasses/#verbose",
"text": "-Xshareclasses:verbose Gives detailed output on the cache I/O activity, listing information about classes that are stored and found. Each class loader is given a unique ID (the bootstrap loader is always 0) and the output shows the class loader hierarchy at work, where class loaders ask their parents for a class if they can't find it themselves. It is typical to see many failed requests; this behavior is expected for the class loader hierarchy. The standard option -verbose:class also enables class sharing verbose output if class sharing is enabled.",
"title": "verbose"
},
{
"location": "/xshareclasses/#verboseaot",
"text": "-Xshareclasses:verboseAOT Enables verbose output when compiled AOT code is being found or stored in the cache. AOT code is generated heuristically. You might not see any AOT code that is generated at all for a small application. You can disable AOT caching by using the noaot suboption. See the Messages Guide for a list of the messages produced.",
"title": "verboseAOT"
},
{
"location": "/xshareclasses/#verbosehelper",
"text": "-Xshareclasses:verboseHelper Enables verbose output for the Java Helper API. This output shows you how the Helper API is used by your class loader.",
"title": "verboseHelper"
},
{
"location": "/xshareclasses/#verboseio",
"text": "-Xshareclasses:verboseIO Gives detailed output on the cache I/O activity, listing information about classes that are stored and found. Each class loader is given a unique ID (the bootstrap loader is always 0) and the output shows the class loader hierarchy at work, where class loaders must ask their parents for a class before they can load it themselves. It is typical to see many failed requests; this behavior is expected for the class loader hierarchy.",
"title": "verboseIO"
},
{
"location": "/xshareclasses/#method-specification-syntax",
"text": "The following examples show how to specify more than one method specification when you are using the findAotMethods , invalidateAotMethods , or revalidateAotMethods suboptions. Each method specification is defined as follows: < packagename >/< classname >[.< methodname >[(< parameters >)]] If you want to include more than one method specification in a single option, separate the specifications with a comma and enclose all the specifications in {braces}. For example: {< packagename / classname >}[.{< methodname >}[({< parameters >})]] You can use an asterisk (*) in most places as a wildcard. You can use an exclamation point (!) before the specification to mean \"everything except this\". Parameters are optional, but if specified, should be enclosed in parentheses and the following native signature formats must be used: B for byte C for char D for double F for float I for int J for long S for short Z for Boolean L<classname>; for objects [ before the signature means array If you want to specify parameters to distinguish between methods, you can use -Xshareclasses:findAotMethods=* (with a wildcard) to list all the parameter variations. Copy the signature for the method that you want from the output. For example, the signature for the parameters (byte[] bytes, int offset, int length, Charset charset) is ([BIILjava/nio/charset/Charset;) Here are some examples: Method signature Matches... * All AOT methods. java/lang/Object All AOT methods in the java.lang.Object class java/util/* All AOT classes and methods in the java.util package java/util/HashMap.putVal All putVal methods in the java.util.HashMap class java/util/HashMap.hash(Ljava/lang/Object;) The private java.util.HashMap.hash(java.lang.Object) method *.equals All equals methods in all classes {java/lang/Object,!java/lang/Object.clone} All methods in java.lang.Object except clone {java/util/*.*(),java/lang/Object.*(*)} All classes or methods with no input parameter in the java.util package, and all methods in java.lang.Object {java/util/*.*(),!java/util/*.*()} Nothing.",
"title": "Method specification syntax"
},
{
"location": "/xshareclasses/#see-also",
"text": "-Xscmx -XX\\:SharedCacheHardLimit",
"title": "See also"
},
{
"location": "/xsigcatch/",
"text": "-Xsigcatch / -Xnosigcatch\n\n\nEnables and disables VM signal handling code.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xsigcatch\n\n\nEnable\n\n\nyes\n\n\n\n\n\n\n-Xnosigcatch\n\n\nDisable",
"title": "-Xsigcatch"
},
{
"location": "/xsigcatch/#-xsigcatch-xnosigcatch",
"text": "Enables and disables VM signal handling code.",
"title": "-Xsigcatch / -Xnosigcatch"
},
{
"location": "/xsigcatch/#syntax",
"text": "Setting Effect Default -Xsigcatch Enable yes -Xnosigcatch Disable",
"title": "Syntax"
},
{
"location": "/xsigchain/",
"text": "-Xsigchain / -Xnosigchain\n\n\nEnables and disables signal handler chaining.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xsigchain\n\n\nEnable\n\n\nyes\n (except on z/OS\u00ae)\n\n\n\n\n\n\n-Xnosigchain\n\n\nDisable",
"title": "-Xsigchain"
},
{
"location": "/xsigchain/#-xsigchain-xnosigchain",
"text": "Enables and disables signal handler chaining.",
"title": "-Xsigchain / -Xnosigchain"
},
{
"location": "/xsigchain/#syntax",
"text": "Setting Effect Default -Xsigchain Enable yes (except on z/OS\u00ae) -Xnosigchain Disable",
"title": "Syntax"
},
{
"location": "/xsignal/",
"text": "-Xsignal\n\n\n(z/OS\u00ae only)\n\n\nThis option controls the behavior of OpenJ9 VM signal handlers.\n\n\nSyntax\n\n\n -Xsignal:<parameter>=<value>\n\n\n\n\n\nParameters\n\n\n \nRestriction:\n You cannot use these parameters together.\n\n\nposixSignalHandler\n\n\n -Xsignal:posixSignalHandler=cooperativeShutdown\n\n\n\n\n\n\n\n\n\nWhen the VM signal handlers for SIGSEGV, SIGILL, SIGBUS, SIGFPE, SIGTRAP, and SIGABRT end a process, they call \nexit()\n, by default. In this case, the z/OS\u2122 Language Environment\u00ae is not aware that the VM ended abnormally.\n\n\nWith \n-Xsignal:posixSignalHandler=cooperativeShutdown\n, the VM no longer uses \nexit()\n to end the process from the signal handlers. Instead, the VM behaves in one of the following ways:\n\n\n\n\nIn response to a z/OS hardware exception, the VM uses \nreturn()\n.\n\n\nIn response to signals raised or injected by software, the VM ends the enclave with \nabend 3565\n.\n\n\n\n\nLanguage Environment detects that the VM is ending abnormally and initiates Resource Recovery Services.\n\n\n\n\n\n\nuserConditionHandler\n\n\n\n\n(31-bit z/OS only)\n-Xsignal:userConditionHandler=percolate\n\n\n\n\n\n\n\n\n\nThis option results in similar behavior to the \n-XCEEHDLR\n option: the VM registers user condition handlers to handle the z/OS exceptions that would otherwise be handled by the VM POSIX signal handlers for the SIGBUS, SIGFPE, SIGILL, SIGSEGV, and SIGTRAP signals.\n\n\nAs with the \n-XCEEHDLR\n option, the VM does not install POSIX signal handlers for these signals.\n\n\nThis option differs from the \n-XCEEHDLR\n option in that the VM percolates \nall\n Language Environment\u00ae conditions that were not triggered and expected by the VM during normal running, including conditions that are severity 2 or greater. The VM generates its own diagnostic information before percolating severity 2 or greater conditions.\n\n\nThe VM is in an undefined state after percolating a severity 2 or greater condition. Applications cannot resume running then call back into, or return to, the VM.\n\n\n\n\n\n\nSee also\n\n\n\n\n-XCEEHDLR\n\n\nSignals used by the VM\n.",
"title": "-Xsignal"
},
{
"location": "/xsignal/#-xsignal",
"text": "(z/OS\u00ae only) This option controls the behavior of OpenJ9 VM signal handlers.",
"title": "-Xsignal"
},
{
"location": "/xsignal/#syntax",
"text": "-Xsignal:<parameter>=<value>",
"title": "Syntax"
},
{
"location": "/xsignal/#parameters",
"text": "Restriction: You cannot use these parameters together.",
"title": "Parameters"
},
{
"location": "/xsignal/#posixsignalhandler",
"text": "-Xsignal:posixSignalHandler=cooperativeShutdown When the VM signal handlers for SIGSEGV, SIGILL, SIGBUS, SIGFPE, SIGTRAP, and SIGABRT end a process, they call exit() , by default. In this case, the z/OS\u2122 Language Environment\u00ae is not aware that the VM ended abnormally. With -Xsignal:posixSignalHandler=cooperativeShutdown , the VM no longer uses exit() to end the process from the signal handlers. Instead, the VM behaves in one of the following ways: In response to a z/OS hardware exception, the VM uses return() . In response to signals raised or injected by software, the VM ends the enclave with abend 3565 . Language Environment detects that the VM is ending abnormally and initiates Resource Recovery Services.",
"title": "posixSignalHandler"
},
{
"location": "/xsignal/#userconditionhandler",
"text": "(31-bit z/OS only) -Xsignal:userConditionHandler=percolate This option results in similar behavior to the -XCEEHDLR option: the VM registers user condition handlers to handle the z/OS exceptions that would otherwise be handled by the VM POSIX signal handlers for the SIGBUS, SIGFPE, SIGILL, SIGSEGV, and SIGTRAP signals. As with the -XCEEHDLR option, the VM does not install POSIX signal handlers for these signals. This option differs from the -XCEEHDLR option in that the VM percolates all Language Environment\u00ae conditions that were not triggered and expected by the VM during normal running, including conditions that are severity 2 or greater. The VM generates its own diagnostic information before percolating severity 2 or greater conditions. The VM is in an undefined state after percolating a severity 2 or greater condition. Applications cannot resume running then call back into, or return to, the VM.",
"title": "userConditionHandler"
},
{
"location": "/xsignal/#see-also",
"text": "-XCEEHDLR Signals used by the VM .",
"title": "See also"
},
{
"location": "/xsoftmx/",
"text": "-Xsoftmx\n\n\nThis option sets a \"soft\" maximum limit for the initial size of the Java\u2122 heap.\n\n\nSyntax\n\n\n -Xsoftmx<size>\n\n\n\n\n\nExplanation\n\n\nUse the \n-Xmx\n option to set a \"hard\" limit for the maximum size of the heap. By default, \n-Xsoftmx\n is set to the same value as \n-Xmx\n. The value of \n-Xms\n must be less than, or equal to, the value of \n-Xsoftmx\n. See the introduction to this topic for more information about specifying \n<size>\n parameters.\n\n\nYou can set this option on the command line, then modify it at run time by using the \nMemoryMXBean.setMaxHeapSize()\n method in the \ncom.ibm.lang.management\n API. By using this API, Java applications can dynamically monitor and adjust the heap size as required. This function can be useful in virtualized or cloud environments, for example, where the available memory might change dynamically to meet business needs. When you use the API, you must specify the value in bytes, such as \n2147483648\n instead of \n2g\n.\n\n\nFor example, you might set the initial heap size to 1 GB and the maximum heap size to 8 GB. You might set a smaller value, such as 2 GB, for \n-Xsoftmx\n, to limit the heap size that is used initially:\n\n\n-\nXms1g\n \n-\nXsoftmx2g\n \n-\nXmx8g\n\n\n\n\n\n\nYou can then use the \ncom.ibm.lang.management\n API from within a Java application to increase the \n-Xsoftmx\n value during run time, as load increases. This change allows the application to use more memory than you specified initially.\n\n\nIf you reduce the \n-Xsoftmx\n value, the garbage collector attempts to respect the new limit. However, the ability to shrink the heap depends on a number of factors. There is no guarantee that a decrease in the heap size will occur. If or when the heap shrinks to less than the new limit, the heap will not grow beyond that limit.\n\n\nWhen the heap shrinks, the garbage collector might release memory. The ability of the operating system to reclaim and use this memory varies based on the capabilities of the operating system.\n\n\n \nNotes:\n\n\n\n\n\n\nWhen using \n-Xgcpolicy:gencon\n, \n-Xsoftmx\n applies only to the non-nursery portion of the heap. In some cases the heap grows to greater than the \n-Xsoftmx\n value because the nursery portion grows, making the heap size exceed the limit that is set. See \n-Xmn\n for limiting the nursery size.\n\n\n\n\n\n\nWhen using \n-Xgcpolicy:metronome\n, \n-Xsoftmx\n is ignored because the Metronome garbage collector does not support contraction or expansion of the heap.\n\n\n\n\n\n\nThere might be little benefit in reducing the \n-Xsoftmx\n value when the Java heap is using large pages. Large pages are pinned in memory and are not reclaimed by the operating system, with the exception of 1M pageable pages on z/OS\u00ae. On certain platforms and processors the VM starts with large pages enabled by default for the Java heap when the operating system is configured to provide large pages.\nFor more information, see \nConfiguring large page memory allocation\n. A future version of the Java virtual machine might provide a hint to the operating system when large pages are no longer in use.",
"title": "-Xsoftmx"
},
{
"location": "/xsoftmx/#-xsoftmx",
"text": "This option sets a \"soft\" maximum limit for the initial size of the Java\u2122 heap.",
"title": "-Xsoftmx"
},
{
"location": "/xsoftmx/#syntax",
"text": "-Xsoftmx<size>",
"title": "Syntax"
},
{
"location": "/xsoftmx/#explanation",
"text": "Use the -Xmx option to set a \"hard\" limit for the maximum size of the heap. By default, -Xsoftmx is set to the same value as -Xmx . The value of -Xms must be less than, or equal to, the value of -Xsoftmx . See the introduction to this topic for more information about specifying <size> parameters. You can set this option on the command line, then modify it at run time by using the MemoryMXBean.setMaxHeapSize() method in the com.ibm.lang.management API. By using this API, Java applications can dynamically monitor and adjust the heap size as required. This function can be useful in virtualized or cloud environments, for example, where the available memory might change dynamically to meet business needs. When you use the API, you must specify the value in bytes, such as 2147483648 instead of 2g . For example, you might set the initial heap size to 1 GB and the maximum heap size to 8 GB. You might set a smaller value, such as 2 GB, for -Xsoftmx , to limit the heap size that is used initially: - Xms1g - Xsoftmx2g - Xmx8g You can then use the com.ibm.lang.management API from within a Java application to increase the -Xsoftmx value during run time, as load increases. This change allows the application to use more memory than you specified initially. If you reduce the -Xsoftmx value, the garbage collector attempts to respect the new limit. However, the ability to shrink the heap depends on a number of factors. There is no guarantee that a decrease in the heap size will occur. If or when the heap shrinks to less than the new limit, the heap will not grow beyond that limit. When the heap shrinks, the garbage collector might release memory. The ability of the operating system to reclaim and use this memory varies based on the capabilities of the operating system. Notes: When using -Xgcpolicy:gencon , -Xsoftmx applies only to the non-nursery portion of the heap. In some cases the heap grows to greater than the -Xsoftmx value because the nursery portion grows, making the heap size exceed the limit that is set. See -Xmn for limiting the nursery size. When using -Xgcpolicy:metronome , -Xsoftmx is ignored because the Metronome garbage collector does not support contraction or expansion of the heap. There might be little benefit in reducing the -Xsoftmx value when the Java heap is using large pages. Large pages are pinned in memory and are not reclaimed by the operating system, with the exception of 1M pageable pages on z/OS\u00ae. On certain platforms and processors the VM starts with large pages enabled by default for the Java heap when the operating system is configured to provide large pages.\nFor more information, see Configuring large page memory allocation . A future version of the Java virtual machine might provide a hint to the operating system when large pages are no longer in use.",
"title": "Explanation"
},
{
"location": "/xsoftrefthreshold/",
"text": "-Xsoftrefthreshold\n\n\nSets the value used by the garbage collector to determine the number of garbage collections after which a soft reference is cleared if its referent has not been marked.\n\n\nSyntax\n\n\n -Xsoftrefthreshold<value>\n\n\n\n\n\nDefault behavior\n\n\nThe default value is 32.\n\n\nExplanation\n\n\nA soft reference (where its referent is not marked) is cleared after a number of garbage collection cycles calculated as: \n<value>\n * (proportion of free heap space)\n\n\nFor example, if \n-Xsoftrefthreshold\n is set to 32, and the heap is 25% free, soft references are cleared after 8 garbage collection cycles.",
"title": "-Xsoftrefthreshold"
},
{
"location": "/xsoftrefthreshold/#-xsoftrefthreshold",
"text": "Sets the value used by the garbage collector to determine the number of garbage collections after which a soft reference is cleared if its referent has not been marked.",
"title": "-Xsoftrefthreshold"
},
{
"location": "/xsoftrefthreshold/#syntax",
"text": "-Xsoftrefthreshold<value>",
"title": "Syntax"
},
{
"location": "/xsoftrefthreshold/#default-behavior",
"text": "The default value is 32.",
"title": "Default behavior"
},
{
"location": "/xsoftrefthreshold/#explanation",
"text": "A soft reference (where its referent is not marked) is cleared after a number of garbage collection cycles calculated as: <value> * (proportion of free heap space) For example, if -Xsoftrefthreshold is set to 32, and the heap is 25% free, soft references are cleared after 8 garbage collection cycles.",
"title": "Explanation"
},
{
"location": "/xss/",
"text": "-Xiss / -Xss / -Xssi\n\n\nDetermines the size and behavior of the stack size for Java\u2122 threads. \n\n\nTo increase the maximum number of threads your system can support, reduce the maximum native stack size.\n\n\nIf you exceed the maximum Java thread stack size, a \njava/lang/OutOfMemoryError\n message is reported.\n\n\nYou can use the \n-verbose:sizes\n option to find out the values that the VM is currently using.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xiss<size>\n\n\nSet initial Java thread stack size\n\n\n2 KB\n\n\n\n\n\n\n-Xss<size>\n\n\nSet maximum Java thread stack size\n\n\n320 KB (31/32-bit); 1024 KB (64-bit)\n\n\n\n\n\n\n-Xssi<size>\n\n\nSet Java thread stack size increment\n\n\n16 KB\n\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter. \n\n\nSee \nDefault settings for the OpenJ9 VM\n for more about default values.\n\n\nSee also\n\n\n\n\n-Xmso\n (Initial stack size for operating system threads)",
"title": "-Xss"
},
{
"location": "/xss/#-xiss-xss-xssi",
"text": "Determines the size and behavior of the stack size for Java\u2122 threads. To increase the maximum number of threads your system can support, reduce the maximum native stack size. If you exceed the maximum Java thread stack size, a java/lang/OutOfMemoryError message is reported. You can use the -verbose:sizes option to find out the values that the VM is currently using.",
"title": "-Xiss / -Xss / -Xssi"
},
{
"location": "/xss/#syntax",
"text": "Setting Effect Default -Xiss<size> Set initial Java thread stack size 2 KB -Xss<size> Set maximum Java thread stack size 320 KB (31/32-bit); 1024 KB (64-bit) -Xssi<size> Set Java thread stack size increment 16 KB See Using -X command-line options for more information about the <size> parameter. See Default settings for the OpenJ9 VM for more about default values.",
"title": "Syntax"
},
{
"location": "/xss/#see-also",
"text": "-Xmso (Initial stack size for operating system threads)",
"title": "See also"
},
{
"location": "/xss/",
"text": "-Xiss / -Xss / -Xssi\n\n\nDetermines the size and behavior of the stack size for Java\u2122 threads. \n\n\nTo increase the maximum number of threads your system can support, reduce the maximum native stack size.\n\n\nIf you exceed the maximum Java thread stack size, a \njava/lang/OutOfMemoryError\n message is reported.\n\n\nYou can use the \n-verbose:sizes\n option to find out the values that the VM is currently using.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xiss<size>\n\n\nSet initial Java thread stack size\n\n\n2 KB\n\n\n\n\n\n\n-Xss<size>\n\n\nSet maximum Java thread stack size\n\n\n320 KB (31/32-bit); 1024 KB (64-bit)\n\n\n\n\n\n\n-Xssi<size>\n\n\nSet Java thread stack size increment\n\n\n16 KB\n\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter. \n\n\nSee \nDefault settings for the OpenJ9 VM\n for more about default values.\n\n\nSee also\n\n\n\n\n-Xmso\n (Initial stack size for operating system threads)",
"title": "-Xssi"
},
{
"location": "/xss/#-xiss-xss-xssi",
"text": "Determines the size and behavior of the stack size for Java\u2122 threads. To increase the maximum number of threads your system can support, reduce the maximum native stack size. If you exceed the maximum Java thread stack size, a java/lang/OutOfMemoryError message is reported. You can use the -verbose:sizes option to find out the values that the VM is currently using.",
"title": "-Xiss / -Xss / -Xssi"
},
{
"location": "/xss/#syntax",
"text": "Setting Effect Default -Xiss<size> Set initial Java thread stack size 2 KB -Xss<size> Set maximum Java thread stack size 320 KB (31/32-bit); 1024 KB (64-bit) -Xssi<size> Set Java thread stack size increment 16 KB See Using -X command-line options for more information about the <size> parameter. See Default settings for the OpenJ9 VM for more about default values.",
"title": "Syntax"
},
{
"location": "/xss/#see-also",
"text": "-Xmso (Initial stack size for operating system threads)",
"title": "See also"
},
{
"location": "/xtgc/",
"text": "-Xtgc\n\n\nProvides garbage collection tracing options.\n\n\nSyntax\n\n\n -Xtgc:<parameter>{,<parameter>}\n\n\n\n\n\nParameters\n\n\n\n\nSpecify one one or more of the following parameters in a comma-separated list:\n\n\n\n\nbacktrace\n\n\n -Xtgc:backtrace\n\n\n\n\n\n\n\nBefore a garbage collection, a single line is printed containing the name of the master thread for garbage collection, as well as the value of the \nosThread\n slot in the \nJ9VMThread\n structure.\n\n\n\n\ncompaction\n\n\n -Xtgc:compaction\n\n\n\n\n\n\n\nPrints extra information showing the relative time spent by threads in the \n\"move\"\n and \n\"fixup\"\n phases of compaction\n\n\n\n\nconcurrent\n\n\n -Xtgc:concurrent\n\n\n\n\n\n\n\nPrints extra information showing the activity of the concurrent mark background thread\n\n\n\n\ndump\n\n\n -Xtgc:dump\n\n\n\n\n\n\n\nPrints a line of output for every free chunk of memory in the system, including \"dark matter\" (free chunks that are not on the free list for some reason, typically because they are too small). Each line contains the base address and the size in bytes of the chunk. If the chunk is followed in the heap by an object, the size and class name of the object is also printed. This argument has a similar effect to the \nterse\n argument.\n\n\n\n\nfreeList\n\n\n -Xtgc:freeList\n\n\n\n\n\n\n\nBefore a garbage collection, prints information about the free list and allocation statistics since the last garbage collection. Prints the number of items on the free list, including \"deferred\" entries (with the scavenger, the unused space is a deferred free list entry). For TLH and non-TLH allocations, prints the total number of allocations, the average allocation size, and the total number of bytes discarded during allocation. For non-TLH allocations, also included is the average number of entries that were searched before a sufficiently large entry was found.\n\n\n\n\nparallel\n\n\n -Xtgc:parallel\n\n\n\n\n\n\n\nProduces statistics on the activity of the parallel threads during the mark and sweep phases of a global garbage collection.\n\n\n\n\nscavenger\n\n\n -Xtgc:scavenger\n\n\n\n\n\n\n\nPrints extra information after each scavenger collection. A histogram is produced showing the number of instances of each class, and their relative ages, present in the survivor space. The information is obtained by performing a linear walk-through of the space.\n\n\n\n\nterse\n\n\n -Xtgc:terse\n\n\n\n\n\n\n\nDumps the contents of the entire heap before and after a garbage collection. For each object or free chunk in the heap, a line of trace output is produced. Each line contains the base address, \"a\" if it is an allocated object, and \"f\" if it is a free chunk, the size of the chunk in bytes, and, if it is an object, its class name.",
"title": "-Xtgc"
},
{
"location": "/xtgc/#-xtgc",
"text": "Provides garbage collection tracing options.",
"title": "-Xtgc"
},
{
"location": "/xtgc/#syntax",
"text": "-Xtgc:<parameter>{,<parameter>}",
"title": "Syntax"
},
{
"location": "/xtgc/#parameters",
"text": "Specify one one or more of the following parameters in a comma-separated list:",
"title": "Parameters"
},
{
"location": "/xtgc/#backtrace",
"text": "-Xtgc:backtrace Before a garbage collection, a single line is printed containing the name of the master thread for garbage collection, as well as the value of the osThread slot in the J9VMThread structure.",
"title": "backtrace"
},
{
"location": "/xtgc/#compaction",
"text": "-Xtgc:compaction Prints extra information showing the relative time spent by threads in the \"move\" and \"fixup\" phases of compaction",
"title": "compaction"
},
{
"location": "/xtgc/#concurrent",
"text": "-Xtgc:concurrent Prints extra information showing the activity of the concurrent mark background thread",
"title": "concurrent"
},
{
"location": "/xtgc/#dump",
"text": "-Xtgc:dump Prints a line of output for every free chunk of memory in the system, including \"dark matter\" (free chunks that are not on the free list for some reason, typically because they are too small). Each line contains the base address and the size in bytes of the chunk. If the chunk is followed in the heap by an object, the size and class name of the object is also printed. This argument has a similar effect to the terse argument.",
"title": "dump"
},
{
"location": "/xtgc/#freelist",
"text": "-Xtgc:freeList Before a garbage collection, prints information about the free list and allocation statistics since the last garbage collection. Prints the number of items on the free list, including \"deferred\" entries (with the scavenger, the unused space is a deferred free list entry). For TLH and non-TLH allocations, prints the total number of allocations, the average allocation size, and the total number of bytes discarded during allocation. For non-TLH allocations, also included is the average number of entries that were searched before a sufficiently large entry was found.",
"title": "freeList"
},
{
"location": "/xtgc/#parallel",
"text": "-Xtgc:parallel Produces statistics on the activity of the parallel threads during the mark and sweep phases of a global garbage collection.",
"title": "parallel"
},
{
"location": "/xtgc/#scavenger",
"text": "-Xtgc:scavenger Prints extra information after each scavenger collection. A histogram is produced showing the number of instances of each class, and their relative ages, present in the survivor space. The information is obtained by performing a linear walk-through of the space.",
"title": "scavenger"
},
{
"location": "/xtgc/#terse",
"text": "-Xtgc:terse Dumps the contents of the entire heap before and after a garbage collection. For each object or free chunk in the heap, a line of trace output is produced. Each line contains the base address, \"a\" if it is an allocated object, and \"f\" if it is a free chunk, the size of the chunk in bytes, and, if it is an object, its class name.",
"title": "terse"
},
{
"location": "/xthr/",
"text": "-Xthr\n\n\nSyntax\n\n\n -Xthr:<parameter>\n\n\n\n\n\nParameters\n\n\nAdaptSpin\n | \nnoAdaptSpin\n\n\n -Xthr:AdaptSpin\n -Xthr:noAdaptSpin\n\n\n\n\n\n\n\nThis tuning option is available to test whether performance optimizations are negatively impacting an application.\n\n\n\n\nfastNotify\n | \nnoFastNotify\n\n\n -Xthr:fastNotify\n -Xthr:noFastNotify\n\n\n\n\n\n\n\nWhen a large number of threads try to acquire a Java\u2122 monitor, throughput of an application can be reduced. This issue is known as high contention. If high contention occurs when the Java \nwait\n and \nnotify\n features are regularly used, you can use \n-Xthr:fastNotify\n to increase throughput. However, \n-Xthr:noFastNotify\n is the default setting, because it is faster in all other scenarios.\n\n\n\n\ncfsYield\n | \nnoCfsYield\n (Linux\u2122 only)\n\n\n -Xthr:cfsYield\n -Xthr:noCfsYield\n\n\n\n\n\n\n\nThe default value, \ncfsYield\n, enables threading optimizations for running on Linux with the Completely Fair Scheduler (CFS) in the default mode (\nsched_compat_yield=0\n). The \nnoCfsYield\n value disables these threading optimizations. You might want to use the \nnoCfsYield\n value if your application uses the \nThread.yield()\n method extensively, because otherwise you might see a performance decrease in cases where yielding is not beneficial.\n\n\n\n\nminimizeUserCPU\n\n\n -Xthr:minimizeUserCPU\n\n\n\n\n\n\n\nMinimizes user-mode CPU usage in thread synchronization where possible. The reduction in CPU usage might be a trade-off in exchange for decreased performance.\n\n\n\n\nsecondarySpinForObjectMonitors\n | \nnoSecondarySpinForObjectMonitors\n\n\n -Xthr:secondarySpinForObjectMonitors\n -Xthr:noSecondarySpinForObjectMonitors\n\n\n\n\n\n\n\nThis tuning option is available to test whether performance optimizations are negatively impacting an application.",
"title": "-Xthr"
},
{
"location": "/xthr/#-xthr",
"text": "",
"title": "-Xthr"
},
{
"location": "/xthr/#syntax",
"text": "-Xthr:<parameter>",
"title": "Syntax"
},
{
"location": "/xthr/#parameters",
"text": "",
"title": "Parameters"
},
{
"location": "/xthr/#adaptspin-noadaptspin",
"text": "-Xthr:AdaptSpin\n -Xthr:noAdaptSpin This tuning option is available to test whether performance optimizations are negatively impacting an application.",
"title": "AdaptSpin | noAdaptSpin"
},
{
"location": "/xthr/#fastnotify-nofastnotify",
"text": "-Xthr:fastNotify\n -Xthr:noFastNotify When a large number of threads try to acquire a Java\u2122 monitor, throughput of an application can be reduced. This issue is known as high contention. If high contention occurs when the Java wait and notify features are regularly used, you can use -Xthr:fastNotify to increase throughput. However, -Xthr:noFastNotify is the default setting, because it is faster in all other scenarios.",
"title": "fastNotify | noFastNotify"
},
{
"location": "/xthr/#cfsyield-nocfsyield-linux-only",
"text": "-Xthr:cfsYield\n -Xthr:noCfsYield The default value, cfsYield , enables threading optimizations for running on Linux with the Completely Fair Scheduler (CFS) in the default mode ( sched_compat_yield=0 ). The noCfsYield value disables these threading optimizations. You might want to use the noCfsYield value if your application uses the Thread.yield() method extensively, because otherwise you might see a performance decrease in cases where yielding is not beneficial.",
"title": "cfsYield | noCfsYield (Linux&trade; only)"
},
{
"location": "/xthr/#minimizeusercpu",
"text": "-Xthr:minimizeUserCPU Minimizes user-mode CPU usage in thread synchronization where possible. The reduction in CPU usage might be a trade-off in exchange for decreased performance.",
"title": "minimizeUserCPU"
},
{
"location": "/xthr/#secondaryspinforobjectmonitors-nosecondaryspinforobjectmonitors",
"text": "-Xthr:secondarySpinForObjectMonitors\n -Xthr:noSecondarySpinForObjectMonitors This tuning option is available to test whether performance optimizations are negatively impacting an application.",
"title": "secondarySpinForObjectMonitors | noSecondarySpinForObjectMonitors"
},
{
"location": "/xtlhprefetch/",
"text": "-XtlhPrefetch\n\n\n(AIX\u00ae, Windows\u2122 only)\n\n\nSpeculatively prefetches bytes in the thread local heap (TLH) ahead of the current allocation pointer during object allocation. This option helps reduce the performance cost of subsequent allocations.\n\n\nSyntax\n\n\n XtlhPrefetch",
"title": "-XtlhPrefetch"
},
{
"location": "/xtlhprefetch/#-xtlhprefetch",
"text": "(AIX\u00ae, Windows\u2122 only) Speculatively prefetches bytes in the thread local heap (TLH) ahead of the current allocation pointer during object allocation. This option helps reduce the performance cost of subsequent allocations.",
"title": "-XtlhPrefetch"
},
{
"location": "/xtlhprefetch/#syntax",
"text": "XtlhPrefetch",
"title": "Syntax"
},
{
"location": "/xtrace/",
"text": "-Xtrace\n\n\nOpenJ9 VM tracing is a powerful feature to help you diagnose problems with minimal affect on performance. Tracing is enabled by default, together with a small set of trace points going to memory buffers. You can enable tracepoints at run time by using levels, components, group names, or individual tracepoint identifiers to trace VM internal operations and instrumented Java\u2122 applications. You can also trace Java methods. See the \nAbout trace\n section that follows for more detail.\n\n\nTrace data can be output in human-readable or in compressed binary formats. The VM provides a tool to process and convert the compressed binary data into a readable format. See \nTrace formatter\n. \n\n\n \nNote:\n You can also control trace by using the \ncom.ibm.jvm.Trace\n API or by using JVMTI from an external agent.\n\n\nXtrace Option Builder\n\n\nUse the \nXtrace Option Builder tool\n to help you specify the correct options and avoid incompatibilities.\n\n\nSyntax\n\n\n-Xtrace:<parameter>\n\n\n\n\n\nYou can get help with \n-Xtrace\nby using the folowing options:\n\n\n\n\n-Xtrace:help\n \u00a0 Displays general trace help\n\n\n-Xtrace:what\n \u00a0 Shows the current trace settings\n\n\n\n\n\n\n\nConfiguring trace\n\n\nThe following parameters can be used to configure trace. (Follow links for more information about individual options.)\n\n\n\n\n\n\n\n\nCommand\n\n\nResult\n\n\n\n\n\n\n\n\n\n\n-Xtrace:properties[=<filename>]\n\n\nConfigures trace options based on a file\n\n\n\n\n\n\n-Xtrace:buffers=<size>[dynamic\\|nodynamic]\n\n\nModifies the size of buffers that are used to store trace data\n\n\n\n\n\n\n-Xtrace:exception.output=<filename>[,<size>]\n\n\nRedirects exceptions trace data to a file.\n\n\n\n\n\n\n-Xtrace:methods=<method_specification>\n\n\nTraces methods\n\n\n\n\n\n\n-Xtrace:output=<filename>[,<size>[,<generations>]]\n\n\nSends trace data to a file, optionally of a specific size and number of generations.\n\n\n\n\n\n\n-Xtrace:resume\n\n\nResumes tracing globally.\n\n\n\n\n\n\n-Xtrace:resumecount=<count>\n\n\nEnables tracing at a thread level after a specified count.\n\n\n\n\n\n\n-Xtrace:sleeptime=<time>\n\n\nPauses trace operations for a specified length of time.\n\n\n\n\n\n\n-Xtrace:stackdepth=<n>\n\n\nLimits the maximum number of stack frames reported by the jstacktrace trace trigger action.\n\n\n\n\n\n\n-Xtrace:suspend\n\n\nSuspends tracing globally.\n\n\n\n\n\n\n-Xtrace:suspendcount=<count>\n\n\nSuspends tracing at a thread level after a specified count.\n\n\n\n\n\n\n-Xtrace:trigger=<clause>\n\n\nDetermines when various triggered trace actions occur, including turning trace on or off.\n\n\n\n\n\n\n\n\n \nNote:\n If an option value contains commas, it must be enclosed in braces. For example: \nmethods={java/lang/*,com/ibm/*}\n\n\nControlling tracepoint activation\n\n\nThe following parameters can be used to control tracepoint activation. (Follow links for more information about individual options.)\n\n\n\n\n\n\n\n\nCommand\n\n\nResult\n\n\n\n\n\n\n\n\n\n\n-Xtrace:maximal=<tracepoint_specification>\n\n\nRecords all associated data.\n\n\n\n\n\n\n-Xtrace:minimal=<tracepoint_specification>\n\n\nRecords only the time stamp and tracepoint identifier.\n\n\n\n\n\n\n-Xtrace:count=<tracepoint_specification>\n\n\nCounts the tracepoints that are used in a trace configuration.\n\n\n\n\n\n\n-Xtrace:print=<tracepoint_specification>\n\n\nPrints the specified tracepoints to stderr in real time.\n\n\n\n\n\n\n-Xtrace:iprint=<tracepoint_specification>\n\n\nPrints the specified tracepoints to stderr in real time with indentation.\n\n\n\n\n\n\n-Xtrace:exception=<tracepoint_specification>\n\n\nEnables exception tracing.\n\n\n\n\n\n\n-Xtrace:external<tracepoint_specification>\n\n\nRoutes trace data to trace listeners, which are registered by using the JVMTI APIs.\n\n\n\n\n\n\n-Xtrace:none[=<tracepoint_specification>]\n\n\nPrevents the trace engine from loading if it is the only trace option specified.\n\n\n\n\n\n\n\n\n \nNote:\n These options control which individual tracepoints are activated at run time and the implicit destination of the trace data. All these properties are independent of each other and can be mixed and matched in any way that you choose. For more information, see \nTracepoint activation\n.\n\n\nAbout trace\n\n\nWith the OpenJ9 trace feature, you can trace VM internal operations, Java applications, and Java methods, or any combination of these.\n\n\n\n\nVM internal operations\n\n\nThe OpenJ9 virtual machine (VM) is extensively instrumented with tracepoints for tracing operations. Interpretating this trace data requires detailed knowledge of the VM, and is intended to diagnose VM problems. No guarantee is given that tracepoints will not vary from release to release and from platform to platform.\n\n\nApplications\n\n\nVM trace contains an application trace facility that allows tracepoints to be placed in Java code, enabling you to combine trace data with the other forms of trace. This capability is supported by the \ncom.ibm.jvm.Trace\n API. Note that an instrumented Java application runs only on an OpenJ9 VM. For more information, see \nApplication trace\n.\n\n\nJava methods\n\n\nUse method trace to debug and trace application code and the system classes provided with the VM. You can trace entry to and exit from Java methods run by the VM. You can select method trace by classname, method name, or both. You can also use wildcards to create complex method selections. For more information about command syntax, see \nmethods\n.\n\n\n\n\nTrace can produce large amounts of data in a very short time. Before running trace, think carefully about what information you need in order to solve the problem. Here are some considerations:\n\n\n\n\nIf you need only the trace information that is produced shortly before the problem occurs, consider wrapping the file by using the \noutput\n option.\n\n\nIn many cases, just use internal trace with an increased buffer size and snap the trace when the problem occurs.\n\n\nIf the problem results in a thread stack dump or operating system signal or exception, trace buffers are snapped automatically to a file that is in the current directory. The file is called: \nSnapnnnn.\nyyyymmdd.hhmmssth.process.trc\n.\n\n\n\n\nYou must also think carefully about which components need to be traced and what level of tracing is required. For example, if you are tracing a suspected shared classes problem, it might be enough to trace all components at level 1, and \nj9shr\n at level 9, while \nmaximal\n can be used to show parameters and other information for the failing component. Tracepoint components and trace levels are described in the following sections: \nTracepoint specification\n and \nTrace levels\n.\n\n\nThere are two types of tracepoints inside the VM: \n\n\n\n\nRegular tracepoints include method tracepoints, application tracepoints, data tracepoints inside the VM and data tracepoints inside class libraries. You can display regular tracepoint data on the screen or save the data to a file. You can also use command line options to trigger specific actions when regular tracepoints fire.\n\n\nAuxiliary tracepoints are a special type of tracepoint that can be fired only when another tracepoint is being processed. For example, the stack frame information produced by the jstacktrace \n-Xtrace:trigger\n command. You cannot control where auxiliary tracepoint data is sent and you cannot set triggers on auxiliary tracepoints. Auxiliary tracepoint data is sent to the same destination as the tracepoint that caused them to be generated.\n\n\n\n\nTrace data can be written to one of the following locations:\n\n\n\n\nMemory buffers that can be dumped or snapped when a problem occurs. Use the \n-Xtrace:buffers=<size>\n option to control the size of the buffer allocated to each thread. Buffers allocated to a thread are discarded when that thread terminates. To examine the trace data captured in these memory buffers, you must snap or dump the data, then format the buffers.\n\n\nOne or more files that are using buffered I/O. Use the \n-Xtrace:output\n option.\n\n\nAn external agent in real time, using the \n-Xtrace:external\n option.\n\n\nstderr in real time.\n\n\nAny combination of the other items in this list.\n\n\n\n\nDefault tracing\n\n\nBy default, the equivalent of the following trace command line is always available in the VM:\n\n\n-Xtrace:maximal=all{level1},exception=j9mm{gclogger}\n\n\n\n\n\nWhen startup is complete, the equivalent of the following command line is added to enable level 2 trace points:\n\n\n-Xtrace:maximal=all{level2}\n\n\n\n\n\nLevel 2 is used for default tracing that would produce too much data during the startup of the VM. If you set other trace options on the command line, or before the VM finishes startup (through use of JVMTI or the \ncom.ibm.jvm.Trace\n API), the level 2 trace points are enabled just before your trace options are processed. This behavior ensures that the default level 2 trace points do not override any changes that you specify.\n\n\nThe data generated by the tracepoints is continuously captured in wrapping memory buffers for each thread.\n\n\nYou can find tracepoint information in the following diagnostics data:\n\n\n\n\nSystem memory dumps, extracted by using jdmpview.\n\n\nSnap traces, generated when the VM encounters a problem or an output file is specified. Using dump agents describes more ways to create a snap trace.\n\n\nFor exception trace only, in Javadumps.\n\n\n\n\nDefault memory management tracing\n\n\nThe default trace options are designed to ensure that Javadumps always contain a record of the most recent memory management history, regardless of how much work the VM has performed since the garbage collection cycle was last called.\n\n\nThe \nexception=j9mm{gclogger}\n clause of the default trace set specifies that a history of garbage collection cycles that have occurred in the VM is continuously recorded. The \ngclogger\n group of tracepoints in the \nj9mm\n component constitutes a set of tracepoints that record a snapshot of each garbage collection cycle. These tracepoints are recorded in their own separate buffer, called the exception buffer. The effect is that the tracepoints are not overwritten by the higher frequency tracepoints of the VM.\n\n\nThe \nGC History\n section of the Javadump is based on the information in the exception buffer. If a garbage collection cycle has occurred in a traced VM, the Java dump probably contains a \nGC History\n section.\n\n\nDefault assertion tracing\n\n\nThe VM includes assertions, implemented as special trace points. By default, internal assertions are detected and diagnostics logs are produced to help assess the error.\n\n\nAssertion failures often indicate a serious problem, and the VM usually stops immediately. In these circumstances, raise an issue, including the standard error output and any diagnostic files that are produced.\n\n\nWhen an assertion trace point is reached, a message like the following output is produced on the standard error stream:\n\n\n16\n:\n43\n:\n48.671\n \n0x10a4800\n \nj9vm\n.\n209\n \n*\n \n**\n \nASSERTION\n \nFAILED\n \n**\n \nat\n \njniinv\n.\nc\n:\n251\n:\n\n\n((\njavaVM\n \n==\n \n((\nvoid\n \n*)\n0\n)))\n\n\n\n\n\n\nThis error stream is followed with information about the diagnostic logs produced:\n\n\nJVMDUMP007I JVM Requesting System Dump using 'core.20060426.124348.976.dmp'\nJVMDUMP010I System Dump written to core.20060426.124348.976.dmp\nJVMDUMP007I JVM Requesting Snap Dump using 'Snap0001.20060426.124648.976.trc'\nJVMDUMP010I Snap Dump written to Snap0001.20060426.124648.976.trc\n\n\n\n\n\nAssertions are special trace points. They can be enabled or disabled by using the standard trace command-line options.\n\n\nAssertion failures might occur early during VM startup, before trace is enabled. In this case, the assert message has a different format, and is not prefixed by a timestamp or thread ID. For example:\n\n\n** ASSERTION FAILED ** j9vmutil.15 at thrinfo.c:371 Assert_VMUtil_true((\n publicFlags & 0x200))\n\n\n\n\n\nAssertion failures that occur early during startup cannot be disabled. These failures do not produce diagnostic dumps, and do not cause the VM to stop.\n\n\nTracepoint activation\n\n\nThe options that control which individual tracepoints are activated at run time and the implicit destination of the trace data are listed under \nSyntax: Controlling tracepoint activation\n\n\n\n\n\nIn some cases, you must use them with other options. For example, if you specify \nmaximal\n or \nminimal\n tracepoints, the trace data is put into memory buffers. If you are going to send the data to a file, you must use an \noutput\n option to specify the destination file name.\n\n\nWith the exception of \nnone\n, all options require at least one \n<tracepoint_specification>\n, which is described in the following section. Multiple statements of each type of trace are allowed and their effect is cumulative. If you want to use multiple trace options of the same name, use a properties file. (See \nproperties\n.)\n\n\nTracepoint specification\n\n\nTracepoints are enabled by specifying \ncomponent\n and \ntracepoint\n.\n\n\nIf no qualifier parameters are entered, all tracepoints are enabled, except for \n<exception.output>\n trace, where the default is all {exception}.\n\n\nThe \n<tracepoint_specification>\n syntax can be further broken down as follows:\n\n\n[!]<component>[{<group>}] or [!]<component>[{<type>}] or [!]<tracepoint_id>[,<tracepoint_id>]\n\n\n\n\n\nWhere:\n\n\n\n\nThe \n!\n symbol is a logical \nnot\n. That is, the tracepoints that are in a specification starting with ! are turned off.\n\n\n<component>\n is a Java component.\n\n\n<group>\n is a tracepoint group, which is a set of tracepoints that are defined within a component.\n\n\n<type>\n is the tracepoint type: \nentry\n, \nexit\n, \nevent\n, \nexception\n, and \neem\n.\n\n\n<tracepoint_id>\n is the tracepoint identifier. The tracepoint identifier constitutes the component name of the tracepoint, followed by its integer number inside that component. For example, \nj9mm.49\n, \nj9shr.20-29\n, \nj9vm.15\n. To understand these numbers, see Determining the tracepoint ID of a tracepoint.\n\n\n\n\nSome tracepoints can be both an \nexit\n and an \nexception\n; that is, the function ended with an error. If you specify either \nexit\n or \nexception\n, these tracepoints are included.\n\n\nLists of Java components and tracepoint groups can be found in the tables that follow.\n\n\nThe following table lists the possible Java components (\n<component>\n). To include all Java components, specify \nall\n.\n\n\n\n\n\n\n\n\nComponent name\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\navl\n\n\nVM AVL tree support\n\n\n\n\n\n\nibm_gpu\n\n\nClass library graphics processing unit (GPU) native code (Linux\u2122 only)\n\n\n\n\n\n\nio\n\n\nClass library java.io native code\n\n\n\n\n\n\nj9bcu\n\n\nVM byte code utilities\n\n\n\n\n\n\nj9bcverify\n\n\nVM byte code verification\n\n\n\n\n\n\nj9codertvm\n\n\nVM byte code run time\n\n\n\n\n\n\nj9dmp\n\n\nVM dump\n\n\n\n\n\n\nj9jcl\n\n\nVM class libraries\n\n\n\n\n\n\nj9jit\n\n\nVM JIT interface\n\n\n\n\n\n\nj9jni\n\n\nVM JNI support\n\n\n\n\n\n\nj9jvmti\n\n\nVM JVMTI support\n\n\n\n\n\n\nj9mm\n\n\nVM memory management\n\n\n\n\n\n\nj9prt\n\n\nVM port library\n\n\n\n\n\n\nj9scar\n\n\nVM class library interface\n\n\n\n\n\n\nj9shr\n\n\nVM shared classes\n\n\n\n\n\n\nj9trc\n\n\nVM trace\n\n\n\n\n\n\nj9util\n\n\nVM utilities\n\n\n\n\n\n\nj9vm\n\n\nVM general\n\n\n\n\n\n\nj9vmutil\n\n\nVM utilities\n\n\n\n\n\n\nj9vrb\n\n\nVM verbose stack walker\n\n\n\n\n\n\nmap\n\n\nVM mapped memory support\n\n\n\n\n\n\nmt\n\n\nJava methods (see \nNote\n)\n\n\n\n\n\n\nnet\n\n\nClass library TCP/IP networking native code\n\n\n\n\n\n\npool\n\n\nVM storage pool support\n\n\n\n\n\n\nrpc\n\n\nVM RPC support\n\n\n\n\n\n\nsimplepool\n\n\nVM storage pool support\n\n\n\n\n\n\nsunvmi\n\n\nVM class library interface\n\n\n\n\n\n\n\n\n \nNote:\n When specifying the \nmt\n component you must also specify the \nmethods\n option.\n\n\nThe following table lists all the tracepoint groups (\n<group>\n). Each group is associated with one or more Java components:\n\n\n\n\n\n\n\n\nComponent name or names\n\n\nGroup name\n\n\nDescription\n\n\n\n\n\n\n\n\n\n\nj9mm\n\n\ngclogger\n\n\nA set of tracepoints that record each garbage collection cycle. Equivalent to \n-verbose:gc\n output\n\n\n\n\n\n\nj9prt\n\n\nnlsmessage\n\n\nA set of tracepoints that record each NLS message that is issued by the VM.\n\n\n\n\n\n\nj9jcl\n, \nj9vm\n\n\nverboseclass\n\n\nA set of tracepoints that record each class as it is loaded. Equivalent to \n-verbose:class\n output.\n\n\n\n\n\n\nj9jni\n, \nj9vm\n\n\ncheckjni\n\n\nA set of tracepoints that record JNI function checks. Equivalent to \n-Xcheck:jni\n output.\n\n\n\n\n\n\nj9vm\n\n\ncheckmemory\n\n\nA set of tracepoints that record memory checks. Equivalent to \n-Xcheck:memory\n output.\n\n\n\n\n\n\nj9vm\n\n\ncheckvm\n\n\nA set of tracepoints that record VM checks. Equivalent to \n-Xcheck:vm\n output.\n\n\n\n\n\n\nj9jit\n\n\nverbose\n\n\nA set of tracepoints that record JIT compiler configuration and method compilation. Equivalent to \n-Xjit:verbose\n output.\n\n\n\n\n\n\nmt\n\n\ncompiledMethods\n\n\nA set of tracepoints that record compiled Java methods.\n\n\n\n\n\n\nmt\n\n\nnativeMethods\n\n\nA set of tracepoints that record Java native methods.\n\n\n\n\n\n\nmt\n\n\nstaticMethods\n\n\nA set of tracepoints that record Java static methods.\n\n\n\n\n\n\n\n\nHere are some examples:\n\n\nTo trace all tracepoints, specify the following command:\n\n\n-Xtrace:maximal=all\n\n\n\n\n\nTo trace all tracepoints except **j9vrb** and **j9trc**, specify the following command:\n\n -Xtrace:minimal={all},minimal={!j9vrb,j9trc}\n\n\n\n\n\nTo trace all entry and exit tracepoints in \nj9bcu\n, specify the following command:\n\n\n-Xtrace:maximal={j9bcu{entry},j9bcu{exit}}\n\n\n\n\n\nTo trace all tracepoints in **j9mm** except tracepoints 20-30, specify the following command:\n\n -Xtrace:maximal=j9mm,maximal=!j9mm.20-30\n\n\n\n\n\nTo trace tracepoints \nj9prt.5\n through \nj9prt.15\n, specify the following command:\n\n\n-Xtrace:print=j9prt.5-15\n\n\n\n\n\nTo trace all **j9trc** tracepoints, specify the following command:\n\n -Xtrace:count=j9trc\n\n\n\n\n\nTo trace all \nentry\n and \nexit\n tracepoints, specify the following command:\n\n\n-Xtrace:external={all{entry},all{exit}}\n\n\n\n\n\nTrace levels\n\n\nTracepoints have been assigned levels 0 through 9 that are based on the importance of the tracepoint.\n\n\nA level 0 tracepoint is the most important. It is reserved for extraordinary events and errors. A level 9 tracepoint is in-depth component detail. To specify a given level of tracing, the \nlevel0\n through \nlevel9\n keywords are used. You can abbreviate these keywords to l0 through l9. For example, if \nlevel5\n is selected, all tracepoints that have levels 0 through 5 are included. Level specifications do not apply to explicit tracepoint specifications that use the \nTPNID\n keyword.\n\n\nThe level is provided as a modifier to a component specification, for example:\n\n\n-Xtrace:maximal={all{level5}}\n\n\n\n\n\nor\n\n\n-Xtrace:maximal={j9mm{L2},j9trc,j9bcu{level9},all{level1}}\n\n\n\n\n\nIn the first example, tracepoints that have a level of 5 or less are enabled for all components. In the second example, all level 1 tracepoints are enabled. All level 2 tracepoints in \nj9mm\n are enabled. All tracepoints up to level 9 are enabled in \nj9bcu\n.\n\n\n \nNote:\n The level applies only to the current component. If multiple trace selection components are found in a trace properties file, the level is reset to the default for each new component.\nLevel specifications do not apply to explicit tracepoint specifications that use the \nTPNID\n keyword.\n\n\nWhen the not operator is specified, the level is inverted; that is, \n!j9mm{level5}\n disables all tracepoints of level 6 or greater for the \nj9mm\n component. The following example enables trace for all components at level 9 (the default), but disables level 6 and higher for the \nlocking\n component, and level 7 and higher for the \nstorage\n component:\n\n\n-Xtrace:print={all},print={!j9trc{l5},j9mm{l6}}\n\n\n\n\n\nHere are some examples:\n\n\nTo count the level zero and level one tracepoints matched, specify the following command:\n\n\n-Xtrace:count=all{L1}\n\n\n\n\n\nTo produce maximal trace of all components at level 5 and \nj9mm\n at level 9, specify the following command:\n\n\n-Xtrace:maximal={all{level5},j9mm{L9}}\n\n\n\n\n\nTo trace all components at level 6, but do not trace \nj9vrb\n at all, and do not trace the \nentry\n and \nexit\n tracepoints in the \nj9trc\n component, specify the following command:\n\n\n-Xtrace:minimal={all{l6}},minimal={!j9vrb,j9trc{entry},j9trc{exit}}\n\n\n\n\n\nParameters\n\n\nParameters to use with the \n-Xtrace\n option:\n\n\nbuffers\n\n\nYou can modify the size of the buffers to change how much diagnostic output is provided in a snap dump. This buffer is allocated for each thread that makes trace entries. The following table shows\nhow this parameter can be set:\n\n\n\n\n\n\n\n\nCommand\n\n\nEffect\n\n\n\n\n\n\n\n\n\n\n-Xtrace:buffers=<size>\n\n\nCreates buffers of the specified \n<size>\n in \nk\n (KB) or \nm\n (MB), allocated as needed to match the rate of trace data generation to the output media.\n\n\n\n\n\n\n-Xtrace:buffers=<size>dynamic\n\n\nCreates buffers of the specified \n<size>\n, allocated as needed to match the rate of trace data generation to the output media.\n\n\n\n\n\n\n-Xtrace:buffers=<size>nodynamic\n\n\nCreates buffers of the specified \n<size>\n, with a maximum allocation of two buffers per thread.\n\n\n\n\n\n\n\n\nIf external trace is enabled, the number of buffers is doubled; that is, each thread allocates two or more buffers. The same buffer size is used for state and exception tracing, but, in this case, buffers are allocated globally. The default is 8 KB per thread.\n\n\nThe \ndynamic\n and \nnodynamic\n suboptions have meaning only when tracing to an output file.\n\n\n \nNote:\n If \nnodynamic\n is specified, you might lose trace data if the volume of trace data exceeds the bandwidth of the trace output file. Message \nUTE115\n is issued when the first trace entry is lost, and message \nUTE018\n is issued when the VM ends.\n\n\nHere are some command line examples:\n\n\nTo set a buffer size of 2 MB per thread, with dynamic buffering, use:\n\n\n-Xtrace:buffers=2m\n\n\n\n\n\nTo limit each thread to 2 trace buffers, each of 128 KB:\n\n\n-Xtrace:buffers={128k,nodynamic}\n\n\n\n\n\ncount\n (tracepoint)\n\n\n-Xtrace:count=<tracepoint_specification>\n\n\n\n\n\nFor further information about \n<tracepoint_specification>\n syntax, see \nTracepoint specification\n.\n\n\nThe count option requests that only a count of the selected tracepoints is kept. When the VM ends, all nonzero totals of tracepoints (sorted by tracepoint id) are written to a file, called \nutTrcCounters\n, in the current directory. This information is useful if you want to determine the overhead of particular tracepoints, but do not want to produce a large amount (GB) of trace data.\n\n\nFor example, to count the tracepoints that are used in the default trace configuration, use the following command:\n\n\n-Xtrace:count=all{level1},count=j9mm{gclogger}\n\n\n\n\n\nexception\n (tracepoint)\n\n\n-Xtrace:exception=<tracepoint_specification>\n\n\n\n\n\nFor further information about \n<tracepoint_specification>\n syntax, see \nTracepoint specification\n.\n\n\nWhen exception trace is enabled, the trace data is collected in internal buffers that are separate from the normal buffers. These internal buffers can then be written to a snap file or written to the file that is specified in an \nexception.output\n option.\n\n\nThe \nexception\n option allows low-volume tracing in buffers and files that are distinct from the higher-volume information that \nminimal\n and \nmaximal\n tracing have provided. In most cases, this information is exception-type data, but you can use this option to capture any trace data that you want.\n\n\nThis form of tracing is channeled through a single set of buffers, as opposed to the buffer-per-thread approach for normal trace. Buffer contention might occur if high volumes of trace data are collected. A difference exists in the \n<tracepoint_specification>\n defaults for exception tracing; see \nTracepoint specification\n.\n\n\n \nNotes:\n\n\n\n\nThe exception trace buffers are intended for low-volume tracing. By default, the exception trace buffers log garbage collection (GC) event tracepoints, see Default tracing. You can send additional tracepoints to the exception buffers or turn off the GC tracepoints. Changing the exception trace buffers alters the contents of the GC History section in any Javadumps.\n\n\nWhen exception trace is entered for an active tracepoint, the current thread ID is checked against the previous caller's thread ID. If it is a different thread, or this is the first call to exception trace, a context tracepoint is put into the trace buffer first. This context tracepoint consists only of the current thread ID, which is necessary because of the single set of buffers for exception trace. (The formatter identifies all trace entries as coming from the Exception trace pseudo thread when it formats exception trace files.)\n\n\n\n\nexception.output\n\n\nUse exception output to redirect exceptions trace data to a file.\n\n\n-Xtrace:exception.output=<filename>[,<size>]\n\n\n\n\n\nWhere:\n\n\n\n\n<filename>\n is a file name, which is created automatically if it does not exist. Otherwise, it is overwritten. To embed specific values in the file name use any of the following variables: \n%d%\n (today's date in \"\nyyyymmdd\" format), \n%p%\n (process ID number of the process generating the trace), or \n%t%\n (time in 24-hour hhmmss format).\n\n\nOptionally, \n<size>\n is a value in megabytes (MB), for example, use \n4m\n to specify 4 MB. When full, it wraps nondestructively to the beginning. If you do not limit the file, it grows indefinitely, until limited by disk space.\n\n\n\n\nHere are some examples:\n\n\nException trace output goes to file \n/u/traces/exception.trc\n with no size limit:\n\n\n-Xtrace:exception.output=/u/traces/exception.trc,maximal\n\n\n\n\n\nException trace output goes to file \nexcept\n and wraps at 2 MB:\n\n\n-Xtrace:exception.output={except,2m},maximal\n\n\n\n\n\nException trace output goes to a file whose filename contains today's date in \n\nyyyymmdd\n format (for example, \ntraceout.20181025.trc\n):\n\n\n-Xtrace:exception.output=traceout.%d.trc,maximal\n\n\n\n\n\nException trace output goes to a file whose filename contains the number of the process (the PID number) that generated it (for example, \ntracefrompid2112.trc\n):\n\n\n-Xtrace:exception.output=tracefrompid%p.trc,maximal\n\n\n\n\n\nException trace output goes to a file whose filename contains the time in \nhhmmss\n format (for example, \ntraceout.080312.trc\n):\n\n\n-Xtrace:exception.output=traceout.%t.trc,maximal\n\n\n\n\n\nexternal\n (tracepoint)\n\n\n-Xtrace:external<tracepoint_specification>\n\n\n\n\n\nFor further information about \n<tracepoint_specification>\n syntax, see \nTracepoint specification\n.\n\n\nThe \nexternal\n option routes trace data to trace listeners, which are registered by using the JVMTI \nRegisterTracePointSubscriber()\n and \nDeregisterTracePointSubscriber()\n APIs.\n\n\nhelp\n\n\n-Xtrace:help\n\n\n\n\n\nDisplays general trace help\n\n\niprint\n (tracepoint)\n\n\n-Xtrace:iprint=<tracepoint_specification>\n\n\n\n\n\nFor further information about \n<tracepoint_specification>\n syntax, see \nTracepoint specification\n.\n\n\nThe \niprint\n option is the same as the \nprint\n option, but uses indenting to format the trace.\n\n\nmaximal\n (tracepoint)\n\n\n-Xtrace:maximal=<tracepoint_specification>\n\n\n\n\n\nFor further information about \n<tracepoint_specification>\n syntax, see \nTracepoint specification\n.\n\n\nWhen specified, trace data is placed into internal trace buffers that can then be written to a snap file or written to the files that are specified in an output trace option. All associated data is traced.\n\n\nminimal\n and \nmaximal\n traces are independent from any types that follow them. For example, if the \nmaximal\n option is specified, it does not affect a later option such as \nprint\n.\n\n\nmethods\n\n\nUsing method trace provides a complete and potentially large diagnosis of code paths inside your application and the system classes. Use wild cards and filtering to control method trace so that you can focus on the sections of code that interest you. To specify one or more method specifications, use the following syntax:\n\n\n-Xtrace:methods=<method_specification>[,<method_specification>]\n\n\n\n\n\nThe syntax for \n<method_specification>\n can be further broken down to the following suboptions:\n\n\n-Xtrace:methods={[!][*][<package>/]<class>[*],[[*]<method>[*]|[()]]}\n\n\n\n\n\nWhere:\n\n\n\n\nThe delimiter between parts of the package name is a forward slash, \"/\".\n\n\nThe \n!\n in the methods parameter is a NOT operator that allows you to tell the VM not to trace the specified method or methods.\n\n\nThe parentheses, (), define whether or not to include method parameters in the trace.\n\n\nIf a method specification includes any commas, the whole specification must be enclosed in braces, for example: \n-Xtrace:methods={java/lang/*,java/util/*},print=mt\n\n\nIt might be necessary to enclose your command line in quotation marks to prevent the shell intercepting and fragmenting comma-separated command lines, for example: \n\"-Xtrace:methods={java/lang/*,java/util/*},print=mt\"\n\n\n\n\nTo output all method trace information to stderr, use either the \nprint\n or \niprint\n suboptions:\n\n\n-Xtrace:print=mt,methods=*.*\n-Xtrace:iprint=mt,methods=*.*\n\n\n\n\n\nThe \niprint\n suboption prints to stderr with indentation.\nTo output method trace information in binary format, see the \noutput\n option.\n\n\nHere are some examples:\n\n\nTracing entry and exit of all methods in a given class:\n To trace all method entry and exit of the \nReaderMain\n class in the default package and the \njava.lang.String\n class, specify the following command:\n\n\n-Xtrace:methods={ReaderMain.*,java/lang/String.*},print=mt\n\n\n\n\n\nTracing entry, exit and input parameters of all methods in a class:\n To trace all method entry, exit, and input of the \nReaderMain\n class in the default package, specify the following command:\n\n\n-Xtrace:methods=ReaderMain.*(),print=mt\n\n\n\n\n\nTracing all methods in a given package:\n To trace all method entry, exit, and input of all classes in the package \ncom.ibm.socket\n, specify the following command:\n\n\n-Xtrace:methods=com/ibm/socket/*.*(),print=mt\n\n\n\n\n\nMultiple method trace:\n To trace all method entry, exit, and input in the \nWidget\n class in the default package and all method entry and exit in the \ncommon\n package, specify the following command:\n\n\n-Xtrace:methods={Widget.*(),common/*},print=mt\n\n\n\n\n\nUsing the ! operator:\n To trace all methods in the \nArticleUI\n class in the default package except those beginning with \"get\", specify the following command:\n\n\n-Xtrace:methods={ArticleUI.*,!ArticleUI.get*},print=mt\n\n\n\n\n\nTracing a specific method in a class:\n This example traces entry and exit of the substring method of the \njava.lang.String class\n. If there is more than one method with the same name, they are all traced. You cannot filter method trace by the signature of the method.\n\n\n-Xtrace:print=mt,methods={java/lang/String.substring}\n\n\n\n\n\nTracing the constructor of a class:\n This example traces entry and exit of the constructors of the \njava.lang.String\n class.\n\n\n-Xtrace:print=mt,methods={java/lang/String.<init>}\n\n\n\n\n\nHere is some example output:\n\n\njava\n \n\"-Xtrace:methods={java/lang*.*},iprint=mt\"\n \nHW\n\n\n10\n:\n02\n:\n42\n.\n281\n*\n0x9e900\n \nmt\n.\n4\n \n>\n \njava\n/\nlang\n/\nJ9VMInternals\n.\ninitialize\n(\nLjava\n/\nlang\n/\nClass\n;)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n281\n \n0x9e900\n \nmt\n.\n4\n \n>\n \njava\n/\nlang\n/\nJ9VMInternals\n.\nverify\n(\nLjava\n/\nlang\n/\nClass\n;)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n281\n \n0x9e900\n \nmt\n.\n4\n \n>\n \njava\n/\nlang\n/\nJ9VMInternals\n.\nverify\n(\nLjava\n/\nlang\n/\nClass\n;)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n281\n \n0x9e900\n \nmt\n.\n4\n \n>\n \njava\n/\nlang\n/\nJ9VMInternals\n.\nsetInitStatus\n(\nLjava\n/\nlang\n/\nClass\n;\nI\n)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n281\n \n0x9e900\n \nmt\n.\n10\n \n<\n \njava\n/\nlang\n/\nJ9VMInternals\n.\nsetInitStatus\n(\nLjava\n/\nlang\n/\nClass\n;\nI\n)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n281\n \n0x9e900\n \nmt\n.\n10\n \n<\n \njava\n/\nlang\n/\nJ9VMInternals\n.\nverify\n(\nLjava\n/\nlang\n/\nClass\n;)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n281\n \n0x9e900\n \nmt\n.\n4\n \n>\n \njava\n/\nlang\n/\nJ9VMInternals\n.\nsetInitStatus\n(\nLjava\n/\nlang\n/\nClass\n;\nI\n)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n281\n \n0x9e900\n \nmt\n.\n10\n \n<\n \njava\n/\nlang\n/\nJ9VMInternals\n.\nsetInitStatus\n(\nLjava\n/\nlang\n/\nClass\n;\nI\n)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n281\n \n0x9e900\n \nmt\n.\n10\n \n<\n \njava\n/\nlang\n/\nJ9VMInternals\n.\nverify\n(\nLjava\n/\nlang\n/\nClass\n;)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n281\n \n0x9e900\n \nmt\n.\n4\n \n>\n \njava\n/\nlang\n/\nJ9VMInternals\n.\ninitialize\n(\nLjava\n/\nlang\n/\nClass\n;)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n281\n \n0x9e900\n \nmt\n.\n4\n \n>\n \njava\n/\nlang\n/\nJ9VMInternals\n.\nsetInitStatus\n(\nLjava\n/\nlang\n/\nClass\n;\nI\n)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n296\n \n0x9e900\n \nmt\n.\n10\n \n<\n \njava\n/\nlang\n/\nJ9VMInternals\n.\nsetInitStatus\n(\nLjava\n/\nlang\n/\nClass\n;\nI\n)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n296\n \n0x9e900\n \nmt\n.\n10\n \n<\n \njava\n/\nlang\n/\nJ9VMInternals\n.\ninitialize\n(\nLjava\n/\nlang\n/\nClass\n;)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n296\n \n0x9e900\n \nmt\n.\n4\n \n>\n \njava\n/\nlang\n/\nString\n.<\nclinit\n>()\nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n296\n \n0x9e900\n \nmt\n.\n4\n \n>\n \njava\n/\nlang\n/\nJ9VMInternals\n.\ninitialize\n(\nLjava\n/\nlang\n/\nClass\n;)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n296\n \n0x9e900\n \nmt\n.\n4\n \n>\n \njava\n/\nlang\n/\nJ9VMInternals\n.\nverify\n(\nLjava\n/\nlang\n/\nClass\n;)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n296\n \n0x9e900\n \nmt\n.\n4\n \n>\n \njava\n/\nlang\n/\nJ9VMInternals\n.\nverify\n(\nLjava\n/\nlang\n/\nClass\n;)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n296\n \n0x9e900\n \nmt\n.\n10\n \n<\n \njava\n/\nlang\n/\nJ9VMInternals\n.\nverify\n(\nLjava\n/\nlang\n/\nClass\n;)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n296\n \n0x9e900\n \nmt\n.\n4\n \n>\n \njava\n/\nlang\n/\nJ9VMInternals\n.\nsetInitStatus\n(\nLjava\n/\nlang\n/\nClass\n;\nI\n)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n328\n \n0x9e900\n \nmt\n.\n10\n \n<\n \njava\n/\nlang\n/\nJ9VMInternals\n.\nsetInitStatus\n(\nLjava\n/\nlang\n/\nClass\n;\nI\n)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n328\n \n0x9e900\n \nmt\n.\n10\n \n<\n \njava\n/\nlang\n/\nJ9VMInternals\n.\nverify\n(\nLjava\n/\nlang\n/\nClass\n;)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n328\n \n0x9e900\n \nmt\n.\n4\n \n>\n \njava\n/\nlang\n/\nJ9VMInternals\n.\ninitialize\n(\nLjava\n/\nlang\n/\nClass\n;)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n328\n \n0x9e900\n \nmt\n.\n10\n \n<\n \njava\n/\nlang\n/\nJ9VMInternals\n.\ninitialize\n(\nLjava\n/\nlang\n/\nClass\n;)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n328\n \n0x9e900\n \nmt\n.\n4\n \n>\n \njava\n/\nlang\n/\nJ9VMInternals\n.\nsetInitStatus\n(\nLjava\n/\nlang\n/\nClass\n;\nI\n)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n328\n \n0x9e900\n \nmt\n.\n10\n \n<\n \njava\n/\nlang\n/\nJ9VMInternals\n.\nsetInitStatus\n(\nLjava\n/\nlang\n/\nClass\n;\nI\n)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n10\n:\n02\n:\n42\n.\n328\n \n0x9e900\n \nmt\n.\n10\n \n<\n \njava\n/\nlang\n/\nJ9VMInternals\n.\ninitialize\n(\nLjava\n/\nlang\n/\nClass\n;)\n\n \nV\n \nCompiled\n \nstatic\n \nmethod\n\n\n\n\n\n\nThe output lines comprise of:\n\n\n\n\n0x9e900\n, the current \nexecenv\n (execution environment). Because every VM thread has its own \nexecenv\n, you can regard \nexecenv\n as a \nthread-id\n. All trace with the same \nexecenv\n relates to a single thread.\n\n\nThe individual tracepoint ID in the \nmt\n component that collects and emits the data.\n\n\nThe remaining fields show whether a method is being entered (>) or exited (<), followed by details of the method.\n\n\n\n\nminimal\n (tracepoint)\n\n\n-Xtrace:minimal=<tracepoint_specification>\n\n\n\n\n\nFor further information about \n<tracepoint_specification>\n syntax, see \nTracepoint specification\n.\n\n\nWhen specified, trace data is placed into internal trace buffers that can then be written to a snap file or written to the files that are specified in an output trace option. Only the time stamp and tracepoint identifier are recorded. When the trace is formatted, missing trace data is replaced with the characters \"???\" in the output file.\n\n\nminimal\n and \nmaximal\n traces are independent from any types that follow them. For example, if the \nminimal\n option is specified, it does not affect a later option such as \nprint\n.\n\n\nnone\n (tracepoint)\n\n\n-Xtrace:none[=<tracepoint_specification>]\n\n\n\n\n\nFor further information about \n<tracepoint_specification>\n syntax, see \nTracepoint specification\n.\n\n\n-Xtrace:none\n prevents the trace engine from loading if it is the only trace option specified. However, if other \n-Xtrace\n options are on the command line, it is treated as the equivalent of \n-Xtrace:none=all\n and the trace engine still loads.\n\n\nIf you specify other tracepoints without specifying \n-Xtrace:none\n, the tracepoints are added to the default set.\n\n\noutput\n\n\nSends trace data to a file, optionally of a specific size and number of generations.\n\n\n-Xtrace:output=<filename>[,<size>[,<generations>]]`\n\n\n\n\n\nWhere:\n\n\n\n\n<filename>\n is a file name, which is created automatically if it does not exist. Otherwise, it is overwritten. To embed specific values in the file name use any of the following variables: \n%d%\n (today's date in \"\nyyyymmdd\" format), \n%p%\n (process ID number of the process generating the trace), or \n%t%\n (time in 24-hour hhmmss format).\n\n\nOptionally, \n<size>\n is a value in megabytes (MB), for example, use \n4m\n to specify 4 MB. When full, it wraps to the beginning. If you do not limit the file, it grows indefinitely, until limited by disk space.\n\n\nOptionally, \n<generations>\n is a value 2 through 36. These values cause up to 36 files to be used sequentially as each file reaches its \n<size>\n threshold. When a file needs to be reused, it is overwritten. If \n<generations>\n is specified, the filename must contain a \n#\n (hash, pound symbol), which will be substituted with its generation identifier, the sequence of which is 0 through 9 followed by A through Z.\n\n\n\n\n \nNote:\n When tracing to a file, buffers for each thread are written when the buffer is full or when the VM ends. If a thread has been inactive for a period of time before the VM ends, what seems to be 'old' trace data is written to the file. When formatted, it then seems that trace data is missing from the other threads, but this is an unavoidable side-effect of the buffer-per-thread design. This effect becomes especially noticeable when you use the generation facility, and format individual earlier generations.\n\n\nHere are some examples:\n\n\nTrace output goes to file \n/u/traces/gc.problem\n with no size limit:\n\n\n-Xtrace:output=/u/traces/gc.problem,maximal=j9gc\n\n\n\n\n\nTrace output goes to file \ntrace\n, which will wrap at 2 MB:\n\n\n-Xtrace:output={trace,2m},maximal=j9gc\n\n\n\n\n\nTrace output goes to files \ngc0.trc\n, \ngc1.trc\n, and \ngc2.trc\n, each 10 MB in size:\n\n\n-Xtrace:output={gc#.trc,10m,3},maximal=j9gc\n\n\n\n\n\nTrace output goes to a file, where the filename contains today's date in \n\nyyyymmdd\n format (for example, \ntraceout.20181025.trc\n):\n\n\n-Xtrace:output=traceout.%d.trc,maximal=j9gc\n\n\n\n\n\nTrace output goes to a file whose name contains the number of the process (the PID number) that generated it (for example, \ntracefrompid2112.trc\n):\n\n\n-Xtrace:output=tracefrompid%p.trc,maximal=j9gc\n\n\n\n\n\nTrace output goes to a file whose name contains the time in \nhhmmss\n format (for example, \ntraceout.080312.trc\n):\n\n\n-Xtrace:output=traceout.%t.trc,maximal=j9gc\n\n\n\n\n\nprint\n (tracepoint)\n\n\n-Xtrace:print=<tracepoint_specification>\n\n\n\n\n\nFor further information about \n<tracepoint_specification>\n syntax, see \nTracepoint specification\n.\n\n\nThe print option causes the specified tracepoints to be routed to stderr in real time. The VM tracepoints are formatted by using \nJ9TraceFormat.dat\n. The class library tracepoints are formatted by \nJ9TraceFormat.dat\n and \nTraceFormat.dat\n.\n\n\nproperties\n\n\nYou can use properties files to control trace. A properties file saves typing and allows you to create a library of files that are tailored to solving problems in a particular area.\n\n\n-Xtrace:properties[=<filename>]\n\n\n\n\n\nIf \n<filename>\n is not specified, the VM searches for a default name of \nIBMTRACE.properties\n in the current directory.\n\n\nAll the options that are in the file are processed in the sequence in which they are stored in the file, before the next option that is obtained through the normal mechanism is processed. Therefore, a command-line property always overrides a property that is in the file.\n\n\nHere is an example of a properties file:\n\n\nminimal=all\n// maximal=j9mm\nmaximal=j9shr\nbuffers=128k,nodynamic\noutput=c:\\traces\\classloader.trc\nprint=tpnid(j9vm.23-25)\n\n\n\n\n\nThe following restrictions apply to the file:\n\n\n\n\nThe file must be a flat ASCII file.\n\n\nNesting is not supported; that is, the file cannot contain a properties option.\n\n\nYou cannot leave properties that have the form \n<name>=<value>\n to default if they are specified in the property file; that is, you must specify a value, for example \nmaximal=all\n.\n\n\nDo not add white space before, after, or within the trace options.\n\n\n\n\nIf any error is found when the file is accessed, VM initialization fails with an explanatory error message and return code.\n\n\nTo use a file \ntrace.props\n stored in the \nc:\\trc\\gc\n directory, specify the following command:\n\n\n-Xtrace:properties=c:\\trc\\gc\\trace.props\n\n\n\n\n\nresume\n\n\nThe resume option resumes tracing globally.\n\n\n-Xtrace:resume\n\n\n\n\n\nThe \nsuspend\n and \nresume\n options are not recursive. That is, two suspends that are followed by a single resume cause trace to be resumed.\n\n\nresumecount\n\n\nThis trace option determines whether tracing is enabled for each thread.\n\n\n-Xtrace:resumecount=<count>\n\n\n\n\n\nIf \n<count>\n is greater than zero, each thread initially has its tracing disabled and must receive \n<count>\n \nresumethis\n actions before it starts tracing. This option is used with the \ntrigger\n option.\n\n\n \nNote:\n You cannot use \nresumecount\n and \nsuspendcount\n together because they use the same internal counter.\n\n\nThe following example starts with all tracing turned off. Each thread starts tracing when it has had three \nresumethis\n actions performed on it:\n\n\n-Xtrace:resumecount=3\n\n\n\n\n\nsleeptime\n\n\nYou can specify how long the sleep lasts when using the \nsleep\n trigger action.\n\n\n-Xtrace:sleeptime=nnn|aaams|bbbs\n\n\n\n\n\nWhere:\n\n\n\n\nnnn\n sleeps for \nnnn\n milliseconds.\n\n\naaams\n sleeps for \naaa\n milliseconds.\n\n\nbbbs\n sleeps for \nbbb\n seconds.\n\n\n\n\nThe default length of time is 30 seconds. If no units are specified, the default time unit is milliseconds.\n\n\nstackdepth\n\n\nUse this option to limit the maximum number of stack frames reported by the \njstacktrace\n trace trigger action.\n\n\n-Xtrace:stackdepth=<n>\n\n\n\n\n\nWhere \n<n>\n is the maximum number of stack frames reported.\n\n\nsuspend\n\n\n-Xtrace:suspend\n\n\n\n\n\nSuspends tracing globally for all threads and all forms of tracing but leaves tracepoints activated.\n\n\nsuspendcount\n\n\nThis trace option determines whether tracing is enabled for each thread.\n\n\n-Xtrace:suspendcount=<count>\n\n\n\n\n\nIf \n<count>\n is greater than zero, each thread initially has its tracing enabled and must receive \n<count>\n \nsuspendthis\n actions before it stops tracing.\n\n\n You cannot use \nresumecount\n and \nsuspendcount\n together because they both set the same internal counter.\n\n\nThis trace option is for use with the \ntrigger\n option.\n\n\nThe following example starts with tracing turned on. Each thread stops tracing when it has had three \nsuspendthis\n actions performed on it:\n\n\n-Xtrace:suspendcount=3\n\n\n\n\n\ntrigger\n\n\nThe \ntrigger\n parameter determines when various triggered trace actions occur. Supported actions include turning tracing on and off for all threads, turning tracing on or off for the current thread, or producing various dumps.\n\n\n-Xtrace:trigger=<clause>[,<clause>]\n\n\n\n\n\nThis trace option does not control \nwhat\n is traced. It controls only whether the information that has been selected by the other trace options is produced as normal or is blocked.\n\n\nTypes\n\n\nEach clause of the \ntrigger\n parameter can be one of the following types:\n\n\n\n\na method (\n-Xtrace:trigger=method{...}\n)\n\n\na tracepoint ID (\n-Xtrace:trigger=tpnid{...}\n)\n\n\na group (\n-Xtrace:trigger=group{...}\n)\n\n\n\n\nYou can specify multiple clauses of the same type if required, but you do not need to specify all types.\n\n\n\n\nmethod\n\n\n\n\n -Xtrace:trigger=method{<methodspec>[,<entryAction>[,<exitAction>[,<delayCount>[,<matchcount>]]]]}\n\n\n\n\n\nOn entering a method that matches \n<methodspec>\n, the specified \n<entryAction>\n is run. On leaving a method that matches \n<methodspec>\n, the specified \n<exitAction>\n is run. If you specify a \n<delayCount>\n, the actions are performed only after a matching \n<methodspec>\n has been entered that many times. If you specify a \n<matchCount>\n, \n<entryAction>\n and \n<exitAction>\n are performed at most that many times.\n\n\n<methodspec>\n is the specification of a Java method, consisting of a class and a method name separated by a dot. For example, specify \nHelloWorld.main\n. If the class is in a package, the package name must be included, separated by slashes. For example, specify \njava/lang/String.getBytes\n.\n\n\nA wildcard \"*\" can be used at the start or end of the class and method names, or both. For example, you can specify \n*/String.get*\n. To specify a constructor method, use \n<init>\n as the method name. Method signatures cannot be specified, so a method specification applies to all overloaded methods.\n\n\n\n\ntracepoint ID\n\n\n\n\n -Xtrace:trigger=tpnid{<tpnid>|<tpnidRange>,<action>[,<delayCount>[,<matchcount>]]}\n\n\n\n\n\nOn finding the specified active tracepoint ID (\n<tpnid>\n) or a tracepoint ID) that falls inside the specified \n<tpnidRange>\n, the specified action is \nrun\n. If you specify a \n<delayCount>\n, the action is performed only after the VM finds such an active \n<tpnid>\n that many times. If you specify a \n<matchCount>\n, \n<action>\n is performed at most that many times.\n\n\n\n\ngroup\n\n\n\n\n -Xtrace:trigger=group{<groupname>,<action>[,<delayCount>[,<matchcount>]]}\n\n\n\n\n\nOn finding any active tracepoint that is defined as being in trace group \n<groupname>\n, for example \nEntry\n or \nExit\n, the specified action is \nrun\n. If you specify a \n<delayCount>\n, the action is performed only after that many active tracepoints from group \n<groupname>\n have been found. If you specify a \n<matchCount>\n, \n<action>\n is performed at most that many times.\n\n\n\n\n\n\nActions\n\n\nWherever an action (\n<action>\n, \n<entryAction>\n, or \n<exitAction>\n) must be specified in one of the \ntrigger\n parameter clauses, you must select from these options:\n\n\n\n\n\n\n\n\n<action>\n\n\nEffect\n\n\n\n\n\n\n\n\n\n\nabort\n\n\nHalt the VM.\n\n\n\n\n\n\nceedump\n\n\nThis action is applicable to z/OS\u00ae only. For more information, see z/OS LE CEEDUMPs.\n\n\n\n\n\n\ncoredump\n\n\nSee \nsysdump\n.\n\n\n\n\n\n\nheapdump\n\n\nProduce a Heapdump. See \nUsing Heapdump\n.\n\n\n\n\n\n\njavadump\n\n\nProduce a Javadump. See \nUsing Javadump\n.\n\n\n\n\n\n\njstacktrace\n\n\nExamine the Java stack of the current thread and generate auxiliary tracepoints for each stack frame. The auxiliary tracepoints are written to the same destination as the tracepoint or method trace that triggered the action. You can control the number of stack frames examined with the stackdepth=n option. See the \nstackdepth\n option.\n\n\n\n\n\n\nresume\n\n\nResume all tracing (except for threads that are suspended by the action of the resumecount property and \nTrace.suspendThis()\n calls).\n\n\n\n\n\n\nresumethis\n\n\nDecrement the suspend count for this thread. If the suspend count is zero or less, resume tracing for this thread.\n\n\n\n\n\n\nsigsev\n\n\nCause a segmentation violation. (Intended for use in debugging.)\n\n\n\n\n\n\nsleep\n\n\nDelay the current thread for a length of time controlled by the sleeptime option. The default is 30 seconds. See sleeptime option.\n\n\n\n\n\n\nsnap\n\n\nSnap all active trace buffers to a file in the current working directory. The file name has the format: \nSnapnnnn.yyyymmdd.hhmmssth.ppppp.trc\n, where \nnnnn\n is the sequence number of the snap file since VM startup, \nyyyymmdd\n is the date, \nhhmmssth\n is the time, and \nppppp\n is the process ID in decimal with leading zeros removed.\n\n\n\n\n\n\nsuspend\n\n\nSuspend all tracing (except for special trace points).\n\n\n\n\n\n\nsuspendthis\n\n\nIncrement the suspend count for this thread. If the suspend-count is greater than zero, prevent all tracing for this thread.\n\n\n\n\n\n\nsysdump\n (or \ncoredump\n)\n\n\nProduce a system dump. See \nDump agents(\n-Xdump:system\n)\n.\n\n\n\n\n\n\n\n\nHere are some examples of using the \ntrigger\n option:\n\n\nTo produce a Java dump when a method is entered, specify the following command:\n\n\n-Xtrace:trigger=method{java/lang/String.getBytes,javadump}\n\n\n\n\n\nTo produce a system dump when a method is entered, specify the following command:\n\n\n-Xtrace:trigger=method{java/lang/String.getBytes,sysdump}\n\n\n\n\n\nTo produce a Java dump when a class constructor is called, specify the following command:\n\n\n\"-Xtrace:trigger=method{java/lang/Thread.<init>,javadump}\"\n\n\n\n\n\n \nNote:\n This trace option is enclosed in quotation marks to avoid unwanted shell expansion of some of the characters.\n\n\nTo produce a Java dump when a class static initializer is called, specify the following command:\n\n\n\"-Xtrace:trigger=method{java/lang/Thread.<clinit>,javadump}\"\n\n\n\n\n\n \nNote:\n This trace option is enclosed in quotation marks to avoid unwanted shell expansion of some of the characters.\n\n\nTo produce a Java dump when a method is entered 1000 times and 1001 times, specify the following command:\n\n\n-Xtrace:trigger=method{java/lang/String.getBytes,javadump,,1000,2}\n\n\n\n\n\nTo start tracing this thread when it enters any method in \njava/lang/String\n, and to stop tracing the thread after exiting the method, specify the following command:\n\n\n-Xtrace:resumecount=1\n\n\n\n\n\n-Xtrace:trigger=method{java/lang/String.*,resumethis,suspendthis}\n\n\nTo resume all tracing when any thread enters a method in any class that starts with \nerror\n, specify the following command:\n\n\n-Xtrace:trigger=method{*.error*,resume}\n\n\n\n\n\nTo trace (all threads) while the application is active; that is, not starting or shut down. (The application name is \nHelloWorld\n), specify the following command:\n\n\n-Xtrace:suspend,trigger=method{HelloWorld.main,resume,suspend}\n\n\n\n\n\nTo print a Java stack trace to the console when the mycomponent.1 tracepoint is reached, specify the following command:\n\n\n-Xtrace:print=mycomponent.1,trigger=tpnid{mycomponent.1,jstacktrace}\n\n\n\n\n\nTo write a Java stack trace to the trace output file when the \nSample.code()\n method is called, specify the following command:\n\n\n-Xtrace:maximal=mt,output=trc.out,methods={mycompany/mypackage/Sample.code},trigger=method{mycompany/mypackage/Sample.code,jstacktrace}\n\n\n\n\n\nwhat\n\n\n-Xtrace:what\n\n\n\n\n\nShows the current trace settings\n\n\nSee also\n\n\n\n\nApplication trace\n\n\nUsing Heapdump\n\n\nUsing Javadump\n\n\nDump viewer",
"title": "-Xtrace"
},
{
"location": "/xtrace/#-xtrace",
"text": "OpenJ9 VM tracing is a powerful feature to help you diagnose problems with minimal affect on performance. Tracing is enabled by default, together with a small set of trace points going to memory buffers. You can enable tracepoints at run time by using levels, components, group names, or individual tracepoint identifiers to trace VM internal operations and instrumented Java\u2122 applications. You can also trace Java methods. See the About trace section that follows for more detail. Trace data can be output in human-readable or in compressed binary formats. The VM provides a tool to process and convert the compressed binary data into a readable format. See Trace formatter . Note: You can also control trace by using the com.ibm.jvm.Trace API or by using JVMTI from an external agent.",
"title": "-Xtrace"
},
{
"location": "/xtrace/#xtrace-option-builder",
"text": "Use the Xtrace Option Builder tool to help you specify the correct options and avoid incompatibilities.",
"title": "Xtrace Option Builder"
},
{
"location": "/xtrace/#syntax",
"text": "-Xtrace:<parameter> You can get help with -Xtrace by using the folowing options: -Xtrace:help \u00a0 Displays general trace help -Xtrace:what \u00a0 Shows the current trace settings",
"title": "Syntax"
},
{
"location": "/xtrace/#configuring-trace",
"text": "The following parameters can be used to configure trace. (Follow links for more information about individual options.) Command Result -Xtrace:properties[=<filename>] Configures trace options based on a file -Xtrace:buffers=<size>[dynamic\\|nodynamic] Modifies the size of buffers that are used to store trace data -Xtrace:exception.output=<filename>[,<size>] Redirects exceptions trace data to a file. -Xtrace:methods=<method_specification> Traces methods -Xtrace:output=<filename>[,<size>[,<generations>]] Sends trace data to a file, optionally of a specific size and number of generations. -Xtrace:resume Resumes tracing globally. -Xtrace:resumecount=<count> Enables tracing at a thread level after a specified count. -Xtrace:sleeptime=<time> Pauses trace operations for a specified length of time. -Xtrace:stackdepth=<n> Limits the maximum number of stack frames reported by the jstacktrace trace trigger action. -Xtrace:suspend Suspends tracing globally. -Xtrace:suspendcount=<count> Suspends tracing at a thread level after a specified count. -Xtrace:trigger=<clause> Determines when various triggered trace actions occur, including turning trace on or off. Note: If an option value contains commas, it must be enclosed in braces. For example: methods={java/lang/*,com/ibm/*}",
"title": "Configuring trace"
},
{
"location": "/xtrace/#controlling-tracepoint-activation",
"text": "The following parameters can be used to control tracepoint activation. (Follow links for more information about individual options.) Command Result -Xtrace:maximal=<tracepoint_specification> Records all associated data. -Xtrace:minimal=<tracepoint_specification> Records only the time stamp and tracepoint identifier. -Xtrace:count=<tracepoint_specification> Counts the tracepoints that are used in a trace configuration. -Xtrace:print=<tracepoint_specification> Prints the specified tracepoints to stderr in real time. -Xtrace:iprint=<tracepoint_specification> Prints the specified tracepoints to stderr in real time with indentation. -Xtrace:exception=<tracepoint_specification> Enables exception tracing. -Xtrace:external<tracepoint_specification> Routes trace data to trace listeners, which are registered by using the JVMTI APIs. -Xtrace:none[=<tracepoint_specification>] Prevents the trace engine from loading if it is the only trace option specified. Note: These options control which individual tracepoints are activated at run time and the implicit destination of the trace data. All these properties are independent of each other and can be mixed and matched in any way that you choose. For more information, see Tracepoint activation .",
"title": "Controlling tracepoint activation"
},
{
"location": "/xtrace/#about-trace",
"text": "With the OpenJ9 trace feature, you can trace VM internal operations, Java applications, and Java methods, or any combination of these. VM internal operations The OpenJ9 virtual machine (VM) is extensively instrumented with tracepoints for tracing operations. Interpretating this trace data requires detailed knowledge of the VM, and is intended to diagnose VM problems. No guarantee is given that tracepoints will not vary from release to release and from platform to platform. Applications VM trace contains an application trace facility that allows tracepoints to be placed in Java code, enabling you to combine trace data with the other forms of trace. This capability is supported by the com.ibm.jvm.Trace API. Note that an instrumented Java application runs only on an OpenJ9 VM. For more information, see Application trace . Java methods Use method trace to debug and trace application code and the system classes provided with the VM. You can trace entry to and exit from Java methods run by the VM. You can select method trace by classname, method name, or both. You can also use wildcards to create complex method selections. For more information about command syntax, see methods . Trace can produce large amounts of data in a very short time. Before running trace, think carefully about what information you need in order to solve the problem. Here are some considerations: If you need only the trace information that is produced shortly before the problem occurs, consider wrapping the file by using the output option. In many cases, just use internal trace with an increased buffer size and snap the trace when the problem occurs. If the problem results in a thread stack dump or operating system signal or exception, trace buffers are snapped automatically to a file that is in the current directory. The file is called: Snapnnnn.\nyyyymmdd.hhmmssth.process.trc . You must also think carefully about which components need to be traced and what level of tracing is required. For example, if you are tracing a suspected shared classes problem, it might be enough to trace all components at level 1, and j9shr at level 9, while maximal can be used to show parameters and other information for the failing component. Tracepoint components and trace levels are described in the following sections: Tracepoint specification and Trace levels . There are two types of tracepoints inside the VM: Regular tracepoints include method tracepoints, application tracepoints, data tracepoints inside the VM and data tracepoints inside class libraries. You can display regular tracepoint data on the screen or save the data to a file. You can also use command line options to trigger specific actions when regular tracepoints fire. Auxiliary tracepoints are a special type of tracepoint that can be fired only when another tracepoint is being processed. For example, the stack frame information produced by the jstacktrace -Xtrace:trigger command. You cannot control where auxiliary tracepoint data is sent and you cannot set triggers on auxiliary tracepoints. Auxiliary tracepoint data is sent to the same destination as the tracepoint that caused them to be generated. Trace data can be written to one of the following locations: Memory buffers that can be dumped or snapped when a problem occurs. Use the -Xtrace:buffers=<size> option to control the size of the buffer allocated to each thread. Buffers allocated to a thread are discarded when that thread terminates. To examine the trace data captured in these memory buffers, you must snap or dump the data, then format the buffers. One or more files that are using buffered I/O. Use the -Xtrace:output option. An external agent in real time, using the -Xtrace:external option. stderr in real time. Any combination of the other items in this list.",
"title": "About trace"
},
{
"location": "/xtrace/#default-tracing",
"text": "By default, the equivalent of the following trace command line is always available in the VM: -Xtrace:maximal=all{level1},exception=j9mm{gclogger} When startup is complete, the equivalent of the following command line is added to enable level 2 trace points: -Xtrace:maximal=all{level2} Level 2 is used for default tracing that would produce too much data during the startup of the VM. If you set other trace options on the command line, or before the VM finishes startup (through use of JVMTI or the com.ibm.jvm.Trace API), the level 2 trace points are enabled just before your trace options are processed. This behavior ensures that the default level 2 trace points do not override any changes that you specify. The data generated by the tracepoints is continuously captured in wrapping memory buffers for each thread. You can find tracepoint information in the following diagnostics data: System memory dumps, extracted by using jdmpview. Snap traces, generated when the VM encounters a problem or an output file is specified. Using dump agents describes more ways to create a snap trace. For exception trace only, in Javadumps.",
"title": "Default tracing"
},
{
"location": "/xtrace/#default-memory-management-tracing",
"text": "The default trace options are designed to ensure that Javadumps always contain a record of the most recent memory management history, regardless of how much work the VM has performed since the garbage collection cycle was last called. The exception=j9mm{gclogger} clause of the default trace set specifies that a history of garbage collection cycles that have occurred in the VM is continuously recorded. The gclogger group of tracepoints in the j9mm component constitutes a set of tracepoints that record a snapshot of each garbage collection cycle. These tracepoints are recorded in their own separate buffer, called the exception buffer. The effect is that the tracepoints are not overwritten by the higher frequency tracepoints of the VM. The GC History section of the Javadump is based on the information in the exception buffer. If a garbage collection cycle has occurred in a traced VM, the Java dump probably contains a GC History section.",
"title": "Default memory management tracing"
},
{
"location": "/xtrace/#default-assertion-tracing",
"text": "The VM includes assertions, implemented as special trace points. By default, internal assertions are detected and diagnostics logs are produced to help assess the error. Assertion failures often indicate a serious problem, and the VM usually stops immediately. In these circumstances, raise an issue, including the standard error output and any diagnostic files that are produced. When an assertion trace point is reached, a message like the following output is produced on the standard error stream: 16 : 43 : 48.671 0x10a4800 j9vm . 209 * ** ASSERTION FAILED ** at jniinv . c : 251 : (( javaVM == (( void *) 0 ))) This error stream is followed with information about the diagnostic logs produced: JVMDUMP007I JVM Requesting System Dump using 'core.20060426.124348.976.dmp'\nJVMDUMP010I System Dump written to core.20060426.124348.976.dmp\nJVMDUMP007I JVM Requesting Snap Dump using 'Snap0001.20060426.124648.976.trc'\nJVMDUMP010I Snap Dump written to Snap0001.20060426.124648.976.trc Assertions are special trace points. They can be enabled or disabled by using the standard trace command-line options. Assertion failures might occur early during VM startup, before trace is enabled. In this case, the assert message has a different format, and is not prefixed by a timestamp or thread ID. For example: ** ASSERTION FAILED ** j9vmutil.15 at thrinfo.c:371 Assert_VMUtil_true((\n publicFlags & 0x200)) Assertion failures that occur early during startup cannot be disabled. These failures do not produce diagnostic dumps, and do not cause the VM to stop.",
"title": "Default assertion tracing"
},
{
"location": "/xtrace/#tracepoint-activation",
"text": "The options that control which individual tracepoints are activated at run time and the implicit destination of the trace data are listed under Syntax: Controlling tracepoint activation In some cases, you must use them with other options. For example, if you specify maximal or minimal tracepoints, the trace data is put into memory buffers. If you are going to send the data to a file, you must use an output option to specify the destination file name. With the exception of none , all options require at least one <tracepoint_specification> , which is described in the following section. Multiple statements of each type of trace are allowed and their effect is cumulative. If you want to use multiple trace options of the same name, use a properties file. (See properties .)",
"title": "Tracepoint activation"
},
{
"location": "/xtrace/#tracepoint-specification",
"text": "Tracepoints are enabled by specifying component and tracepoint . If no qualifier parameters are entered, all tracepoints are enabled, except for <exception.output> trace, where the default is all {exception}. The <tracepoint_specification> syntax can be further broken down as follows: [!]<component>[{<group>}] or [!]<component>[{<type>}] or [!]<tracepoint_id>[,<tracepoint_id>] Where: The ! symbol is a logical not . That is, the tracepoints that are in a specification starting with ! are turned off. <component> is a Java component. <group> is a tracepoint group, which is a set of tracepoints that are defined within a component. <type> is the tracepoint type: entry , exit , event , exception , and eem . <tracepoint_id> is the tracepoint identifier. The tracepoint identifier constitutes the component name of the tracepoint, followed by its integer number inside that component. For example, j9mm.49 , j9shr.20-29 , j9vm.15 . To understand these numbers, see Determining the tracepoint ID of a tracepoint. Some tracepoints can be both an exit and an exception ; that is, the function ended with an error. If you specify either exit or exception , these tracepoints are included. Lists of Java components and tracepoint groups can be found in the tables that follow. The following table lists the possible Java components ( <component> ). To include all Java components, specify all . Component name Description avl VM AVL tree support ibm_gpu Class library graphics processing unit (GPU) native code (Linux\u2122 only) io Class library java.io native code j9bcu VM byte code utilities j9bcverify VM byte code verification j9codertvm VM byte code run time j9dmp VM dump j9jcl VM class libraries j9jit VM JIT interface j9jni VM JNI support j9jvmti VM JVMTI support j9mm VM memory management j9prt VM port library j9scar VM class library interface j9shr VM shared classes j9trc VM trace j9util VM utilities j9vm VM general j9vmutil VM utilities j9vrb VM verbose stack walker map VM mapped memory support mt Java methods (see Note ) net Class library TCP/IP networking native code pool VM storage pool support rpc VM RPC support simplepool VM storage pool support sunvmi VM class library interface Note: When specifying the mt component you must also specify the methods option. The following table lists all the tracepoint groups ( <group> ). Each group is associated with one or more Java components: Component name or names Group name Description j9mm gclogger A set of tracepoints that record each garbage collection cycle. Equivalent to -verbose:gc output j9prt nlsmessage A set of tracepoints that record each NLS message that is issued by the VM. j9jcl , j9vm verboseclass A set of tracepoints that record each class as it is loaded. Equivalent to -verbose:class output. j9jni , j9vm checkjni A set of tracepoints that record JNI function checks. Equivalent to -Xcheck:jni output. j9vm checkmemory A set of tracepoints that record memory checks. Equivalent to -Xcheck:memory output. j9vm checkvm A set of tracepoints that record VM checks. Equivalent to -Xcheck:vm output. j9jit verbose A set of tracepoints that record JIT compiler configuration and method compilation. Equivalent to -Xjit:verbose output. mt compiledMethods A set of tracepoints that record compiled Java methods. mt nativeMethods A set of tracepoints that record Java native methods. mt staticMethods A set of tracepoints that record Java static methods. Here are some examples: To trace all tracepoints, specify the following command: -Xtrace:maximal=all To trace all tracepoints except **j9vrb** and **j9trc**, specify the following command:\n\n -Xtrace:minimal={all},minimal={!j9vrb,j9trc} To trace all entry and exit tracepoints in j9bcu , specify the following command: -Xtrace:maximal={j9bcu{entry},j9bcu{exit}} To trace all tracepoints in **j9mm** except tracepoints 20-30, specify the following command:\n\n -Xtrace:maximal=j9mm,maximal=!j9mm.20-30 To trace tracepoints j9prt.5 through j9prt.15 , specify the following command: -Xtrace:print=j9prt.5-15 To trace all **j9trc** tracepoints, specify the following command:\n\n -Xtrace:count=j9trc To trace all entry and exit tracepoints, specify the following command: -Xtrace:external={all{entry},all{exit}}",
"title": "Tracepoint specification"
},
{
"location": "/xtrace/#trace-levels",
"text": "Tracepoints have been assigned levels 0 through 9 that are based on the importance of the tracepoint. A level 0 tracepoint is the most important. It is reserved for extraordinary events and errors. A level 9 tracepoint is in-depth component detail. To specify a given level of tracing, the level0 through level9 keywords are used. You can abbreviate these keywords to l0 through l9. For example, if level5 is selected, all tracepoints that have levels 0 through 5 are included. Level specifications do not apply to explicit tracepoint specifications that use the TPNID keyword. The level is provided as a modifier to a component specification, for example: -Xtrace:maximal={all{level5}} or -Xtrace:maximal={j9mm{L2},j9trc,j9bcu{level9},all{level1}} In the first example, tracepoints that have a level of 5 or less are enabled for all components. In the second example, all level 1 tracepoints are enabled. All level 2 tracepoints in j9mm are enabled. All tracepoints up to level 9 are enabled in j9bcu . Note: The level applies only to the current component. If multiple trace selection components are found in a trace properties file, the level is reset to the default for each new component.\nLevel specifications do not apply to explicit tracepoint specifications that use the TPNID keyword. When the not operator is specified, the level is inverted; that is, !j9mm{level5} disables all tracepoints of level 6 or greater for the j9mm component. The following example enables trace for all components at level 9 (the default), but disables level 6 and higher for the locking component, and level 7 and higher for the storage component: -Xtrace:print={all},print={!j9trc{l5},j9mm{l6}} Here are some examples: To count the level zero and level one tracepoints matched, specify the following command: -Xtrace:count=all{L1} To produce maximal trace of all components at level 5 and j9mm at level 9, specify the following command: -Xtrace:maximal={all{level5},j9mm{L9}} To trace all components at level 6, but do not trace j9vrb at all, and do not trace the entry and exit tracepoints in the j9trc component, specify the following command: -Xtrace:minimal={all{l6}},minimal={!j9vrb,j9trc{entry},j9trc{exit}}",
"title": "Trace levels"
},
{
"location": "/xtrace/#parameters",
"text": "Parameters to use with the -Xtrace option:",
"title": "Parameters"
},
{
"location": "/xtrace/#buffers",
"text": "You can modify the size of the buffers to change how much diagnostic output is provided in a snap dump. This buffer is allocated for each thread that makes trace entries. The following table shows\nhow this parameter can be set: Command Effect -Xtrace:buffers=<size> Creates buffers of the specified <size> in k (KB) or m (MB), allocated as needed to match the rate of trace data generation to the output media. -Xtrace:buffers=<size>dynamic Creates buffers of the specified <size> , allocated as needed to match the rate of trace data generation to the output media. -Xtrace:buffers=<size>nodynamic Creates buffers of the specified <size> , with a maximum allocation of two buffers per thread. If external trace is enabled, the number of buffers is doubled; that is, each thread allocates two or more buffers. The same buffer size is used for state and exception tracing, but, in this case, buffers are allocated globally. The default is 8 KB per thread. The dynamic and nodynamic suboptions have meaning only when tracing to an output file. Note: If nodynamic is specified, you might lose trace data if the volume of trace data exceeds the bandwidth of the trace output file. Message UTE115 is issued when the first trace entry is lost, and message UTE018 is issued when the VM ends. Here are some command line examples: To set a buffer size of 2 MB per thread, with dynamic buffering, use: -Xtrace:buffers=2m To limit each thread to 2 trace buffers, each of 128 KB: -Xtrace:buffers={128k,nodynamic}",
"title": "buffers"
},
{
"location": "/xtrace/#count-tracepoint",
"text": "-Xtrace:count=<tracepoint_specification> For further information about <tracepoint_specification> syntax, see Tracepoint specification . The count option requests that only a count of the selected tracepoints is kept. When the VM ends, all nonzero totals of tracepoints (sorted by tracepoint id) are written to a file, called utTrcCounters , in the current directory. This information is useful if you want to determine the overhead of particular tracepoints, but do not want to produce a large amount (GB) of trace data. For example, to count the tracepoints that are used in the default trace configuration, use the following command: -Xtrace:count=all{level1},count=j9mm{gclogger}",
"title": "count (tracepoint)"
},
{
"location": "/xtrace/#exception-tracepoint",
"text": "-Xtrace:exception=<tracepoint_specification> For further information about <tracepoint_specification> syntax, see Tracepoint specification . When exception trace is enabled, the trace data is collected in internal buffers that are separate from the normal buffers. These internal buffers can then be written to a snap file or written to the file that is specified in an exception.output option. The exception option allows low-volume tracing in buffers and files that are distinct from the higher-volume information that minimal and maximal tracing have provided. In most cases, this information is exception-type data, but you can use this option to capture any trace data that you want. This form of tracing is channeled through a single set of buffers, as opposed to the buffer-per-thread approach for normal trace. Buffer contention might occur if high volumes of trace data are collected. A difference exists in the <tracepoint_specification> defaults for exception tracing; see Tracepoint specification . Notes: The exception trace buffers are intended for low-volume tracing. By default, the exception trace buffers log garbage collection (GC) event tracepoints, see Default tracing. You can send additional tracepoints to the exception buffers or turn off the GC tracepoints. Changing the exception trace buffers alters the contents of the GC History section in any Javadumps. When exception trace is entered for an active tracepoint, the current thread ID is checked against the previous caller's thread ID. If it is a different thread, or this is the first call to exception trace, a context tracepoint is put into the trace buffer first. This context tracepoint consists only of the current thread ID, which is necessary because of the single set of buffers for exception trace. (The formatter identifies all trace entries as coming from the Exception trace pseudo thread when it formats exception trace files.)",
"title": "exception (tracepoint)"
},
{
"location": "/xtrace/#exceptionoutput",
"text": "Use exception output to redirect exceptions trace data to a file. -Xtrace:exception.output=<filename>[,<size>] Where: <filename> is a file name, which is created automatically if it does not exist. Otherwise, it is overwritten. To embed specific values in the file name use any of the following variables: %d% (today's date in \"\nyyyymmdd\" format), %p% (process ID number of the process generating the trace), or %t% (time in 24-hour hhmmss format). Optionally, <size> is a value in megabytes (MB), for example, use 4m to specify 4 MB. When full, it wraps nondestructively to the beginning. If you do not limit the file, it grows indefinitely, until limited by disk space. Here are some examples: Exception trace output goes to file /u/traces/exception.trc with no size limit: -Xtrace:exception.output=/u/traces/exception.trc,maximal Exception trace output goes to file except and wraps at 2 MB: -Xtrace:exception.output={except,2m},maximal Exception trace output goes to a file whose filename contains today's date in \nyyyymmdd format (for example, traceout.20181025.trc ): -Xtrace:exception.output=traceout.%d.trc,maximal Exception trace output goes to a file whose filename contains the number of the process (the PID number) that generated it (for example, tracefrompid2112.trc ): -Xtrace:exception.output=tracefrompid%p.trc,maximal Exception trace output goes to a file whose filename contains the time in hhmmss format (for example, traceout.080312.trc ): -Xtrace:exception.output=traceout.%t.trc,maximal",
"title": "exception.output"
},
{
"location": "/xtrace/#external-tracepoint",
"text": "-Xtrace:external<tracepoint_specification> For further information about <tracepoint_specification> syntax, see Tracepoint specification . The external option routes trace data to trace listeners, which are registered by using the JVMTI RegisterTracePointSubscriber() and DeregisterTracePointSubscriber() APIs.",
"title": "external (tracepoint)"
},
{
"location": "/xtrace/#help",
"text": "-Xtrace:help Displays general trace help",
"title": "help"
},
{
"location": "/xtrace/#iprint-tracepoint",
"text": "-Xtrace:iprint=<tracepoint_specification> For further information about <tracepoint_specification> syntax, see Tracepoint specification . The iprint option is the same as the print option, but uses indenting to format the trace.",
"title": "iprint (tracepoint)"
},
{
"location": "/xtrace/#maximal-tracepoint",
"text": "-Xtrace:maximal=<tracepoint_specification> For further information about <tracepoint_specification> syntax, see Tracepoint specification . When specified, trace data is placed into internal trace buffers that can then be written to a snap file or written to the files that are specified in an output trace option. All associated data is traced. minimal and maximal traces are independent from any types that follow them. For example, if the maximal option is specified, it does not affect a later option such as print .",
"title": "maximal (tracepoint)"
},
{
"location": "/xtrace/#methods",
"text": "Using method trace provides a complete and potentially large diagnosis of code paths inside your application and the system classes. Use wild cards and filtering to control method trace so that you can focus on the sections of code that interest you. To specify one or more method specifications, use the following syntax: -Xtrace:methods=<method_specification>[,<method_specification>] The syntax for <method_specification> can be further broken down to the following suboptions: -Xtrace:methods={[!][*][<package>/]<class>[*],[[*]<method>[*]|[()]]} Where: The delimiter between parts of the package name is a forward slash, \"/\". The ! in the methods parameter is a NOT operator that allows you to tell the VM not to trace the specified method or methods. The parentheses, (), define whether or not to include method parameters in the trace. If a method specification includes any commas, the whole specification must be enclosed in braces, for example: -Xtrace:methods={java/lang/*,java/util/*},print=mt It might be necessary to enclose your command line in quotation marks to prevent the shell intercepting and fragmenting comma-separated command lines, for example: \"-Xtrace:methods={java/lang/*,java/util/*},print=mt\" To output all method trace information to stderr, use either the print or iprint suboptions: -Xtrace:print=mt,methods=*.*\n-Xtrace:iprint=mt,methods=*.* The iprint suboption prints to stderr with indentation.\nTo output method trace information in binary format, see the output option. Here are some examples: Tracing entry and exit of all methods in a given class: To trace all method entry and exit of the ReaderMain class in the default package and the java.lang.String class, specify the following command: -Xtrace:methods={ReaderMain.*,java/lang/String.*},print=mt Tracing entry, exit and input parameters of all methods in a class: To trace all method entry, exit, and input of the ReaderMain class in the default package, specify the following command: -Xtrace:methods=ReaderMain.*(),print=mt Tracing all methods in a given package: To trace all method entry, exit, and input of all classes in the package com.ibm.socket , specify the following command: -Xtrace:methods=com/ibm/socket/*.*(),print=mt Multiple method trace: To trace all method entry, exit, and input in the Widget class in the default package and all method entry and exit in the common package, specify the following command: -Xtrace:methods={Widget.*(),common/*},print=mt Using the ! operator: To trace all methods in the ArticleUI class in the default package except those beginning with \"get\", specify the following command: -Xtrace:methods={ArticleUI.*,!ArticleUI.get*},print=mt Tracing a specific method in a class: This example traces entry and exit of the substring method of the java.lang.String class . If there is more than one method with the same name, they are all traced. You cannot filter method trace by the signature of the method. -Xtrace:print=mt,methods={java/lang/String.substring} Tracing the constructor of a class: This example traces entry and exit of the constructors of the java.lang.String class. -Xtrace:print=mt,methods={java/lang/String.<init>} Here is some example output: java \"-Xtrace:methods={java/lang*.*},iprint=mt\" HW 10 : 02 : 42 . 281 * 0x9e900 mt . 4 > java / lang / J9VMInternals . initialize ( Ljava / lang / Class ;) \n V Compiled static method 10 : 02 : 42 . 281 0x9e900 mt . 4 > java / lang / J9VMInternals . verify ( Ljava / lang / Class ;) \n V Compiled static method 10 : 02 : 42 . 281 0x9e900 mt . 4 > java / lang / J9VMInternals . verify ( Ljava / lang / Class ;) \n V Compiled static method 10 : 02 : 42 . 281 0x9e900 mt . 4 > java / lang / J9VMInternals . setInitStatus ( Ljava / lang / Class ; I ) \n V Compiled static method 10 : 02 : 42 . 281 0x9e900 mt . 10 < java / lang / J9VMInternals . setInitStatus ( Ljava / lang / Class ; I ) \n V Compiled static method 10 : 02 : 42 . 281 0x9e900 mt . 10 < java / lang / J9VMInternals . verify ( Ljava / lang / Class ;) \n V Compiled static method 10 : 02 : 42 . 281 0x9e900 mt . 4 > java / lang / J9VMInternals . setInitStatus ( Ljava / lang / Class ; I ) \n V Compiled static method 10 : 02 : 42 . 281 0x9e900 mt . 10 < java / lang / J9VMInternals . setInitStatus ( Ljava / lang / Class ; I ) \n V Compiled static method 10 : 02 : 42 . 281 0x9e900 mt . 10 < java / lang / J9VMInternals . verify ( Ljava / lang / Class ;) \n V Compiled static method 10 : 02 : 42 . 281 0x9e900 mt . 4 > java / lang / J9VMInternals . initialize ( Ljava / lang / Class ;) \n V Compiled static method 10 : 02 : 42 . 281 0x9e900 mt . 4 > java / lang / J9VMInternals . setInitStatus ( Ljava / lang / Class ; I ) \n V Compiled static method 10 : 02 : 42 . 296 0x9e900 mt . 10 < java / lang / J9VMInternals . setInitStatus ( Ljava / lang / Class ; I ) \n V Compiled static method 10 : 02 : 42 . 296 0x9e900 mt . 10 < java / lang / J9VMInternals . initialize ( Ljava / lang / Class ;) \n V Compiled static method 10 : 02 : 42 . 296 0x9e900 mt . 4 > java / lang / String .< clinit >() V Compiled static method 10 : 02 : 42 . 296 0x9e900 mt . 4 > java / lang / J9VMInternals . initialize ( Ljava / lang / Class ;) \n V Compiled static method 10 : 02 : 42 . 296 0x9e900 mt . 4 > java / lang / J9VMInternals . verify ( Ljava / lang / Class ;) \n V Compiled static method 10 : 02 : 42 . 296 0x9e900 mt . 4 > java / lang / J9VMInternals . verify ( Ljava / lang / Class ;) \n V Compiled static method 10 : 02 : 42 . 296 0x9e900 mt . 10 < java / lang / J9VMInternals . verify ( Ljava / lang / Class ;) \n V Compiled static method 10 : 02 : 42 . 296 0x9e900 mt . 4 > java / lang / J9VMInternals . setInitStatus ( Ljava / lang / Class ; I ) \n V Compiled static method 10 : 02 : 42 . 328 0x9e900 mt . 10 < java / lang / J9VMInternals . setInitStatus ( Ljava / lang / Class ; I ) \n V Compiled static method 10 : 02 : 42 . 328 0x9e900 mt . 10 < java / lang / J9VMInternals . verify ( Ljava / lang / Class ;) \n V Compiled static method 10 : 02 : 42 . 328 0x9e900 mt . 4 > java / lang / J9VMInternals . initialize ( Ljava / lang / Class ;) \n V Compiled static method 10 : 02 : 42 . 328 0x9e900 mt . 10 < java / lang / J9VMInternals . initialize ( Ljava / lang / Class ;) \n V Compiled static method 10 : 02 : 42 . 328 0x9e900 mt . 4 > java / lang / J9VMInternals . setInitStatus ( Ljava / lang / Class ; I ) \n V Compiled static method 10 : 02 : 42 . 328 0x9e900 mt . 10 < java / lang / J9VMInternals . setInitStatus ( Ljava / lang / Class ; I ) \n V Compiled static method 10 : 02 : 42 . 328 0x9e900 mt . 10 < java / lang / J9VMInternals . initialize ( Ljava / lang / Class ;) \n V Compiled static method The output lines comprise of: 0x9e900 , the current execenv (execution environment). Because every VM thread has its own execenv , you can regard execenv as a thread-id . All trace with the same execenv relates to a single thread. The individual tracepoint ID in the mt component that collects and emits the data. The remaining fields show whether a method is being entered (>) or exited (<), followed by details of the method.",
"title": "methods"
},
{
"location": "/xtrace/#minimal-tracepoint",
"text": "-Xtrace:minimal=<tracepoint_specification> For further information about <tracepoint_specification> syntax, see Tracepoint specification . When specified, trace data is placed into internal trace buffers that can then be written to a snap file or written to the files that are specified in an output trace option. Only the time stamp and tracepoint identifier are recorded. When the trace is formatted, missing trace data is replaced with the characters \"???\" in the output file. minimal and maximal traces are independent from any types that follow them. For example, if the minimal option is specified, it does not affect a later option such as print .",
"title": "minimal (tracepoint)"
},
{
"location": "/xtrace/#none-tracepoint",
"text": "-Xtrace:none[=<tracepoint_specification>] For further information about <tracepoint_specification> syntax, see Tracepoint specification . -Xtrace:none prevents the trace engine from loading if it is the only trace option specified. However, if other -Xtrace options are on the command line, it is treated as the equivalent of -Xtrace:none=all and the trace engine still loads. If you specify other tracepoints without specifying -Xtrace:none , the tracepoints are added to the default set.",
"title": "none (tracepoint)"
},
{
"location": "/xtrace/#output",
"text": "Sends trace data to a file, optionally of a specific size and number of generations. -Xtrace:output=<filename>[,<size>[,<generations>]]` Where: <filename> is a file name, which is created automatically if it does not exist. Otherwise, it is overwritten. To embed specific values in the file name use any of the following variables: %d% (today's date in \"\nyyyymmdd\" format), %p% (process ID number of the process generating the trace), or %t% (time in 24-hour hhmmss format). Optionally, <size> is a value in megabytes (MB), for example, use 4m to specify 4 MB. When full, it wraps to the beginning. If you do not limit the file, it grows indefinitely, until limited by disk space. Optionally, <generations> is a value 2 through 36. These values cause up to 36 files to be used sequentially as each file reaches its <size> threshold. When a file needs to be reused, it is overwritten. If <generations> is specified, the filename must contain a # (hash, pound symbol), which will be substituted with its generation identifier, the sequence of which is 0 through 9 followed by A through Z. Note: When tracing to a file, buffers for each thread are written when the buffer is full or when the VM ends. If a thread has been inactive for a period of time before the VM ends, what seems to be 'old' trace data is written to the file. When formatted, it then seems that trace data is missing from the other threads, but this is an unavoidable side-effect of the buffer-per-thread design. This effect becomes especially noticeable when you use the generation facility, and format individual earlier generations. Here are some examples: Trace output goes to file /u/traces/gc.problem with no size limit: -Xtrace:output=/u/traces/gc.problem,maximal=j9gc Trace output goes to file trace , which will wrap at 2 MB: -Xtrace:output={trace,2m},maximal=j9gc Trace output goes to files gc0.trc , gc1.trc , and gc2.trc , each 10 MB in size: -Xtrace:output={gc#.trc,10m,3},maximal=j9gc Trace output goes to a file, where the filename contains today's date in \nyyyymmdd format (for example, traceout.20181025.trc ): -Xtrace:output=traceout.%d.trc,maximal=j9gc Trace output goes to a file whose name contains the number of the process (the PID number) that generated it (for example, tracefrompid2112.trc ): -Xtrace:output=tracefrompid%p.trc,maximal=j9gc Trace output goes to a file whose name contains the time in hhmmss format (for example, traceout.080312.trc ): -Xtrace:output=traceout.%t.trc,maximal=j9gc",
"title": "output"
},
{
"location": "/xtrace/#print-tracepoint",
"text": "-Xtrace:print=<tracepoint_specification> For further information about <tracepoint_specification> syntax, see Tracepoint specification . The print option causes the specified tracepoints to be routed to stderr in real time. The VM tracepoints are formatted by using J9TraceFormat.dat . The class library tracepoints are formatted by J9TraceFormat.dat and TraceFormat.dat .",
"title": "print (tracepoint)"
},
{
"location": "/xtrace/#properties",
"text": "You can use properties files to control trace. A properties file saves typing and allows you to create a library of files that are tailored to solving problems in a particular area. -Xtrace:properties[=<filename>] If <filename> is not specified, the VM searches for a default name of IBMTRACE.properties in the current directory. All the options that are in the file are processed in the sequence in which they are stored in the file, before the next option that is obtained through the normal mechanism is processed. Therefore, a command-line property always overrides a property that is in the file. Here is an example of a properties file: minimal=all\n// maximal=j9mm\nmaximal=j9shr\nbuffers=128k,nodynamic\noutput=c:\\traces\\classloader.trc\nprint=tpnid(j9vm.23-25) The following restrictions apply to the file: The file must be a flat ASCII file. Nesting is not supported; that is, the file cannot contain a properties option. You cannot leave properties that have the form <name>=<value> to default if they are specified in the property file; that is, you must specify a value, for example maximal=all . Do not add white space before, after, or within the trace options. If any error is found when the file is accessed, VM initialization fails with an explanatory error message and return code. To use a file trace.props stored in the c:\\trc\\gc directory, specify the following command: -Xtrace:properties=c:\\trc\\gc\\trace.props",
"title": "properties"
},
{
"location": "/xtrace/#resume",
"text": "The resume option resumes tracing globally. -Xtrace:resume The suspend and resume options are not recursive. That is, two suspends that are followed by a single resume cause trace to be resumed.",
"title": "resume"
},
{
"location": "/xtrace/#resumecount",
"text": "This trace option determines whether tracing is enabled for each thread. -Xtrace:resumecount=<count> If <count> is greater than zero, each thread initially has its tracing disabled and must receive <count> resumethis actions before it starts tracing. This option is used with the trigger option. Note: You cannot use resumecount and suspendcount together because they use the same internal counter. The following example starts with all tracing turned off. Each thread starts tracing when it has had three resumethis actions performed on it: -Xtrace:resumecount=3",
"title": "resumecount"
},
{
"location": "/xtrace/#sleeptime",
"text": "You can specify how long the sleep lasts when using the sleep trigger action. -Xtrace:sleeptime=nnn|aaams|bbbs Where: nnn sleeps for nnn milliseconds. aaams sleeps for aaa milliseconds. bbbs sleeps for bbb seconds. The default length of time is 30 seconds. If no units are specified, the default time unit is milliseconds.",
"title": "sleeptime"
},
{
"location": "/xtrace/#stackdepth",
"text": "Use this option to limit the maximum number of stack frames reported by the jstacktrace trace trigger action. -Xtrace:stackdepth=<n> Where <n> is the maximum number of stack frames reported.",
"title": "stackdepth"
},
{
"location": "/xtrace/#suspend",
"text": "-Xtrace:suspend Suspends tracing globally for all threads and all forms of tracing but leaves tracepoints activated.",
"title": "suspend"
},
{
"location": "/xtrace/#suspendcount",
"text": "This trace option determines whether tracing is enabled for each thread. -Xtrace:suspendcount=<count> If <count> is greater than zero, each thread initially has its tracing enabled and must receive <count> suspendthis actions before it stops tracing. You cannot use resumecount and suspendcount together because they both set the same internal counter. This trace option is for use with the trigger option. The following example starts with tracing turned on. Each thread stops tracing when it has had three suspendthis actions performed on it: -Xtrace:suspendcount=3",
"title": "suspendcount"
},
{
"location": "/xtrace/#trigger",
"text": "The trigger parameter determines when various triggered trace actions occur. Supported actions include turning tracing on and off for all threads, turning tracing on or off for the current thread, or producing various dumps. -Xtrace:trigger=<clause>[,<clause>] This trace option does not control what is traced. It controls only whether the information that has been selected by the other trace options is produced as normal or is blocked.",
"title": "trigger"
},
{
"location": "/xtrace/#types",
"text": "Each clause of the trigger parameter can be one of the following types: a method ( -Xtrace:trigger=method{...} ) a tracepoint ID ( -Xtrace:trigger=tpnid{...} ) a group ( -Xtrace:trigger=group{...} ) You can specify multiple clauses of the same type if required, but you do not need to specify all types. method -Xtrace:trigger=method{<methodspec>[,<entryAction>[,<exitAction>[,<delayCount>[,<matchcount>]]]]} On entering a method that matches <methodspec> , the specified <entryAction> is run. On leaving a method that matches <methodspec> , the specified <exitAction> is run. If you specify a <delayCount> , the actions are performed only after a matching <methodspec> has been entered that many times. If you specify a <matchCount> , <entryAction> and <exitAction> are performed at most that many times. <methodspec> is the specification of a Java method, consisting of a class and a method name separated by a dot. For example, specify HelloWorld.main . If the class is in a package, the package name must be included, separated by slashes. For example, specify java/lang/String.getBytes . A wildcard \"*\" can be used at the start or end of the class and method names, or both. For example, you can specify */String.get* . To specify a constructor method, use <init> as the method name. Method signatures cannot be specified, so a method specification applies to all overloaded methods. tracepoint ID -Xtrace:trigger=tpnid{<tpnid>|<tpnidRange>,<action>[,<delayCount>[,<matchcount>]]} On finding the specified active tracepoint ID ( <tpnid> ) or a tracepoint ID) that falls inside the specified <tpnidRange> , the specified action is run . If you specify a <delayCount> , the action is performed only after the VM finds such an active <tpnid> that many times. If you specify a <matchCount> , <action> is performed at most that many times. group -Xtrace:trigger=group{<groupname>,<action>[,<delayCount>[,<matchcount>]]} On finding any active tracepoint that is defined as being in trace group <groupname> , for example Entry or Exit , the specified action is run . If you specify a <delayCount> , the action is performed only after that many active tracepoints from group <groupname> have been found. If you specify a <matchCount> , <action> is performed at most that many times.",
"title": "Types"
},
{
"location": "/xtrace/#actions",
"text": "Wherever an action ( <action> , <entryAction> , or <exitAction> ) must be specified in one of the trigger parameter clauses, you must select from these options: <action> Effect abort Halt the VM. ceedump This action is applicable to z/OS\u00ae only. For more information, see z/OS LE CEEDUMPs. coredump See sysdump . heapdump Produce a Heapdump. See Using Heapdump . javadump Produce a Javadump. See Using Javadump . jstacktrace Examine the Java stack of the current thread and generate auxiliary tracepoints for each stack frame. The auxiliary tracepoints are written to the same destination as the tracepoint or method trace that triggered the action. You can control the number of stack frames examined with the stackdepth=n option. See the stackdepth option. resume Resume all tracing (except for threads that are suspended by the action of the resumecount property and Trace.suspendThis() calls). resumethis Decrement the suspend count for this thread. If the suspend count is zero or less, resume tracing for this thread. sigsev Cause a segmentation violation. (Intended for use in debugging.) sleep Delay the current thread for a length of time controlled by the sleeptime option. The default is 30 seconds. See sleeptime option. snap Snap all active trace buffers to a file in the current working directory. The file name has the format: Snapnnnn.yyyymmdd.hhmmssth.ppppp.trc , where nnnn is the sequence number of the snap file since VM startup, yyyymmdd is the date, hhmmssth is the time, and ppppp is the process ID in decimal with leading zeros removed. suspend Suspend all tracing (except for special trace points). suspendthis Increment the suspend count for this thread. If the suspend-count is greater than zero, prevent all tracing for this thread. sysdump (or coredump ) Produce a system dump. See Dump agents( -Xdump:system ) . Here are some examples of using the trigger option: To produce a Java dump when a method is entered, specify the following command: -Xtrace:trigger=method{java/lang/String.getBytes,javadump} To produce a system dump when a method is entered, specify the following command: -Xtrace:trigger=method{java/lang/String.getBytes,sysdump} To produce a Java dump when a class constructor is called, specify the following command: \"-Xtrace:trigger=method{java/lang/Thread.<init>,javadump}\" Note: This trace option is enclosed in quotation marks to avoid unwanted shell expansion of some of the characters. To produce a Java dump when a class static initializer is called, specify the following command: \"-Xtrace:trigger=method{java/lang/Thread.<clinit>,javadump}\" Note: This trace option is enclosed in quotation marks to avoid unwanted shell expansion of some of the characters. To produce a Java dump when a method is entered 1000 times and 1001 times, specify the following command: -Xtrace:trigger=method{java/lang/String.getBytes,javadump,,1000,2} To start tracing this thread when it enters any method in java/lang/String , and to stop tracing the thread after exiting the method, specify the following command: -Xtrace:resumecount=1 -Xtrace:trigger=method{java/lang/String.*,resumethis,suspendthis} To resume all tracing when any thread enters a method in any class that starts with error , specify the following command: -Xtrace:trigger=method{*.error*,resume} To trace (all threads) while the application is active; that is, not starting or shut down. (The application name is HelloWorld ), specify the following command: -Xtrace:suspend,trigger=method{HelloWorld.main,resume,suspend} To print a Java stack trace to the console when the mycomponent.1 tracepoint is reached, specify the following command: -Xtrace:print=mycomponent.1,trigger=tpnid{mycomponent.1,jstacktrace} To write a Java stack trace to the trace output file when the Sample.code() method is called, specify the following command: -Xtrace:maximal=mt,output=trc.out,methods={mycompany/mypackage/Sample.code},trigger=method{mycompany/mypackage/Sample.code,jstacktrace}",
"title": "Actions"
},
{
"location": "/xtrace/#what",
"text": "-Xtrace:what Shows the current trace settings",
"title": "what"
},
{
"location": "/xtrace/#see-also",
"text": "Application trace Using Heapdump Using Javadump Dump viewer",
"title": "See also"
},
{
"location": "/xtunevirtualized/",
"text": "-Xtune:virtualized\n\n\nOptimizes OpenJ9 VM function for virtualized environments, such as a cloud by reducing OpenJ9 VM CPU consumption when idle.\n\n\n \nNote:\n Performance is optimized if there is a large shared class cache (SCC) and AOT space in the SCC is not capped.\n\n\nSyntax\n\n\n -Xtune:virtualized\n\n\n\n\n\nSee also\n\n\n\n\nFor an example of the effect of using this option, see: \nMeasuring the strengths of OpenJDK with Eclipse OpenJ9",
"title": "-Xtune:virtualized"
},
{
"location": "/xtunevirtualized/#-xtunevirtualized",
"text": "Optimizes OpenJ9 VM function for virtualized environments, such as a cloud by reducing OpenJ9 VM CPU consumption when idle. Note: Performance is optimized if there is a large shared class cache (SCC) and AOT space in the SCC is not capped.",
"title": "-Xtune:virtualized"
},
{
"location": "/xtunevirtualized/#syntax",
"text": "-Xtune:virtualized",
"title": "Syntax"
},
{
"location": "/xtunevirtualized/#see-also",
"text": "For an example of the effect of using this option, see: Measuring the strengths of OpenJDK with Eclipse OpenJ9",
"title": "See also"
},
{
"location": "/xverbosegclog/",
"text": "-Xverbosegclog\n\n\nCauses garbage collection (GC) output from the \n-verbose:gc\n option to be written to a specified file.\n\n\nSyntax\n\n\n -Xverbosegclog[:<filename>[,<x>,<y>]]\n\n\n\n\n\n\n\n\n\nwhere \n<filename>\n is the name of the file to which output is written. Dump agent tokens can be used in the filename.\n\n\nIf the file cannot be found, the file is created, and output is written to the new file.\n\n\nIf the file cannot be created (for example, if an invalid filename is specified), output is redirected to \nstderr\n.\n\n\nIf you do not specify a file name, \nverbosegc.%Y%m%d.%H%M%S.%pid.txt\n is used (for example, \nverbosegc.20180124.093210.1234.txt\n).\n\n\nIf you specify \n<x>\n and \n<y>\n, output is redirected to \nx\n files, each containing \ny\n GC cycles.\n\n\n\n\n\n\nDefault behavior\n\n\nBy default, no verbose GC logging occurs.\n\n\nSee also\n\n\n\n\nDump agent tokens\n for more information.",
"title": "-Xverbosegclog"
},
{
"location": "/xverbosegclog/#-xverbosegclog",
"text": "Causes garbage collection (GC) output from the -verbose:gc option to be written to a specified file.",
"title": "-Xverbosegclog"
},
{
"location": "/xverbosegclog/#syntax",
"text": "-Xverbosegclog[:<filename>[,<x>,<y>]] where <filename> is the name of the file to which output is written. Dump agent tokens can be used in the filename. If the file cannot be found, the file is created, and output is written to the new file. If the file cannot be created (for example, if an invalid filename is specified), output is redirected to stderr . If you do not specify a file name, verbosegc.%Y%m%d.%H%M%S.%pid.txt is used (for example, verbosegc.20180124.093210.1234.txt ). If you specify <x> and <y> , output is redirected to x files, each containing y GC cycles.",
"title": "Syntax"
},
{
"location": "/xverbosegclog/#default-behavior",
"text": "By default, no verbose GC logging occurs.",
"title": "Default behavior"
},
{
"location": "/xverbosegclog/#see-also",
"text": "Dump agent tokens for more information.",
"title": "See also"
},
{
"location": "/xverify/",
"text": "-Xverify\n\n\nAs described in the \nOracle documentation\n, this Hotspot option enables or disables the verifier. For compatibility, this option is also supported by the OpenJ9 VM.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-Xverify\n\n\nEnables verification for all non-bootstrap classes. \n-Xfuture\n verification is not enabled.\n\n\nyes\n\n\n\n\n\n\n-Xverify:all\n\n\nEnables verification for all classes and enables \n-Xfuture\n verification. \u00a0 \nNote:\n This setting might have an impact on performance.\n\n\n\n\n\n\n\n\n-Xverify:remote\n\n\nFor compatibility, this parameter is accepted, but is equivalent to the default \n-Xverify\n.\n\n\n\n\n\n\n\n\n-Xverify:none\n\n\nDisables the verifier. \u00a0 \nNote:\n This is not a supported configuration. If you encounter problems with the verifier turned off, remove this option and try to reproduce the problem.",
"title": "-Xverify"
},
{
"location": "/xverify/#-xverify",
"text": "As described in the Oracle documentation , this Hotspot option enables or disables the verifier. For compatibility, this option is also supported by the OpenJ9 VM.",
"title": "-Xverify"
},
{
"location": "/xverify/#syntax",
"text": "Setting Effect Default -Xverify Enables verification for all non-bootstrap classes. -Xfuture verification is not enabled. yes -Xverify:all Enables verification for all classes and enables -Xfuture verification. \u00a0 Note: This setting might have an impact on performance. -Xverify:remote For compatibility, this parameter is accepted, but is equivalent to the default -Xverify . -Xverify:none Disables the verifier. \u00a0 Note: This is not a supported configuration. If you encounter problems with the verifier turned off, remove this option and try to reproduce the problem.",
"title": "Syntax"
},
{
"location": "/xzero/",
"text": "-Xzero\n\n\nEnables reduction of the memory footprint of the Java\u2122 runtime environment when concurrently running multiple Java invocations.\n\n\nThis option is deprecated and will be removed in a future release.\n\n\n This option can be used only with Java SE version 8 runtime environments. \n\n\n-Xzero\n might not be appropriate for all types of applications because it changes the implementation of \njava.util.ZipFile\n, which might cause extra memory usage.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\n\n\n\n\n\n\n\n\n-Xzero:none\n\n\nDisable all sub options\n\n\n\n\n\n\n-Xzero:describe\n\n\nPrints the sub options in effect\n\n\n\n\n\n\n-Xzero:sharebootzip\n\n\nEnables the sharebootzip sub option\n\n\n\n\n\n\n-Xzero:nosharebootzip\n\n\nDisables the sharebootzip sub option\n\n\n\n\n\n\n\n\nThe following parameters are no longer supported. The options are parsed but do nothing:\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\n\n\n\n\n\n\n\n\n-Xzero:j9zip\n\n\nEnables the j9zip sub option\n\n\n\n\n\n\n-Xzero:noj9zip\n\n\nDisables the j9zip sub option\n\n\n\n\n\n\n-Xzero:sharezip\n\n\nEnables the sharezip sub option\n\n\n\n\n\n\n-Xzero:nosharezip\n\n\nDisables the sharezip sub option",
"title": "-Xzero"
},
{
"location": "/xzero/#-xzero",
"text": "Enables reduction of the memory footprint of the Java\u2122 runtime environment when concurrently running multiple Java invocations. This option is deprecated and will be removed in a future release. This option can be used only with Java SE version 8 runtime environments. -Xzero might not be appropriate for all types of applications because it changes the implementation of java.util.ZipFile , which might cause extra memory usage.",
"title": "-Xzero"
},
{
"location": "/xzero/#syntax",
"text": "Setting Effect -Xzero:none Disable all sub options -Xzero:describe Prints the sub options in effect -Xzero:sharebootzip Enables the sharebootzip sub option -Xzero:nosharebootzip Disables the sharebootzip sub option The following parameters are no longer supported. The options are parsed but do nothing: Setting Effect -Xzero:j9zip Enables the j9zip sub option -Xzero:noj9zip Disables the j9zip sub option -Xzero:sharezip Enables the sharezip sub option -Xzero:nosharezip Disables the sharezip sub option",
"title": "Syntax"
},
{
"location": "/xx_jvm_commands/",
"text": "Using -XX command-line options\n\n\nJava\u2122 VM command-line options that are specified with -XX: are not checked for validity. If the VM does not recognize the option, the option is ignored. These options can therefore be used across different VM versions without ensuring a particular level of the VM.\n\n\nFor options that take a \n<size>\n parameter, add a suffix to the size value: \"k\" or \"K\" to indicate kilobytes, \"m\" or \"M\" to indicate megabytes, or \"g\" or \"G\" to indicate gigabytes.\n\n\nFor example, to set the \n-Xmx\n value to 16 MB, you can specify \n-Xmx16M\n, \n-Xmx16m\n, \n-Xmx16384K\n, or \nXmx16384k\n on the command line.",
"title": "Using -XX options"
},
{
"location": "/xx_jvm_commands/#using-xx-command-line-options",
"text": "Java\u2122 VM command-line options that are specified with -XX: are not checked for validity. If the VM does not recognize the option, the option is ignored. These options can therefore be used across different VM versions without ensuring a particular level of the VM. For options that take a <size> parameter, add a suffix to the size value: \"k\" or \"K\" to indicate kilobytes, \"m\" or \"M\" to indicate megabytes, or \"g\" or \"G\" to indicate gigabytes. For example, to set the -Xmx value to 16 MB, you can specify -Xmx16M , -Xmx16m , -Xmx16384K , or Xmx16384k on the command line.",
"title": "Using -XX command-line options"
},
{
"location": "/xxactiveprocessorcount/",
"text": "-XX:ActiveProcessorCount\n\n\nThis Hotspot option is recognized by OpenJ9 for compatibility. Use this option to override the number of CPUs that the VM automatically detects and uses when creating threads for various subsystems.\n\n\nSyntax\n\n\n -XX:ActiveProcessorCount=<n>\n\n\n\n\n\nWhere \n<n>\n is the number of CPUs.\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\n1 or greater\n\n\nThere is no default value. This option is not enabled by default. If set to \n0\n, there is no effect.\n\n\n\n\n\n\n\n\nWhen you set this option the following line in a Java dump file is updated to indicate the number of CPUs specified:\n\n\n2CIACTIVECPU Active CPUs\n\n\n\n\n\nIf this option is not set, the value for this line is \n0\n Active CPUs.",
"title": "-XXActiveProcessorCount"
},
{
"location": "/xxactiveprocessorcount/#-xxactiveprocessorcount",
"text": "This Hotspot option is recognized by OpenJ9 for compatibility. Use this option to override the number of CPUs that the VM automatically detects and uses when creating threads for various subsystems.",
"title": "-XX:ActiveProcessorCount"
},
{
"location": "/xxactiveprocessorcount/#syntax",
"text": "-XX:ActiveProcessorCount=<n> Where <n> is the number of CPUs. Setting Value Default <n> 1 or greater There is no default value. This option is not enabled by default. If set to 0 , there is no effect. When you set this option the following line in a Java dump file is updated to indicate the number of CPUs specified: 2CIACTIVECPU Active CPUs If this option is not set, the value for this line is 0 Active CPUs.",
"title": "Syntax"
},
{
"location": "/xxallowvmshutdown/",
"text": "-XXallowvmshutdown\n\n\nThis option is provided as a workaround for applications that cannot shut down cleanly, as described in \nAPAR IZ59734\n.\n\n\nSyntax\n\n\n -XX:allowvmshutdown:[false|true]\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\nfalse\n\n\nDisable\n\n\n\n\n\n\n\n\ntrue\n\n\nEnable\n\n\nyes",
"title": "-XXallowvmshutdown"
},
{
"location": "/xxallowvmshutdown/#-xxallowvmshutdown",
"text": "This option is provided as a workaround for applications that cannot shut down cleanly, as described in APAR IZ59734 .",
"title": "-XXallowvmshutdown"
},
{
"location": "/xxallowvmshutdown/#syntax",
"text": "-XX:allowvmshutdown:[false|true] Setting Effect Default false Disable true Enable yes",
"title": "Syntax"
},
{
"location": "/xxcodecachetotal/",
"text": "-XX:codecachetotal\n\n\nThis option is an alias for the \n-Xcodecachetotal\n option.\n\n\nSyntax\n\n\n -XX:codecachetotal=<size>\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about specifying the \n<size>\n parameter.",
"title": "-XX:codecachetotal"
},
{
"location": "/xxcodecachetotal/#-xxcodecachetotal",
"text": "This option is an alias for the -Xcodecachetotal option.",
"title": "-XX:codecachetotal"
},
{
"location": "/xxcodecachetotal/#syntax",
"text": "-XX:codecachetotal=<size> See Using -X command-line options for more information about specifying the <size> parameter.",
"title": "Syntax"
},
{
"location": "/xxdisableexplicitgc/",
"text": "-XX:[+|-]DisableExplicitGC\n\n\nThis Hotspot option is recognized by OpenJ9 for compatibility. See \n\u2011Xenableexplicitgc.md / \u2011Xdisableexplicitgc\n for details.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:+DisableExplicitGC\n\n\nEnable GC\n\n\nyes\n\n\n\n\n\n\n-XX:-DisableExplicitGC\n\n\nDisable GC",
"title": "-XX:[+|-]DisableExplicitGC"
},
{
"location": "/xxdisableexplicitgc/#-xx-disableexplicitgc",
"text": "This Hotspot option is recognized by OpenJ9 for compatibility. See \u2011Xenableexplicitgc.md / \u2011Xdisableexplicitgc for details.",
"title": "-XX:[+|-]DisableExplicitGC"
},
{
"location": "/xxdisableexplicitgc/#syntax",
"text": "Setting Effect Default -XX:+DisableExplicitGC Enable GC yes -XX:-DisableExplicitGC Disable GC",
"title": "Syntax"
},
{
"location": "/xxdisclaimjitscratch/",
"text": "-XX:[+|-]DisclaimJitScratch\n\n\n \nRestriction:\n This option is deprecated; the option is accepted but ignored.\n\n\n(Linux\u2122 only)\n\n\nThe \n-XX:+DisclaimJitScratch\n option signals to the operating system to discard temporary physical memory that is consumed by the JIT compilation threads.\n\n\nSyntax\n\n\n -XX:[+|-]DisclaimJitScratch\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:+DisclaimJitScratch\n\n\nEnable\n\n\n\n\n\n\n\n\n-XX:-DisclaimJitScratch\n\n\nDisable\n\n\nyes\n\n\n\n\n\n\n\n\nExplanation\n\n\nDiscarding temporary physical memory can reduce the physical memory reported in use by the Java\u2122 application. The physical memory that is released is available to other processes without the operating system needing to search for the least recently used frames.\n\n\nThe \n-XX:-DisclaimJitScratch\n option turns off a previously enabled \n-XX:+DisclaimJitScratch\n option.",
"title": "-XX:[+|-]DisclaimJitScratch"
},
{
"location": "/xxdisclaimjitscratch/#-xx91-93disclaimjitscratch",
"text": "Restriction: This option is deprecated; the option is accepted but ignored. (Linux\u2122 only) The -XX:+DisclaimJitScratch option signals to the operating system to discard temporary physical memory that is consumed by the JIT compilation threads.",
"title": "-XX:[+|-]DisclaimJitScratch"
},
{
"location": "/xxdisclaimjitscratch/#syntax",
"text": "-XX:[+|-]DisclaimJitScratch Setting Effect Default -XX:+DisclaimJitScratch Enable -XX:-DisclaimJitScratch Disable yes",
"title": "Syntax"
},
{
"location": "/xxdisclaimjitscratch/#explanation",
"text": "Discarding temporary physical memory can reduce the physical memory reported in use by the Java\u2122 application. The physical memory that is released is available to other processes without the operating system needing to search for the least recently used frames. The -XX:-DisclaimJitScratch option turns off a previously enabled -XX:+DisclaimJitScratch option.",
"title": "Explanation"
},
{
"location": "/xxenablecpumonitor/",
"text": "-XX:[+|-]EnableCPUMonitor\n\n\nThis option relates to the information about the CPU usage of thread categories that is available with the \ncom.ibm.lang.management.JvmCpuMonitorMXBean\n application programming interface.\n\n\n \nRestriction:\n This option might not be supported in subsequent releases.\n\n\nSyntax\n\n\n -XX:[+|-]EnableCPUMonitor\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:+EnableCPUMonitor\n\n\nEnable\n\n\nyes\n\n\n\n\n\n\n-XX:-EnableCPUMonitor\n\n\nDisable\n\n\n\n\n\n\n\n\n\n\nExplanation\n\n\nThe \n-XX:+EnableCPUMonitor\n option enables CPU monitoring, which allows a JMX bean to track CPU usage on a per thread basis and attributes the usage against different categories. For more information, see the \nJvmCpuMonitorMXBean\n interface in the \ncom.ibm.lang.management\n API documentation.\n\n\nTo turn off CPU monitoring, set the \n-XX:-EnableCPUMonitor\n option on the command line.\n\n\nSee also\n\n\n\n\n-XX:[+|-]ReduceCPUMonitorOverhead",
"title": "-XX:[+|-]EnableCPUMonitor"
},
{
"location": "/xxenablecpumonitor/#-xx91-93enablecpumonitor",
"text": "This option relates to the information about the CPU usage of thread categories that is available with the com.ibm.lang.management.JvmCpuMonitorMXBean application programming interface. Restriction: This option might not be supported in subsequent releases.",
"title": "-XX:[+|-]EnableCPUMonitor"
},
{
"location": "/xxenablecpumonitor/#syntax",
"text": "-XX:[+|-]EnableCPUMonitor Setting Effect Default -XX:+EnableCPUMonitor Enable yes -XX:-EnableCPUMonitor Disable",
"title": "Syntax"
},
{
"location": "/xxenablecpumonitor/#explanation",
"text": "The -XX:+EnableCPUMonitor option enables CPU monitoring, which allows a JMX bean to track CPU usage on a per thread basis and attributes the usage against different categories. For more information, see the JvmCpuMonitorMXBean interface in the com.ibm.lang.management API documentation. To turn off CPU monitoring, set the -XX:-EnableCPUMonitor option on the command line.",
"title": "Explanation"
},
{
"location": "/xxenablecpumonitor/#see-also",
"text": "-XX:[+|-]ReduceCPUMonitorOverhead",
"title": "See also"
},
{
"location": "/xxhandlesigxfsz/",
"text": "-XX:[+|-]handleSIGXFSZ\n\n\n(Linux\u2122 only)\n\n\nThis option affects the handling of the operating system signal \nSIGXFSZ\n. This signal is generated when a process attempts to write to a file that causes the maximum file size \nulimit\n to be exceeded.\n\n\nSyntax\n\n\n -XX:[+|-]handleSIGXFSZ\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:+handleSIGXFSZ\n\n\nEnable\n\n\nyes\n\n\n\n\n\n\n-XX:-handleSIGXFSZ\n\n\nDisable\n\n\n\n\n\n\n\n\n\n\nExplanation\n\n\nWhen enabled, the VM handles the signal \nSIGXFSZ\n and continues, without ending. When a file is written from a Java\u2122 API class that exceeds the maximum file size \nulimit\n, an exception is raised. Log files that are created by the VM are silently truncated when they reach the maximum file size \nulimit\n.\n\n\nWhen the option is disabled, the VM does not handle the signal \nSIGXFSZ\n. In this situation, if the maximum file size \nulimit\n for any file is reached, the operating system ends the process with a core dump.",
"title": "-XX:[+|-]handleSIGXFSZ"
},
{
"location": "/xxhandlesigxfsz/#-xx91-93handlesigxfsz",
"text": "(Linux\u2122 only) This option affects the handling of the operating system signal SIGXFSZ . This signal is generated when a process attempts to write to a file that causes the maximum file size ulimit to be exceeded.",
"title": "-XX:[+|-]handleSIGXFSZ"
},
{
"location": "/xxhandlesigxfsz/#syntax",
"text": "-XX:[+|-]handleSIGXFSZ Setting Effect Default -XX:+handleSIGXFSZ Enable yes -XX:-handleSIGXFSZ Disable",
"title": "Syntax"
},
{
"location": "/xxhandlesigxfsz/#explanation",
"text": "When enabled, the VM handles the signal SIGXFSZ and continues, without ending. When a file is written from a Java\u2122 API class that exceeds the maximum file size ulimit , an exception is raised. Log files that are created by the VM are silently truncated when they reach the maximum file size ulimit . When the option is disabled, the VM does not handle the signal SIGXFSZ . In this situation, if the maximum file size ulimit for any file is reached, the operating system ends the process with a core dump.",
"title": "Explanation"
},
{
"location": "/xxheapdumponoutofmemory/",
"text": "-XX:[+|-]HeapDumpOnOutOfMemory\n\n\nThis Hotspot option is recognized by OpenJ9. You can use the option to to disable Java\u2122, heap, snap, and system dumps on out-of-memory conditions, which are enabled by default. \n\n\nSyntax\n\n\n -XX:[+|-]HeapDumpOnOutOfMemory\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:+HeapDumpOnOutOfMemory\n\n\nEnable\n\n\nyes\n\n\n\n\n\n\n-XX:-HeapDumpOnOutOfMemory\n\n\nDisable",
"title": "-XX:[+|-]HeapDumpOnOutOfMemory"
},
{
"location": "/xxheapdumponoutofmemory/#-xx91-93heapdumponoutofmemory",
"text": "This Hotspot option is recognized by OpenJ9. You can use the option to to disable Java\u2122, heap, snap, and system dumps on out-of-memory conditions, which are enabled by default.",
"title": "-XX:[+|-]HeapDumpOnOutOfMemory"
},
{
"location": "/xxheapdumponoutofmemory/#syntax",
"text": "-XX:[+|-]HeapDumpOnOutOfMemory Setting Effect Default -XX:+HeapDumpOnOutOfMemory Enable yes -XX:-HeapDumpOnOutOfMemory Disable",
"title": "Syntax"
},
{
"location": "/xxheapdumppath/",
"text": "-XX:HeapDumpPath\n\n\n(Linux only)\n\n\nThis Hotspot option is recognized by OpenJ9 for compatibility, and you can use it as an alias for \n-Xdump:directory=<path>\n.\n\n\nThis option sets the directory for all VM dumps including heap dumps, javacores, and system dumps.\n\n\nSyntax\n\n\n -XX:HeapDumpPath=<path>\n\n\n\n\n\nwhere \n<path>\n is the directory to which all dump types are written. This directory path is prefixed to the path of all non-absolute dump file names, including the file names for the default dump agents.",
"title": "-XX:HeapDumpPath"
},
{
"location": "/xxheapdumppath/#-xxheapdumppath",
"text": "(Linux only) This Hotspot option is recognized by OpenJ9 for compatibility, and you can use it as an alias for -Xdump:directory=<path> . This option sets the directory for all VM dumps including heap dumps, javacores, and system dumps.",
"title": "-XX:HeapDumpPath"
},
{
"location": "/xxheapdumppath/#syntax",
"text": "-XX:HeapDumpPath=<path> where <path> is the directory to which all dump types are written. This directory path is prefixed to the path of all non-absolute dump file names, including the file names for the default dump agents.",
"title": "Syntax"
},
{
"location": "/xxheapmanagementmxbeancompatibility/",
"text": "-XX:[+|-]HeapManagementMXBeanCompatibility\n\n\nThe MXBean interface now reports more detailed information about memory pools and garbage collectors for a garbage collection policy. In addition, the names of memory pools and garbage collectors are changed to match the naming convention that is used for verbose garbage collection logging. This option provides compatibility with earlier versions of the VM.\n\n\nSyntax\n\n\n -XX:[+|-]HeapManagementMXBeanCompatibility\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:+HeapManagementMXBeanCompatibility\n\n\nEnable\n\n\n\n\n\n\n\n\n-XX:-HeapManagementMXBeanCompatibility\n\n\nDisable\n\n\nyes\n\n\n\n\n\n\n\n\nSetting \n-XX:+HeapManagementMXBeanCompatibility\n on the command line turns on compatibility with earlier versions of the VM. Information about memory pools and garbage collectors are reported in the older format.\n\n\nWhen compatibility is turned off, the VM reports more detailed information and matches the naming of memory pools and garbage collectors to the naming convention that is used for verbose garbage collection logging.\n\n\nExplanation\n\n\nThe additional information that is available from the MXBean interface for later versions is shown in the following table:\n\n\n\n\n\n\n\n\nGarbage collection policy\n\n\nMemoryPool\n names\n\n\nGarbageCollector\n names\n\n\n\n\n\n\n\n\n\n\ngencon\n\n\nnursery-allocate, nursery-survivor, tenured-LOA, tenured-SOA, tenured\n\n\nscavenge, global\n\n\n\n\n\n\noptthruput\n or \noptavgpause\n\n\ntenured-LOA, tenured-SOA, tenured\n\n\nglobal\n\n\n\n\n\n\nbalanced\n\n\nbalanced-reserved, balanced-eden, balanced-survivor, balanced-old\n\n\npartial gc, global garbage collect\n\n\n\n\n\n\nmetronome\n\n\nJavaHeap\n\n\nglobal\n\n\n\n\n\n\n\n\nThe \nMemoryPoolMXBean\n API reports values for 4 detailed memory pools instead of a single value for the overall Java\u2122 heap. In some cases the total sum of the 4 pools is more than the maximum heap size. This irregularity can be caused if data for each pool is collected between garbage collection cycles, where objects have been moved or reclaimed. If you want to collect memory usage data that is synchronized across the memory pools, use the \nGarbageCollectionNotificationInfo\n or \nGarbageCollectorMXBean.getLastGcInfo\n extensions.\n\n\nEarlier releases included only the following names:\n\n\n\n\nMemoryPool\n pool name: \nJava heap\n\n\nGarbageCollector\n name: \nCopy\n and \nMarkSweepCompact\n.\n\n\n\n\nSee also\n\n\n\n\nVerbose garbage collection logging\n.\n\n\n\n\nFor more information about IBM\u00ae MXBeans, see the \ncom.ibm.lang.management\n API documentation.",
"title": "-XX:[+|-]HeapManagementMXBeanCompatibility"
},
{
"location": "/xxheapmanagementmxbeancompatibility/#-xx91-93heapmanagementmxbeancompatibility",
"text": "The MXBean interface now reports more detailed information about memory pools and garbage collectors for a garbage collection policy. In addition, the names of memory pools and garbage collectors are changed to match the naming convention that is used for verbose garbage collection logging. This option provides compatibility with earlier versions of the VM.",
"title": "-XX:[+|-]HeapManagementMXBeanCompatibility"
},
{
"location": "/xxheapmanagementmxbeancompatibility/#syntax",
"text": "-XX:[+|-]HeapManagementMXBeanCompatibility Setting Effect Default -XX:+HeapManagementMXBeanCompatibility Enable -XX:-HeapManagementMXBeanCompatibility Disable yes Setting -XX:+HeapManagementMXBeanCompatibility on the command line turns on compatibility with earlier versions of the VM. Information about memory pools and garbage collectors are reported in the older format. When compatibility is turned off, the VM reports more detailed information and matches the naming of memory pools and garbage collectors to the naming convention that is used for verbose garbage collection logging.",
"title": "Syntax"
},
{
"location": "/xxheapmanagementmxbeancompatibility/#explanation",
"text": "The additional information that is available from the MXBean interface for later versions is shown in the following table: Garbage collection policy MemoryPool names GarbageCollector names gencon nursery-allocate, nursery-survivor, tenured-LOA, tenured-SOA, tenured scavenge, global optthruput or optavgpause tenured-LOA, tenured-SOA, tenured global balanced balanced-reserved, balanced-eden, balanced-survivor, balanced-old partial gc, global garbage collect metronome JavaHeap global The MemoryPoolMXBean API reports values for 4 detailed memory pools instead of a single value for the overall Java\u2122 heap. In some cases the total sum of the 4 pools is more than the maximum heap size. This irregularity can be caused if data for each pool is collected between garbage collection cycles, where objects have been moved or reclaimed. If you want to collect memory usage data that is synchronized across the memory pools, use the GarbageCollectionNotificationInfo or GarbageCollectorMXBean.getLastGcInfo extensions. Earlier releases included only the following names: MemoryPool pool name: Java heap GarbageCollector name: Copy and MarkSweepCompact .",
"title": "Explanation"
},
{
"location": "/xxheapmanagementmxbeancompatibility/#see-also",
"text": "Verbose garbage collection logging . For more information about IBM\u00ae MXBeans, see the com.ibm.lang.management API documentation.",
"title": "See also"
},
{
"location": "/xxidletuningcompactonidle/",
"text": "-XX:[+|-]IdleTuningCompactOnIdle\n\n\n(Linux\u2122 only)\n\n\nThis option controls garbage collection processing with compaction when the status of the OpenJ9 VM is set to idle.\n\n\n \nRestrictions:\n This option applies only to Linux architectures when the Generational Concurrent (\ngencon\n) garbage collection policy is in use. This option is not effective if the object heap is configured to use large pages.\n\n\nSyntax\n\n\n -XX:[+|-]IdleTuningCompactOnIdle\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:+IdleTuningCompactOnIdle\n\n\nEnable\n\n\n\n\n\n\n\n\n-XX:-IdleTuningCompactOnIdle\n\n\nDisable\n\n\nyes\n\n\n\n\n\n\n\n\nIf you enable this option, the OpenJ9 VM attempts to compact the object heap when the VM status is idle.\n\n\nThe \n-XX:+IdleTuningCompactOnIdle\n option can be used with the \n-XX:+IdleTuningMinIdleWaitTime\n. If a value for the \n-XX:+IdleTuningMinIdleWaitTime\n option is not explicitly specified, the VM sets a default value of 180 seconds. If you want the VM to subsequently attempt to release the free memory pages in the object heap, use the \n-XX:+IdleTuningGcOnIdle\n option.\n\n\nSee also\n\n\n\n\n-XX:IdleTuningMinFreeHeapOnIdle\n\n\n-XX:IdleTuningMinIdleWaitTime\n\n\n-XX:[+|-]IdleTuningGcOnIdle",
"title": "-XX:[+|-]IdleTuningCompactOnIdle"
},
{
"location": "/xxidletuningcompactonidle/#-xx91-93idletuningcompactonidle",
"text": "(Linux\u2122 only) This option controls garbage collection processing with compaction when the status of the OpenJ9 VM is set to idle. Restrictions: This option applies only to Linux architectures when the Generational Concurrent ( gencon ) garbage collection policy is in use. This option is not effective if the object heap is configured to use large pages.",
"title": "-XX:[+|-]IdleTuningCompactOnIdle"
},
{
"location": "/xxidletuningcompactonidle/#syntax",
"text": "-XX:[+|-]IdleTuningCompactOnIdle Setting Effect Default -XX:+IdleTuningCompactOnIdle Enable -XX:-IdleTuningCompactOnIdle Disable yes If you enable this option, the OpenJ9 VM attempts to compact the object heap when the VM status is idle. The -XX:+IdleTuningCompactOnIdle option can be used with the -XX:+IdleTuningMinIdleWaitTime . If a value for the -XX:+IdleTuningMinIdleWaitTime option is not explicitly specified, the VM sets a default value of 180 seconds. If you want the VM to subsequently attempt to release the free memory pages in the object heap, use the -XX:+IdleTuningGcOnIdle option.",
"title": "Syntax"
},
{
"location": "/xxidletuningcompactonidle/#see-also",
"text": "-XX:IdleTuningMinFreeHeapOnIdle -XX:IdleTuningMinIdleWaitTime -XX:[+|-]IdleTuningGcOnIdle",
"title": "See also"
},
{
"location": "/xxidletuninggconidle/",
"text": "-XX:[+|-]IdleTuningGcOnIdle\n\n\n(Linux\u2122 only)\n\n\nThis option can be used to reduce the memory footprint of the OpenJ9 VM when it is in an idle state.\n\n\n \nRestrictions:\n This option applies only to Linux architectures when the Generational Concurrent (\ngencon\n) garbage collection policy is in use. This option is not effective if the object heap is configured to use large pages.\n\n\nSyntax\n\n\n -XX:[+|-]IdleTuningGcOnIdle\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:+IdleTuningGcOnIdle\n\n\nEnable\n\n\n\n\n\n\n\n\n-XX:-IdleTuningGcOnIdle\n\n\nDisable\n\n\nyes\n\n\n\n\n\n\n\n\nWhen the VM enters the idle state, enabling this option causes the VM to release free memory pages in the object heap without resizing the Java\u2122 heap. The pages are reclaimed by the operating system, which reduces the physical memory footprint of the VM.\n\n\nThis option is used with \n-XX:IdleTuningMinIdleWaitTime\n and \n-XX:IdleTuningMinFreeHeapOnIdle\n . If values for these options are not explicitly specified, the VM sets the following defaults:\n\n\n\n\n-XX:IdleTuningMinIdleWaitTime\n=180\n\n\n-XX:IdleTuningMinFreeHeapOnIdle\n=0\n\n\n\n\nIf you want the VM to attempt to compact the object heap before releasing memory, use the\n-XX:+IdleTuningCompactOnIdle\n option.\n\n\nSee also\n\n\n\n\n-XX:IdleTuningMinIdleWaitTime\n\n\n-XX:IdleTuningMinFreeHeapOnIdle\n\n\n-XX:[+|-]IdleTuningCompactOnIdle",
"title": "-XX:[+|-]IdleTuningGcOnIdle"
},
{
"location": "/xxidletuninggconidle/#-xx91-93idletuninggconidle",
"text": "(Linux\u2122 only) This option can be used to reduce the memory footprint of the OpenJ9 VM when it is in an idle state. Restrictions: This option applies only to Linux architectures when the Generational Concurrent ( gencon ) garbage collection policy is in use. This option is not effective if the object heap is configured to use large pages.",
"title": "-XX:[+|-]IdleTuningGcOnIdle"
},
{
"location": "/xxidletuninggconidle/#syntax",
"text": "-XX:[+|-]IdleTuningGcOnIdle Setting Effect Default -XX:+IdleTuningGcOnIdle Enable -XX:-IdleTuningGcOnIdle Disable yes When the VM enters the idle state, enabling this option causes the VM to release free memory pages in the object heap without resizing the Java\u2122 heap. The pages are reclaimed by the operating system, which reduces the physical memory footprint of the VM. This option is used with -XX:IdleTuningMinIdleWaitTime and -XX:IdleTuningMinFreeHeapOnIdle . If values for these options are not explicitly specified, the VM sets the following defaults: -XX:IdleTuningMinIdleWaitTime =180 -XX:IdleTuningMinFreeHeapOnIdle =0 If you want the VM to attempt to compact the object heap before releasing memory, use the -XX:+IdleTuningCompactOnIdle option.",
"title": "Syntax"
},
{
"location": "/xxidletuninggconidle/#see-also",
"text": "-XX:IdleTuningMinIdleWaitTime -XX:IdleTuningMinFreeHeapOnIdle -XX:[+|-]IdleTuningCompactOnIdle",
"title": "See also"
},
{
"location": "/xxidletuningminfreeheaponidle/",
"text": "-XX:IdleTuningMinFreeHeapOnIdle\n\n\n(Linux\u2122 only)\n\n\nThis option controls the percentage of free memory pages in the object heap that can be released when the OpenJ9 VM is in an idle state.\n\n\n \nRestrictions:\n This option applies only to Linux architectures when the Generational Concurrent (\ngencon\n) garbage collection policy is in use. This option is not effective if the object heap is configured to use large pages.\n\n\nSyntax\n\n\n -XX:IdleTuningMinFreeHeapOnIdle=<percentage>\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<percentage>\n\n\n[0 - 100]\n\n\n0\n\n\n\n\n\n\n\n\nWhen used with \n-XX:+IdleTuningGcOnIdle\n, this option can be used to place an upper bound on the percentage of free memory pages in the object heap that can be released when the VM is in an idle state. If \n-XX:IdleTuningMinFreeHeapOnIdle\n is not specified, the VM uses a default value of 0.\n\n\nExample\n\n\nIf you set \n-XX:IdleTuningMinFreeHeapOnIdle=10\n, no more than 90% of the free memory pages in the object heap can be released by the VM when it is in an idle state.\n\n\nSee also\n\n\n\n\n-XX:IdleTuningMinIdleWaitTime\n\n\n-XX:[+|-]IdleTuningCompactOnIdle\n\n\n-XX:[+|-]IdleTuningGcOnIdle",
"title": "-XX:IdleTuningMinFreeHeapOnIdle"
},
{
"location": "/xxidletuningminfreeheaponidle/#-xxidletuningminfreeheaponidle",
"text": "(Linux\u2122 only) This option controls the percentage of free memory pages in the object heap that can be released when the OpenJ9 VM is in an idle state. Restrictions: This option applies only to Linux architectures when the Generational Concurrent ( gencon ) garbage collection policy is in use. This option is not effective if the object heap is configured to use large pages.",
"title": "-XX:IdleTuningMinFreeHeapOnIdle"
},
{
"location": "/xxidletuningminfreeheaponidle/#syntax",
"text": "-XX:IdleTuningMinFreeHeapOnIdle=<percentage> Setting Value Default <percentage> [0 - 100] 0 When used with -XX:+IdleTuningGcOnIdle , this option can be used to place an upper bound on the percentage of free memory pages in the object heap that can be released when the VM is in an idle state. If -XX:IdleTuningMinFreeHeapOnIdle is not specified, the VM uses a default value of 0.",
"title": "Syntax"
},
{
"location": "/xxidletuningminfreeheaponidle/#example",
"text": "If you set -XX:IdleTuningMinFreeHeapOnIdle=10 , no more than 90% of the free memory pages in the object heap can be released by the VM when it is in an idle state.",
"title": "Example"
},
{
"location": "/xxidletuningminfreeheaponidle/#see-also",
"text": "-XX:IdleTuningMinIdleWaitTime -XX:[+|-]IdleTuningCompactOnIdle -XX:[+|-]IdleTuningGcOnIdle",
"title": "See also"
},
{
"location": "/xxidletuningminidlewaittime/",
"text": "-XX:IdleTuningMinIdleWaitTime\n\n\n (Linux\u2122 only) \n\n\nWhen the OpenJ9 VM is idle, this option controls the minimum length of time that the VM must be idle before the status of the VM is set to idle. Further tuning options control the compaction of the object heap and the release of free memory pages, which reduces the footprint of the VM.\n\n\n \nRestrictions:\n This option applies only to Linux architectures when the Generational Concurrent (\ngencon\n) garbage collection policy is in use. This option is not effective if the object heap is configured to use large pages.\n\n\nSyntax\n\n\n -XX:IdleTuningMinIdleWaitTime=<secs>\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<secs>\n\n\n[0 or greater]\n\n\n0\n\n\n\n\n\n\n\n\nThe value used for \n<secs>\n specifies the minimum length of time in seconds that the VM is idle before the state is set to idle. Setting the value to 0 disables this feature, which causes the following idle tuning options to have no effect:\n\n\n\n\n-XX:+IdleTuningCompactOnIdle\n\n\n-XX:+IdleTuningGcOnIdle\n\n\n-XX:IdleTuningMinFreeHeapOnIdle\n\n\n\n\nSee also\n\n\n\n\n-XX:[+|-]IdleTuningCompactOnIdle\n\n\n-XX:[+|-]IdleTuningGcOnIdle\n\n\n-XX:IdleTuningMinFreeHeapOnIdle",
"title": "-XX:IdleTuningMinIdleWaitTime"
},
{
"location": "/xxidletuningminidlewaittime/#-xxidletuningminidlewaittime",
"text": "(Linux\u2122 only) When the OpenJ9 VM is idle, this option controls the minimum length of time that the VM must be idle before the status of the VM is set to idle. Further tuning options control the compaction of the object heap and the release of free memory pages, which reduces the footprint of the VM. Restrictions: This option applies only to Linux architectures when the Generational Concurrent ( gencon ) garbage collection policy is in use. This option is not effective if the object heap is configured to use large pages.",
"title": "-XX:IdleTuningMinIdleWaitTime"
},
{
"location": "/xxidletuningminidlewaittime/#syntax",
"text": "-XX:IdleTuningMinIdleWaitTime=<secs> Setting Value Default <secs> [0 or greater] 0 The value used for <secs> specifies the minimum length of time in seconds that the VM is idle before the state is set to idle. Setting the value to 0 disables this feature, which causes the following idle tuning options to have no effect: -XX:+IdleTuningCompactOnIdle -XX:+IdleTuningGcOnIdle -XX:IdleTuningMinFreeHeapOnIdle",
"title": "Syntax"
},
{
"location": "/xxidletuningminidlewaittime/#see-also",
"text": "-XX:[+|-]IdleTuningCompactOnIdle -XX:[+|-]IdleTuningGcOnIdle -XX:IdleTuningMinFreeHeapOnIdle",
"title": "See also"
},
{
"location": "/xxignoreunrecognizedvmoptions/",
"text": "-XX:[+|-]IgnoreUnrecognizedVMOptions\n\n\nThis Oracle option affects the behavior of the Hotspot JVM when it finds an unrecognized top-level option at startup. This option is implemented in the OpenJ9 VM for compatibility.\n\n\nSyntax\n\n\n -XX:[+|-]IgnoreUnrecognizedVMOptions\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:+IgnoreUnrecognizedVMOptions\n\n\nEnable\n\n\n\n\n\n\n\n\n-XX:-IgnoreUnrecognizedVMOptions\n\n\nDisable\n\n\nyes",
"title": "-XX:[+|-]IgnoreUnrecognizedVMOptions"
},
{
"location": "/xxignoreunrecognizedvmoptions/#-xx91-93ignoreunrecognizedvmoptions",
"text": "This Oracle option affects the behavior of the Hotspot JVM when it finds an unrecognized top-level option at startup. This option is implemented in the OpenJ9 VM for compatibility.",
"title": "-XX:[+|-]IgnoreUnrecognizedVMOptions"
},
{
"location": "/xxignoreunrecognizedvmoptions/#syntax",
"text": "-XX:[+|-]IgnoreUnrecognizedVMOptions Setting Effect Default -XX:+IgnoreUnrecognizedVMOptions Enable -XX:-IgnoreUnrecognizedVMOptions Disable yes",
"title": "Syntax"
},
{
"location": "/xxinitialrampercentage/",
"text": "-XX:InitialRAMPercentage\n\n\nThis Oracle Hotspot option can be used to specify the initial size of the Java heap as a percentage of the total memory available to the VM. The option is recognized by the OpenJ9 VM and is provided for compatibility.\n\n\nSyntax\n\n\n -XX:InitialRAMPercentage=N\n\n\n\n\n\n\n\nWhere N is a value between 0 and 100, which can by of type \"double\". For example, 12.3456.\n\n\n\n\n \nNote:\n If you set a value for \n-Xms\n, this option is ignored.\n\n\nIf your application is running in a container and you have specified \n-XX:+UseContainerSupport\n, both the default heap size for containers and the \n-XX:InitialRAMPercentage\n option are based on the available container memory.",
"title": "-XX:InitialRAMPercentage"
},
{
"location": "/xxinitialrampercentage/#-xxinitialrampercentage",
"text": "This Oracle Hotspot option can be used to specify the initial size of the Java heap as a percentage of the total memory available to the VM. The option is recognized by the OpenJ9 VM and is provided for compatibility.",
"title": "-XX:InitialRAMPercentage"
},
{
"location": "/xxinitialrampercentage/#syntax",
"text": "-XX:InitialRAMPercentage=N Where N is a value between 0 and 100, which can by of type \"double\". For example, 12.3456. Note: If you set a value for -Xms , this option is ignored. If your application is running in a container and you have specified -XX:+UseContainerSupport , both the default heap size for containers and the -XX:InitialRAMPercentage option are based on the available container memory.",
"title": "Syntax"
},
{
"location": "/xxinitialheapsize/",
"text": "-XX:InitialHeapSize / -XX:MaxHeapSize\n\n\nThese Hotspot options for specifying heap size are recognized by OpenJ9 for compatibility. See \n-Xms / -Xmx\n for details.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\n\n\n\n\n\n\n\n\n-XX:InitialHeapSize<size>\n\n\nSet initial heap size\n\n\n\n\n\n\n-XX:MaxHeapSize<size>\n\n\nSet maximum heap size",
"title": "-XX:InitialHeapSize"
},
{
"location": "/xxinitialheapsize/#-xxinitialheapsize-xxmaxheapsize",
"text": "These Hotspot options for specifying heap size are recognized by OpenJ9 for compatibility. See -Xms / -Xmx for details.",
"title": "-XX:InitialHeapSize / -XX:MaxHeapSize"
},
{
"location": "/xxinitialheapsize/#syntax",
"text": "Setting Effect -XX:InitialHeapSize<size> Set initial heap size -XX:MaxHeapSize<size> Set maximum heap size",
"title": "Syntax"
},
{
"location": "/xxinterleavememory/",
"text": "-XX:[+|-]InterleaveMemory\n\n\n(AIX\u00ae, Linux\u2122, and Windows\u2122 only, but not Linux on IBM Z\u00ae)\n\n\nUse the \n-XX:+InterleaveMemory\n option to enable the interleaving of allocated memory across NUMA nodes.\n\n\nSyntax\n\n\n -XX:[+|-]InterleaveMemory\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:+InterleaveMemory\n\n\nEnable\n\n\n\n\n\n\n\n\n-XX:-InterleaveMemory\n\n\nDisable\n\n\nyes",
"title": "-XX:[+|-]InterleaveMemory"
},
{
"location": "/xxinterleavememory/#-xx91-93interleavememory",
"text": "(AIX\u00ae, Linux\u2122, and Windows\u2122 only, but not Linux on IBM Z\u00ae) Use the -XX:+InterleaveMemory option to enable the interleaving of allocated memory across NUMA nodes.",
"title": "-XX:[+|-]InterleaveMemory"
},
{
"location": "/xxinterleavememory/#syntax",
"text": "-XX:[+|-]InterleaveMemory Setting Effect Default -XX:+InterleaveMemory Enable -XX:-InterleaveMemory Disable yes",
"title": "Syntax"
},
{
"location": "/xxlazysymbolresolution/",
"text": "-XX:[+|-]LazySymbolResolution\n\n\n(Linux\u2122 only)\n\n\nThis option affects the timing of symbol resolution for functions in user native libraries.\n\n\nSyntax\n\n\n -XX:[+|-]LazySymbolResolution\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:+LazySymbolResolution\n\n\nEnable\n\n\nyes\n\n\n\n\n\n\n-XX:-LazySymbolResolution\n\n\nDisable\n\n\n\n\n\n\n\n\n\n\nExplanation\n\n\nEnabling this option forces the VM to delay symbol resolution for each function in a user native library, until the function is called.\nThe \n-XX:-LazySymbolResolution\n option forces the VM to immediately resolve symbols for all functions in a user native library when the library is loaded.\n\n\nThese options apply only to functions; variable symbols are always resolved immediately when loaded. If you attempt to use these options on an operating system other than Linux, the options are accepted, but ignored.",
"title": "-XX:[+|-]LazySymbolResolution"
},
{
"location": "/xxlazysymbolresolution/#-xx91-93lazysymbolresolution",
"text": "(Linux\u2122 only) This option affects the timing of symbol resolution for functions in user native libraries.",
"title": "-XX:[+|-]LazySymbolResolution"
},
{
"location": "/xxlazysymbolresolution/#syntax",
"text": "-XX:[+|-]LazySymbolResolution Setting Effect Default -XX:+LazySymbolResolution Enable yes -XX:-LazySymbolResolution Disable",
"title": "Syntax"
},
{
"location": "/xxlazysymbolresolution/#explanation",
"text": "Enabling this option forces the VM to delay symbol resolution for each function in a user native library, until the function is called.\nThe -XX:-LazySymbolResolution option forces the VM to immediately resolve symbols for all functions in a user native library when the library is loaded. These options apply only to functions; variable symbols are always resolved immediately when loaded. If you attempt to use these options on an operating system other than Linux, the options are accepted, but ignored.",
"title": "Explanation"
},
{
"location": "/xxmaxdirectmemorysize/",
"text": "-XX:MaxDirectMemorySize\n\n\nThis Oracle Hotspot option sets a limit on the amount of memory that can be reserved for all Direct Byte Buffers.\n\n\nSyntax\n\n\n-XX:MaxDirectMemorySize<size>\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<size>\n\n\n[1[k|K|m|M|g|G] or greater]\n\n\nDepends on maximum heap size\n\n\n\n\n\n\n\n\nThe value you choose is the limit on memory that can be reserved for all Direct Byte Buffers. If a value is set for this option, the sum of all Direct Byte Buffer sizes cannot exceed the limit. After the limit is reached, a new Direct Byte Buffer can be allocated only when enough old buffers are freed to provide enough space to allocate the new buffer.\n\n\nBy default, the VM limits the amount of heap memory used for Direct Byte Buffers to approximately 85% of the maximum heap size.",
"title": "-XX:MaxDirectMemorySize"
},
{
"location": "/xxmaxdirectmemorysize/#-xxmaxdirectmemorysize",
"text": "This Oracle Hotspot option sets a limit on the amount of memory that can be reserved for all Direct Byte Buffers.",
"title": "-XX:MaxDirectMemorySize"
},
{
"location": "/xxmaxdirectmemorysize/#syntax",
"text": "-XX:MaxDirectMemorySize<size> Setting Value Default <size> [1[k|K|m|M|g|G] or greater] Depends on maximum heap size The value you choose is the limit on memory that can be reserved for all Direct Byte Buffers. If a value is set for this option, the sum of all Direct Byte Buffer sizes cannot exceed the limit. After the limit is reached, a new Direct Byte Buffer can be allocated only when enough old buffers are freed to provide enough space to allocate the new buffer. By default, the VM limits the amount of heap memory used for Direct Byte Buffers to approximately 85% of the maximum heap size.",
"title": "Syntax"
},
{
"location": "/xxinitialheapsize/",
"text": "-XX:InitialHeapSize / -XX:MaxHeapSize\n\n\nThese Hotspot options for specifying heap size are recognized by OpenJ9 for compatibility. See \n-Xms / -Xmx\n for details.\n\n\nSyntax\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\n\n\n\n\n\n\n\n\n-XX:InitialHeapSize<size>\n\n\nSet initial heap size\n\n\n\n\n\n\n-XX:MaxHeapSize<size>\n\n\nSet maximum heap size",
"title": "-XX:MaxHeapSize"
},
{
"location": "/xxinitialheapsize/#-xxinitialheapsize-xxmaxheapsize",
"text": "These Hotspot options for specifying heap size are recognized by OpenJ9 for compatibility. See -Xms / -Xmx for details.",
"title": "-XX:InitialHeapSize / -XX:MaxHeapSize"
},
{
"location": "/xxinitialheapsize/#syntax",
"text": "Setting Effect -XX:InitialHeapSize<size> Set initial heap size -XX:MaxHeapSize<size> Set maximum heap size",
"title": "Syntax"
},
{
"location": "/xxmaxrampercentage/",
"text": "-XX:MaxRAMPercentage\n\n\nThis Oracle Hotspot option can be used to specify the maximum Java heap size as a percentage of the total memory available to the VM. The option is recognized by the OpenJ9 VM and is provided for compatibility.\n\n\nSyntax\n\n\n -XX:MaxRAMPercentage=N\n\n\n\n\n\n\n\nWhere N is a value between 0 and 100, which can by of type \"double\". For example, 12.3456.\n\n\n\n\n \nNote:\n If you set a value for \n-Xmx\n, this option is ignored.\n\n\nIf your application is running in a container and you have specified \n-XX:+UseContainerSupport\n, both the default heap size for containers and the \n-XX:MaxRAMPercentage\n option are based on the available container memory.",
"title": "-XX:MaxRAMPercentage"
},
{
"location": "/xxmaxrampercentage/#-xxmaxrampercentage",
"text": "This Oracle Hotspot option can be used to specify the maximum Java heap size as a percentage of the total memory available to the VM. The option is recognized by the OpenJ9 VM and is provided for compatibility.",
"title": "-XX:MaxRAMPercentage"
},
{
"location": "/xxmaxrampercentage/#syntax",
"text": "-XX:MaxRAMPercentage=N Where N is a value between 0 and 100, which can by of type \"double\". For example, 12.3456. Note: If you set a value for -Xmx , this option is ignored. If your application is running in a container and you have specified -XX:+UseContainerSupport , both the default heap size for containers and the -XX:MaxRAMPercentage option are based on the available container memory.",
"title": "Syntax"
},
{
"location": "/xxnosuballoc32bitmem/",
"text": "-XXnosuballoc32bitmem\n\n\n(z/OS\u00ae only)\n\n\nWhen compressed references are used with a 64-bit OpenJ9 VM on z/OS\u00ae, this option forces the VM to use 31-bit memory allocation functions provided by z/OS.\n\n\nSyntax\n\n\n -XXnosuballoc32bitmem\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XXnosuballoc32bitmem\n\n\nEnable\n\n\n\n\n\n\n\n\nNo setting\n\n\nDisable\n\n\nyes\n\n\n\n\n\n\n\n\nExplanation\n\n\nThis option is provided as a workaround for customers who need to use fewer pages of 31-bit virtual storage per VM invocation. Using this option might result in a small increase in the number of frames of central storage used by the VM. However, the option frees 31-bit pages for use by native code or other applications in the same address space.\n\n\nIf this option is not specified, the VM uses an allocation strategy for 31-bit memory that reserves a region of 31-bit virtual memory.",
"title": "-XXnosuballoc32bitmem"
},
{
"location": "/xxnosuballoc32bitmem/#-xxnosuballoc32bitmem",
"text": "(z/OS\u00ae only) When compressed references are used with a 64-bit OpenJ9 VM on z/OS\u00ae, this option forces the VM to use 31-bit memory allocation functions provided by z/OS.",
"title": "-XXnosuballoc32bitmem"
},
{
"location": "/xxnosuballoc32bitmem/#syntax",
"text": "-XXnosuballoc32bitmem Setting Effect Default -XXnosuballoc32bitmem Enable No setting Disable yes",
"title": "Syntax"
},
{
"location": "/xxnosuballoc32bitmem/#explanation",
"text": "This option is provided as a workaround for customers who need to use fewer pages of 31-bit virtual storage per VM invocation. Using this option might result in a small increase in the number of frames of central storage used by the VM. However, the option frees 31-bit pages for use by native code or other applications in the same address space. If this option is not specified, the VM uses an allocation strategy for 31-bit memory that reserves a region of 31-bit virtual memory.",
"title": "Explanation"
},
{
"location": "/xxpagealigndirectmemory/",
"text": "-XX:[+|-]PageAlignDirectMemory\n\n\nThis Oracle Hotspot option affects the alignment of direct byte buffer allocation and is implemented by the OpenJ9 VM for compatibility.\n\n\nSyntax\n\n\n -XX:[+|-]PageAlignDirectMemory\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:+PageAlignDirectMemory\n\n\nEnable\n\n\n\n\n\n\n\n\n-XX:-PageAlignDirectMemory\n\n\nDisable\n\n\nyes\n\n\n\n\n\n\n\n\nAs discussed in the Oracle documentation, before Java\u2122 SE 7, direct buffers that were allocated using \njava.nio.ByteBuffer.allocateDirect(int)\n were aligned on a page boundary. This behavior changed in Java SE 7 and the \n-XX:+PageAlignDirectMemory\n option is provided to revert to the previous behavior.\n\n\nFor more information about the changes, see \nRFE 4837564\n, which was introduced in the \nJava SE 7 release notes\n.",
"title": "-XX:[+|-]PageAlignDirectMemory"
},
{
"location": "/xxpagealigndirectmemory/#-xx91-93pagealigndirectmemory",
"text": "This Oracle Hotspot option affects the alignment of direct byte buffer allocation and is implemented by the OpenJ9 VM for compatibility.",
"title": "-XX:[+|-]PageAlignDirectMemory"
},
{
"location": "/xxpagealigndirectmemory/#syntax",
"text": "-XX:[+|-]PageAlignDirectMemory Setting Effect Default -XX:+PageAlignDirectMemory Enable -XX:-PageAlignDirectMemory Disable yes As discussed in the Oracle documentation, before Java\u2122 SE 7, direct buffers that were allocated using java.nio.ByteBuffer.allocateDirect(int) were aligned on a page boundary. This behavior changed in Java SE 7 and the -XX:+PageAlignDirectMemory option is provided to revert to the previous behavior. For more information about the changes, see RFE 4837564 , which was introduced in the Java SE 7 release notes .",
"title": "Syntax"
},
{
"location": "/xxreducecpumonitoroverhead/",
"text": "-XX:[+|-]ReduceCPUMonitorOverhead\n\n\n(AIX\u00ae, Linux\u2122, and Windows\u2122 only)\n\n\nThis option relates to the CPU usage of thread categories that can be obtained with the \ncom.ibm.lang.management.JvmCpuMonitorMXBean\n application programming interface. This option affects the way that the VM records the amount of CPU usage of non-Garbage Collection (GC) threads that do work on behalf of GC.\n\n\nMost GC policies require non-GC threads to do some GC housekeeping work in proportion to the amount of memory allocation that they do. Ideally the exact amount of CPU time that the thread spends doing this housekeeping work should be accounted for in the GC thread category. However there is an overhead that is associated with maintaining the CPU usage data in the correct thread category.\n\n\n \nRestriction:\n This option is not supported on z/OS\u00ae. If you attempt to use this option, the following message is generated:\n\n\nJVMJ9VM145E\n \n-\nXX\n:-\nReduceCPUMonitorOverhead\n \nis\n \nunsupported\n \non\n \nz\n/\nOS\n.\n \nError\n:\n \nCould\n \nnot\n \ncreate\n \nthe\n \nJava\n \nVirtual\n \nMachine\n.\n\n\n\n\n\n\nSyntax\n\n\n-XX:[+|-]ReduceCPUMonitorOverhead\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:+ReduceCPUMonitorOverhead\n\n\nEnable\n\n\nyes\n\n\n\n\n\n\n-XX:-ReduceCPUMonitorOverhead\n\n\nDisable\n\n\n\n\n\n\n\n\n\n\nWhen you enable this option, the VM does not maintain information on the amount of CPU usage that non-GC threads spend in doing work on behalf of GC.\nIf you set \n-XX:-ReduceCPUMonitorOverhead\n, the OpenJ9 VM monitors the amount of GC work that a non-GC thread does and accounts for it in the GC category. This information is made available in the \ncom.ibm.lang.management.JvmCpuMonitorMXBean\n. Setting this option results in a small increase in application startup time, which varies according to platform.\n\n\nSee also\n\n\n\n\n-XX:[+|-]EnableCPUMonitor",
"title": "-XX:[+|-]ReduceCPUMonitorOverhead"
},
{
"location": "/xxreducecpumonitoroverhead/#-xx91-93reducecpumonitoroverhead",
"text": "(AIX\u00ae, Linux\u2122, and Windows\u2122 only) This option relates to the CPU usage of thread categories that can be obtained with the com.ibm.lang.management.JvmCpuMonitorMXBean application programming interface. This option affects the way that the VM records the amount of CPU usage of non-Garbage Collection (GC) threads that do work on behalf of GC. Most GC policies require non-GC threads to do some GC housekeeping work in proportion to the amount of memory allocation that they do. Ideally the exact amount of CPU time that the thread spends doing this housekeeping work should be accounted for in the GC thread category. However there is an overhead that is associated with maintaining the CPU usage data in the correct thread category. Restriction: This option is not supported on z/OS\u00ae. If you attempt to use this option, the following message is generated: JVMJ9VM145E - XX :- ReduceCPUMonitorOverhead is unsupported on z / OS . Error : Could not create the Java Virtual Machine .",
"title": "-XX:[+|-]ReduceCPUMonitorOverhead"
},
{
"location": "/xxreducecpumonitoroverhead/#syntax",
"text": "-XX:[+|-]ReduceCPUMonitorOverhead Setting Effect Default -XX:+ReduceCPUMonitorOverhead Enable yes -XX:-ReduceCPUMonitorOverhead Disable When you enable this option, the VM does not maintain information on the amount of CPU usage that non-GC threads spend in doing work on behalf of GC.\nIf you set -XX:-ReduceCPUMonitorOverhead , the OpenJ9 VM monitors the amount of GC work that a non-GC thread does and accounts for it in the GC category. This information is made available in the com.ibm.lang.management.JvmCpuMonitorMXBean . Setting this option results in a small increase in application startup time, which varies according to platform.",
"title": "Syntax"
},
{
"location": "/xxreducecpumonitoroverhead/#see-also",
"text": "-XX:[+|-]EnableCPUMonitor",
"title": "See also"
},
{
"location": "/xxruntimeinstrumentation/",
"text": "-XX:[+|-]RuntimeInstrumentation\n\n\n(AIX\u00ae, Linux\u2122, and z/OS\u00ae only)\n\n\nThis option controls the use of the Runtime Instrumentation (RI) facility in the virtual machines that support it.\n\n\nThe RI facility is a feature that is available in POWER8\u00ae, zEC12, and later processors that offers hardware support for collecting profiling information at run time. The process uses minimal resources. The use of the RI facility is not enabled by default.\n\n\nSyntax\n\n\n -XX:[+|-]RuntimeInstrumentation\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:+RuntimeInstrumentation\n\n\nEnable\n\n\n\n\n\n\n\n\n-XX:-RuntimeInstrumentation\n\n\nDisable\n\n\nyes\n\n\n\n\n\n\n\n\n \nNote:\n On Linux, the RI facility on Power 8 and later processors uses the Performance Monitoring Unit (PMU) inside the processor. However, the PMU is also used by system profilers like \noprofile\n or \nperf\n. Due to the current Linux kernel implementation, a user cannot reliably profile a Java\u2122 application when RI is enabled. Although this limitation might be addressed in future Linux kernels, for reliable profiling on Power systems that use Linux, the \n-XX:-RuntimeInstrumentation\n option must be used.",
"title": "-XX:[+|-]RuntimeInstrumentation"
},
{
"location": "/xxruntimeinstrumentation/#-xx91-93runtimeinstrumentation",
"text": "(AIX\u00ae, Linux\u2122, and z/OS\u00ae only) This option controls the use of the Runtime Instrumentation (RI) facility in the virtual machines that support it. The RI facility is a feature that is available in POWER8\u00ae, zEC12, and later processors that offers hardware support for collecting profiling information at run time. The process uses minimal resources. The use of the RI facility is not enabled by default.",
"title": "-XX:[+|-]RuntimeInstrumentation"
},
{
"location": "/xxruntimeinstrumentation/#syntax",
"text": "-XX:[+|-]RuntimeInstrumentation Setting Effect Default -XX:+RuntimeInstrumentation Enable -XX:-RuntimeInstrumentation Disable yes Note: On Linux, the RI facility on Power 8 and later processors uses the Performance Monitoring Unit (PMU) inside the processor. However, the PMU is also used by system profilers like oprofile or perf . Due to the current Linux kernel implementation, a user cannot reliably profile a Java\u2122 application when RI is enabled. Although this limitation might be addressed in future Linux kernels, for reliable profiling on Power systems that use Linux, the -XX:-RuntimeInstrumentation option must be used.",
"title": "Syntax"
},
{
"location": "/xxsethwprefetch/",
"text": "-XXsetHWPrefetch\n\n\n(AIX\u00ae only)\n\n\nThis option enables or disables hardware prefetch. Hardware prefetch can improve the performance of applications by prefetching memory. However, because of the workload characteristics of many Java\u2122 applications, prefetching often has an adverse effect on performance.\n\n\nSyntax\n\n\n -XXsetHWPrefetch=[none|os-default]\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\nnone\n\n\nDisable\n\n\nyes\n\n\n\n\n\n\nos-default\n\n\nEnable\n\n\n\n\n\n\n\n\n\n\nThe \n-XXsetHWPrefetch:none\n option disables hardware prefetch. Although you can disable hardware prefetch on AIX by issuing the command \ndscrctl -n -s 1\n, this command disables hardware prefetch for all processes, and for all future processes, which might not be desirable in a mixed workload environment. The \n-XXsetHWPrefetch:none\n option allows hardware prefetch to be disabled for individual VMs.\n\n\nTo enable hardware prefetch with the default value for the operating system, specify \n-XXsetHWPrefetch:os-default\n. Use this option only for applications that can obtain a performance gain from hardware prefetch.",
"title": "-XXsetHWPrefetch"
},
{
"location": "/xxsethwprefetch/#-xxsethwprefetch",
"text": "(AIX\u00ae only) This option enables or disables hardware prefetch. Hardware prefetch can improve the performance of applications by prefetching memory. However, because of the workload characteristics of many Java\u2122 applications, prefetching often has an adverse effect on performance.",
"title": "-XXsetHWPrefetch"
},
{
"location": "/xxsethwprefetch/#syntax",
"text": "-XXsetHWPrefetch=[none|os-default] Setting Effect Default none Disable yes os-default Enable The -XXsetHWPrefetch:none option disables hardware prefetch. Although you can disable hardware prefetch on AIX by issuing the command dscrctl -n -s 1 , this command disables hardware prefetch for all processes, and for all future processes, which might not be desirable in a mixed workload environment. The -XXsetHWPrefetch:none option allows hardware prefetch to be disabled for individual VMs. To enable hardware prefetch with the default value for the operating system, specify -XXsetHWPrefetch:os-default . Use this option only for applications that can obtain a performance gain from hardware prefetch.",
"title": "Syntax"
},
{
"location": "/xxshareclassesenablebci/",
"text": "-XX:ShareClassesDisableBCI / \n -XX:ShareClassesEnableBCI\n\n\nThe option \n-Xshareclasses:enableBCI\n improves startup performance without using a modification context, when using JVMTI class modification. This suboption allows classes loaded from the shared cache to be modified using a JVMTI \nClassFileLoadHook\n, or a \njava.lang.instrument\n agent, and prevents modified classes being stored in the shared classes cache. You can turn off this option by specifying \n-XX:ShareClassesDisableBCI\n when you start your Java\u2122 application.\n\n\nSyntax\n\n\n -XX:ShareClassesDisableBCI|ShareClassesEnableBCI\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:ShareClassesDisableBCI\n\n\nDisable\n\n\n\n\n\n\n\n\n-XX:ShareClassesEnableBCI\n\n\nEnable\n\n\nyes\n\n\n\n\n\n\n\n\nThese options are equivalent to \n-Xshareclasses:disableBCI\n and \n-Xshareclasses:enableBCI\n. For more information, see \n-Xshareclasses\n.\n\n\nSee also\n\n\n\n\nRuntime bytecode modification",
"title": "-XX:ShareClassesDisableBCI"
},
{
"location": "/xxshareclassesenablebci/#-xxshareclassesdisablebci-xxshareclassesenablebci",
"text": "The option -Xshareclasses:enableBCI improves startup performance without using a modification context, when using JVMTI class modification. This suboption allows classes loaded from the shared cache to be modified using a JVMTI ClassFileLoadHook , or a java.lang.instrument agent, and prevents modified classes being stored in the shared classes cache. You can turn off this option by specifying -XX:ShareClassesDisableBCI when you start your Java\u2122 application.",
"title": "-XX:ShareClassesDisableBCI / -XX:ShareClassesEnableBCI"
},
{
"location": "/xxshareclassesenablebci/#syntax",
"text": "-XX:ShareClassesDisableBCI|ShareClassesEnableBCI Setting Effect Default -XX:ShareClassesDisableBCI Disable -XX:ShareClassesEnableBCI Enable yes These options are equivalent to -Xshareclasses:disableBCI and -Xshareclasses:enableBCI . For more information, see -Xshareclasses .",
"title": "Syntax"
},
{
"location": "/xxshareclassesenablebci/#see-also",
"text": "Runtime bytecode modification",
"title": "See also"
},
{
"location": "/xxshareclassesenablebci/",
"text": "-XX:ShareClassesDisableBCI / \n -XX:ShareClassesEnableBCI\n\n\nThe option \n-Xshareclasses:enableBCI\n improves startup performance without using a modification context, when using JVMTI class modification. This suboption allows classes loaded from the shared cache to be modified using a JVMTI \nClassFileLoadHook\n, or a \njava.lang.instrument\n agent, and prevents modified classes being stored in the shared classes cache. You can turn off this option by specifying \n-XX:ShareClassesDisableBCI\n when you start your Java\u2122 application.\n\n\nSyntax\n\n\n -XX:ShareClassesDisableBCI|ShareClassesEnableBCI\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:ShareClassesDisableBCI\n\n\nDisable\n\n\n\n\n\n\n\n\n-XX:ShareClassesEnableBCI\n\n\nEnable\n\n\nyes\n\n\n\n\n\n\n\n\nThese options are equivalent to \n-Xshareclasses:disableBCI\n and \n-Xshareclasses:enableBCI\n. For more information, see \n-Xshareclasses\n.\n\n\nSee also\n\n\n\n\nRuntime bytecode modification",
"title": "-XX:ShareClassesEnableBCI"
},
{
"location": "/xxshareclassesenablebci/#-xxshareclassesdisablebci-xxshareclassesenablebci",
"text": "The option -Xshareclasses:enableBCI improves startup performance without using a modification context, when using JVMTI class modification. This suboption allows classes loaded from the shared cache to be modified using a JVMTI ClassFileLoadHook , or a java.lang.instrument agent, and prevents modified classes being stored in the shared classes cache. You can turn off this option by specifying -XX:ShareClassesDisableBCI when you start your Java\u2122 application.",
"title": "-XX:ShareClassesDisableBCI / -XX:ShareClassesEnableBCI"
},
{
"location": "/xxshareclassesenablebci/#syntax",
"text": "-XX:ShareClassesDisableBCI|ShareClassesEnableBCI Setting Effect Default -XX:ShareClassesDisableBCI Disable -XX:ShareClassesEnableBCI Enable yes These options are equivalent to -Xshareclasses:disableBCI and -Xshareclasses:enableBCI . For more information, see -Xshareclasses .",
"title": "Syntax"
},
{
"location": "/xxshareclassesenablebci/#see-also",
"text": "Runtime bytecode modification",
"title": "See also"
},
{
"location": "/xxsharedcachehardlimit/",
"text": "-XX:SharedCacheHardLimit\n\n\nSpecifies the size for a new shared class cache. Use this option together with the \n-Xscmx\n option to set actual and soft maximum size limits respectively.\n\n\nSyntax\n\n\n -XX:SharedCacheHardLimit=<size>\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<size>\n\n\n[1[k|K|m|M|g|G] or greater]\n\n\n\n\n\n\n\n\n\n\nSee \nUsing -X command-line options\n for more information about the \n<size>\n parameter.\n\n\nWhen you use this option with the \n-Xscmx\n option, the \n-Xscmx\n option sets the soft maximum size, and the \n-XX:SharedCacheHardLimit\n option sets the actual size, of a new shared class cache. For more information, see \n-Xscmx\n.\n\n\nIf you use this option without the \n-Xscmx\n option, the behavior is the same as using the \n-Xscmx\n option by itself; both options set the actual size of the shared class cache.\n\n\nFor more information about cache sizes, see \nCache size limits\n.\n\n\nExample\n\n\nThe following settings, when used together, set the soft maximum size of the shared classes cache to 16 MB and the actual maximum cache size to 64 MB.\n\n\n-XX:SharedCacheHardLimit=64m -Xscmx16m\n\n\n\n\n\nSee also\n\n\n\n\n-Xscmx",
"title": "-XX:SharedCacheHardLimit"
},
{
"location": "/xxsharedcachehardlimit/#-xxsharedcachehardlimit",
"text": "Specifies the size for a new shared class cache. Use this option together with the -Xscmx option to set actual and soft maximum size limits respectively.",
"title": "-XX:SharedCacheHardLimit"
},
{
"location": "/xxsharedcachehardlimit/#syntax",
"text": "-XX:SharedCacheHardLimit=<size> Setting Value Default <size> [1[k|K|m|M|g|G] or greater] See Using -X command-line options for more information about the <size> parameter. When you use this option with the -Xscmx option, the -Xscmx option sets the soft maximum size, and the -XX:SharedCacheHardLimit option sets the actual size, of a new shared class cache. For more information, see -Xscmx . If you use this option without the -Xscmx option, the behavior is the same as using the -Xscmx option by itself; both options set the actual size of the shared class cache. For more information about cache sizes, see Cache size limits .",
"title": "Syntax"
},
{
"location": "/xxsharedcachehardlimit/#example",
"text": "The following settings, when used together, set the soft maximum size of the shared classes cache to 16 MB and the actual maximum cache size to 64 MB. -XX:SharedCacheHardLimit=64m -Xscmx16m",
"title": "Example"
},
{
"location": "/xxsharedcachehardlimit/#see-also",
"text": "-Xscmx",
"title": "See also"
},
{
"location": "/xxstacktraceinthrowable/",
"text": "-XX:-StackTraceInThrowable\n\n\nThis option removes stack traces from exceptions.\n\n\nSyntax\n\n\n \n-\nXX\n:-\nStackTraceInThrowable\n\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:-StackTraceInThrowable\n\n\nDisable\n\n\nNo\n\n\n\n\n\n\n\n\n\n\n\n\nWhile stack traces are included in exceptions by default, recording them can have a negative impact on performance. Use this option if you want to remove stack traces, although this might cause difficulties with problem determination.\n\n\nWhen this option is enabled, \nThrowable.getStackTrace()\n returns an empty array and the stack trace is displayed when an uncaught exception occurs. \nThread.getStackTrace()\n and \nThread.getAllStackTraces()\n are not affected by this option.",
"title": "-XX:-StackTraceInThrowable"
},
{
"location": "/xxstacktraceinthrowable/#-xx-stacktraceinthrowable",
"text": "This option removes stack traces from exceptions.",
"title": "-XX:-StackTraceInThrowable"
},
{
"location": "/xxstacktraceinthrowable/#syntax",
"text": "- XX :- StackTraceInThrowable Setting Effect Default -XX:-StackTraceInThrowable Disable No While stack traces are included in exceptions by default, recording them can have a negative impact on performance. Use this option if you want to remove stack traces, although this might cause difficulties with problem determination. When this option is enabled, Throwable.getStackTrace() returns an empty array and the stack trace is displayed when an uncaught exception occurs. Thread.getStackTrace() and Thread.getAllStackTraces() are not affected by this option.",
"title": "Syntax"
},
{
"location": "/xxthreadstacksize/",
"text": "-XX:ThreadStackSize\n\n\nThis Hotspot option to set the maximum Java thread stack size is recognized by OpenJ9 for compatibility. See \n-Xss\n for details.\n\n\nSyntax\n\n\n-XX:ThreadStackSize<size>",
"title": "-XX:ThreadStackSize"
},
{
"location": "/xxthreadstacksize/#-xxthreadstacksize",
"text": "This Hotspot option to set the maximum Java thread stack size is recognized by OpenJ9 for compatibility. See -Xss for details.",
"title": "-XX:ThreadStackSize"
},
{
"location": "/xxthreadstacksize/#syntax",
"text": "-XX:ThreadStackSize<size>",
"title": "Syntax"
},
{
"location": "/xxusecompressedoops/",
"text": "-XX:[+|-]UseCompressedOops\n\n\n(64-bit only)\n\n\nThis Oracle Hotspot option enables or disables compressed references in 64-bit JVMs. The option is recognized by the OpenJ9 VM and is provided to help when porting applications from the Hotspot JVM to the OpenJ9 VM. This option might not be supported in subsequent releases.\n\n\nSyntax\n\n\n -XX:[+|-]UseCompressedOops\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:+UseCompressedOops\n\n\nEnable\n\n\n\n\n\n\n\n\n-XX:-UseCompressedOops\n\n\nDisable\n\n\n\n\n\n\n\n\n\n\nThe \n-XX:+UseCompressedOops\n option is similar to specifying \n-Xcompressedrefs\n. Compressed references are used by default when the maximum memory size for an application is set above a platform-specific value. For more information, see \n-Xcompressedrefs\n.",
"title": "-XX:[+|-]UseCompressedOops"
},
{
"location": "/xxusecompressedoops/#-xx91-93usecompressedoops",
"text": "(64-bit only) This Oracle Hotspot option enables or disables compressed references in 64-bit JVMs. The option is recognized by the OpenJ9 VM and is provided to help when porting applications from the Hotspot JVM to the OpenJ9 VM. This option might not be supported in subsequent releases.",
"title": "-XX:[+|-]UseCompressedOops"
},
{
"location": "/xxusecompressedoops/#syntax",
"text": "-XX:[+|-]UseCompressedOops Setting Effect Default -XX:+UseCompressedOops Enable -XX:-UseCompressedOops Disable The -XX:+UseCompressedOops option is similar to specifying -Xcompressedrefs . Compressed references are used by default when the maximum memory size for an application is set above a platform-specific value. For more information, see -Xcompressedrefs .",
"title": "Syntax"
},
{
"location": "/xxusecontainersupport/",
"text": "-XX:[+|-]UseContainerSupport\n\n\n(Linux\u2122 only)\n\n\nIf your application is running in a container that imposes a memory limit, the VM allocates a larger fraction of memory to the Java heap. To turn off this behavior, set the \n-XX:-UserContainerSupport\n option on the command line.\n\n\nSyntax\n\n\n -XX:[+|-]UseContainerSupport\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:-UseContainerSupport\n\n\nDisable\n\n\n\n\n\n\n\n\n-XX:+UseContainerSupport\n\n\nEnable\n\n\nyes\n\n\n\n\n\n\n\n\nWhen using container technology, applications are typically run on their own and do not need to compete for memory. The OpenJ9 VM detects when it is running inside a container that imposes a memory limit, and adjusts the maximum Java heap size appropriately.\n\n\nThe following table shows the values that are used when \n-XX:+UserContainerSupport\n is set:\n\n\n\n\n\n\n\n\nContainer memory limit \n<size>\n\n\nMaximum Java heap size\n\n\n\n\n\n\n\n\n\n\nLess than 1 GB\n\n\n50% \n<size>\n\n\n\n\n\n\n1 GB - 2 GB\n\n\n<size>\n - 512 MB\n\n\n\n\n\n\nGreater than 2 GB\n\n\n75% \n<size>\n\n\n\n\n\n\n\n\nThe default heap size for containers takes affect only when the following conditions are met:\n\n\n\n\nThe application is running in a container environment.\n\n\nThe memory limit for the container is set.\n\n\nThe \n-XX:+UseContainerSupport\n option is set, which is the default behavior.\n\n\n\n\nTo prevent the VM adjusting the maximum heap size when running in a container, set \n-XX:-UseContainerSupport\n.\n\n\nWhen \n-XX:MaxRAMPercentage\n or \n-XX:InitialRAMPercentage\n are used with \n-XX:+UseContainerSupport\n, the corresponding heap setting is determined based on the memory limit of the container. For example, to set the maximum heap size to 80% of the container memory, specify the following options:\n\n\n-XX:+UseContainerSupport -XX:MaxRAMPercentage=80",
"title": "-XX:[+|-]UseContainerSupport"
},
{
"location": "/xxusecontainersupport/#-xx-usecontainersupport",
"text": "(Linux\u2122 only) If your application is running in a container that imposes a memory limit, the VM allocates a larger fraction of memory to the Java heap. To turn off this behavior, set the -XX:-UserContainerSupport option on the command line.",
"title": "-XX:[+|-]UseContainerSupport"
},
{
"location": "/xxusecontainersupport/#syntax",
"text": "-XX:[+|-]UseContainerSupport Setting Effect Default -XX:-UseContainerSupport Disable -XX:+UseContainerSupport Enable yes When using container technology, applications are typically run on their own and do not need to compete for memory. The OpenJ9 VM detects when it is running inside a container that imposes a memory limit, and adjusts the maximum Java heap size appropriately. The following table shows the values that are used when -XX:+UserContainerSupport is set: Container memory limit <size> Maximum Java heap size Less than 1 GB 50% <size> 1 GB - 2 GB <size> - 512 MB Greater than 2 GB 75% <size> The default heap size for containers takes affect only when the following conditions are met: The application is running in a container environment. The memory limit for the container is set. The -XX:+UseContainerSupport option is set, which is the default behavior. To prevent the VM adjusting the maximum heap size when running in a container, set -XX:-UseContainerSupport . When -XX:MaxRAMPercentage or -XX:InitialRAMPercentage are used with -XX:+UseContainerSupport , the corresponding heap setting is determined based on the memory limit of the container. For example, to set the maximum heap size to 80% of the container memory, specify the following options: -XX:+UseContainerSupport -XX:MaxRAMPercentage=80",
"title": "Syntax"
},
{
"location": "/xxusenogc/",
"text": "-XX:[+|-]UseNoGC\n\n\nThe \n-XX:+UseNoGC\n option enables a garbage collection policy that expands the Java object heap in the normal way until the limit is reached, but memory is not\nreclaimed through garbage collection.\n\n\nSyntax\n\n\n -XX:[+|-]UseNoGC\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:+UseNoGC\n\n\nEnable\n\n\n\n\n\n\n\n\n-XX:-UseNoGC\n\n\nDisable\n\n\nyes\n\n\n\n\n\n\n\n\nExplanation\n\n\nThis policy can be useful for test purposes and for short-lived applications. When the limit is reached an \nOutOfMemory\n error is generated and the VM shuts down. This policy can also be enabled with the \n-Xgcpolicy:nogc\n option.\n\n\nThe \n-XX:-UseNoGC\n option turns off a previously enabled \n-XX:+UseNoGC\n option.",
"title": "-XX:[+|-]UseNoGC"
},
{
"location": "/xxusenogc/#-xx91-93usenogc",
"text": "The -XX:+UseNoGC option enables a garbage collection policy that expands the Java object heap in the normal way until the limit is reached, but memory is not\nreclaimed through garbage collection.",
"title": "-XX:[+|-]UseNoGC"
},
{
"location": "/xxusenogc/#syntax",
"text": "-XX:[+|-]UseNoGC Setting Effect Default -XX:+UseNoGC Enable -XX:-UseNoGC Disable yes",
"title": "Syntax"
},
{
"location": "/xxusenogc/#explanation",
"text": "This policy can be useful for test purposes and for short-lived applications. When the limit is reached an OutOfMemory error is generated and the VM shuts down. This policy can also be enabled with the -Xgcpolicy:nogc option. The -XX:-UseNoGC option turns off a previously enabled -XX:+UseNoGC option.",
"title": "Explanation"
},
{
"location": "/xxverboseverification/",
"text": "-XX:[+|-]VerboseVerification\n\n\nYou can use this option to control the output of verbose diagnostic data that relates to verification.\n\n\nThe Oracle documentation to support this option is no longer available, because it is no longer used by the Hotspot VM. An explanation is provided here.\n\n\nSyntax\n\n\n -XX:[+|-]VerboseVerification\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:-VerboseVerification\n\n\nDisable\n\n\nyes\n\n\n\n\n\n\n-XX:+VerboseVerification\n\n\nEnable\n\n\n\n\n\n\n\n\n\n\nUse \n-XX:-VerboseVerification\n to enable the output of verbose diagnostic data to \nstderr\n that is generated during verification from the class file \nStackMapTable\n attribute. The data provides extra contextual information about bytecode verification, which helps diagnose bytecode or stackmap deficiencies in the field.\n\n\nClass files that have \nStackMapTable\n attributes (that is, class files that conform to version 50.0 or later of the class file format specification), are introduced in Java\u2122 V6. Class files with \nStackMapTable\n attributes are marked as \nnew format\n in the verbose output, as shown in the example. Class files without the \nStackMapTable\n attributes are marked as \nold format\n. The \nStackMapTable\n diagnostic information is available only to classes verified with the new format.\n\n\nHere is an example of \nStackMapTable\n diagnostic output:\n\n\nVerifying\n \nclass\n \njava\n.\nexample\n.\nibm\n.\ncom\n \nwith\n \nnew\n \nformat\n\n\nVerifying\n \nmethod\n \njava\n.\nexample\n.\nibm\n.\ncom\n.\nfoo\n(\nLjava\n/\nlang\n/\nString\n;\nLjava\n/\nlang\n/\nClass\n;[\nLjava\n/\nlang\n/\nString\n;\nLjava\n/\nio\n/\nPrintStream\n;)\nI\n\n\nStackMapTable\n:\n \nframe_count\n \n=\n \n3\n\n\ntable\n \n=\n \n{\n\n \nbci\n:\n \n@37\n\n \nflags\n:\n \n{\n \n}\n\n \nlocals\n:\n \n{\n \n'\njava\n/\nlang\n/\nString\n'\n,\n \n'\njava\n/\nlang\n/\nClass\n'\n,\n \n'\n[\nLjava\n/\nlang\n/\nString\n;\n'\n,\n \n'\njava\n/\nio\n/\nPrintStream\n'\n,\n \n'\njava\n/\nlang\n/\nClass\n'\n \n}\n\n \nstack\n:\n \n{\n \n'\njava\n/\nlang\n/\nThreadDeath\n'\n \n}\n\n \nbci\n:\n \n@42\n\n \nflags\n:\n \n{\n \n}\n\n \nlocals\n:\n \n{\n \n'\njava\n/\nlang\n/\nString\n'\n,\n \n'\njava\n/\nlang\n/\nClass\n'\n,\n \n'\n[\nLjava\n/\nlang\n/\nString\n;\n'\n,\n \n'\njava\n/\nio\n/\nPrintStream\n'\n,\n \n'\njava\n/\nlang\n/\nClass\n'\n \n}\n\n \nstack\n:\n \n{\n \n'\njava\n/\nlang\n/\nThrowable\n'\n \n}\n\n \nbci\n:\n \n@79\n\n \nflags\n:\n \n{\n \n}\n\n \nlocals\n:\n \n{\n \n'\njava\n/\nlang\n/\nString\n'\n,\n \n'\njava\n/\nlang\n/\nClass\n'\n,\n \n'\n[\nLjava\n/\nlang\n/\nString\n;\n'\n,\n \n'\njava\n/\nio\n/\nPrintStream\n'\n,\n \n'\njava\n/\nlang\n/\nClass\n'\n,\n\n \n'\njava\n/\nlang\n/\nThrowable\n'\n \n}\n\n \nstack\n:\n \n{\n \n}\n\n \n}\n\n\nEnd\n \nclass\n \nverification\n \nfor\n:\n \njava\n.\nexample\n.\nibm\n.\ncom",
"title": "-XX:[+|-]VerboseVerification"
},
{
"location": "/xxverboseverification/#-xx91-93verboseverification",
"text": "You can use this option to control the output of verbose diagnostic data that relates to verification. The Oracle documentation to support this option is no longer available, because it is no longer used by the Hotspot VM. An explanation is provided here.",
"title": "-XX:[+|-]VerboseVerification"
},
{
"location": "/xxverboseverification/#syntax",
"text": "-XX:[+|-]VerboseVerification Setting Effect Default -XX:-VerboseVerification Disable yes -XX:+VerboseVerification Enable Use -XX:-VerboseVerification to enable the output of verbose diagnostic data to stderr that is generated during verification from the class file StackMapTable attribute. The data provides extra contextual information about bytecode verification, which helps diagnose bytecode or stackmap deficiencies in the field. Class files that have StackMapTable attributes (that is, class files that conform to version 50.0 or later of the class file format specification), are introduced in Java\u2122 V6. Class files with StackMapTable attributes are marked as new format in the verbose output, as shown in the example. Class files without the StackMapTable attributes are marked as old format . The StackMapTable diagnostic information is available only to classes verified with the new format. Here is an example of StackMapTable diagnostic output: Verifying class java . example . ibm . com with new format Verifying method java . example . ibm . com . foo ( Ljava / lang / String ; Ljava / lang / Class ;[ Ljava / lang / String ; Ljava / io / PrintStream ;) I StackMapTable : frame_count = 3 table = { \n bci : @37 \n flags : { } \n locals : { ' java / lang / String ' , ' java / lang / Class ' , ' [ Ljava / lang / String ; ' , ' java / io / PrintStream ' , ' java / lang / Class ' } \n stack : { ' java / lang / ThreadDeath ' } \n bci : @42 \n flags : { } \n locals : { ' java / lang / String ' , ' java / lang / Class ' , ' [ Ljava / lang / String ; ' , ' java / io / PrintStream ' , ' java / lang / Class ' } \n stack : { ' java / lang / Throwable ' } \n bci : @79 \n flags : { } \n locals : { ' java / lang / String ' , ' java / lang / Class ' , ' [ Ljava / lang / String ; ' , ' java / io / PrintStream ' , ' java / lang / Class ' , \n ' java / lang / Throwable ' } \n stack : { } \n } End class verification for : java . example . ibm . com",
"title": "Syntax"
},
{
"location": "/xxvmlockclassloader/",
"text": "-XX:[+|-]VMLockClassLoader\n\n\nThis option affects synchronization on class loaders that are not parallel-capable class loaders, during class loading.\n\n\nSyntax\n\n\n -XX:[+|-]VMLockClassLoader\n\n\n\n\n\n\n\n\n\n\n\nSetting\n\n\nEffect\n\n\nDefault\n\n\n\n\n\n\n\n\n\n\n-XX:+VMLockClassLoader\n\n\nEnable\n\n\nyes\n\n\n\n\n\n\n-XX:-VMLockClassLoader\n\n\nDisable\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nThe option, \n-XX:+VMLockClassLoader\n, causes the VM to force synchronization on a class loader that is not a parallel capable class loader during class loading. This action occurs even if the \nloadClass()\n method for that class loader is not synchronized. For information about parallel capable class loaders, see \njava.lang.ClassLoader.registerAsParallelCapable()\n. Note that this option might cause a deadlock if class loaders use non-hierarchical delegation. For example, setting the system property \nosgi.classloader.lock=classname\n with Equinox is known to cause a deadlock. This is the default option.\n\n\nWhen specifying the \n-XX:-VMLockClassLoader\n option, the VM does not force synchronization on a class loader during class loading. The class loader still conforms to class library synchronization, such as a synchronized \nloadClass()\n method.",
"title": "-XX:[+|-]VMLockClassLoader"
},
{
"location": "/xxvmlockclassloader/#-xx91-93vmlockclassloader",
"text": "This option affects synchronization on class loaders that are not parallel-capable class loaders, during class loading.",
"title": "-XX:[+|-]VMLockClassLoader"
},
{
"location": "/xxvmlockclassloader/#syntax",
"text": "-XX:[+|-]VMLockClassLoader Setting Effect Default -XX:+VMLockClassLoader Enable yes -XX:-VMLockClassLoader Disable The option, -XX:+VMLockClassLoader , causes the VM to force synchronization on a class loader that is not a parallel capable class loader during class loading. This action occurs even if the loadClass() method for that class loader is not synchronized. For information about parallel capable class loaders, see java.lang.ClassLoader.registerAsParallelCapable() . Note that this option might cause a deadlock if class loaders use non-hierarchical delegation. For example, setting the system property osgi.classloader.lock=classname with Equinox is known to cause a deadlock. This is the default option. When specifying the -XX:-VMLockClassLoader option, the VM does not force synchronization on a class loader during class loading. The class loader still conforms to class library synchronization, such as a synchronized loadClass() method.",
"title": "Syntax"
},
{
"location": "/tool_jdmpview/",
"text": "Dump viewer (\njdmpview\n)\n\n\nThe dump viewer is a command-line tool that allows you to examine the contents of system dumps produced from the OpenJ9 VM. The dump viewer allows you to view both Java\u2122 and native information from the time the dump was produced.\n\n\nFor long running tasks, the dump viewer can also be run in batch mode.\n\n\nThe dump viewer is useful for diagnosing \nOutOfMemoryError\n exceptions in Java\u2122 applications. For problems like general protection faults (GPF), system abends, and SIGSEVs, a system debugger such as \ngdb\n (Linux) provides more information.\n\n\nSyntax\n\n\nStarting the dump viewer\n\n\njdmpview -core <core file>\n\n\n\n\n\nWhere \n<core file>\n specifies a dump file. \n\n\nOn z/OS\u00ae, you can copy the dump to an HFS file and supply that as input to \njdmpview\n, or you can supply a fully qualified MVS\u2122 data set name. For example:\n\n\n> jdmpview -core USER1.JVM.TDUMP.SSHD6.D070430.T092211\nDTFJView version 4.28.3, using DTFJ version 1.11.28004\nLoading image from DTFJ...\n\n\n\n\n\nMVS data set names may contain the dollar sign ($). Names that contain a dollar sign must be enclosed by single quotation marks ('). For example:\n\n\n> jdmpview -core 'USER1.JVM.$TDUMP.SSH$D7.D141211.T045506'\n\n\n\n\n\nAfter \njdmpview\n processes the dump files, a session starts, showing this message:\n\n\nFor a list of commands, type \"help\"; for how to use \"help\", type \"help help\"\n>\n\n\n\n\n\nIf you run the \njdmpview\n tool on a compressed file that contains multiple dumps, the tool detects and shows all the dump files, whether these are system dumps, Java dumps, or heap dumps. Because of this behavior, more than one context might be displayed when you start \njdmpview\n. To switch context, type \ncontext <n>\n, where \n<n>\n is the context value for the dump you want to investigate.\n\n\nOn z/OS, a system dump can contain multiple address spaces and an address space can contain multiple VM instances. In this case, the context allows you to select the address space and VM instance within the dump file. The following z/OS example shows address spaces (\nASID\n), with two JVMs occupying address space \n0x73\n (context 5 and 6). The current context is 5 (\nCTX:5>\n), shown with an asterisk. To view the JVM in context 6, you can switch by specifying \ncontext 6\n. \n\n\nCTX\n:\n5\n>\n \ncontext\n\n\nAvailable\n \ncontexts\n \n(*\n \n=\n \ncurrently\n \nselected\n \ncontext\n)\n \n:\n\n\n\n0\n \n:\n \nASID\n:\n \n0x1\n \n:\n \nNo\n \nJRE\n \n:\n \nNo\n \nJRE\n\n\n1\n \n:\n \nASID\n:\n \n0x3\n \n:\n \nNo\n \nJRE\n \n:\n \nNo\n \nJRE\n\n\n2\n \n:\n \nASID\n:\n \n0x4\n \n:\n \nNo\n \nJRE\n \n:\n \nNo\n \nJRE\n\n\n3\n \n:\n \nASID\n:\n \n0x6\n \n:\n \nNo\n \nJRE\n \n:\n \nNo\n \nJRE\n\n\n4\n \n:\n \nASID\n:\n \n0x7\n \n:\n \nNo\n \nJRE\n \n:\n \nNo\n \nJRE\n\n\n*\n5\n \n:\n \nASID\n:\n \n0x73\n \nEDB\n:\n \n0x83d2053a0\n \n:\n \nJRE\n \n1.8\n.\n0\n \nz\n/\nOS\n \ns390x\n-\n64\n \nbuild\n \n20181117\n_128845\n \n(\npmz6480\n-\n20181120\n_01\n)\n\n\n6\n \n:\n \nASID\n:\n \n0x73\n \nEDB\n:\n \n0x8004053a0\n \n:\n \nJRE\n \n1.8\n.\n0\n \nz\n/\nOS\n \ns390x\n-\n64\n \nbuild\n \n20181117\n_128845\n \n(\npmz6480\n-\n20181120\n_01\n)\n\n\n7\n \n:\n \nASID\n:\n \n0x73\n \nEDB\n:\n \n0x4a7bd9e8\n \n:\n \nNo\n \nJRE\n\n\n8\n \n:\n \nASID\n:\n \n0xffff\n \n:\n \nNo\n \nJRE\n \n:\n \nNo\n \nJRE\n\n\n\n\n\n\nIf you are using \njdmpview\n to view Java dumps and heap dumps, some options do not produce any output. For example, a heap dump doesn't contain the information requested by the \ninfo system\n command, but does contain information requested by the \ninfo class\n command.\n\n\nIf you are viewing a dump where there are a large number of objects on the heap, you can speed up the performance of \njdmpview\n by ensuring that your system has enough memory available and does not need to page memory to disk. To achieve this, start \njdmpview\n with a larger heap size by specifying the \n-Xmx\n option. Use the \n-J\n option to pass the \n-Xmx\n command line option to the JVM. For example:\n\n\njdmpview -J-Xmx<n> -core <core file>\n\n\n\n\n\nThe options available to the dump viewer session are shown under \nSession parameters\n\n\nStarting in batch mode\n\n\nFor long running or routine jobs, \njdmpview\n can be used in batch mode.\n\n\nYou can run a single command without specifying a command file by appending the command to the end of the \njdmpview\n command line. For example:\n\n\njdmpview -core mycore.dmp info class\n\n\n\n\n\nWhen specifying jdmpview commands that accept a wildcard parameter, you must replace the wildcard symbol with \nALL\n to prevent the shell interpreting the wildcard symbol. For example, in interactive mode, the command \ninfo thread *\n must be specified in the following way:\n\n\njdmpview -core mycore.dmp info thread ALL\n\n\n\n\n\nBatch mode is controlled with the following command line options:\n\n\n\n\n\n\n\n\nOption\n\n\nExplanation\n\n\n\n\n\n\n\n\n\n\n-cmdfile <path to command file>\n\n\nA file that contains a series of jdmpview commands, which are read and run sequentially.\n\n\n\n\n\n\n-charset <character set name>\n\n\nThe character set for the commands specified in -cmdfile (name must be a supported charset as defined in java.nio.charset.Charset. For example, US-ASCII)\n\n\n\n\n\n\n-outfile <path to output file>\n\n\nThe file to record any output generated by commands.\n\n\n\n\n\n\n-overwrite\n\n\nIf the file specified in -outfile exists, this option overwrites the file.\n\n\n\n\n\n\n-append\n\n\nIf the file specified in -outfile exists, new output messages are appended to the end of that file. The -append and -overwrite options cannot be used at the same time.\n\n\n\n\n\n\n\n\nThe command file can have empty lines that contain spaces, or comment lines that start with // or #. These lines are ignored by jdmpview. Example command file:\n\n\n// commands.txt\ninfo system\ninfo proc\n\n\n\n\n\nTo run jdmpview in batch mode, using this command file, specify:\n\n\njdmpview -outfile out.txt [-overwrite|-append] -cmdfile commands.txt -core <path to core file>\n\n\n\n\n\nWhen the output file exists, you need to specify either the \n-overwrite\n option or the \n-append\n option. If you do not, an error message is generated.\n\n\nProcessing output\n\n\nYou can redirect command output to a file, or pipe the command output to another command.\n\n\nTo redirect jdmpview command output to a file, use one of the following formats:\n\n\ncommand > <target_file>\n\n\n\n\n\nIf the target file exists, this redirection overwrites the content within it.\n\n\ncommand >> <target_file>\n\n\n\n\n\nIf the target file exists, this redirection appends the output to it.\n\n\nWhere \n<target_file>\n is the file name, which can include the full path to the file.\n\n\nTo pipe \njdmpview\n command output to another command, use the vertical bar (|) character. For example:\n\n\ncommand | grep string\n\n\n\n\n\nYou can chain more than two commands together by using multiple vertical bar characters.\n\n\nThe following commands can be used to interrogate the output:\n\n\n\n\ncharsFrom\n\n\ncharsTo\n\n\ngrep\n\n\ntokens\n\n\n\n\nUsing \nCharsFrom\n\n\nUse the \ncharsFrom\n command after the vertical bar character to exclude all characters that come before a specified pattern in a resulting line.\n\n\ncharsFrom <options> pattern\n\n\n\n\n\nWhere \n<options>\n:\n\n\n\n\n-e\n or \n-exclude\n : Exclude the matched pattern from the resulting line. By default, the matched pattern is included in the resulting line.\n\n\n-keep\n : Keep lines that do not contain a match to the pattern. By default, lines that do not contain a match are excluded from the results.\n\n\n-i\n or \n-ignoreCase\n : Ignore case.\n\n\n\n\nFor example, the following command displays resulting lines that contain the pattern \njre\n, and trims each line to exclude all characters that come before this pattern:\n\n\n> info mod | charsFrom jre\njre/lib/ppc64/libzip.so @ 0x0, sections:\njre/lib/ppc64/libdbgwrapper80.so @ 0x0, sections:\njre/lib/ppc64/libverify.so @ 0x0, sections:\njre/lib/ppc64/libjava.so @ 0x0, sections:\njre/lib/ppc64/compressedrefs/libjclse7b_28.so @ 0x0, sections:\n\n\n\n\n\nUsing \nCharsTo\n\n\nUse the \nCharsTo\n command after the vertical bar character to include the characters in a resulting line until a specific pattern is found.\n\n\ncharsTo <options> pattern\n\n\n\n\n\nWhere \n<options>\n:\n\n\n\n\n-include\n : Include the matched pattern in the resulting line. By default, the matched pattern is excluded from the resulting line.\n\n\n-keep\n : Keep lines that do not contain a match to the pattern. By default, lines that do not contain a match are excluded from the results.\n\n\n-i\n or \n-ignoreCase\n : Ignore case.\n\n\n\n\nFor example, the following command displays lines that contain the pattern \"@\", and trims each line to exclude all characters from \"@\" onwards:\n\n\n> info mod | charsTo @\nbin/java\n/usr/lib64/gconv/UTF-16.so\n/test/sdk/lib/ppc64le/libnet.so\n/test/sdk/lib/ppc64le/libnio.so\n/test/sdk/lib/ppc64le/libzip.so\n/test/sdk/lib/ppc64le/libjsig.so\nlibjsig.so\n\n\n\n\n\nYou can also use \ncharsFrom\n and \ncharsTo\n together, separated by a vertical bar character. For example, the following command displays lines that contain the pattern \"lib\", and trims each line to exclude all characters that come before this pattern, as well as all characters from the pattern \n@\n :\n\n\n> info mod | charsFrom lib | charsTo @\nlib/ppc64le/libzip.so\nlib/ppc64le/libjsig.so\nlib/ppc64le/libverify.so\nlib/ppc64le/libjava.so\nlib/ppc64le/compressedrefs/libj9jit29.so\n\n\n\n\n\n \nNote:\n The line will not be displayed if the \ncharsFrom\n and \ncharsTo\n are used together, but only one of the patterns are matched in a line. Furthermore, the line will not be displayed if both patterns are matched in a line, but the \ncharsTo\n pattern appears before, and not after, the \ncharsFrom\n pattern.\n\n\nUsing \ngrep\n\n\nUse the \ngrep\n command after the vertical bar character to show which lines match a specified pattern.\n\n\ngrep <options> pattern\n\n\n\n\n\nWhere \n<options>\n:\n\n\n\n\n-i\n : Ignore case.\n\n\n-r\n, \n-G\n, or \n--regex\n: Use a regular expression as defined in the Java documentation of the java.utils.regex.Pattern class.\n\n\n-b\n or \n--block\n : Show blocks of lines where at least one of the lines matches the pattern. Blocks of lines are separated by empty lines.\n\n\n-A\n <NUM> or +<NUM> : Show at most <NUM> lines after the matching line. For example grep -A 2 pattern or grep +2 pattern.\n\n\n-B\n <NUM> or -<NUM> : Show at most <NUM> lines before the matching line.\n\n\n-C\n <NUM> or +-<NUM> : Show at most <NUM> lines before and after the matching line.\n\n\n-v\n or \n--invert-match\n : Use with the grep command to show lines that do not match the pattern. These options are equivalent to the grep- command.\n\n\n-F\n or \n--fixed-strings\n : Do not treat the asterisk (*) as a wildcard character. Use these options with the \n-r\n, \n-G\n, or \n--regex\n options.\n\n\n\n\nPattern rules:\n\n\n\n\nAn asterisk (*) in a pattern is treated as a wildcard character unless you specify the \n-F\n or \n--fixed-strings\n options.\n\n\nIf a pattern contains spaces, enclose the pattern in a pair of double quotation marks (\").\n\n\nIf a pattern contains double quotation marks, enclose the pattern in a pair of single quotation marks (').\n\n\n\n\nYou can specify multiple sub-patterns to match by using the following format, but only if you do not use the \n-r\n, \n-G\n, or \n--regex\n options:\n\n\n\"[pattern1|pattern2|...|patternN]\"\n\n\nThe initial and trailing double quotation marks and brackets ([ ]) are required. Use a vertical bar character to separate the sub-patterns. Quotation marks and the vertical bar are not allowed in a sub-pattern. Spaces are allowed in the middle of a sub-pattern, but leading and trailing spaces will be trimmed.\n\n\n\n\n\n\nUse the \ngrep\n command to show lines that do not match the pattern.\n\n\n\n\n\n\nFor example, the following command displays the number of instances and total heap size for the \njava/lang/String\n class:\n\n\n> info class | grep java/lang/String \n94 7688 [Ljava/lang/String; \n1822 58304 java/lang/String \n1 16 java/lang/String$CaseInsensitiveComparator \n0 0 java/lang/String$UnsafeHelpers\n\n\n\n\n\nThe following command uses two pipes in combination to display the number of instances and total heap size for the \njava/lang/StringCoding.StringDecoder\n class:\n\n\n> info class | grep java/lang/String | grep -i decoder\n1 48 java/lang/StringCoding$StringDecoder\n\n\n\n\n\nUsing \ntokens\n\n\nUse the \ntokens\n command after the vertical bar character to isolate specified tokens in the resulting lines.\n\n\ntokens [options] range[,range][..range]\n\n\n\n\n\nYou can define range in the following formats:\n\n\n\n\nx\n\n\nx,y\n\n\nx..y\n\n\n\n\nA set of rules applies to these formats:\n\n\n\n\nx or y can be prefixed with \"-\". This means that x or y are counting backwards from the end of a list. For example, a y value of -1 represents the last token in a list, while -2 represents the penultimate token in a list.\n\n\nx must represent a token that either precedes or is at the same position as y.\n\n\n\n\nIn this format, if x is omitted, it is assumed to be '1'. If y is omitted, it is assumed to be '-1'.\n\n\nFor example, the following command displays the first and second token for each resulting line:\n\n\n> info mmap | grep -r ^0x | tokens 1,2\n0x0000000000012fff 0x000000000000d000\n0x0000000000017fff 0x0000000000004000\n0x00000000009dafff 0x0000000000018000\n0x00000000009fffff 0x000000000001f000\n0x0000000000cbefff 0x0000000000002000\n0x0000000000d76fff 0x0000000000001000\n0x0000000003145fff 0x0000000000071000\n0x0000000003b93fff 0x0000000000003000\n\n\n\n\n\nSession parameters\n\n\nWhen \njdmpview\n is started, many parameters can be used during the session to interrogate the system dump data, which are divided into \ngeneral\n and \nexpert\n parameters. The \ngeneral\n parameters are documented in this section. To see a list of \nexpert\n parameters, use the \n!j9help\n option.\n\n\n!j9help\n\n\n !j9help\n\n\n\n\n\n\n\nLists all \nexpert\n parameters that can be used in a session, with a brief description.\n\n\n\n\ncd\n\n\n cd <directory_name>\n\n\n\n\n\n\n\nChanges the working directory to \n<directory_name>\n. The working directory is used for log files. Logging is controlled by the \nset logging\n command. Use the \npwd\n command to query the current working directory.\n\n\n\n\ncmdfile\n\n\n cmdfile <directory_name>\n\n\n\n\n\n\n\nRuns all of the commands in a file. The commands are read line by line and run sequentially. Empty lines, and lines that start with \n//\n or \n#\n, are ignored. Use the option charset to identify the character set that is used in the chosen file. The character set must be supported, as defined in \njava.nio.charset.Charset\n, such as \nUS-ASCII\n.\n\n\n\n\ndeadlock\n\n\n\n\n\n\nThis command detects deadlock situations in the Java application that was running when the system dump was produced. Example output:\n\n\ndeadlock loop:\nthread: Thread-2 (monitor object: 0x9e32c8) waiting for =>\nthread: Thread-3 (monitor object: 0x9e3300) waiting for =>\nthread: Thread-2 (monitor object: 0x9e32c8)\n\n\n\n\n\nIn this example, the deadlock analysis shows that \nThread-2\n is waiting for a lock held by \nThread-3\n, which is in turn waiting for a lock held earlier by \nThread-2\n.\n\n\nThreads are identified by their Java thread name, whereas object monitors are identified by the address of the object in the Java heap. You can obtain further information about the threads using the \ninfo thread *\n command. You can obtain further information about the monitors using the \nx/J <0xaddr>\n command.\n\n\n\n\n\n\nfind\n\n\n find <pattern>,<start_address>,<end_address>,<memory_boundary>, <bytes_to_print>,<matches_to_display>\n\n\n\n\n\n\n\n\n\nThis command searches for \n<pattern>\n in the memory segment from \n<start_address>\n to \n<end_address>\n (both inclusive), and shows the number of matching addresses you specify with \n<matches_to_display>\n. You can also display the next \n<bytes_to_print>\n bytes for the last match.\n\n\nBy default, the \nfind\n command searches for the pattern at every byte in the range. If you know the pattern is aligned to a particular byte boundary, you can specify \n<memory_boundary>\n to search every \n<memory_boundary>\n bytes. For example, if you specify a \n<memory_boundary>\n of \"4\", the command searches for the pattern every 4 bytes.\n\n\n\n\n\n\nfindnext\n\n\n findptr <pattern>,<start_address>,<end_address>,<memory_boundary>,<bytes_to_print>,<matches_to_display>\n\n\n\n\n\n\n\n\n\nFinds the next instance of the last string passed to \nfind\n or \nfindptr\n. It repeats the previous \nfind\n or \nfindptr\n command, depending on which one was issued last, starting from the last match.\n\n\nSearches memory for the given pointer. \nfindptr\n searches for \n<pattern>\n as a pointer in the memory segment from \n<start_address>\n to \n<end_address>\n (both inclusive), and shows the number of matching addresses you specify with \n<matches_to_display>\n. You can also display the next \n<bytes_to_print>\n bytes for the last match.\n\n\nBy default, the \nfindptr\n command searches for the pattern at every byte in the range. If you know the pattern is aligned to a particular byte boundary, you can specify \n<memory_boundary>\n to search every \n<memory_boundary>\n bytes. For example, if you specify a \n<memory_boundary>\n of \"4\", the command searches for the pattern every 4 bytes.\n\n\n\n\n\n\nhelp\n\n\n help [<command_name>]\n\n\n\n\n\n\n\nShows information for a specific command. If you supply no parameters, help shows the complete list of supported commands.\n\n\n\n\nhistory\n\n\n history|his [-r][<N>]\n\n\n\n\n\n\n\nRecalls and displays the history of commands that you have run. The default behavior is to display the 20 most recent commands. If you use the argument \n<N>\n, then N commands are displayed. For example, if you run history 35, then the 35 most recent commands are displayed. You can also use the \n-r\n option with \n<N>\n to run the Nth most recent command in your history. Using the \n-r\n option alone runs the most recent command in your history.\n\n\n\n\ninfo thread\n\n\n info thread [*|all|<native_thread_ID>|<zos_TCB_address>]\n\n\n\n\n\n\n\n\n\nDisplays information about Java and native threads. The following information is displayed for all threads (\"*\"), or the specified thread:\n\n\n\n\nThread id\n\n\nRegisters\n\n\nStack sections\n\n\nThread frames: procedure name and base pointer\n\n\nThread properties: list of native thread properties and their values. For example: thread priority.\n\n\nAssociated Java thread, if applicable:\n\n\nName of Java thread\n\n\nAddress of associated \njava.lang.Thread\n object\n\n\nState (shown in JVMTI and \njava.lang.Thread.State\n formats)\n\n\nThe monitor the thread is waiting for\n\n\nThread frames: base pointer, method, and filename:line\n\n\n\n\n\n\n\n\nIf you supply no parameters, the command shows information about the current thread.\n\n\n\n\n\n\ninfo system\n\n\n\n\n\n\nDisplays the following information about the system that produced the core dump:\n\n\n\n\nAmount of memory\n\n\nOperating system\n\n\nVirtual machine or virtual machines present\n\n\n\n\n\n\n\n\ninfo class\n\n\n info class [<class_name>] [-sort:<name>|<count>|<size>]\n\n\n\n\n\n\n\nDisplays the inheritance chain and other data for a given class.\n\n\n\n\nIf a class name is passed to info class, the following information is shown about that class:\n\n\n- Name\n- ID\n- Superclass ID\n- Class loader ID\n- Modifiers\n- Number of instances and total size of instances\n- Inheritance chain\n- Fields with modifiers (and values for static fields)\n- Methods with modifiers\n\nIf no parameters are passed to `info class`, the following information is shown:\n\n- The number of instances of each class.\n- The total size of all instances of each class.\n- The class name\n- The total number of instances of all classes.\n- The total size of all objects.\n\nThe `sort` option allows the list of classes to be sorted by name (default), by number of instances of each class, or by the total size of instances of each class.\n\n\n\n\n\ninfo proc\n\n\n\n\n\n\nDisplays threads, command-line arguments, environment variables, and shared modules of the current process.\n\n\nTo view the shared modules used by a process, use the \ninfo sym\n command.\n\n\n\n\n\n\ninfo jitm\n\n\n\n\n\n\nDisplays JIT compiled methods and their addresses:\n\n\n\n\nMethod name and signature\n\n\nMethod start address\n\n\nMethod end address\n\n\n\n\n\n\n\n\ninfo lock\n\n\n\n\nDisplays a list of available monitors and locked objects.\n\n\n\n\ninfo sym\n\n\n\n\nDisplays a list of available modules. For each process in the address spaces, this command shows a list of module sections for each module, their start and end addresses, names, and sizes.\n\n\n\n\ninfo mmap\n\n\n info mmap [<address>] [-verbose] [-sort:<size>|<address>]\n\n\n\n\n\n\n\nDisplays a summary list of memory sections in the process address space, with start and end address, size, and properties. If an address parameter is specified, the results show details of only the memory section containing the address. If \n-verbose\n is specified, full details of the properties of each memory section are displayed. The \n-sort\n option allows the list of memory sections to be sorted by size or by start address (default).\n\n\n\n\ninfo heap\n\n\n info heap [*|<heap_name>*]\n\n\n\n\n\n\n\n\n\nIf no parameters are passed to this command, the heap names and heap sections are shown.\n\n\nUsing either \"*\" or a heap name shows the following information about all heaps or the specified heap:\n\n\n\n\nHeap name\n\n\n(Heap size and occupancy)\n\n\nHeap sections\n\n\nSection name\n\n\nSection size\n\n\nWhether the section is shared\n\n\nWhether the section is executable\n\n\nWhether the section is read only\n\n\n\n\n\n\n\n\nheapdump\n\n\n heapdump [<heaps>]\n\n\n\n\n\n\n\nGenerates a Java heap dump to a file. You can select which Java heaps to dump by listing the heap names, separated by spaces. To see which heaps are available, use the \ninfo heap\n command. By default, all Java heaps are dumped.\n\n\n\n\nhexdump\n\n\n hexdump <hex_address> <bytes_to_print>\n\n\n\n\n\n\n\nDisplays a section of memory in a hexdump-like format. Displays \n<bytes_to_print>\n bytes of memory contents starting from \n<hex_address>\n.\n\n\n\n\n+\n\n\n\n\nDisplays the next section of memory in hexdump-like format. This command is used with the hexdump command to enable easy scrolling forwards through memory. The previous hexdump command is repeated, starting from the end of the previous one.\n\n\n\n\n-\n\n\n\n\nDisplays the previous section of memory in hexdump-like format. This command is used with the hexdump command to enable easy scrolling backwards through memory. The previous hexdump command is repeated, starting from a position before the previous one.\n\n\n\n\npwd\n\n\n\n\nDisplays the current working directory, which is the directory where log files are stored.\n\n\n\n\nquit\n\n\n\n\nExits the core file viewing tool; any log files that are currently open are closed before exit.\n\n\n\n\nset heapdump\n\n\n\n\nConfigures Heapdump generation settings.\nset heapdump <options>\n\n\n\n\n\n\n\n\n\nwhere \n<options>\n are:\n\n\n\n\nphd\n: Set the Heapdump format to Portable Heapdump, which is the default.\n\n\ntxt\n: Set the Heapdump format to classic.\n\n\nfile <file>\n: Set the destination of the Heapdump.\n\n\nmultiplefiles [on|off]\n: If multiplefiles is set to on, each Java heap in the system dump is written to a separate file. If multiplefiles is set to off, all Java heaps are written to the same file. The default is off.\n\n\n\n\n\n\n\n\nset logging\n\n\n set logging <options>\n\n\n\n\n\n\n\n\n\nConfigures logging settings, starts logging, or stops logging. This parameter enables the results of commands to be logged to a file, where \n<options>\n are:\n\n\n\n\n[on|off]\n: Turns logging on or off. (Default: off)\n\n\nfile <filename>\n: Sets the file to log to. The path is relative to the directory returned by the pwd command, unless an absolute path is specified. If the file is set while logging is on, the change takes effect the next time logging is started. Not set by default.\n\n\noverwrite [on|off]\n: Turns overwriting of the specified log file on or off. When overwrite is off, log messages are appended to the log file. When overwrite is on, the log file is overwritten after the set logging command. (Default: off)\n\n\nredirect [on|off]\n: Turns redirecting to file on or off, with off being the default. When logging is set to on:\n\n\nA value of on for redirect sends non-error output only to the log file.\n\n\nA value of off for redirect sends non-error output to the console and log file.\n\n\n\n\nRedirect must be turned off before logging can be turned off. (Default: off)\n\n\n\n\n\n\nshow heapdump\n\n\n\n\nDisplays the current Heapdump generation settings.\n\n\n\n\nshow logging\n\n\n\n\n\n\nDisplays the current logging settings:\n\n\n\n\nset_logging = [on|off]\n\n\nset_logging_file =\n\n\nset_logging_overwrite = [on|off]\n\n\nset_logging_redirect = [on|off]\n\n\ncurrent_logging_file =\n\n\n\n\nThe file that is currently being logged to might be different from set_logging_file, if that value was changed after logging was started.\n\n\n\n\n\n\nwhatis \n<hex_address>\n\n\n\n\nDisplays information about \nwhatis\n stored at the given memory address, \n<hex_address>\n. This command examines the memory location at \n<hex_address>\n and tries to find out more information about this address. For example:\n>\n \nwhatis\n \n0x8e76a8\n\n\n\nheap\n \n#\n1\n \n-\n \nname\n:\n \nDefault\n@19f\nce8\n\n\n0x8e76a8\n \nis\n \nwithin\n \nheap\n \nsegment\n:\n \n8\nb0000\n \n--\n \ncb0000\n\n\n0x8e76a8\n \nis\n \nstart\n \nof\n \nan\n \nobject\n \nof\n \ntype\n \njava\n/\nlang\n/\nThread\n\n\n\n\n\n\n\n\n\n\nx/ (examine)\n\n\n\n\n\n\nPasses the number of items to display and the unit size, as listed in the following table, to the sub-command. For example, \nx/12bd\n.\n\n\n\n\n\n\n\n\nAbbreviation\n\n\nUnit\n\n\nSize\n\n\n\n\n\n\n\n\n\n\nb\n\n\nByte\n\n\n8-bit\n\n\n\n\n\n\nh\n\n\nHalf word\n\n\n16-bit\n\n\n\n\n\n\nw\n\n\nWord\n\n\n32-bit\n\n\n\n\n\n\ng\n\n\nGiant word\n\n\n64-bit\n\n\n\n\n\n\n\n\nThis command is similar to the use of the \nx/\n command in gdb, including the use of defaults.\n\n\n\n\n\n\nx/J [<class_name>|<0xaddr>]\n\n\n\n\n\n\nDisplays information about a particular object, or all objects of a class. If \n<class_name>\n is supplied, all static fields with their values are shown, followed by all objects of that class with their fields and values. If an object address (in hex) is supplied, static fields for that object's class are not shown; the other fields and values of that object are printed along with its address.\n\n\n \nNote:\n This command ignores the number of items and unit size passed to it by the \nx/\n command.\n\n\n\n\n\n\nx/D <0xaddr>\n\n\n\n\n\n\nDisplays the integer at the specified address, adjusted for the hardware architecture this dump file is from. For example, the file might be from a big endian architecture.\n\n\n This command uses the number of items and unit size passed to it by the \nx/\n command.\n\n\n\n\n\n\nx/X <0xaddr>\n\n\n\n\n\n\nDisplays the hex value of the bytes at the specified address, adjusted for the hardware architecture this dump file is from. For example, the file might be from a big endian architecture.\n\n\n \nNote:\n This command uses the number of items and unit size passed to it by the \nx/\n command.\n\n\n\n\n\n\nx/K <0xaddr>\n\n\n\n\n\n\nWhere the size is defined by the pointer size of the architecture, this parameter shows the value of each section of memory. The output is adjusted for the hardware architecture this dump file is from, starting at the specified address. It also displays a module with a module section and an offset from the start of that module section in memory if the pointer points to that module section. If no symbol is found, it displays a \"*\" and an offset from the current address if the pointer points to an address in 4KB (4096 bytes) of the current address. Although this command can work on an arbitrary section of memory, it is probably more useful on a section of memory that refers to a stack frame. To find the memory section of a thread stack frame, use the info thread command.\n\n\n \nNote:\n This command uses the number of items and unit size passed to it by the \nx/\n command.\n\n\n\n\n\n\nExample\n\n\nThis example session illustrates a selection of the commands available and their use.\n\n\nIn the example session, which is generated on a Linux system, some lines have been removed for clarity (and terseness).\n\n\nUser input is prefaced by a greater than symbol (>).\n\n\n \ntest\n@\nmadras\n:\n~/\ntest\n>\n \nsdk\n/\nbin\n/\njdmpview\n \n-\ncore\n \ncore\n.20121116.154147.16838.0001\n.\ndmp\n\n \nDTFJView\n \nversion\n \n4.27.57\n,\n \nusing\n \nDTFJ\n \nversion\n \n1.10.27022\n\n \nLoading\n \nimage\n \nfrom\n \nDTFJ\n...\n\n\n \nFor\n \na\n \nlist\n \nof\n \ncommands\n,\n \ntype\n \n\"help\"\n;\n \nfor\n \nhow\n \nto\n \nuse\n \n\"help\"\n,\n \ntype\n \n\"help help\"\n\n \nAvailable\n \ncontexts\n \n(\n*\n \n=\n \ncurrently\n \nselected\n \ncontext\n)\n \n:\n\n\n \nSource\n \n:\n \nfile\n:\n///home/test/core.20121116.154147.16838.0001.dmp\n\n \n*\n0\n \n:\n \nPID\n:\n \n16867\n \n:\n \nJRE\n \n1.8.0\n \nLinux\n \nppc64\n-\n64\n \nbuild\n \n20121115\n_128521\n \n(\npxp6480\n-\n20121116\n_01\n \n)\n\n\n \n>\n \nhelp\n\n \n+\n \ndisplays\n \nthe\n \nnext\n \nsection\n \nof\n \nmemory\n \nin\n \nhexdump\n-\nlike\n \nformat\n\n \n-\n \ndisplays\n \nthe\n \nprevious\n \nsection\n \nof\n \nmemory\n \nin\n \nhexdump\n-\nlike\n \nformat\n\n \ncd\n \nchanges\n \nthe\n \ncurrent\n \nworking\n \ndirectory\n,\n \nused\n \nfor\n \nlog\n \nfiles\n\n \nclose\n \n[\ncontext\n \nid\n]\n \ncloses\n \nthe\n \nconnection\n \nto\n \na\n \ncore\n \nfile\n\n \ncontext\n \n[\nID\n|\nasid\n \nID\n]\n \nswitch\n \nto\n \nthe\n \nselected\n \ncontext\n\n \ndeadlock\n \ndisplays\n \ninformation\n \nabout\n \ndeadlocks\n \nif\n \nthere\n \nare\n \nany\n\n \nexit\n \nExit\n \nthe\n \napplication\n\n \nfind\n \nsearches\n \nmemory\n \nfor\n \na\n \ngiven\n \nstring\n\n \nfindnext\n \nfinds\n \nthe\n \nnext\n \ninstance\n \nof\n \nthe\n \nlast\n \nstring\n \npassed\n \nto\n \n\"find\"\n\n \nfindptr\n \nsearches\n \nmemory\n \nfor\n \nthe\n \ngiven\n \npointer\n\n \nheapdump\n \ngenerates\n \na\n \nPHD\n \nor\n \nclassic\n \nformat\n \nheapdump\n\n \nhelp\n \n[\ncommand\n \nname\n]\n \ndisplays\n \nlist\n \nof\n \ncommands\n \nor\n \nhelp\n \nfor\n \na\n \nspecific\n \ncommand\n\n \nhexdump\n \noutputs\n \na\n \nsection\n \nof\n \nmemory\n \nin\n \na\n \nhexdump\n-\nlike\n \nformat\n\n \ninfo\n \n<\ncomponent\n>\n \nInformation\n \nabout\n \nthe\n \nspecified\n \ncomponent\n\n \ninfo\n \nclass\n \n<\nJava\n \nclass\n \nname\n>\n \nProvides\n \ninformation\n \nabout\n \nthe\n \nspecified\n \nJava\n \nclass\n\n \ninfo\n \nheap\n \n[\n*|\nheap\n \nname\n]\n \nDisplays\n \ninformation\n \nabout\n \nJava\n \nheaps\n\n \ninfo\n \njitm\n \nDisplays\n \nJIT\n'\ned\n \nmethods\n \nand\n \ntheir\n \naddresses\n\n \ninfo\n \nlock\n \noutputs\n \na\n \nlist\n \nof\n \nsystem\n \nmonitors\n \nand\n \nlocked\n \nobjects\n\n \ninfo\n \nmmap\n \nOutputs\n \na\n \nlist\n \nof\n \nall\n \nmemory\n \nsegments\n \nin\n \nthe\n \naddress\n \nspace\n\n \ninfo\n \nmod\n \noutputs\n \nmodule\n \ninformation\n\n \ninfo\n \nproc\n \nshortened\n \nform\n \nof\n \ninfo\n \nprocess\n\n \ninfo\n \nprocess\n \ndisplays\n \nthreads\n,\n \ncommand\n \nline\n \narguments\n,\n \nenvironment\n\n \ninfo\n \nsym\n \nan\n \nalias\n \nfor\n \n'\nmod\n'\n\n \ninfo\n \nsys\n \nshortened\n \nform\n \nof\n \ninfo\n \nsystem\n\n \ninfo\n \nsystem\n \ndisplays\n \ninformation\n \nabout\n \nthe\n \nsystem\n \nthe\n \ncore\n \ndump\n \nis\n \nfrom\n\n \ninfo\n \nthread\n \ndisplays\n \ninformation\n \nabout\n \nJava\n \nand\n \nnative\n \nthreads\n\n \nlog\n \n[\nname\n \nlevel\n]\n \ndisplay\n \nand\n \ncontrol\n \ninstances\n \nof\n \njava\n.\nutil\n.\nlogging\n.\nLogger\n\n \nopen\n \n[\npath\n \nto\n \ncore\n]\n \nopens\n \nthe\n \nspecified\n \ncore\n \nfile\n\n \nplugins\n \nPlugin\n \nmanagement\n \ncommands\n\n \nlist\n \nShow\n \nthe\n \nlist\n \nof\n \nloaded\n \nplugins\n \nfor\n \nthe\n \ncurrent\n \ncontext\n\n \nreload\n \nReload\n \nplugins\n \nfor\n \nthe\n \ncurrent\n \ncontext\n\n \nshowpath\n \nShow\n \nthe\n \nDTFJ\n \nView\n \nplugin\n \nsearch\n \npath\n \nfor\n \nthe\n \ncurrent\n \ncontext\n\n \nsetpath\n \nSet\n \nthe\n \nDTFJ\n \nView\n \nplugin\n \nsearch\n \npath\n \nfor\n \nthe\n \ncurrent\n \ncontext\n\n \npwd\n \ndisplays\n \nthe\n \ncurrent\n \nworking\n \ndirectory\n\n \nquit\n \nExit\n \nthe\n \napplication\n\n \nset\n \n[\nlogging\n|\nheapdump\n]\n \nSets\n \noptions\n \nfor\n \nthe\n \nspecified\n \ncommand\n\n \nset\n \nheapdump\n \nconfigures\n \nheapdump\n \nformat\n,\n \nfilename\n \nand\n \nmultiple\n \nheap\n \nsupport\n\n \nset\n \nlogging\n \nconfigures\n \nseveral\n \nlogging\n-\nrelated\n \nparameters\n,\n \nstarts\n/\nstops\n \nlogging\n\n \non\n \nturn\n \non\n \nlogging\n\n \noff\n \nturn\n \noff\n \nlogging\n\n \nfile\n \nturn\n \non\n \nlogging\n\n \noverwrite\n \ncontrols\n \nthe\n \noverwriting\n \nof\n \nlog\n \nfiles\n\n \nshow\n \n[\nlogging\n|\nheapdump\n]\n \nDisplays\n \nthe\n \ncurrent\n \nset\n \noptions\n \nfor\n \na\n \ncommand\n\n \nshow\n \nheapdump\n \ndisplays\n \nheapdump\n \nsettings\n\n \nshow\n \nlogging\n \nshows\n \nthe\n \ncurrent\n \nlogging\n \noptions\n\n \nwhatis\n \n[\nhex\n \naddress\n]\n \ngives\n \ninformation\n \nabout\n \nwhat\n \nis\n \nstored\n \nat\n \nthe\n \ngiven\n \nmemory\n \naddress\n\n \nx\n/\nd\n \n<\nhex\n \naddress\n>\n \ndisplays\n \nthe\n \ninteger\n \nat\n \nthe\n \nspecified\n \naddress\n\n \nx\n/\nj\n \n<\nobject\n \naddress\n>\n \n[\nclass\n \nname\n]\n \ndisplays\n \ninformation\n \nabout\n \na\n \nparticular\n \nobject\n \nor\n \nall\n \nobjects\n \nof\n \na\n \nclass\n\n \nx\n/\nk\n \n<\nhex\n \naddress\n>\n \ndisplays\n \nthe\n \nspecified\n \nmemory\n \nsection\n \nas\n \nif\n \nit\n \nwere\n \na\n \nstack\n \nframe\n \nparameters\n\n \nx\n/\nx\n \n<\nhex\n \naddress\n>\n \ndisplays\n \nthe\n \nhex\n \nvalue\n \nof\n \nthe\n \nbytes\n \nat\n \nthe\n \nspecified\n \naddress\n\n\n \n>\n \nset\n \nlogging\n \nfile\n \nlog\n.\ntxt\n\n \nlogging\n \nturned\n \non\n;\n \noutputting\n \nto\n \n\"/home/test/log.txt\"\n\n\n \n>\n \ninfo\n \nsystem\n\n \nMachine\n \nOS\n:\n \nLinux\n\n \nHypervisor\n:\n \nPowerVM\n\n \nMachine\n \nname\n:\n \nmadras\n\n \nMachine\n \nIP\n \naddress\n(\nes\n)\n:\n\n \n9.20.88.155\n\n \nSystem\n \nmemory\n:\n \n8269201408\n\n\n \nDump\n \ncreation\n \ntime\n:\n \n2015\n/\n08\n/\n10\n \n14\n:\n44\n:\n36\n:\n01\n9\n\n \nDump\n \ncreation\n \ntime\n \n(\nnanoseconds\n)\n:\n \n21314421467539\n\n\n \nJava\n \nversion\n:\n\n \nJRE\n \n1.8.0\n \nLinux\n \nppc64\n-\n64\n \nbuild\n \n20121115\n_128521\n \n(\npxp6490\n-\n20121116\n_01\n)\n\n\n \nJVM\n \nstart\n \ntime\n:\n \n2015\n/\n08\n/\n10\n \n14\n:\n44\n:\n05\n:\n690\n\n \nJVM\n \nstart\n \ntime\n \n(\nnanoseconds\n)\n:\n \n21284086192267\n\n\n \n>\n \ninfo\n \nthread\n \n*\n\n \nnative\n \nthreads\n \nfor\n \naddress\n \nspace\n\n \nprocess\n \nid\n:\n \n16838\n\n\n \nthread\n \nid\n:\n \n16839\n\n \nregisters\n:\n\n\n \nnative\n \nstack\n \nsections\n:\n\n \nnative\n \nstack\n \nframes\n:\n\n \nproperties\n:\n\n \nassociated\n \nJava\n \nthread\n:\n\n \nname\n:\n \nmain\n\n \nThread\n \nobject\n:\n \njava\n/\nlang\n/\nThread\n \n@\n \n0x2ffd1e08\n\n \nPriority\n:\n \n5\n\n \nThread\n.\nState\n:\n \nRUNNABLE\n\n \nJVMTI\n \nstate\n:\n \nALIVE\n \nRUNNABLE\n\n \nJava\n \nstack\n \nframes\n:\n\n \nbp\n:\n \n0x0000000000085b28\n \nmethod\n:\n \nvoid\n \ncom\n/\nibm\n/\njvm\n/\nDump\n.\nSystemDumpImpl\n()\n \n(\nNative\n \nMethod\n)\n\n \nobjects\n:\n \n<\nno\n \nobjects\n \nin\n \nthis\n \nframe\n>\n\n \nbp\n:\n \n0x0000000000085b40\n \nmethod\n:\n \nvoid\n \ncom\n/\nibm\n/\njvm\n/\nDump\n.\nSystemDump\n()\n \nsource\n:\n \nDump\n.\njava\n:\n41\n\n \nobjects\n:\n \n<\nno\n \nobjects\n \nin\n \nthis\n \nframe\n>\n\n \nbp\n:\n \n0x0000000000085b68\n \nmethod\n:\n \nvoid\n \nmySystemDump\n.\nmain\n(\nString\n[])\n \nsource\n:\n \nmySystemDump\n.\njava\n:\n29\n\n \nobjects\n:\n \n<\nno\n \nobjects\n \nin\n \nthis\n \nframe\n>\n\n \n===\nLines\n \nRemoved\n===\n\n\n \nname\n:\n \nGC\n \nSlave\n\n \nid\n:\n \n16860\n\n \nThread\n \nobject\n:\n \njava\n/\nlang\n/\nThread\n \n@\n \n0x3001b980\n\n \nPriority\n:\n \n5\n\n \nThread\n.\nState\n:\n \nWAITING\n\n \nJVMTI\n \nstate\n:\n \nALIVE\n \nWAITING\n \nWAITING_INDEFINITELY\n \nIN_OBJECT_WAIT\n\n \nwaiting\n \nto\n \nbe\n \nnotified\n \non\n:\n \n\"MM_ParallelDispatcher::slaveThread\"\n \nwith\n \nID\n \n0x1004cbc8\n \nowner\n \nname\n:\n \n<\nunowned\n>\n\n \nJava\n \nstack\n \nframes\n:\n \n<\nno\n \nframes\n \nto\n \nprint\n>\n\n\n \nname\n:\n \nGC\n \nSlave\n\n \nid\n:\n \n16861\n\n \nThread\n \nobject\n:\n \njava\n/\nlang\n/\nThread\n \n@\n \n0x3001c180\n\n \nPriority\n:\n \n5\n\n \nThread\n.\nState\n:\n \nWAITING\n\n \nJVMTI\n \nstate\n:\n \nALIVE\n \nWAITING\n \nWAITING_INDEFINITELY\n \nIN_OBJECT_WAIT\n\n \nwaiting\n \nto\n \nbe\n \nnotified\n \non\n:\n \n\"MM_ParallelDispatcher::slaveThread\"\n \nwith\n \nID\n \n0x1004cbc8\n \nowner\n \nname\n:\n \n<\nunowned\n>\n\n \nJava\n \nstack\n \nframes\n:\n \n<\nno\n \nframes\n \nto\n \nprint\n>\n\n\n \nname\n:\n \nSignal\n \nDispatcher\n\n \nid\n:\n \n16847\n\n \nThread\n \nobject\n:\n \ncom\n/\nibm\n/\nmisc\n/\nSignalDispatcher\n \n@\n \n0x3000f268\n\n \nPriority\n:\n \n5\n\n \nThread\n.\nState\n:\n \nRUNNABLE\n\n \nJVMTI\n \nstate\n:\n \nALIVE\n \nRUNNABLE\n\n \nJava\n \nstack\n \nframes\n:\n\n \nbp\n:\n \n0x00000000000df748\n \nmethod\n:\n \nint\n \ncom\n/\nibm\n/\nmisc\n/\nSignalDispatcher\n.\nwaitForSignal\n()\n \n(\nNative\n \nMethod\n)\n\n \nobjects\n:\n \n<\nno\n \nobjects\n \nin\n \nthis\n \nframe\n>\n\n \nbp\n:\n \n0x00000000000df788\n \nmethod\n:\n \nvoid\n \ncom\n/\nibm\n/\nmisc\n/\nSignalDispatcher\n.\nrun\n()\n \nsource\n:\n \nSignalDispatcher\n.\njava\n:\n54\n\n \nobjects\n:\n \n0x30015828\n \n0x30015828\n\n \n===\nLines\n \nRemoved\n===\n\n\n\n \n>\n \ninfo\n \nheap\n \n*\n\n\n \nHeap\n \n#\n1\n:\n \nGenerational\n@\nfff78303d30\n\n \nSection\n \n#\n1\n:\n \nHeap\n \nextent\n \nat\n \n0x100d0000\n \n(\n0x300000\n \nbytes\n)\n\n \nSize\n:\n \n3145728\n \nbytes\n\n \nShared\n:\n \nfalse\n\n \nExecutable\n:\n \nfalse\n\n \nRead\n \nOnly\n:\n \nfalse\n\n \nSection\n \n#\n2\n:\n \nHeap\n \nextent\n \nat\n \n0x2ffd0000\n \n(\n0x80000\n \nbytes\n)\n\n \nSize\n:\n \n524288\n \nbytes\n\n \nShared\n:\n \nfalse\n\n \nExecutable\n:\n \nfalse\n\n \nRead\n \nOnly\n:\n \nfalse\n\n \nSection\n \n#\n3\n:\n \nHeap\n \nextent\n \nat\n \n0x30050000\n \n(\n0x80000\n \nbytes\n)\n\n \nSize\n:\n \n524288\n \nbytes\n\n \nShared\n:\n \nfalse\n\n \nExecutable\n:\n \nfalse\n\n \nRead\n \nOnly\n:\n \nfalse\n\n\n \n>\n \ninfo\n \nclass\n \njava\n/\nlang\n/\nString\n\n \nname\n \n=\n \njava\n/\nlang\n/\nString\n\n\n \nID\n \n=\n \n0x37c00\n \nsuperID\n \n=\n \n0x30300\n\n \nclassLoader\n \n=\n \n0x2ffe9b58\n \nmodifiers\n:\n \npublic\n \nfinal\n\n\n \nnumber\n \nof\n \ninstances\n:\n \n2146\n\n \ntotal\n \nsize\n \nof\n \ninstances\n:\n \n51504\n \nbytes\n\n\n \nInheritance\n \nchain\n....\n\n \njava\n/\nlang\n/\nObject\n\n \njava\n/\nlang\n/\nString\n\n\n \nFields\n......\n\n \nstatic\n \nfields\n \nfor\n \n\"java/lang/String\"\n\n \nprivate\n \nstatic\n \nfinal\n \nlong\n \nserialVersionUID\n \n=\n \n-\n6849794470754667710\n \n(\n0xa0f0a4387a3bb342\n)\n\n \npublic\n \nstatic\n \nfinal\n \njava\n.\nutil\n.\nComparator\n \nCASE_INSENSITIVE_ORDER\n \n=\n \n<\nobject\n>\n \n@\n \n0x2ffd0278\n\n \nprivate\n \nstatic\n \nfinal\n \nchar\n[]\n \nascii\n \n=\n \n<\nobject\n>\n \n@\n \n0x2ffd02c8\n\n \nprivate\n \nstatic\n \nString\n[]\n \nstringArray\n \n=\n \n<\nobject\n>\n \n@\n \n0x2ffd0298\n\n \nprivate\n \nstatic\n \nfinal\n \nint\n \nstringArraySize\n \n=\n \n10\n \n(\n0xa\n)\n\n \nstatic\n \nboolean\n \nenableCopy\n \n=\n \nfalse\n\n \nprivate\n \nstatic\n \nint\n \nseed\n \n=\n \n-\n126504465\n \n(\n0xfffffffff875b1ef\n)\n\n \nprivate\n \nstatic\n \nchar\n[]\n \nstartCombiningAbove\n \n=\n \n<\nobject\n>\n \n@\n \n0x100d0c40\n\n \nprivate\n \nstatic\n \nchar\n[]\n \nendCombiningAbove\n \n=\n \n<\nobject\n>\n \n@\n \n0x100d0cc0\n\n \nprivate\n \nstatic\n \nfinal\n \nchar\n[]\n \nupperValues\n \n=\n \n<\nobject\n>\n \n@\n \n0x100d0d40\n\n \nprivate\n \nstatic\n \nfinal\n \njava\n.\nio\n.\nObjectStreamField\n[]\n \nserialPersistentFields\n \n=\n \n<\nobject\n>\n \n@\n \n0x2ffd0920\n\n\n \nnon\n-\nstatic\n \nfields\n \nfor\n \n\"java/lang/String\"\n\n \nprivate\n \nfinal\n \nchar\n[]\n \nvalue\n\n \nprivate\n \nfinal\n \nint\n \noffset\n\n \nprivate\n \nfinal\n \nint\n \ncount\n\n \nprivate\n \nint\n \nhashCode\n\n \nprivate\n \nint\n \nhashCode32\n\n\n \nMethods\n......\n\n\n \nBytecode\n \nrange\n(\ns\n)\n:\n \n:\n \nprivate\n \nstatic\n \nnative\n \nint\n \ngetSeed\n()\n\n \nBytecode\n \nrange\n(\ns\n)\n:\n \nfff76d8ce48\n \n--\n \nfff76d8ce5e\n:\n \npublic\n \nvoid\n \n<\ninit\n>\n()\n\n \nBytecode\n \nrange\n(\ns\n)\n:\n \nfff76d8ce88\n \n--\n \nfff76d8cecd\n:\n \nprivate\n \nvoid\n \n<\ninit\n>\n(\nString\n,\n \nchar\n)\n\n \nBytecode\n \nrange\n(\ns\n)\n:\n \nfff76d8cf10\n \n--\n \nfff76d8cf19\n:\n \npublic\n \nvoid\n \n<\ninit\n>\n(\nbyte\n[])\n\n \nBytecode\n \nrange\n(\ns\n)\n:\n \nfff76d8cf40\n \n--\n \nfff76d8cf4a\n:\n \npublic\n \nvoid\n \n<\ninit\n>\n(\nbyte\n[],\n \nint\n)\n\n \nBytecode\n \nrange\n(\ns\n)\n:\n \nfff76d8cf7c\n \n--\n \nfff76d8cfb5\n:\n \npublic\n \nvoid\n \n<\ninit\n>\n(\nbyte\n[],\n \nint\n,\n \nint\n)\n\n \nBytecode\n \nrange\n(\ns\n)\n:\n \nfff76d8cff8\n \n--\n \nfff76d8d065\n:\n \npublic\n \nvoid\n \n<\ninit\n>\n(\nbyte\n[],\n \nint\n,\n \nint\n,\n \nint\n)\n\n \nBytecode\n \nrange\n(\ns\n)\n:\n \nfff76d8d0c4\n \n--\n \nfff76d8d10c\n:\n \npublic\n \nvoid\n \n<\ninit\n>\n(\nbyte\n[],\n \nint\n,\n \nint\n,\n \nString\n)\n\n \n===\nLines\n \nRemoved\n===\n\n\n \n>\n \nwhatis\n \n0x2ffd0298\n\n \nheap\n \n#\n1\n \n-\n \nname\n:\n \nGenerational\n@\nfff78303d30\n\n \n0x2ffd0298\n \nis\n \nwithin\n \nheap\n \nsegment\n:\n \n2ff\nd0000\n \n--\n \n30050000\n\n \n0x2ffd0298\n \nis\n \nthe\n \nstart\n \nof\n \nan\n \nobject\n \nof\n \ntype\n \n[\nLjava\n/\nlang\n/\nString\n;",
"title": "Dump viewer"
},
{
"location": "/tool_jdmpview/#dump-viewer-jdmpview",
"text": "The dump viewer is a command-line tool that allows you to examine the contents of system dumps produced from the OpenJ9 VM. The dump viewer allows you to view both Java\u2122 and native information from the time the dump was produced. For long running tasks, the dump viewer can also be run in batch mode. The dump viewer is useful for diagnosing OutOfMemoryError exceptions in Java\u2122 applications. For problems like general protection faults (GPF), system abends, and SIGSEVs, a system debugger such as gdb (Linux) provides more information.",
"title": "Dump viewer (jdmpview)"
},
{
"location": "/tool_jdmpview/#syntax",
"text": "",
"title": "Syntax"
},
{
"location": "/tool_jdmpview/#starting-the-dump-viewer",
"text": "jdmpview -core <core file> Where <core file> specifies a dump file. On z/OS\u00ae, you can copy the dump to an HFS file and supply that as input to jdmpview , or you can supply a fully qualified MVS\u2122 data set name. For example: > jdmpview -core USER1.JVM.TDUMP.SSHD6.D070430.T092211\nDTFJView version 4.28.3, using DTFJ version 1.11.28004\nLoading image from DTFJ... MVS data set names may contain the dollar sign ($). Names that contain a dollar sign must be enclosed by single quotation marks ('). For example: > jdmpview -core 'USER1.JVM.$TDUMP.SSH$D7.D141211.T045506' After jdmpview processes the dump files, a session starts, showing this message: For a list of commands, type \"help\"; for how to use \"help\", type \"help help\"\n> If you run the jdmpview tool on a compressed file that contains multiple dumps, the tool detects and shows all the dump files, whether these are system dumps, Java dumps, or heap dumps. Because of this behavior, more than one context might be displayed when you start jdmpview . To switch context, type context <n> , where <n> is the context value for the dump you want to investigate. On z/OS, a system dump can contain multiple address spaces and an address space can contain multiple VM instances. In this case, the context allows you to select the address space and VM instance within the dump file. The following z/OS example shows address spaces ( ASID ), with two JVMs occupying address space 0x73 (context 5 and 6). The current context is 5 ( CTX:5> ), shown with an asterisk. To view the JVM in context 6, you can switch by specifying context 6 . CTX : 5 > context Available contexts (* = currently selected context ) : 0 : ASID : 0x1 : No JRE : No JRE 1 : ASID : 0x3 : No JRE : No JRE 2 : ASID : 0x4 : No JRE : No JRE 3 : ASID : 0x6 : No JRE : No JRE 4 : ASID : 0x7 : No JRE : No JRE * 5 : ASID : 0x73 EDB : 0x83d2053a0 : JRE 1.8 . 0 z / OS s390x - 64 build 20181117 _128845 ( pmz6480 - 20181120 _01 ) 6 : ASID : 0x73 EDB : 0x8004053a0 : JRE 1.8 . 0 z / OS s390x - 64 build 20181117 _128845 ( pmz6480 - 20181120 _01 ) 7 : ASID : 0x73 EDB : 0x4a7bd9e8 : No JRE 8 : ASID : 0xffff : No JRE : No JRE If you are using jdmpview to view Java dumps and heap dumps, some options do not produce any output. For example, a heap dump doesn't contain the information requested by the info system command, but does contain information requested by the info class command. If you are viewing a dump where there are a large number of objects on the heap, you can speed up the performance of jdmpview by ensuring that your system has enough memory available and does not need to page memory to disk. To achieve this, start jdmpview with a larger heap size by specifying the -Xmx option. Use the -J option to pass the -Xmx command line option to the JVM. For example: jdmpview -J-Xmx<n> -core <core file> The options available to the dump viewer session are shown under Session parameters",
"title": "Starting the dump viewer"
},
{
"location": "/tool_jdmpview/#starting-in-batch-mode",
"text": "For long running or routine jobs, jdmpview can be used in batch mode. You can run a single command without specifying a command file by appending the command to the end of the jdmpview command line. For example: jdmpview -core mycore.dmp info class When specifying jdmpview commands that accept a wildcard parameter, you must replace the wildcard symbol with ALL to prevent the shell interpreting the wildcard symbol. For example, in interactive mode, the command info thread * must be specified in the following way: jdmpview -core mycore.dmp info thread ALL Batch mode is controlled with the following command line options: Option Explanation -cmdfile <path to command file> A file that contains a series of jdmpview commands, which are read and run sequentially. -charset <character set name> The character set for the commands specified in -cmdfile (name must be a supported charset as defined in java.nio.charset.Charset. For example, US-ASCII) -outfile <path to output file> The file to record any output generated by commands. -overwrite If the file specified in -outfile exists, this option overwrites the file. -append If the file specified in -outfile exists, new output messages are appended to the end of that file. The -append and -overwrite options cannot be used at the same time. The command file can have empty lines that contain spaces, or comment lines that start with // or #. These lines are ignored by jdmpview. Example command file: // commands.txt\ninfo system\ninfo proc To run jdmpview in batch mode, using this command file, specify: jdmpview -outfile out.txt [-overwrite|-append] -cmdfile commands.txt -core <path to core file> When the output file exists, you need to specify either the -overwrite option or the -append option. If you do not, an error message is generated.",
"title": "Starting in batch mode"
},
{
"location": "/tool_jdmpview/#processing-output",
"text": "You can redirect command output to a file, or pipe the command output to another command. To redirect jdmpview command output to a file, use one of the following formats: command > <target_file> If the target file exists, this redirection overwrites the content within it. command >> <target_file> If the target file exists, this redirection appends the output to it. Where <target_file> is the file name, which can include the full path to the file. To pipe jdmpview command output to another command, use the vertical bar (|) character. For example: command | grep string You can chain more than two commands together by using multiple vertical bar characters. The following commands can be used to interrogate the output: charsFrom charsTo grep tokens",
"title": "Processing output"
},
{
"location": "/tool_jdmpview/#using-charsfrom",
"text": "Use the charsFrom command after the vertical bar character to exclude all characters that come before a specified pattern in a resulting line. charsFrom <options> pattern Where <options> : -e or -exclude : Exclude the matched pattern from the resulting line. By default, the matched pattern is included in the resulting line. -keep : Keep lines that do not contain a match to the pattern. By default, lines that do not contain a match are excluded from the results. -i or -ignoreCase : Ignore case. For example, the following command displays resulting lines that contain the pattern jre , and trims each line to exclude all characters that come before this pattern: > info mod | charsFrom jre\njre/lib/ppc64/libzip.so @ 0x0, sections:\njre/lib/ppc64/libdbgwrapper80.so @ 0x0, sections:\njre/lib/ppc64/libverify.so @ 0x0, sections:\njre/lib/ppc64/libjava.so @ 0x0, sections:\njre/lib/ppc64/compressedrefs/libjclse7b_28.so @ 0x0, sections:",
"title": "Using CharsFrom"
},
{
"location": "/tool_jdmpview/#using-charsto",
"text": "Use the CharsTo command after the vertical bar character to include the characters in a resulting line until a specific pattern is found. charsTo <options> pattern Where <options> : -include : Include the matched pattern in the resulting line. By default, the matched pattern is excluded from the resulting line. -keep : Keep lines that do not contain a match to the pattern. By default, lines that do not contain a match are excluded from the results. -i or -ignoreCase : Ignore case. For example, the following command displays lines that contain the pattern \"@\", and trims each line to exclude all characters from \"@\" onwards: > info mod | charsTo @\nbin/java\n/usr/lib64/gconv/UTF-16.so\n/test/sdk/lib/ppc64le/libnet.so\n/test/sdk/lib/ppc64le/libnio.so\n/test/sdk/lib/ppc64le/libzip.so\n/test/sdk/lib/ppc64le/libjsig.so\nlibjsig.so You can also use charsFrom and charsTo together, separated by a vertical bar character. For example, the following command displays lines that contain the pattern \"lib\", and trims each line to exclude all characters that come before this pattern, as well as all characters from the pattern @ : > info mod | charsFrom lib | charsTo @\nlib/ppc64le/libzip.so\nlib/ppc64le/libjsig.so\nlib/ppc64le/libverify.so\nlib/ppc64le/libjava.so\nlib/ppc64le/compressedrefs/libj9jit29.so Note: The line will not be displayed if the charsFrom and charsTo are used together, but only one of the patterns are matched in a line. Furthermore, the line will not be displayed if both patterns are matched in a line, but the charsTo pattern appears before, and not after, the charsFrom pattern.",
"title": "Using CharsTo"
},
{
"location": "/tool_jdmpview/#using-grep",
"text": "Use the grep command after the vertical bar character to show which lines match a specified pattern. grep <options> pattern Where <options> : -i : Ignore case. -r , -G , or --regex : Use a regular expression as defined in the Java documentation of the java.utils.regex.Pattern class. -b or --block : Show blocks of lines where at least one of the lines matches the pattern. Blocks of lines are separated by empty lines. -A <NUM> or +<NUM> : Show at most <NUM> lines after the matching line. For example grep -A 2 pattern or grep +2 pattern. -B <NUM> or -<NUM> : Show at most <NUM> lines before the matching line. -C <NUM> or +-<NUM> : Show at most <NUM> lines before and after the matching line. -v or --invert-match : Use with the grep command to show lines that do not match the pattern. These options are equivalent to the grep- command. -F or --fixed-strings : Do not treat the asterisk (*) as a wildcard character. Use these options with the -r , -G , or --regex options. Pattern rules: An asterisk (*) in a pattern is treated as a wildcard character unless you specify the -F or --fixed-strings options. If a pattern contains spaces, enclose the pattern in a pair of double quotation marks (\"). If a pattern contains double quotation marks, enclose the pattern in a pair of single quotation marks ('). You can specify multiple sub-patterns to match by using the following format, but only if you do not use the -r , -G , or --regex options: \"[pattern1|pattern2|...|patternN]\" The initial and trailing double quotation marks and brackets ([ ]) are required. Use a vertical bar character to separate the sub-patterns. Quotation marks and the vertical bar are not allowed in a sub-pattern. Spaces are allowed in the middle of a sub-pattern, but leading and trailing spaces will be trimmed. Use the grep command to show lines that do not match the pattern. For example, the following command displays the number of instances and total heap size for the java/lang/String class: > info class | grep java/lang/String \n94 7688 [Ljava/lang/String; \n1822 58304 java/lang/String \n1 16 java/lang/String$CaseInsensitiveComparator \n0 0 java/lang/String$UnsafeHelpers The following command uses two pipes in combination to display the number of instances and total heap size for the java/lang/StringCoding.StringDecoder class: > info class | grep java/lang/String | grep -i decoder\n1 48 java/lang/StringCoding$StringDecoder",
"title": "Using grep"
},
{
"location": "/tool_jdmpview/#using-tokens",
"text": "Use the tokens command after the vertical bar character to isolate specified tokens in the resulting lines. tokens [options] range[,range][..range] You can define range in the following formats: x x,y x..y A set of rules applies to these formats: x or y can be prefixed with \"-\". This means that x or y are counting backwards from the end of a list. For example, a y value of -1 represents the last token in a list, while -2 represents the penultimate token in a list. x must represent a token that either precedes or is at the same position as y. In this format, if x is omitted, it is assumed to be '1'. If y is omitted, it is assumed to be '-1'. For example, the following command displays the first and second token for each resulting line: > info mmap | grep -r ^0x | tokens 1,2\n0x0000000000012fff 0x000000000000d000\n0x0000000000017fff 0x0000000000004000\n0x00000000009dafff 0x0000000000018000\n0x00000000009fffff 0x000000000001f000\n0x0000000000cbefff 0x0000000000002000\n0x0000000000d76fff 0x0000000000001000\n0x0000000003145fff 0x0000000000071000\n0x0000000003b93fff 0x0000000000003000",
"title": "Using tokens"
},
{
"location": "/tool_jdmpview/#session-parameters",
"text": "When jdmpview is started, many parameters can be used during the session to interrogate the system dump data, which are divided into general and expert parameters. The general parameters are documented in this section. To see a list of expert parameters, use the !j9help option.",
"title": "Session parameters"
},
{
"location": "/tool_jdmpview/#j9help",
"text": "!j9help Lists all expert parameters that can be used in a session, with a brief description.",
"title": "!j9help"
},
{
"location": "/tool_jdmpview/#cd",
"text": "cd <directory_name> Changes the working directory to <directory_name> . The working directory is used for log files. Logging is controlled by the set logging command. Use the pwd command to query the current working directory.",
"title": "cd"
},
{
"location": "/tool_jdmpview/#cmdfile",
"text": "cmdfile <directory_name> Runs all of the commands in a file. The commands are read line by line and run sequentially. Empty lines, and lines that start with // or # , are ignored. Use the option charset to identify the character set that is used in the chosen file. The character set must be supported, as defined in java.nio.charset.Charset , such as US-ASCII .",
"title": "cmdfile"
},
{
"location": "/tool_jdmpview/#deadlock",
"text": "This command detects deadlock situations in the Java application that was running when the system dump was produced. Example output: deadlock loop:\nthread: Thread-2 (monitor object: 0x9e32c8) waiting for =>\nthread: Thread-3 (monitor object: 0x9e3300) waiting for =>\nthread: Thread-2 (monitor object: 0x9e32c8) In this example, the deadlock analysis shows that Thread-2 is waiting for a lock held by Thread-3 , which is in turn waiting for a lock held earlier by Thread-2 . Threads are identified by their Java thread name, whereas object monitors are identified by the address of the object in the Java heap. You can obtain further information about the threads using the info thread * command. You can obtain further information about the monitors using the x/J <0xaddr> command.",
"title": "deadlock"
},
{
"location": "/tool_jdmpview/#find",
"text": "find <pattern>,<start_address>,<end_address>,<memory_boundary>, <bytes_to_print>,<matches_to_display> This command searches for <pattern> in the memory segment from <start_address> to <end_address> (both inclusive), and shows the number of matching addresses you specify with <matches_to_display> . You can also display the next <bytes_to_print> bytes for the last match. By default, the find command searches for the pattern at every byte in the range. If you know the pattern is aligned to a particular byte boundary, you can specify <memory_boundary> to search every <memory_boundary> bytes. For example, if you specify a <memory_boundary> of \"4\", the command searches for the pattern every 4 bytes.",
"title": "find"
},
{
"location": "/tool_jdmpview/#findnext",
"text": "findptr <pattern>,<start_address>,<end_address>,<memory_boundary>,<bytes_to_print>,<matches_to_display> Finds the next instance of the last string passed to find or findptr . It repeats the previous find or findptr command, depending on which one was issued last, starting from the last match. Searches memory for the given pointer. findptr searches for <pattern> as a pointer in the memory segment from <start_address> to <end_address> (both inclusive), and shows the number of matching addresses you specify with <matches_to_display> . You can also display the next <bytes_to_print> bytes for the last match. By default, the findptr command searches for the pattern at every byte in the range. If you know the pattern is aligned to a particular byte boundary, you can specify <memory_boundary> to search every <memory_boundary> bytes. For example, if you specify a <memory_boundary> of \"4\", the command searches for the pattern every 4 bytes.",
"title": "findnext"
},
{
"location": "/tool_jdmpview/#help",
"text": "help [<command_name>] Shows information for a specific command. If you supply no parameters, help shows the complete list of supported commands.",
"title": "help"
},
{
"location": "/tool_jdmpview/#history",
"text": "history|his [-r][<N>] Recalls and displays the history of commands that you have run. The default behavior is to display the 20 most recent commands. If you use the argument <N> , then N commands are displayed. For example, if you run history 35, then the 35 most recent commands are displayed. You can also use the -r option with <N> to run the Nth most recent command in your history. Using the -r option alone runs the most recent command in your history.",
"title": "history"
},
{
"location": "/tool_jdmpview/#info-thread",
"text": "info thread [*|all|<native_thread_ID>|<zos_TCB_address>] Displays information about Java and native threads. The following information is displayed for all threads (\"*\"), or the specified thread: Thread id Registers Stack sections Thread frames: procedure name and base pointer Thread properties: list of native thread properties and their values. For example: thread priority. Associated Java thread, if applicable: Name of Java thread Address of associated java.lang.Thread object State (shown in JVMTI and java.lang.Thread.State formats) The monitor the thread is waiting for Thread frames: base pointer, method, and filename:line If you supply no parameters, the command shows information about the current thread.",
"title": "info thread"
},
{
"location": "/tool_jdmpview/#info-system",
"text": "Displays the following information about the system that produced the core dump: Amount of memory Operating system Virtual machine or virtual machines present",
"title": "info system"
},
{
"location": "/tool_jdmpview/#info-class",
"text": "info class [<class_name>] [-sort:<name>|<count>|<size>] Displays the inheritance chain and other data for a given class. If a class name is passed to info class, the following information is shown about that class: - Name\n- ID\n- Superclass ID\n- Class loader ID\n- Modifiers\n- Number of instances and total size of instances\n- Inheritance chain\n- Fields with modifiers (and values for static fields)\n- Methods with modifiers\n\nIf no parameters are passed to `info class`, the following information is shown:\n\n- The number of instances of each class.\n- The total size of all instances of each class.\n- The class name\n- The total number of instances of all classes.\n- The total size of all objects.\n\nThe `sort` option allows the list of classes to be sorted by name (default), by number of instances of each class, or by the total size of instances of each class.",
"title": "info class"
},
{
"location": "/tool_jdmpview/#info-proc",
"text": "Displays threads, command-line arguments, environment variables, and shared modules of the current process. To view the shared modules used by a process, use the info sym command.",
"title": "info proc"
},
{
"location": "/tool_jdmpview/#info-jitm",
"text": "Displays JIT compiled methods and their addresses: Method name and signature Method start address Method end address",
"title": "info jitm"
},
{
"location": "/tool_jdmpview/#info-lock",
"text": "Displays a list of available monitors and locked objects.",
"title": "info lock"
},
{
"location": "/tool_jdmpview/#info-sym",
"text": "Displays a list of available modules. For each process in the address spaces, this command shows a list of module sections for each module, their start and end addresses, names, and sizes.",
"title": "info sym"
},
{
"location": "/tool_jdmpview/#info-mmap",
"text": "info mmap [<address>] [-verbose] [-sort:<size>|<address>] Displays a summary list of memory sections in the process address space, with start and end address, size, and properties. If an address parameter is specified, the results show details of only the memory section containing the address. If -verbose is specified, full details of the properties of each memory section are displayed. The -sort option allows the list of memory sections to be sorted by size or by start address (default).",
"title": "info mmap"
},
{
"location": "/tool_jdmpview/#info-heap",
"text": "info heap [*|<heap_name>*] If no parameters are passed to this command, the heap names and heap sections are shown. Using either \"*\" or a heap name shows the following information about all heaps or the specified heap: Heap name (Heap size and occupancy) Heap sections Section name Section size Whether the section is shared Whether the section is executable Whether the section is read only",
"title": "info heap"
},
{
"location": "/tool_jdmpview/#heapdump",
"text": "heapdump [<heaps>] Generates a Java heap dump to a file. You can select which Java heaps to dump by listing the heap names, separated by spaces. To see which heaps are available, use the info heap command. By default, all Java heaps are dumped.",
"title": "heapdump"
},
{
"location": "/tool_jdmpview/#hexdump",
"text": "hexdump <hex_address> <bytes_to_print> Displays a section of memory in a hexdump-like format. Displays <bytes_to_print> bytes of memory contents starting from <hex_address> .",
"title": "hexdump"
},
{
"location": "/tool_jdmpview/#_1",
"text": "Displays the next section of memory in hexdump-like format. This command is used with the hexdump command to enable easy scrolling forwards through memory. The previous hexdump command is repeated, starting from the end of the previous one.",
"title": "+"
},
{
"location": "/tool_jdmpview/#-",
"text": "Displays the previous section of memory in hexdump-like format. This command is used with the hexdump command to enable easy scrolling backwards through memory. The previous hexdump command is repeated, starting from a position before the previous one.",
"title": "-"
},
{
"location": "/tool_jdmpview/#pwd",
"text": "Displays the current working directory, which is the directory where log files are stored.",
"title": "pwd"
},
{
"location": "/tool_jdmpview/#quit",
"text": "Exits the core file viewing tool; any log files that are currently open are closed before exit.",
"title": "quit"
},
{
"location": "/tool_jdmpview/#set-heapdump",
"text": "Configures Heapdump generation settings. set heapdump <options> where <options> are: phd : Set the Heapdump format to Portable Heapdump, which is the default. txt : Set the Heapdump format to classic. file <file> : Set the destination of the Heapdump. multiplefiles [on|off] : If multiplefiles is set to on, each Java heap in the system dump is written to a separate file. If multiplefiles is set to off, all Java heaps are written to the same file. The default is off.",
"title": "set heapdump"
},
{
"location": "/tool_jdmpview/#set-logging",
"text": "set logging <options> Configures logging settings, starts logging, or stops logging. This parameter enables the results of commands to be logged to a file, where <options> are: [on|off] : Turns logging on or off. (Default: off) file <filename> : Sets the file to log to. The path is relative to the directory returned by the pwd command, unless an absolute path is specified. If the file is set while logging is on, the change takes effect the next time logging is started. Not set by default. overwrite [on|off] : Turns overwriting of the specified log file on or off. When overwrite is off, log messages are appended to the log file. When overwrite is on, the log file is overwritten after the set logging command. (Default: off) redirect [on|off] : Turns redirecting to file on or off, with off being the default. When logging is set to on: A value of on for redirect sends non-error output only to the log file. A value of off for redirect sends non-error output to the console and log file. Redirect must be turned off before logging can be turned off. (Default: off)",
"title": "set logging"
},
{
"location": "/tool_jdmpview/#show-heapdump",
"text": "Displays the current Heapdump generation settings.",
"title": "show heapdump"
},
{
"location": "/tool_jdmpview/#show-logging",
"text": "Displays the current logging settings: set_logging = [on|off] set_logging_file = set_logging_overwrite = [on|off] set_logging_redirect = [on|off] current_logging_file = The file that is currently being logged to might be different from set_logging_file, if that value was changed after logging was started.",
"title": "show logging"
},
{
"location": "/tool_jdmpview/#whatis-hex_address",
"text": "Displays information about whatis stored at the given memory address, <hex_address> . This command examines the memory location at <hex_address> and tries to find out more information about this address. For example: > whatis 0x8e76a8 heap # 1 - name : Default @19f ce8 0x8e76a8 is within heap segment : 8 b0000 -- cb0000 0x8e76a8 is start of an object of type java / lang / Thread",
"title": "whatis &lt;hex_address&gt;"
},
{
"location": "/tool_jdmpview/#x-examine",
"text": "Passes the number of items to display and the unit size, as listed in the following table, to the sub-command. For example, x/12bd . Abbreviation Unit Size b Byte 8-bit h Half word 16-bit w Word 32-bit g Giant word 64-bit This command is similar to the use of the x/ command in gdb, including the use of defaults.",
"title": "x/ (examine)"
},
{
"location": "/tool_jdmpview/#xj-class_name0xaddr",
"text": "Displays information about a particular object, or all objects of a class. If <class_name> is supplied, all static fields with their values are shown, followed by all objects of that class with their fields and values. If an object address (in hex) is supplied, static fields for that object's class are not shown; the other fields and values of that object are printed along with its address. Note: This command ignores the number of items and unit size passed to it by the x/ command.",
"title": "x/J [&lt;class_name&gt;|&lt;0xaddr&gt;]"
},
{
"location": "/tool_jdmpview/#xd-0xaddr",
"text": "Displays the integer at the specified address, adjusted for the hardware architecture this dump file is from. For example, the file might be from a big endian architecture. This command uses the number of items and unit size passed to it by the x/ command.",
"title": "x/D &lt;0xaddr&gt;"
},
{
"location": "/tool_jdmpview/#xx-0xaddr",
"text": "Displays the hex value of the bytes at the specified address, adjusted for the hardware architecture this dump file is from. For example, the file might be from a big endian architecture. Note: This command uses the number of items and unit size passed to it by the x/ command.",
"title": "x/X &lt;0xaddr&gt;"
},
{
"location": "/tool_jdmpview/#xk-0xaddr",
"text": "Where the size is defined by the pointer size of the architecture, this parameter shows the value of each section of memory. The output is adjusted for the hardware architecture this dump file is from, starting at the specified address. It also displays a module with a module section and an offset from the start of that module section in memory if the pointer points to that module section. If no symbol is found, it displays a \"*\" and an offset from the current address if the pointer points to an address in 4KB (4096 bytes) of the current address. Although this command can work on an arbitrary section of memory, it is probably more useful on a section of memory that refers to a stack frame. To find the memory section of a thread stack frame, use the info thread command. Note: This command uses the number of items and unit size passed to it by the x/ command.",
"title": "x/K &lt;0xaddr&gt;"
},
{
"location": "/tool_jdmpview/#example",
"text": "This example session illustrates a selection of the commands available and their use. In the example session, which is generated on a Linux system, some lines have been removed for clarity (and terseness). User input is prefaced by a greater than symbol (>). test @ madras : ~/ test > sdk / bin / jdmpview - core core .20121116.154147.16838.0001 . dmp \n DTFJView version 4.27.57 , using DTFJ version 1.10.27022 \n Loading image from DTFJ ... \n\n For a list of commands , type \"help\" ; for how to use \"help\" , type \"help help\" \n Available contexts ( * = currently selected context ) : \n\n Source : file : ///home/test/core.20121116.154147.16838.0001.dmp \n * 0 : PID : 16867 : JRE 1.8.0 Linux ppc64 - 64 build 20121115 _128521 ( pxp6480 - 20121116 _01 ) \n\n > help \n + displays the next section of memory in hexdump - like format \n - displays the previous section of memory in hexdump - like format \n cd changes the current working directory , used for log files \n close [ context id ] closes the connection to a core file \n context [ ID | asid ID ] switch to the selected context \n deadlock displays information about deadlocks if there are any \n exit Exit the application \n find searches memory for a given string \n findnext finds the next instance of the last string passed to \"find\" \n findptr searches memory for the given pointer \n heapdump generates a PHD or classic format heapdump \n help [ command name ] displays list of commands or help for a specific command \n hexdump outputs a section of memory in a hexdump - like format \n info < component > Information about the specified component \n info class < Java class name > Provides information about the specified Java class \n info heap [ *| heap name ] Displays information about Java heaps \n info jitm Displays JIT ' ed methods and their addresses \n info lock outputs a list of system monitors and locked objects \n info mmap Outputs a list of all memory segments in the address space \n info mod outputs module information \n info proc shortened form of info process \n info process displays threads , command line arguments , environment \n info sym an alias for ' mod ' \n info sys shortened form of info system \n info system displays information about the system the core dump is from \n info thread displays information about Java and native threads \n log [ name level ] display and control instances of java . util . logging . Logger \n open [ path to core ] opens the specified core file \n plugins Plugin management commands \n list Show the list of loaded plugins for the current context \n reload Reload plugins for the current context \n showpath Show the DTFJ View plugin search path for the current context \n setpath Set the DTFJ View plugin search path for the current context \n pwd displays the current working directory \n quit Exit the application \n set [ logging | heapdump ] Sets options for the specified command \n set heapdump configures heapdump format , filename and multiple heap support \n set logging configures several logging - related parameters , starts / stops logging \n on turn on logging \n off turn off logging \n file turn on logging \n overwrite controls the overwriting of log files \n show [ logging | heapdump ] Displays the current set options for a command \n show heapdump displays heapdump settings \n show logging shows the current logging options \n whatis [ hex address ] gives information about what is stored at the given memory address \n x / d < hex address > displays the integer at the specified address \n x / j < object address > [ class name ] displays information about a particular object or all objects of a class \n x / k < hex address > displays the specified memory section as if it were a stack frame parameters \n x / x < hex address > displays the hex value of the bytes at the specified address \n\n > set logging file log . txt \n logging turned on ; outputting to \"/home/test/log.txt\" \n\n > info system \n Machine OS : Linux \n Hypervisor : PowerVM \n Machine name : madras \n Machine IP address ( es ) : \n 9.20.88.155 \n System memory : 8269201408 \n\n Dump creation time : 2015 / 08 / 10 14 : 44 : 36 : 01 9 \n Dump creation time ( nanoseconds ) : 21314421467539 \n\n Java version : \n JRE 1.8.0 Linux ppc64 - 64 build 20121115 _128521 ( pxp6490 - 20121116 _01 ) \n\n JVM start time : 2015 / 08 / 10 14 : 44 : 05 : 690 \n JVM start time ( nanoseconds ) : 21284086192267 \n\n > info thread * \n native threads for address space \n process id : 16838 \n\n thread id : 16839 \n registers : \n\n native stack sections : \n native stack frames : \n properties : \n associated Java thread : \n name : main \n Thread object : java / lang / Thread @ 0x2ffd1e08 \n Priority : 5 \n Thread . State : RUNNABLE \n JVMTI state : ALIVE RUNNABLE \n Java stack frames : \n bp : 0x0000000000085b28 method : void com / ibm / jvm / Dump . SystemDumpImpl () ( Native Method ) \n objects : < no objects in this frame > \n bp : 0x0000000000085b40 method : void com / ibm / jvm / Dump . SystemDump () source : Dump . java : 41 \n objects : < no objects in this frame > \n bp : 0x0000000000085b68 method : void mySystemDump . main ( String []) source : mySystemDump . java : 29 \n objects : < no objects in this frame > \n === Lines Removed === \n\n name : GC Slave \n id : 16860 \n Thread object : java / lang / Thread @ 0x3001b980 \n Priority : 5 \n Thread . State : WAITING \n JVMTI state : ALIVE WAITING WAITING_INDEFINITELY IN_OBJECT_WAIT \n waiting to be notified on : \"MM_ParallelDispatcher::slaveThread\" with ID 0x1004cbc8 owner name : < unowned > \n Java stack frames : < no frames to print > \n\n name : GC Slave \n id : 16861 \n Thread object : java / lang / Thread @ 0x3001c180 \n Priority : 5 \n Thread . State : WAITING \n JVMTI state : ALIVE WAITING WAITING_INDEFINITELY IN_OBJECT_WAIT \n waiting to be notified on : \"MM_ParallelDispatcher::slaveThread\" with ID 0x1004cbc8 owner name : < unowned > \n Java stack frames : < no frames to print > \n\n name : Signal Dispatcher \n id : 16847 \n Thread object : com / ibm / misc / SignalDispatcher @ 0x3000f268 \n Priority : 5 \n Thread . State : RUNNABLE \n JVMTI state : ALIVE RUNNABLE \n Java stack frames : \n bp : 0x00000000000df748 method : int com / ibm / misc / SignalDispatcher . waitForSignal () ( Native Method ) \n objects : < no objects in this frame > \n bp : 0x00000000000df788 method : void com / ibm / misc / SignalDispatcher . run () source : SignalDispatcher . java : 54 \n objects : 0x30015828 0x30015828 \n === Lines Removed === \n\n\n > info heap * \n\n Heap # 1 : Generational @ fff78303d30 \n Section # 1 : Heap extent at 0x100d0000 ( 0x300000 bytes ) \n Size : 3145728 bytes \n Shared : false \n Executable : false \n Read Only : false \n Section # 2 : Heap extent at 0x2ffd0000 ( 0x80000 bytes ) \n Size : 524288 bytes \n Shared : false \n Executable : false \n Read Only : false \n Section # 3 : Heap extent at 0x30050000 ( 0x80000 bytes ) \n Size : 524288 bytes \n Shared : false \n Executable : false \n Read Only : false \n\n > info class java / lang / String \n name = java / lang / String \n\n ID = 0x37c00 superID = 0x30300 \n classLoader = 0x2ffe9b58 modifiers : public final \n\n number of instances : 2146 \n total size of instances : 51504 bytes \n\n Inheritance chain .... \n java / lang / Object \n java / lang / String \n\n Fields ...... \n static fields for \"java/lang/String\" \n private static final long serialVersionUID = - 6849794470754667710 ( 0xa0f0a4387a3bb342 ) \n public static final java . util . Comparator CASE_INSENSITIVE_ORDER = < object > @ 0x2ffd0278 \n private static final char [] ascii = < object > @ 0x2ffd02c8 \n private static String [] stringArray = < object > @ 0x2ffd0298 \n private static final int stringArraySize = 10 ( 0xa ) \n static boolean enableCopy = false \n private static int seed = - 126504465 ( 0xfffffffff875b1ef ) \n private static char [] startCombiningAbove = < object > @ 0x100d0c40 \n private static char [] endCombiningAbove = < object > @ 0x100d0cc0 \n private static final char [] upperValues = < object > @ 0x100d0d40 \n private static final java . io . ObjectStreamField [] serialPersistentFields = < object > @ 0x2ffd0920 \n\n non - static fields for \"java/lang/String\" \n private final char [] value \n private final int offset \n private final int count \n private int hashCode \n private int hashCode32 \n\n Methods ...... \n\n Bytecode range ( s ) : : private static native int getSeed () \n Bytecode range ( s ) : fff76d8ce48 -- fff76d8ce5e : public void < init > () \n Bytecode range ( s ) : fff76d8ce88 -- fff76d8cecd : private void < init > ( String , char ) \n Bytecode range ( s ) : fff76d8cf10 -- fff76d8cf19 : public void < init > ( byte []) \n Bytecode range ( s ) : fff76d8cf40 -- fff76d8cf4a : public void < init > ( byte [], int ) \n Bytecode range ( s ) : fff76d8cf7c -- fff76d8cfb5 : public void < init > ( byte [], int , int ) \n Bytecode range ( s ) : fff76d8cff8 -- fff76d8d065 : public void < init > ( byte [], int , int , int ) \n Bytecode range ( s ) : fff76d8d0c4 -- fff76d8d10c : public void < init > ( byte [], int , int , String ) \n === Lines Removed === \n\n > whatis 0x2ffd0298 \n heap # 1 - name : Generational @ fff78303d30 \n 0x2ffd0298 is within heap segment : 2ff d0000 -- 30050000 \n 0x2ffd0298 is the start of an object of type [ Ljava / lang / String ;",
"title": "Example"
},
{
"location": "/tool_traceformat/",
"text": "Trace formatter (\ntraceformat\n)\n\n\nThe trace formatter is a Java\u2122 program that converts binary trace point data in a trace file to a readable form. The formatter requires the \nTraceFormat.dat\n and \nJ9TraceFormat.dat\n files, which contain the formatting templates. The formatter produces a file that contains header information about the VM that produced the binary trace file, a list of threads for which trace points were produced, and the formatted trace points with their time stamp, thread ID, trace point ID, and trace point data.\n\n\nSyntax\n\n\nTo use the trace formatter on a binary trace file type:\n\n\n traceformat <input_file> [<output_file>] <parameters>\n\n\n\n\n\nWhere \n<input_file>\n is the name of the binary trace file to be formatted, and \n<output_file>\n is the name of the output file. If you do not specify an output file, the output file is called \ninput_file.fmt\n.\n\n\nThe size of the heap that is needed to format the trace is directly proportional to the number of threads present in the trace file. For large numbers of threads the formatter might run out of memory, generating the error \nOutOfMemoryError\n. In this case, increase the heap size by using the \n-Xmx\n option.\n\n\nParameters\n\n\nThe following \n<parameters>\n are available with the trace formatter:\n\n\n\n\n\n\n\n\nOption\n\n\nExplanation\n\n\n\n\n\n\n\n\n\n\n-datfile=<file1.dat>[,<file2.dat>]\n\n\nA comma-separated list of trace formatting data files. By default, the following files are used:$JAVA_HOME/lib/J9TraceFormat.dat and $JAVA_HOME/lib/TraceFormat.dat\n\n\n\n\n\n\n-format_time=yes|no\n\n\nSpecifies whether to format the time stamps into human readable form. The default is \nyes\n.\n\n\n\n\n\n\n-help\n\n\nDisplays usage information.\n\n\n\n\n\n\n-indent\n\n\nIndents trace messages at each \nEntry\n trace point and outdents trace messages at each \nExit\n trace point. The default is not to indent the messages.\n\n\n\n\n\n\n-summary\n\n\nPrints summary information to the screen without generating an output file.\n\n\n\n\n\n\n-threads=<thread id>[,<thread id>]...\n\n\nFilters the output for the given thread IDs only. thread id is the ID of the thread, which can be specified in decimal or hex (0x) format. Any number of thread IDs can be specified, separated by commas.\n\n\n\n\n\n\n-timezone=+|-HH:MM\n\n\nSpecifies the offset from UTC, as positive or negative hours and minutes, to apply when formatting time stamps.\n\n\n\n\n\n\n-verbose\n\n\nOutput detailed warning and error messages, and performance statistics.\n\n\n\n\n\n\n\n\nExamples\n\n\nThe following example shows output from running the trace formatter command:\n\n\n C:\\test>traceformat sample.trc\n Writing formatted trace output to file sample.trc.fmt\n Processing 0.4921875Mb of binary trace data\n Completed processing of 6983 tracepoints with 0 warnings and 0 errors\n\n\n\n\n\nThe formatted trace output looks similar to the following extract, which is truncated to show the key areas of information:\n\n\n \nTrace\n \nSummary\n\n\n \nService\n \nlevel\n:\n\n \nJRE\n \n1\n.\n8\n.\n0\n \nWindows\n \n7\n \namd64-64\n \nbuild\n \n(\npwa6480sr2-20150624_06\n(\nSR2\n))\n\n\n \nJVM\n \nstartup\n \noptions\n:\n\n \n-Xoptionsfile\n=\nc\n:\n\\\nbuild\n\\\npwa6480sr2-20150624\n\\\nsdk\n\\\nlib\n\\\ncompressedrefs\n\\\noptions\n.\ndefault\n\n \n....\n\n\n \nProcessor\n \ninformation\n:\n\n \nArch\n \nfamily\n:\n \nAMD64\n\n \nProcessor\n \nSub-type\n:\n \nOpteron\n\n \nNum\n \nProcessors\n:\n \n8\n\n \nWord\n \nsize\n:\n \n64\n\n\n \nTrace\n \nactivation\n \ninformation\n::\n\n \nFORMAT\n=\nc\n:\n\\\nbuild\n\\\npwa6480sr2-20150624\n\\\nsdk\n\\\nlib\n;.\n\n \nMAXIMAL\n=\nall\n{\nlevel1\n}\n\n \nEXCEPTION\n=\nj9mm\n{\ngclogger\n}\n\n \nMAXIMAL\n=\nall\n{\nlevel2\n}\n\n \noutput\n=\nsample\n\n\n \nTrace\n \nfile\n \nheader\n:\n\n \nJVM\n \nstart\n \ntime\n:\n \n08\n:\n58\n:\n35\n.\n527000000\n\n \nGenerations\n:\n \n1\n\n \nPointer\n \nsize\n:\n \n8\n\n\n \nActive\n \nthreads\n\n \n....\n\n \n0x000000000f155f00\n \nAttach\n \nAPI\n \nwait\n \nloop\n\n \n0x000000000f18b200\n \nThread-1\n\n \n0x000000000f190200\n \nThread-3\n\n\n\n \nTrace\n \nFormatted\n \nData\n\n\n \nTime\n \n(\nUTC\n)\n \nThread\n \nID\n \nTracepoint\n \nID\n \nType\n \nTracepoint\n \nData\n\n \n08\n:\n58\n:\n35\n.\n527291919\n \n*\n0x000000000f010500\n \nj9trc\n.\n0\n \nEvent\n \nTrace\n \nengine\n \ninitialized\n \nfor\n \nVM\n \n=\n \n0x3ad4d0\n\n \n08\n:\n58\n:\n35\n.\n527349836\n \n0x000000000f010500\n \nj9prt\n.\n0\n \nEvent\n \nTrace\n \nengine\n \ninitialized\n \nfor\n \nmodule\n \nj9port\n\n \n08\n:\n58\n:\n35\n.\n527354040\n \n0x000000000f010500\n \nj9thr\n.\n0\n \nEvent\n \nTrace\n \nengine\n \ninitialized\n \nfor\n \nmodule\n \nj9thr\n\n \n08\n:\n58\n:\n35\n.\n529409621\n \n*\n0x000000000f01eb00\n \nj9trc\n.\n5\n \nEvent\n \nThread\n \nstarted\n \nVMthread\n \n=\n \n0xf01eb00\n,\n \nname\n \n=\n \n(\nunnamed\n \nthread\n),\n \nnativeID\n \n=\n \n0x24a798\n\n \n....\n\n \n08\n:\n58\n:\n35\n.\n536134516\n \n0x000000000f010500\n \nj9vm\n.\n1\n \nEntry\n \n>\nCreate\n \nRAM\n \nclass\n \nfrom\n \nROM\n \nclass\n \n0x3cab680\n \nin\n \nclass\n \nloader\n \n0x3042338\n\n \n08\n:\n58\n:\n35\n.\n536136384\n \n0x000000000f010500\n \nj9vm\n.\n80\n \nEvent\n \nROM\n \nclass\n \n0x3cab680\n \nis\n \nnamed\n \njava\n/\nlang\n/\nObject\n\n \n08\n:\n58\n:\n35\n.\n536200373\n \n0x000000000f010500\n \nj9vm\n.\n2\n \nExit\n \n<\nCreated\n \nRAM\n \nclass\n \n0xf03ef00\n \nfrom\n \nROM\n \nclass\n \n0x3cab680",
"title": "Trace formatter"
},
{
"location": "/tool_traceformat/#trace-formatter-traceformat",
"text": "The trace formatter is a Java\u2122 program that converts binary trace point data in a trace file to a readable form. The formatter requires the TraceFormat.dat and J9TraceFormat.dat files, which contain the formatting templates. The formatter produces a file that contains header information about the VM that produced the binary trace file, a list of threads for which trace points were produced, and the formatted trace points with their time stamp, thread ID, trace point ID, and trace point data.",
"title": "Trace formatter (traceformat)"
},
{
"location": "/tool_traceformat/#syntax",
"text": "To use the trace formatter on a binary trace file type: traceformat <input_file> [<output_file>] <parameters> Where <input_file> is the name of the binary trace file to be formatted, and <output_file> is the name of the output file. If you do not specify an output file, the output file is called input_file.fmt . The size of the heap that is needed to format the trace is directly proportional to the number of threads present in the trace file. For large numbers of threads the formatter might run out of memory, generating the error OutOfMemoryError . In this case, increase the heap size by using the -Xmx option.",
"title": "Syntax"
},
{
"location": "/tool_traceformat/#parameters",
"text": "The following <parameters> are available with the trace formatter: Option Explanation -datfile=<file1.dat>[,<file2.dat>] A comma-separated list of trace formatting data files. By default, the following files are used:$JAVA_HOME/lib/J9TraceFormat.dat and $JAVA_HOME/lib/TraceFormat.dat -format_time=yes|no Specifies whether to format the time stamps into human readable form. The default is yes . -help Displays usage information. -indent Indents trace messages at each Entry trace point and outdents trace messages at each Exit trace point. The default is not to indent the messages. -summary Prints summary information to the screen without generating an output file. -threads=<thread id>[,<thread id>]... Filters the output for the given thread IDs only. thread id is the ID of the thread, which can be specified in decimal or hex (0x) format. Any number of thread IDs can be specified, separated by commas. -timezone=+|-HH:MM Specifies the offset from UTC, as positive or negative hours and minutes, to apply when formatting time stamps. -verbose Output detailed warning and error messages, and performance statistics.",
"title": "Parameters"
},
{
"location": "/tool_traceformat/#examples",
"text": "The following example shows output from running the trace formatter command: C:\\test>traceformat sample.trc\n Writing formatted trace output to file sample.trc.fmt\n Processing 0.4921875Mb of binary trace data\n Completed processing of 6983 tracepoints with 0 warnings and 0 errors The formatted trace output looks similar to the following extract, which is truncated to show the key areas of information: Trace Summary \n\n Service level : \n JRE 1 . 8 . 0 Windows 7 amd64-64 build ( pwa6480sr2-20150624_06 ( SR2 )) \n\n JVM startup options : \n -Xoptionsfile = c : \\ build \\ pwa6480sr2-20150624 \\ sdk \\ lib \\ compressedrefs \\ options . default \n .... \n\n Processor information : \n Arch family : AMD64 \n Processor Sub-type : Opteron \n Num Processors : 8 \n Word size : 64 \n\n Trace activation information :: \n FORMAT = c : \\ build \\ pwa6480sr2-20150624 \\ sdk \\ lib ;. \n MAXIMAL = all { level1 } \n EXCEPTION = j9mm { gclogger } \n MAXIMAL = all { level2 } \n output = sample \n\n Trace file header : \n JVM start time : 08 : 58 : 35 . 527000000 \n Generations : 1 \n Pointer size : 8 \n\n Active threads \n .... \n 0x000000000f155f00 Attach API wait loop \n 0x000000000f18b200 Thread-1 \n 0x000000000f190200 Thread-3 \n\n\n Trace Formatted Data \n\n Time ( UTC ) Thread ID Tracepoint ID Type Tracepoint Data \n 08 : 58 : 35 . 527291919 * 0x000000000f010500 j9trc . 0 Event Trace engine initialized for VM = 0x3ad4d0 \n 08 : 58 : 35 . 527349836 0x000000000f010500 j9prt . 0 Event Trace engine initialized for module j9port \n 08 : 58 : 35 . 527354040 0x000000000f010500 j9thr . 0 Event Trace engine initialized for module j9thr \n 08 : 58 : 35 . 529409621 * 0x000000000f01eb00 j9trc . 5 Event Thread started VMthread = 0xf01eb00 , name = ( unnamed thread ), nativeID = 0x24a798 \n .... \n 08 : 58 : 35 . 536134516 0x000000000f010500 j9vm . 1 Entry > Create RAM class from ROM class 0x3cab680 in class loader 0x3042338 \n 08 : 58 : 35 . 536136384 0x000000000f010500 j9vm . 80 Event ROM class 0x3cab680 is named java / lang / Object \n 08 : 58 : 35 . 536200373 0x000000000f010500 j9vm . 2 Exit < Created RAM class 0xf03ef00 from ROM class 0x3cab680",
"title": "Examples"
},
{
"location": "/tool_builder/",
"text": "Option builder tools\n\n\nYou can modify many of the command-line options by specifying a number of parameters.\n\n\nSeveral of the options have many available parameters that you can combine in numerous ways to achieve the effect you want.\n\n\nTools are available for the following options to help you select these parameters correctly, achieve the correct combinations, and avoid conflicts:\n\n\n\n\n\n\n-Xdump\n\n\n\n\n\n\n-Xtrace",
"title": "Option builder"
},
{
"location": "/tool_builder/#option-builder-tools",
"text": "You can modify many of the command-line options by specifying a number of parameters. Several of the options have many available parameters that you can combine in numerous ways to achieve the effect you want. Tools are available for the following options to help you select these parameters correctly, achieve the correct combinations, and avoid conflicts: -Xdump -Xtrace",
"title": "Option builder tools"
},
{
"location": "/openj9_support/",
"text": "Supported environments\n\n\nThe Eclipse OpenJ9 project source code can be built against multiple JDK levels starting with JDK8,\nso the question of support has a more complicated answer than at OpenJDK. Our community is committed\nto supporting JDK levels as long as they are supported at the OpenJDK open source project with a significant\nuser base. Currently, Eclipse OpenJ9 produces a new release every quarter that can build against all JDK levels\ncurrently supported by the OpenJDK community. We are committed to accepting problem reports when using\nEclipse OpenJ9 against a supported OpenJDK level, with fixes being delivered in each release of Eclipse OpenJ9.\n\n\nIn order to track the OpenJDK 6 month release cadence, OpenJ9 also produces two releases a year that support only\na single JDK level. These releases will occur in March and September with the intention of supporting only\nthe corresponding new OpenJDK feature release (ie: 11, 12, ...).\n\n\nThe following table summarizes which JDK levels are expected to be supported by which Eclipse OpenJ9 releases,\nalong with projected release dates. All future dates and support expectations are predictions that might change\ndepending on how the OpenJDK and OpenJ9 projects evolve over time. Note also that columns may be removed from\nthis table over time.\n\n\nEclipse OpenJ9 releases\n\n\n\n\n\n\n\n\nOpenJ9 release\n\n\nRelease date\n\n\nJDK8 (LTS)\n\n\nJDK10\n\n\nJDK11 (LTS)\n\n\nJDK12\n\n\nJDK13\n\n\n\n\n\n\n\n\n\n\nv0.8.0\n\n\nMarch 2018\n\n\nYes\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nv0.9.0\n\n\nAugust 2018\n\n\nYes\n\n\nYes\n\n\n\n\n\n\n\n\n\n\n\n\nv0.10.0\n\n\nSeptember 2018\n\n\nNo\n\n\nNo\n\n\nYes(*3)\n\n\n\n\n\n\n\n\n\n\nv0.11.0\n\n\nOctober 2018 (*1)\n\n\nYes\n\n\nNo\n\n\nYes\n\n\n\n\n\n\n\n\n\n\nv0.12.0\n\n\nJanuary 2019 (*1)\n\n\nNo (*2)\n\n\nNo\n\n\nNo (*2)\n\n\nYes\n\n\n\n\n\n\n\n\nv0.13.0\n\n\nMarch 2019 (*1)\n\n\nNo\n\n\nNo\n\n\nNo\n\n\nYes(*3)\n\n\n\n\n\n\n\n\nv0.14.0\n\n\nApril 2019 (*1)\n\n\nNo (*2)\n\n\nNo\n\n\nNo (*2)\n\n\nYes\n\n\n\n\n\n\n\n\nv0.15.0\n\n\nJuly 2019 (*1)\n\n\nNo (*2)\n\n\nNo\n\n\nNo (*2)\n\n\nNo\n\n\nYes\n\n\n\n\n\n\n\n\n \nNotes:\n\n\n\n\n(*1): These OpenJ9 releases are expected, in line with our support statement.\n\n\n(*2): We fully expect that OpenJDK8 will have open community maintainers beyond January 2019,\nso we expect to be able to continue supporting JDK8 beyond that date. Until maintainers have been established\nwe are unable to make a definitive support statement. This position is the same for JDK11 and all future \"LTS\" releases.\n\n\n(*3): These OpenJ9 releases are the feature releases that only support the new OpenJDK release.\n\n\n\n\nFor any issues or limitations of an Eclipse OpenJ9 release, read the \nrelease notes\n.\n\n\nPlatform support\n\n\nThe Eclipse OpenJ9 project is open to supporting any hardware/operating system platforms\nprovided that we have community members available to maintain them. For practical\nreasons the Eclipse OpenJ9 JVM does not currently run on every platform.\n\n\n \nNote:\n If you obtain pre-built binaries from \nAdoptOpenJDK.net\n,\nplatform support might vary, depending on their build environment.\n\n\nOpenJDK 8\n\n\nOpenJDK8 binaries are supported on the minimum operating system levels shown in the following tables:\n\n\n\n\n\n\n\n\nLinux\n\n\nx32\n\n\nx64\n\n\nppc64le\n\n\nZ31\n\n\nZ64\n\n\n\n\n\n\n\n\n\n\nCentos 6\n\n\nY\n\n\nY\n\n\nY\n\n\nN\n\n\nN\n\n\n\n\n\n\nCentos 7\n\n\nY\n\n\nY\n\n\nY\n\n\nN\n\n\nN\n\n\n\n\n\n\nRed Hat Enterprise Linux (RHEL) 6\n\n\nY\n\n\nY\n\n\nY\n\n\nY\n\n\nY\n\n\n\n\n\n\nRHEL 7\n\n\nY\n\n\nY\n\n\nY\n\n\nY\n\n\nY\n\n\n\n\n\n\nSUSE Linux Enterprise Server (SLES) 12\n\n\nY\n\n\nY\n\n\nY\n\n\nY\n\n\nY\n\n\n\n\n\n\nUbuntu 16.04\n\n\nY\n\n\nY\n\n\nY\n\n\nN\n\n\nY\n\n\n\n\n\n\nUbuntu 18.04\n\n\nY\n\n\nY\n\n\nY\n\n\nN\n\n\nY\n\n\n\n\n\n\n\n\n \nNote:\n Not all of these distributions are tested, but Linux distributions that have a\nminimum glibc version 2.12 are expected to function without problems.\n\n\n\n\n\n\n\n\nWindows\n\n\nx32\n\n\nx64\n\n\n\n\n\n\n\n\n\n\nWindows 10\n\n\nY\n\n\nY\n\n\n\n\n\n\nWindows Server 2012\n\n\nY\n\n\nY\n\n\n\n\n\n\nWindows Server 2012 R2\n\n\nY\n\n\nY\n\n\n\n\n\n\nWindows Server 2016\n\n\nY\n\n\nY\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nAIX\u00ae\n\n\nppc32\n\n\nppc64\n\n\n\n\n\n\n\n\n\n\nAIX 7.1 TL4\n\n\nY\n\n\nY\n\n\n\n\n\n\nAIX 7.2\n\n\nY\n\n\nY\n\n\n\n\n\n\n\n\nWhen public support for an operating system version ends, OpenJ9 can no longer be supported on that level.\n\n\nOpenJDK 10\n\n\nOpenJDK10 binaries are supported on the minimum operating system levels shown in the following tables:\n\n\n\n\n\n\n\n\nLinux\n\n\nx64\n\n\nppc64le\n\n\nZ64\n\n\n\n\n\n\n\n\n\n\nCentos 6\n\n\nY\n\n\nY\n\n\nN\n\n\n\n\n\n\nCentos 7\n\n\nY\n\n\nY\n\n\nN\n\n\n\n\n\n\nRed Hat Enterprise Linux (RHEL) 6\n\n\nY\n\n\nY\n\n\nY\n\n\n\n\n\n\nRHEL 7\n\n\nY\n\n\nY\n\n\nY\n\n\n\n\n\n\nSUSE Linux Enterprise Server (SLES) 12\n\n\nY\n\n\nY\n\n\nY\n\n\n\n\n\n\nUbuntu 16.04\n\n\nY\n\n\nY\n\n\nY\n\n\n\n\n\n\nUbuntu 18.04\n\n\nY\n\n\nY\n\n\nY\n\n\n\n\n\n\n\n\n \nNote:\n Not all of these distributions are tested, but Linux distributions that have a\nminimum glibc version 2.12 are expected to function without problems.\n\n\n\n\n\n\n\n\nWindows\n\n\nx64\n\n\n\n\n\n\n\n\n\n\nWindows 10\n\n\nY\n\n\n\n\n\n\nWindows Server 2012\n\n\nY\n\n\n\n\n\n\nWindows Server 2012 R2\n\n\nY\n\n\n\n\n\n\nWindows Server 2016\n\n\nY\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nAIX\n\n\nppc64\n\n\n\n\n\n\n\n\n\n\nAIX 7.1 TL4\n\n\nY\n\n\n\n\n\n\nAIX 7.2\n\n\nY\n\n\n\n\n\n\n\n\nWhen public support for an operating system version ends, OpenJ9 can no longer be supported on that level.\n\n\nOpenJDK 11\n\n\nOpenJDK11 binaries are supported on the minimum operating system levels shown in the following tables:\n\n\n\n\n\n\n\n\nLinux\n\n\nx64\n\n\nppc64le\n\n\nZ64\n\n\n\n\n\n\n\n\n\n\nCentos 6\n\n\nY\n\n\nY\n\n\nN\n\n\n\n\n\n\nCentos 7\n\n\nY\n\n\nY\n\n\nN\n\n\n\n\n\n\nRed Hat Enterprise Linux (RHEL) 6\n\n\nY\n\n\nY\n\n\nY\n\n\n\n\n\n\nRHEL 7\n\n\nY\n\n\nY\n\n\nY\n\n\n\n\n\n\nSUSE Linux Enterprise Server (SLES) 12\n\n\nY\n\n\nY\n\n\nY\n\n\n\n\n\n\nUbuntu 16.04\n\n\nY\n\n\nY\n\n\nY\n\n\n\n\n\n\nUbuntu 18.04\n\n\nY\n\n\nY\n\n\nY\n\n\n\n\n\n\n\n\n \nNote:\n Not all of these distributions are tested, but Linux distributions that have a\nminimum glibc version 2.12 are expected to function without problems.\n\n\n\n\n\n\n\n\nWindows\n\n\nx64\n\n\n\n\n\n\n\n\n\n\nWindows 10\n\n\nY\n\n\n\n\n\n\nWindows Server 2012\n\n\nY\n\n\n\n\n\n\nWindows Server 2012 R2\n\n\nY\n\n\n\n\n\n\nWindows Server 2016\n\n\nY\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nAIX\n\n\nppc64\n\n\n\n\n\n\n\n\n\n\nAIX 7.1 TL4\n\n\nY\n\n\n\n\n\n\nAIX 7.2\n\n\nY\n\n\n\n\n\n\n\n\nWhen public support for an operating system version ends, OpenJ9 can no longer be supported on that level.\n\n\nBuild environments\n\n\nThe project build and test OpenJDK with OpenJ9 on a number of platforms. The operating system and compiler levels for the build systems are shown in the following tables.\n\n\nOpenJDK 8\n\n\n\n\n\n\n\n\nPlatform\n\n\nOperating system\n\n\nCompiler\n\n\n\n\n\n\n\n\n\n\nLinux x86 64-bit\n\n\nUbuntu 16.04\n\n\ngcc 4.8.5\n\n\n\n\n\n\nLinux on POWER\u00ae LE 64-bit\n\n\nUbuntu 16.04\n\n\ngcc 4.8.5\n\n\n\n\n\n\nLinux on IBM Z\u00ae 64-bit\n\n\nUbuntu 16.04\n\n\ngcc 4.8.5\n\n\n\n\n\n\nWindows x86 32-bit\n\n\nWindows Server 2012 R2\n\n\nMicrosoft Visual Studio 2010 SP1\n\n\n\n\n\n\nWindows x86 64-bit\n\n\nWindows Server 2012 R2\n\n\nMicrosoft Visual Studio 2010 SP1\n\n\n\n\n\n\nAIX POWER BE 64-bit\n\n\nAIX 7.1 TL04\n\n\nxlc/C++ 13.1.3\n\n\n\n\n\n\n\n\n \nNote:\n The minimum level of gcc supported for\nbuilding OpenJDK 8 on Linux is v4.4.7. However, plans are in place to update the minimum supported level to at least v4.8 in the future.\n\n\nOpenJDK 10\n\n\n\n\n\n\n\n\nPlatform\n\n\nOperating system\n\n\nCompiler\n\n\n\n\n\n\n\n\n\n\nLinux x86 64-bit\n\n\nUbuntu 16.04\n\n\ngcc 4.8.5\n\n\n\n\n\n\nLinux on POWER LE 64-bit\n\n\nUbuntu 16.04\n\n\ngcc 4.8.5\n\n\n\n\n\n\nLinux on IBM Z 64-bit\n\n\nUbuntu 16.04\n\n\ngcc 4.8.5\n\n\n\n\n\n\nWindows x86 64-bit\n\n\nWindows Server 2012 R2\n\n\nMicrosoft Visual Studio 2013\n\n\n\n\n\n\nAIX POWER BE 64-bit\n\n\nAIX 7.1 TL04\n\n\nxlc/C++ 13.1.3\n\n\n\n\n\n\n\n\nOpenJDK 11\n\n\n\n\n\n\n\n\nPlatform\n\n\nOperating system\n\n\nCompiler\n\n\n\n\n\n\n\n\n\n\nLinux x86 64-bit\n\n\nUbuntu 16.04\n\n\ngcc 7.3\n\n\n\n\n\n\nLinux on POWER LE 64-bit\n\n\nUbuntu 16.04\n\n\ngcc 7.3\n\n\n\n\n\n\nLinux on IBM Z 64-bit\n\n\nUbuntu 16.04\n\n\ngcc 7.3\n\n\n\n\n\n\nWindows x86 64-bit\n\n\nWindows Server 2012 R2\n\n\nMicrosoft Visual Studio 2017\n\n\n\n\n\n\nAIX POWER BE 64-bit\n\n\nAIX 7.1 TL04\n\n\nxlc/C++ 13.1.3",
"title": "Supported environments"
},
{
"location": "/openj9_support/#supported-environments",
"text": "The Eclipse OpenJ9 project source code can be built against multiple JDK levels starting with JDK8,\nso the question of support has a more complicated answer than at OpenJDK. Our community is committed\nto supporting JDK levels as long as they are supported at the OpenJDK open source project with a significant\nuser base. Currently, Eclipse OpenJ9 produces a new release every quarter that can build against all JDK levels\ncurrently supported by the OpenJDK community. We are committed to accepting problem reports when using\nEclipse OpenJ9 against a supported OpenJDK level, with fixes being delivered in each release of Eclipse OpenJ9. In order to track the OpenJDK 6 month release cadence, OpenJ9 also produces two releases a year that support only\na single JDK level. These releases will occur in March and September with the intention of supporting only\nthe corresponding new OpenJDK feature release (ie: 11, 12, ...). The following table summarizes which JDK levels are expected to be supported by which Eclipse OpenJ9 releases,\nalong with projected release dates. All future dates and support expectations are predictions that might change\ndepending on how the OpenJDK and OpenJ9 projects evolve over time. Note also that columns may be removed from\nthis table over time.",
"title": "Supported environments"
},
{
"location": "/openj9_support/#eclipse-openj9-releases",
"text": "OpenJ9 release Release date JDK8 (LTS) JDK10 JDK11 (LTS) JDK12 JDK13 v0.8.0 March 2018 Yes v0.9.0 August 2018 Yes Yes v0.10.0 September 2018 No No Yes(*3) v0.11.0 October 2018 (*1) Yes No Yes v0.12.0 January 2019 (*1) No (*2) No No (*2) Yes v0.13.0 March 2019 (*1) No No No Yes(*3) v0.14.0 April 2019 (*1) No (*2) No No (*2) Yes v0.15.0 July 2019 (*1) No (*2) No No (*2) No Yes Notes: (*1): These OpenJ9 releases are expected, in line with our support statement. (*2): We fully expect that OpenJDK8 will have open community maintainers beyond January 2019,\nso we expect to be able to continue supporting JDK8 beyond that date. Until maintainers have been established\nwe are unable to make a definitive support statement. This position is the same for JDK11 and all future \"LTS\" releases. (*3): These OpenJ9 releases are the feature releases that only support the new OpenJDK release. For any issues or limitations of an Eclipse OpenJ9 release, read the release notes .",
"title": "Eclipse OpenJ9 releases"
},
{
"location": "/openj9_support/#platform-support",
"text": "The Eclipse OpenJ9 project is open to supporting any hardware/operating system platforms\nprovided that we have community members available to maintain them. For practical\nreasons the Eclipse OpenJ9 JVM does not currently run on every platform. Note: If you obtain pre-built binaries from AdoptOpenJDK.net ,\nplatform support might vary, depending on their build environment.",
"title": "Platform support"
},
{
"location": "/openj9_support/#openjdk-8",
"text": "OpenJDK8 binaries are supported on the minimum operating system levels shown in the following tables: Linux x32 x64 ppc64le Z31 Z64 Centos 6 Y Y Y N N Centos 7 Y Y Y N N Red Hat Enterprise Linux (RHEL) 6 Y Y Y Y Y RHEL 7 Y Y Y Y Y SUSE Linux Enterprise Server (SLES) 12 Y Y Y Y Y Ubuntu 16.04 Y Y Y N Y Ubuntu 18.04 Y Y Y N Y Note: Not all of these distributions are tested, but Linux distributions that have a\nminimum glibc version 2.12 are expected to function without problems. Windows x32 x64 Windows 10 Y Y Windows Server 2012 Y Y Windows Server 2012 R2 Y Y Windows Server 2016 Y Y AIX\u00ae ppc32 ppc64 AIX 7.1 TL4 Y Y AIX 7.2 Y Y When public support for an operating system version ends, OpenJ9 can no longer be supported on that level.",
"title": "OpenJDK 8"
},
{
"location": "/openj9_support/#openjdk-10",
"text": "OpenJDK10 binaries are supported on the minimum operating system levels shown in the following tables: Linux x64 ppc64le Z64 Centos 6 Y Y N Centos 7 Y Y N Red Hat Enterprise Linux (RHEL) 6 Y Y Y RHEL 7 Y Y Y SUSE Linux Enterprise Server (SLES) 12 Y Y Y Ubuntu 16.04 Y Y Y Ubuntu 18.04 Y Y Y Note: Not all of these distributions are tested, but Linux distributions that have a\nminimum glibc version 2.12 are expected to function without problems. Windows x64 Windows 10 Y Windows Server 2012 Y Windows Server 2012 R2 Y Windows Server 2016 Y AIX ppc64 AIX 7.1 TL4 Y AIX 7.2 Y When public support for an operating system version ends, OpenJ9 can no longer be supported on that level.",
"title": "OpenJDK 10"
},
{
"location": "/openj9_support/#openjdk-11",
"text": "OpenJDK11 binaries are supported on the minimum operating system levels shown in the following tables: Linux x64 ppc64le Z64 Centos 6 Y Y N Centos 7 Y Y N Red Hat Enterprise Linux (RHEL) 6 Y Y Y RHEL 7 Y Y Y SUSE Linux Enterprise Server (SLES) 12 Y Y Y Ubuntu 16.04 Y Y Y Ubuntu 18.04 Y Y Y Note: Not all of these distributions are tested, but Linux distributions that have a\nminimum glibc version 2.12 are expected to function without problems. Windows x64 Windows 10 Y Windows Server 2012 Y Windows Server 2012 R2 Y Windows Server 2016 Y AIX ppc64 AIX 7.1 TL4 Y AIX 7.2 Y When public support for an operating system version ends, OpenJ9 can no longer be supported on that level.",
"title": "OpenJDK 11"
},
{
"location": "/openj9_support/#build-environments",
"text": "The project build and test OpenJDK with OpenJ9 on a number of platforms. The operating system and compiler levels for the build systems are shown in the following tables.",
"title": "Build environments"
},
{
"location": "/openj9_support/#openjdk-8_1",
"text": "Platform Operating system Compiler Linux x86 64-bit Ubuntu 16.04 gcc 4.8.5 Linux on POWER\u00ae LE 64-bit Ubuntu 16.04 gcc 4.8.5 Linux on IBM Z\u00ae 64-bit Ubuntu 16.04 gcc 4.8.5 Windows x86 32-bit Windows Server 2012 R2 Microsoft Visual Studio 2010 SP1 Windows x86 64-bit Windows Server 2012 R2 Microsoft Visual Studio 2010 SP1 AIX POWER BE 64-bit AIX 7.1 TL04 xlc/C++ 13.1.3 Note: The minimum level of gcc supported for\nbuilding OpenJDK 8 on Linux is v4.4.7. However, plans are in place to update the minimum supported level to at least v4.8 in the future.",
"title": "OpenJDK 8"
},
{
"location": "/openj9_support/#openjdk-10_1",
"text": "Platform Operating system Compiler Linux x86 64-bit Ubuntu 16.04 gcc 4.8.5 Linux on POWER LE 64-bit Ubuntu 16.04 gcc 4.8.5 Linux on IBM Z 64-bit Ubuntu 16.04 gcc 4.8.5 Windows x86 64-bit Windows Server 2012 R2 Microsoft Visual Studio 2013 AIX POWER BE 64-bit AIX 7.1 TL04 xlc/C++ 13.1.3",
"title": "OpenJDK 10"
},
{
"location": "/openj9_support/#openjdk-11_1",
"text": "Platform Operating system Compiler Linux x86 64-bit Ubuntu 16.04 gcc 7.3 Linux on POWER LE 64-bit Ubuntu 16.04 gcc 7.3 Linux on IBM Z 64-bit Ubuntu 16.04 gcc 7.3 Windows x86 64-bit Windows Server 2012 R2 Microsoft Visual Studio 2017 AIX POWER BE 64-bit AIX 7.1 TL04 xlc/C++ 13.1.3",
"title": "OpenJDK 11"
},
{
"location": "/openj9_defaults/",
"text": "Default settings for the OpenJ9 VM\n\n\nThe following tables provide a quick reference to the default settings for the VM when it is first installed.\n\n\nThe last 2 columns show whether the default setting can be changed by a command-line parameter or an environment variable. Note that if both are set, the command-line parameter always takes precedence.\n\n\n\n\n\n\n\n\nVM setting\n\n\nDefault\n\n\nCommand line\n\n\nEnv. variable\n\n\n\n\n\n\n\n\n\n\nJavadump\n\n\nEnabled\n\n\nyes\n\n\nyes\n\n\n\n\n\n\nHeapdump\n\n\nDisabled\n\n\nyes\n\n\nyes\n\n\n\n\n\n\nSystem dump\n\n\nEnabled\n\n\nyes\n\n\nyes\n\n\n\n\n\n\nSnap traces\n\n\nEnabled\n\n\nyes\n\n\nyes\n\n\n\n\n\n\nJIT dump\n\n\nEnabled\n\n\nyes\n\n\nyes\n\n\n\n\n\n\nVerbose output\n\n\nDisabled\n\n\nyes\n\n\nno\n\n\n\n\n\n\nCompressed references\n\n\n(See \nNote 1\n)\n\n\nyes\n\n\nyes\n\n\n\n\n\n\nBoot classpath search\n\n\nDisabled\n\n\nyes\n\n\nno\n\n\n\n\n\n\nJNI checks\n\n\nDisabled\n\n\nyes\n\n\nno\n\n\n\n\n\n\nRemote debugging\n\n\nDisabled\n\n\nyes\n\n\nno\n\n\n\n\n\n\nStrict conformance checks\n\n\nDisabled\n\n\nyes\n\n\nno\n\n\n\n\n\n\nQuickstart\n\n\nDisabled\n\n\nyes\n\n\nno\n\n\n\n\n\n\nRemote debug info server\n\n\nDisabled\n\n\nyes\n\n\nno\n\n\n\n\n\n\nReduced signaling\n\n\nDisabled\n\n\nyes\n\n\nno\n\n\n\n\n\n\nSignal handler chaining\n\n\nEnabled\n\n\nyes\n\n\nno\n\n\n\n\n\n\nClasspath\n\n\nNot set\n\n\nyes\n\n\nyes\n\n\n\n\n\n\nClass data sharing\n\n\nDisabled\n\n\nyes\n\n\nno\n\n\n\n\n\n\nAccessibility support\n\n\nEnabled\n\n\nno\n\n\nyes\n\n\n\n\n\n\nJIT compiler\n\n\nEnabled\n\n\nyes\n\n\nyes\n\n\n\n\n\n\nAOT compiler (See \nNote 2\n)\n\n\nEnabled\n\n\nyes\n\n\nno\n\n\n\n\n\n\nJIT debug options\n\n\nDisabled\n\n\nyes\n\n\nno\n\n\n\n\n\n\nJava2D max size of fonts with algorithmic bold\n\n\n14 point\n\n\nno\n\n\nyes\n\n\n\n\n\n\nJava2D use rendered bitmaps in scalable fonts\n\n\nEnabled\n\n\nno\n\n\nyes\n\n\n\n\n\n\nJava2D freetype font rasterizing\n\n\nEnabled\n\n\nno\n\n\nyes\n\n\n\n\n\n\nJava2D use AWT fonts\n\n\nDisabled\n\n\nno\n\n\nyes\n\n\n\n\n\n\n\n\n \nNotes:\n\n\n\n\n\n\nOn AIX\u00ae, Linux\u2122, and Windows\u2122: Enabled for \n-Xmx\n values \u2264 57 GB, otherwise disabled.\n\n\nOn z/OS\u00ae: Enabled for \n-Xmx\n values \u2264 25 GB, otherwise disabled. With \nAPAR OA49416\n, enabled for \n-Xmx\n values \u2264 57 GB.\n\n\n\n\n\n\nAOT is not used by the VM unless shared classes are also enabled.\n\n\n\n\n\n\n\n\n\n\n\n\nVM setting\n\n\nAIX\n\n\nLinux\n\n\nWindows\n\n\nz/OS\n\n\nCommand line\n\n\nEnv. variable\n\n\n\n\n\n\n\n\n\n\nDefault locale\n\n\nNone\n\n\nNone\n\n\nN/A\n\n\nNone\n\n\nno\n\n\nyes\n\n\n\n\n\n\nTime to wait before starting plug-in\n\n\nN/A\n\n\nZero\n\n\nN/A\n\n\nN/A\n\n\nno\n\n\nyes\n\n\n\n\n\n\nTemporary directory\n\n\n/tmp\n\n\n/tmp\n\n\nc:\\temp\n\n\n/tmp\n\n\nno\n\n\nyes\n\n\n\n\n\n\nPlug-in redirection\n\n\nNone\n\n\nNone\n\n\nN/A\n\n\nNone\n\n\nno\n\n\nyes\n\n\n\n\n\n\nIM switching\n\n\nDisabled\n\n\nDisabled\n\n\nN/A\n\n\nDisabled\n\n\nno\n\n\nyes\n\n\n\n\n\n\nIM modifiers\n\n\nDisabled\n\n\nDisabled\n\n\nN/A\n\n\nDisabled\n\n\nno\n\n\nyes\n\n\n\n\n\n\nThread model\n\n\nN/A\n\n\nN/A\n\n\nN/A\n\n\nNative\n\n\nno\n\n\nyes\n\n\n\n\n\n\nInitial stack size for Java\u2122 Threads 32-bit. Use \n-Xiss<size>\n\n\n2 KB\n\n\n2 KB\n\n\n2 KB\n\n\n2 KB\n\n\nyes\n\n\nno\n\n\n\n\n\n\nMaximum stack size for Java Threads 32-bit. Use \n-Xss<size>\n\n\n320 KB\n\n\n320 KB\n\n\n320 KB\n\n\n320 KB\n\n\nyes\n\n\nno\n\n\n\n\n\n\nStack size for OS Threads 32-bit. Use \n-Xmso<size>\n\n\n256 KB\n\n\n256 KB\n\n\n32 KB\n\n\n256 KB\n\n\nyes\n\n\nno\n\n\n\n\n\n\nInitial stack size for Java Threads 64-bit. Use \n-Xiss<size>\n\n\n2 KB\n\n\n2 KB\n\n\n2 KB\n\n\n2 KB\n\n\nyes\n\n\nno\n\n\n\n\n\n\nMaximum stack size for Java Threads 64-bit. Use \n-Xss<size>\n\n\n1024 KB\n\n\n1024 KB\n\n\n1024 KB\n\n\n1024 KB\n\n\nyes\n\n\nno\n\n\n\n\n\n\nStack size for OS Threads 64-bit. Use \n-Xmso<size>\n\n\n256 KB\n\n\n256 KB\n\n\n256 KB\n\n\n256 KB\n\n\nyes\n\n\nno\n\n\n\n\n\n\nInitial heap size. Use \n-Xms<size>\n\n\n8 MB\n\n\n8 MB\n\n\n8 MB\n\n\n8 MB\n\n\nyes\n\n\nno\n\n\n\n\n\n\nMaximum Java heap size. Use \n-Xmx<size>\n\n\nSee \nNotes\n\n\nSee \nNotes\n\n\nSee \nNotes\n\n\nSee \nNotes\n\n\nyes\n\n\nno\n\n\n\n\n\n\nPage size for the Java object heap and code cache (For restrictions, see the \n-Xlp:codecache\n and \n-Xlp:objectheap\n options).\n\n\nOperating system default\n\n\nArchitecture: x86: 2MB, IBM Z\u00ae: 1MB, Other architectures: Operating system default\n\n\nOperating system default\n\n\n1M pageable\n\n\nyes\n\n\nno\n\n\n\n\n\n\n\n\n \nNotes:\n\n\nThe default value of \n-Xmx\n depends on the version of Java.\n\n\n\n\n\n\n The value is half the available memory with a minimum of 16MB and a maximum of 512 MB. \n\n\n\n\n\n\n The value is 25% of the available memory with a maximum of 25 GB. However, where there is 2 GB or less of physical memory, the value set is 50% of available memory with a minimum value of 16 MB and a maximum value of 512 MB. \n\n\n\n\n\n\nAvailable memory\n is defined as being the smallest of two values: The real or \nphysical\n memory or the \nRLIMIT_AS\n value.",
"title": "Default settings"
},
{
"location": "/openj9_defaults/#default-settings-for-the-openj9-vm",
"text": "The following tables provide a quick reference to the default settings for the VM when it is first installed. The last 2 columns show whether the default setting can be changed by a command-line parameter or an environment variable. Note that if both are set, the command-line parameter always takes precedence. VM setting Default Command line Env. variable Javadump Enabled yes yes Heapdump Disabled yes yes System dump Enabled yes yes Snap traces Enabled yes yes JIT dump Enabled yes yes Verbose output Disabled yes no Compressed references (See Note 1 ) yes yes Boot classpath search Disabled yes no JNI checks Disabled yes no Remote debugging Disabled yes no Strict conformance checks Disabled yes no Quickstart Disabled yes no Remote debug info server Disabled yes no Reduced signaling Disabled yes no Signal handler chaining Enabled yes no Classpath Not set yes yes Class data sharing Disabled yes no Accessibility support Enabled no yes JIT compiler Enabled yes yes AOT compiler (See Note 2 ) Enabled yes no JIT debug options Disabled yes no Java2D max size of fonts with algorithmic bold 14 point no yes Java2D use rendered bitmaps in scalable fonts Enabled no yes Java2D freetype font rasterizing Enabled no yes Java2D use AWT fonts Disabled no yes Notes: On AIX\u00ae, Linux\u2122, and Windows\u2122: Enabled for -Xmx values \u2264 57 GB, otherwise disabled. On z/OS\u00ae: Enabled for -Xmx values \u2264 25 GB, otherwise disabled. With APAR OA49416 , enabled for -Xmx values \u2264 57 GB. AOT is not used by the VM unless shared classes are also enabled. VM setting AIX Linux Windows z/OS Command line Env. variable Default locale None None N/A None no yes Time to wait before starting plug-in N/A Zero N/A N/A no yes Temporary directory /tmp /tmp c:\\temp /tmp no yes Plug-in redirection None None N/A None no yes IM switching Disabled Disabled N/A Disabled no yes IM modifiers Disabled Disabled N/A Disabled no yes Thread model N/A N/A N/A Native no yes Initial stack size for Java\u2122 Threads 32-bit. Use -Xiss<size> 2 KB 2 KB 2 KB 2 KB yes no Maximum stack size for Java Threads 32-bit. Use -Xss<size> 320 KB 320 KB 320 KB 320 KB yes no Stack size for OS Threads 32-bit. Use -Xmso<size> 256 KB 256 KB 32 KB 256 KB yes no Initial stack size for Java Threads 64-bit. Use -Xiss<size> 2 KB 2 KB 2 KB 2 KB yes no Maximum stack size for Java Threads 64-bit. Use -Xss<size> 1024 KB 1024 KB 1024 KB 1024 KB yes no Stack size for OS Threads 64-bit. Use -Xmso<size> 256 KB 256 KB 256 KB 256 KB yes no Initial heap size. Use -Xms<size> 8 MB 8 MB 8 MB 8 MB yes no Maximum Java heap size. Use -Xmx<size> See Notes See Notes See Notes See Notes yes no Page size for the Java object heap and code cache (For restrictions, see the -Xlp:codecache and -Xlp:objectheap options). Operating system default Architecture: x86: 2MB, IBM Z\u00ae: 1MB, Other architectures: Operating system default Operating system default 1M pageable yes no Notes: The default value of -Xmx depends on the version of Java. The value is half the available memory with a minimum of 16MB and a maximum of 512 MB. The value is 25% of the available memory with a maximum of 25 GB. However, where there is 2 GB or less of physical memory, the value set is 50% of available memory with a minimum value of 16 MB and a maximum value of 512 MB. Available memory is defined as being the smallest of two values: The real or physical memory or the RLIMIT_AS value.",
"title": "Default settings for the OpenJ9 VM"
},
{
"location": "/openj9_directories/",
"text": "Directory conventions\n\n\nThe following tables provide a quick reference to the OpenJ9 VM directory location on different Java\u2122 versions and different platform architectures. Some\npages refer to the VM directory location as \n<vm_dir>\n.\n\n\n\n\n\n\n\n\nOperating system\n\n\nJava 8\n\n\nJava 10 and later\n\n\n\n\n\n\n\n\n\n\nAIX\u00ae\n\n\n<install_dir>/jre/lib/ppc[64]/default\n\n\n<install_dir>/\n\n\n\n\n\n\nLinux\u2122\n\n\n<install_dir>/jre/lib/<arch>/default\n\n\n<install_dir>/\n\n\n\n\n\n\nWindows\u2122\n\n\n<install_dir>\\jre\\bin\\default\n\n\n<install_dir>\\\n\n\n\n\n\n\nz/OS\u00ae\n\n\n<install_dir>/jre/lib/s390[x]/default\n\n\n<install_dir>/\n\n\n\n\n\n\n\n\nWhere:\n\n\n\n\n<install_dir>\n is your JDK installation directory.\n\n\n<arch>\n depends on the architecture your Linux distribution is running on. See the following table for possible values:\n\n\n\n\n\n\n\n\n\n\nArchitecture\n\n\nValue of \n<arch>\n\n\n\n\n\n\n\n\n\n\nx86 32-bit\n\n\ni386\n\n\n\n\n\n\nx86 64-bit\n\n\nx86-64\n\n\n\n\n\n\nIBM POWER\u00ae 32-bit (Big Endian)\n\n\nppc\n\n\n\n\n\n\nIBM POWER 64-bit (Big Endian)\n\n\nppc64\n\n\n\n\n\n\nIBM POWER 64-bit (Little Endian)\n\n\nppc64le\n\n\n\n\n\n\nIBM Z\u00ae 31-bit\n\n\ns390\n\n\n\n\n\n\nIBM Z 64-bit\n\n\ns390x",
"title": "Directory conventions"
},
{
"location": "/openj9_directories/#directory-conventions",
"text": "The following tables provide a quick reference to the OpenJ9 VM directory location on different Java\u2122 versions and different platform architectures. Some\npages refer to the VM directory location as <vm_dir> . Operating system Java 8 Java 10 and later AIX\u00ae <install_dir>/jre/lib/ppc[64]/default <install_dir>/ Linux\u2122 <install_dir>/jre/lib/<arch>/default <install_dir>/ Windows\u2122 <install_dir>\\jre\\bin\\default <install_dir>\\ z/OS\u00ae <install_dir>/jre/lib/s390[x]/default <install_dir>/ Where: <install_dir> is your JDK installation directory. <arch> depends on the architecture your Linux distribution is running on. See the following table for possible values: Architecture Value of <arch> x86 32-bit i386 x86 64-bit x86-64 IBM POWER\u00ae 32-bit (Big Endian) ppc IBM POWER 64-bit (Big Endian) ppc64 IBM POWER 64-bit (Little Endian) ppc64le IBM Z\u00ae 31-bit s390 IBM Z 64-bit s390x",
"title": "Directory conventions"
},
{
"location": "/messages_intro/",
"text": "OpenJ9 VM messages\n\n\nMessages are issued by the OpenJ9 virtual machine (VM) in response to certain conditions. Understanding what the messages\nmean can help you with problem determination.\n\n\nMessage categories\n\n\nThere are three main categories of message:\n\n\n\n\nInformation\n\n\nInformation messages provide information about VM processing. For example, a dump information message is typically issued when a dump agent requests a dump.\n\n\nWarning\n\n\nWarning messages are issued by the VM to indicate conditions that might need user intervention.\n\n\nError\n\n\nError messages are issued by the VM when normal processing cannot proceed, because of unexpected conditions.\n\n\n\n\nOpenJ9 virtual machine messages have the following format:\n\n\n JVM<type><number><code>\n\n\n\n\n\nwhere:\n\n\n\n\nJVM\n is a standard prefix.\n\n\n<type>\n refers to the VM subcomponent that issued the message.\n\n\n<number>\n is a unique numerical number.\n\n\n<code>\n is one of the following codes:\n\n\nI\n - Information message\n\n\nW\n - Warning message\n\n\nE\n - Error message\n\n\n\n\n\n\n\n\nThese messages can help you with problem determination.\n\n\nBy default, all error and some information messages are routed to the system log and also written to \nstderr\n or \nstdout\n. The specific information messages are \nJVMDUMP039I\n, \nJVMDUMP032I\n, and \nJVMDUMP033I\n, which provide valuable additional information about dumps produced by the VM. To route additional message types to the system log, or turn off message logging to the system log, use the \n-Xlog\n option. The \n-Xlog\n option does not affect messages written to the standard error stream (stderr). See \nOpenJ9 command-line options\n.\n\n\nFinding logged messages\n\n\nLogged messages can be found in different locations, according to platform.\n\n\nFinding AIX messages\n\n\nOn AIX\u00ae, messages are logged by the syslog daemon (\n/usr/sbin/syslogd\n). Logged messages are written to the syslog file that is configured in \n/etc/syslog.conf\n. If the syslog daemon is not running, logged messages are lost.\n\n\nYou can redirect messages from the syslog daemon to the AIX error log facility by performing the following configuration steps:\n\n\n\n\nSet up a redirect in the file \nsyslog.conf\n so that syslog messages are sent to the error log, by adding the following line:\n\n\n\n\n user.debug errlog\n\n\n\n\n\n\n\nIf \nsyslogd\n is already running, reload the updated configuration by running the following command:\n\n\n\n\n refresh -s syslogd\n\n\n\n\n\n\n\nThe updated configuration is used each time \nsyslogd\n starts. 4. Use the AIX \nerrpt\n command or the System Management Interface Tool (SMIT) to read the messages sent to the error log.\n\n\n\n\nFor more information about AIX logging, see: \nError-logging overview\n.\n\n\nFinding Linux messages\n\n\nOn Linux\u2122, messages are logged by the \nsyslog\n daemon. To find where messages are logged, check the syslog configuration file.\n\n\nFinding Windows messages\n\n\nOn Windows\u2122, messages are logged in the application events section of the event viewer.\n\n\nFinding z/OS messages\n\n\nOn z/OS\u00ae, messages are sent to the operator console. To see the messages, go from the \nispf\n panel to the \nsdsf\n panel, then open the \nlog\n panel.\n\n\nObtaining detailed message descriptions\n\n\nDetailed message information is available to help with problem diagnosis.\n\n\nUnderstanding the warning or error message issued by the VM can help you diagnose problems. All warning and error messages issued by the VM are listed by type in the messages guide: \nIBM\u00ae VM messages\n.\n\n\nThe messages, error codes, and exit codes in this guide apply to multiple versions of the VM.\n\n\n \nNote:\n If the VM fills all available memory, the message number might be produced without a description for the error that caused the problem. Look for the message number in the relevant section of the J9 VM Messages guide to see the message description and the additional information provided.",
"title": "OpenJ9 messages"
},
{
"location": "/messages_intro/#openj9-vm-messages",
"text": "Messages are issued by the OpenJ9 virtual machine (VM) in response to certain conditions. Understanding what the messages\nmean can help you with problem determination.",
"title": "OpenJ9 VM messages"
},
{
"location": "/messages_intro/#message-categories",
"text": "There are three main categories of message: Information Information messages provide information about VM processing. For example, a dump information message is typically issued when a dump agent requests a dump. Warning Warning messages are issued by the VM to indicate conditions that might need user intervention. Error Error messages are issued by the VM when normal processing cannot proceed, because of unexpected conditions. OpenJ9 virtual machine messages have the following format: JVM<type><number><code> where: JVM is a standard prefix. <type> refers to the VM subcomponent that issued the message. <number> is a unique numerical number. <code> is one of the following codes: I - Information message W - Warning message E - Error message These messages can help you with problem determination. By default, all error and some information messages are routed to the system log and also written to stderr or stdout . The specific information messages are JVMDUMP039I , JVMDUMP032I , and JVMDUMP033I , which provide valuable additional information about dumps produced by the VM. To route additional message types to the system log, or turn off message logging to the system log, use the -Xlog option. The -Xlog option does not affect messages written to the standard error stream (stderr). See OpenJ9 command-line options .",
"title": "Message categories"
},
{
"location": "/messages_intro/#finding-logged-messages",
"text": "Logged messages can be found in different locations, according to platform.",
"title": "Finding logged messages"
},
{
"location": "/messages_intro/#finding-aix-messages",
"text": "On AIX\u00ae, messages are logged by the syslog daemon ( /usr/sbin/syslogd ). Logged messages are written to the syslog file that is configured in /etc/syslog.conf . If the syslog daemon is not running, logged messages are lost. You can redirect messages from the syslog daemon to the AIX error log facility by performing the following configuration steps: Set up a redirect in the file syslog.conf so that syslog messages are sent to the error log, by adding the following line: user.debug errlog If syslogd is already running, reload the updated configuration by running the following command: refresh -s syslogd The updated configuration is used each time syslogd starts. 4. Use the AIX errpt command or the System Management Interface Tool (SMIT) to read the messages sent to the error log. For more information about AIX logging, see: Error-logging overview .",
"title": "Finding AIX messages"
},
{
"location": "/messages_intro/#finding-linux-messages",
"text": "On Linux\u2122, messages are logged by the syslog daemon. To find where messages are logged, check the syslog configuration file.",
"title": "Finding Linux messages"
},
{
"location": "/messages_intro/#finding-windows-messages",
"text": "On Windows\u2122, messages are logged in the application events section of the event viewer.",
"title": "Finding Windows messages"
},
{
"location": "/messages_intro/#finding-zos-messages",
"text": "On z/OS\u00ae, messages are sent to the operator console. To see the messages, go from the ispf panel to the sdsf panel, then open the log panel.",
"title": "Finding z/OS messages"
},
{
"location": "/messages_intro/#obtaining-detailed-message-descriptions",
"text": "Detailed message information is available to help with problem diagnosis. Understanding the warning or error message issued by the VM can help you diagnose problems. All warning and error messages issued by the VM are listed by type in the messages guide: IBM\u00ae VM messages . The messages, error codes, and exit codes in this guide apply to multiple versions of the VM. Note: If the VM fills all available memory, the message number might be produced without a description for the error that caused the problem. Look for the message number in the relevant section of the J9 VM Messages guide to see the message description and the additional information provided.",
"title": "Obtaining detailed message descriptions"
},
{
"location": "/env_var/",
"text": "Environment variables\n\n\nAlthough 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.\n\n\n \nNote:\n Environment variables are overridden by command-line arguments.\n\n\nFinding and setting environment variables\n\n\nTo show the current environment, run:\n\n\n\n\nset\n (Windows\u2122)\n\n\nenv\n (AIX\u00ae, Linux\u2122)\n\n\nset\n (z/OS\u00ae)\n\n\n\n\nTo show a particular environment variable, run:\n\n\n\n\necho %ENVNAME%\n (Windows)\n\n\necho $ENVNAME\n (AIX, Linux, and z/OS)\n\n\n\n\nUse values exactly as shown in the documentation. The names of environment variables are case-sensitive in AIX, Linux, and z/OS.\n\n\nTo set the environment variable \nLOGIN_NAME\n to \nFred\n, run:\n\n\n\n\nset LOGIN_NAME=Fred\n (Windows)\n\n\nexport LOGIN_NAME=Fred\n (AIX/Linux: ksh or bash shells)\n\n\n\n\nThese variables are set only for the current shell or command-line session.\n\n\nIf you are setting multiple values for an environment variable in a list:\n\n\n\n\nOn AIX, Linux, and z/OS the separator is typically a colon (:).\n\n\nOn Windows the separator is typically a semicolon (;).\n\n\n\n\nGeneral options\n\n\nGeneral VM environment variables are shown in the following table:\n\n\n\n\n\n\n\n\nEnvironment\u00a0variable\n\n\nUsage information\n\n\n\n\n\n\n\n\n\n\nIBM_JAVA_COMMAND_LINE\n\n\nThis 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.\n\n\n\n\n\n\nIBM_JAVA_OPTIONS=<option>\n\n\nSet this variable to store default Java options, including \n-X\n, \n-D\n, or \n-verbose:gc\n style options. For example, \n-Xms256m -Djava.compiler\n. Any options set are overridden by equivalent options that are specified when Java is started. This variable does not support \n-fullversion\n or \n-version\n. 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 \n-Xtrace:output\n.\n\n\n\n\n\n\nJAVA_FONTS=<list of directories>\n\n\nSet this environment variable to specify the font directory. Setting this variable is equivalent to setting the property \njava.awt.fonts\n on Windows operating systems, and \nsun.java2d.fontpath\n on other operating systems.\n\n\n\n\n\n\n\n\nDump agent options\n\n\nThe preferred mechanism for controlling the production of dumps is by using the \n-Xdump\n option. However, these legacy environment variables are preserved and can still be used. The following table describes dump agent options:\n\n\n\n\n\n\n\n\nEnvironment Variable\n\n\nUsage Information\n\n\n\n\n\n\n\n\n\n\nJAVA_DUMP_OPTS\n\n\nUsed to control the conditions under which dumps are produced.\n\n\n\n\n\n\n\n\nIf you set agents for a condition by using the \nJAVA_DUMP_OPTS\n environment variable, default dump agents for that condition are disabled; however, any \n-Xdump\n options that are specified on the command line are used.\n\n\nThe \nJAVA_DUMP_OPTS\n environment variable uses the following syntax:\n\n\nJAVA_DUMP_OPTS=\"ON<condition>(<agent>[<count>],<agent>[<count>]),\nON<condition>(<agent>[<count>],...),...)\"\n\n\n\n\n\nWhere:\n\n\n\n\n<condition>\n is one of the following values:\n\n\nANYSIGNAL\n\n\nDUMP\n\n\nERROR\n\n\nINTERRUPT\n\n\nEXCEPTION\n\n\nOUTOFMEMORY\n\n\n\n\n\n\n<agent>\n is one of the following values:\n\n\nALL\n\n\nNONE\n\n\nJAVADUMP\n\n\nSYSDUMP\n\n\nHEAPDUMP\n\n\nCEEDUMP\n (z/OS specific)\n\n\n\n\n\n\n<count>\n 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.\n\n\n\n\nJAVA_DUMP_OPTS\n 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:\n\n\nONERROR\n(\nSYSDUMP\n[\n1\n]),\nONERROR\n(\nJAVADUMP\n)\n\n\n\n\n\n\nAlso, the \nONANYSIGNAL\n condition is parsed before all others, so\n\n\nONINTERRUPT\n(\nNONE\n),\nONANYSIGNAL\n(\nSYSDUMP\n)\n\n\n\n\n\n\nhas the same effect as\n\n\nONANYSIGNAL\n(\nSYSDUMP\n),\nONINTERRUPT\n(\nNONE\n)\n\n\n\n\n\n\nIf the \nJAVA_DUMP_TOOL\n environment variable is set, that variable is assumed to specify a valid executable name and is parsed for replaceable fields, such as \n%pid\n. If \n%pid\n is detected in the string, the string is replaced with the VM's own process ID. The tool that is specified by \nJAVA_DUMP_TOOL\n is run after any system dump or heap dump is taken, before anything else.\n\n\nThe dump settings are applied in the following order. Settings later in the list take precedence:\n\n\n\n\nDefault VM dump behavior.\n\n\n-Xdump\n command-line options that specify \n-Xdump:<type>:defaults\n, see \nOpenJ9 default options\n.\n\n\nDISABLE_JAVADUMP\n, \nIBM_HEAPDUMP\n, and \nIBM_HEAP_DUMP\n environment variables.\n\n\nIBM_JAVADUMP_OUTOFMEMORY\n and \nIBM_HEAPDUMP_OUTOFMEMORY\n environment variables.\n\n\nJAVA_DUMP_OPTS\n environment variable.\n\n\nRemaining \n-Xdump\n command-line options.\n\n\n\n\nSetting \nJAVA_DUMP_OPTS\n affects only those conditions that you specify. Actions on other conditions are unchanged.\n\n\nSignal mapping\n\n\nWhen setting the \nJAVA_DUMP_OPTS\n environment variable, the mapping of operating system signals to the \"condition\" is shown in the following table:\n\n\n\n\n\n\n\n\nCondition\n\n\nz/OS\n\n\nWindows\n\n\nLinux and AIX\n\n\n\n\n\n\n\n\n\n\nEXCEPTION\n\n\nSIGTRAP, SIGILL, SIGSEGV, SIGFPE, SIGBUS, SIGSYS, SIGXFSV\n\n\nSIGILL, SIGSEGV, SIGFPE\n\n\nSIGTRAP, SIGILL, SIGSEGV, SIGFPE, SIGBUS, SIGXFSV\n\n\n\n\n\n\nINTERRUPT\n\n\nSIGINT, SIGTERM, SIGHUP\n\n\nSIGINT, SIGTERM\n\n\nSIGINT, SIGTERM, SIGHUP\n\n\n\n\n\n\nERROR\n\n\nSIGABRT\n\n\nSIGABRT\n\n\nSIGABRT\n\n\n\n\n\n\nDUMP\n\n\nSIGQUIT\n\n\nSIGBREAK\n\n\nSIGQUIT\n\n\n\n\n\n\n\n\nJava dump options\n\n\nThe preferred mechanism for controlling the production of Java dumps is by using the \n-Xdump:java\n option. However, these legacy environment variables are preserved and can still be used.\n\n\n\n\n\n\n\n\nEnvironment Variable\n\n\nUsage Information\n\n\n\n\n\n\n\n\n\n\nDISABLE_JAVADUMP=[TRUE|FALSE]\n\n\nSetting \nDISABLE_JAVADUMP\n to \nTRUE\n is the equivalent of using \n-Xdump:java:none\n and stops the default production of Java dumps.\n\n\n\n\n\n\nIBM_JAVACOREDIR=<directory>\n\n\nThe default location into which the Java dump is written. On z/OS, the \n_CEE_DMPTARG\n environment variable is used instead.\n\n\n\n\n\n\nIBM_JAVADUMP_OUTOFMEMORY=[TRUE|FALSE]\n\n\nBy setting this environment variable to \nFALSE\n, 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 \nTRUE\n to generate a dump when an out-of-memory exception is thrown, even if it is handled by the application. Set to \nFALSE\n to disable Java dumps for an out-of-memory exception.\n\n\n\n\n\n\nTMPDIR=<directory>\n\n\nThis 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 \n/tmp\n (\nC:\\temp\n for Windows).\n\n\n\n\n\n\n\n\n \nNote:\n You can use the dump agent \nJAVA_DUMP_OPTS\n variable to control the conditions under which Java dumps are produced.\n\n\nHeap dump options\n\n\nThe preferred mechanism for controlling the production of Java dumps is by using the \n-Xdump:heap\n option. However, these legacy environment variables are preserved and can still be used.\n\n\n\n\n\n\n\n\nEnvironment Variable\n\n\nUsage Information\n\n\n\n\n\n\n\n\n\n\nIBM_HEAPDUMP=[TRUE|FALSE]\n\n\nSetting this option to \nTRUE\n enables heap dump production by using signals.\n\n\n\n\n\n\nIBM_HEAP_DUMP=[TRUE|FALSE]\n\n\nSetting this option to \nTRUE\n enables heap dump production by using signals.\n\n\n\n\n\n\nIBM_HEAPDUMPDIR=<directory>\n\n\nThe default location into which the heap dump is written. On z/OS, the \n_CEE_DMPTARG\n environment variable is used instead.\n\n\n\n\n\n\nIBM_HEAPDUMP_OUTOFMEMORY=[TRUE|FALSE]\n\n\nControls 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.\n\n\n\n\n\n\nIBM_JAVA_HEAPDUMP_TEST\n\n\nUse this environment variable to cause the VM to generate both PHD and text versions of heap dumps. Equivalent to \nopts=PHD+CLASSIC\n on the \n-Xdump:heap\n option.\n\n\n\n\n\n\nIBM_JAVA_HEAPDUMP_TEXT\n\n\nUse this environment variable to cause the VM to generate a text (human readable) Heap dump. Equivalent to \nopts=CLASSIC\n on the \n-Xdump:heap\n option.\n\n\n\n\n\n\nTMPDIR=<directory>\n\n\nThis 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 \n/tmp\n (\nC:\\temp\n for Windows).\n\n\n\n\n\n\n\n\n \nNote:\n You can use the dump agent \nJAVA_DUMP_OPTS\n variable to control the conditions under which Heap dumps are produced.\n\n\nOther diagnostic options\n\n\nThe following table lists other environment variables that can be set for diagnostic purposes:\n\n\n\n\n\n\n\n\nEnvironment variable\n\n\nUsage Instructions\n\n\n\n\n\n\n\n\n\n\nIBM_COREDIR=<directory>\n\n\nSet this variable to specify an alternative location for system dumps, JIT dumps, and snap trace. On z/OS, \n_CEE_DMPTARG\n is used instead for snap trace, and transaction dumps are written to TSO according to \nJAVA_DUMP_TDUMP_PATTERN\n. On Linux, the dump is written to the directory that is specified directory by the operating system before being moved to the specified location.\n\n\n\n\n\n\nIBM_JAVA_ABEND_ON_FAILURE=Y\n (z/OS only)\n\n\nThis 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.\n\n\n\n\n\n\nJAVA_DUMP_TDUMP_PATTERN=<string>\n (z/OS only)\n\n\nThe specified \n<string>\n is passed to IEATDUMP to use as the data/set name for the Transaction Dump. The default \n<string>\n is \n%uid.JVM.TDUMP.%job.D%y%m%d.T%H%M%S\n (31-bit) or \n%uid.JVM.%job.D%y%m%d.T%H%M%S.X&amp;DS\n (64-bit), where \n%uid\n is found from the C code fragment shown in \nNotes\n.\n\n\n\n\n\n\nJAVA_THREAD_MODEL=<string>\n\n\n<string>\n can be defined as one of the following values: \nNATIVE\n (all threads are created as \n_MEDIUM_WEIGHT\n), \nHEAVY\n (all threads are created as \n_HEAVY_WEIGHT\n), \nMEDIUM\n (same as \nNATIVE\n), or \nNULL\n. The default is \nNATIVE\n.\n\n\n\n\n\n\nIBM_JVM_DEBUG_PROG=<debugger>\n (Linux only)\n\n\nSet this variable to start the VM under the specified debugger.\n\n\n\n\n\n\nIBM_MALLOCTRACE=TRUE\n\n\nSetting this variable to a non-null value lets you trace memory allocation in the VM. You can use this variable with the \n-Dcom.ibm.dbgmalloc=true\n system property to trace native allocations from the Java classes. This variable is equivalent to the command-line option \n-Xcheck:memory\n.\n\n\n\n\n\n\nIBM_USE_FLOATING_STACKS=TRUE\n (Linux only)\n\n\nSet this variable to override the automatic disabling of floating stacks. If this variable is not set, the launcher might set \nLD_ASSUME_KERNEL=2.2.5\n.\n\n\n\n\n\n\nIBM_XE_COE_NAME=<value>\n\n\nSet 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, \njava/lang/InternalError\n. A Signal 11 is followed by a JVMXE message and then the VM ends.\n\n\n\n\n\n\nJAVA_PLUGIN_TRACE=TRUE\n\n\nWhen this variable is set to \nTRUE\n 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 \nFALSE\n, so that a Java plug-in trace is not produced.\n\n\n\n\n\n\n\n\n \nNotes:\n\nC code fragment to discover \n%uid\n for \nJAVA_DUMP_TDUMP_PATTERN=<string>\n:\n\n\npwd = getpwuid(getuid());\npwd->pw_name;\n\n\n\n\n\nDeprecated JIT options\n\n\nThe following table describes deprecated environment variables for the JIT compiler:\n\n\n\n\n\n\n\n\nEnvironment Variable\n\n\nUsage Information\n\n\n\n\n\n\n\n\n\n\nIBM_MIXED_MODE_THRESHOLD\n\n\nUse \n-Xjit:count=<value>\n instead of this variable.\n\n\n\n\n\n\nJAVA_COMPILER\n\n\nUse \n-Djava.compiler=<value>\n 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\u2122) set (z/OS\u00ae) To show a particular environment variable, run: echo %ENVNAME% (Windows) echo $ENVNAME (AIX, Linux, and z/OS) Use values exactly as shown in the documentation. The names of environment variables are case-sensitive in AIX, Linux, and z/OS. To set the environment variable LOGIN_NAME to Fred , run: set LOGIN_NAME=Fred (Windows) export LOGIN_NAME=Fred (AIX/Linux: ksh or bash 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, 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\u00a0variable 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. IBM_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 -fullversion or -version . 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 . 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.",
"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>]),\nON<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 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, 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_JVM_DEBUG_PROG=<debugger> (Linux only) Set this variable to start the VM under the specified debugger. IBM_MALLOCTRACE=TRUE Setting this variable to a non-null value lets you trace memory allocation in the VM. You can use this variable with the -Dcom.ibm.dbgmalloc=true system property to trace native allocations from the Java classes. This variable is equivalent to the command-line option -Xcheck:memory . IBM_USE_FLOATING_STACKS=TRUE (Linux only) Set this variable to override the automatic disabling of floating stacks. If this variable is not set, the launcher might set LD_ASSUME_KERNEL=2.2.5 . 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: \nC code fragment to discover %uid for JAVA_DUMP_TDUMP_PATTERN=<string> : pwd = getpwuid(getuid());\npwd->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": "/legal/",
"text": "Legal\n\n\nLicense agreement, notices, copyright, and trademark information for the user documentation.\n\n\nLicense agreement\n\n\nSee \nLicense\n\n\nNotices\n\n\nSee \nNotices\n\n\nCopyright information\n\n\nEclipse OpenJ9 documentation is subject to the following copyright:\n\n\nCopyright (c) 2017, 2018 IBM Corp.\n\n\n\n\n\nTrademarks\n\n\nIBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at \"Copyright and trademark information\"\n\nhere\n.\n\n\nJava and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.\n\n\nLinux is a registered trademark of Linus Torvalds in the United States, other countries, or both.\n\n\nMicrosoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both.",
"title": "Legal"
},
{
"location": "/legal/#legal",
"text": "License agreement, notices, copyright, and trademark information for the user documentation.",
"title": "Legal"
},
{
"location": "/legal/#license-agreement",
"text": "See License",
"title": "License agreement"
},
{
"location": "/legal/#notices",
"text": "See Notices",
"title": "Notices"
},
{
"location": "/legal/#copyright-information",
"text": "Eclipse OpenJ9 documentation is subject to the following copyright: Copyright (c) 2017, 2018 IBM Corp.",
"title": "Copyright information"
},
{
"location": "/legal/#trademarks",
"text": "IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at \"Copyright and trademark information\" here . Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both.",
"title": "Trademarks"
}
]
}