Generated from commit: 3516f59e3a8dd7e57c431ef8e57d9860664c8517
diff --git a/search/search_index.json b/search/search_index.json
index 6eda621..1a67ff8 100644
--- a/search/search_index.json
+++ b/search/search_index.json
@@ -3367,7 +3367,7 @@
},
{
"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",
+ "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\nbootClassesOnly\n\n\n -Xshareclasses:bootClassesOnly\n\n\n\n\n\n\n\nDisables caching of classes that are loaded by class loaders other than the bootstrap class loader. If you use this suboption, the \nnonfatal\n suboption is also set, so this suboption is the equivalent of specifying \n-Xshareclasses:bootClassesOnly,nonfatal\n.\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 as follows. You must have sufficient permissions in \n<directory>\n:\n\n\n \n/tmp/javasharedresources\n \n\n\n The user's home directory, unless the \ngroupAccess\n parameter is specified, in which case it is \n/tmp/javasharedresources\n, because some members of the group might not have access to the user's home directory. \n\n\n\n\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. For persistent caches, the directory must not be on an NFS mount.\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\nfatal\n\n\n -Xshareclasses:fatal\n\n\n\n\n\n\n\nThe VM does not start if class data sharing fails, for example because there was an error when accessing the cache directory. An error message is generated. This suboption is specified by default unless you use the \nbootClassesOnly\n suboption, which is equivalent to \n-Xshareclasses:bootClassesOnly,nonfatal\n. You can override this behavior by specifying \n-Xshareclasses:bootClassesOnly,fatal\n. See also \nnonfatal\n.\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. See also \nfatal\n.\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"
},
{
@@ -3416,8 +3416,13 @@
"title": "allowClasspaths"
},
{
+ "location": "/xshareclasses/#bootclassesonly",
+ "text": "-Xshareclasses:bootClassesOnly Disables caching of classes that are loaded by class loaders other than the bootstrap class loader. If you use this suboption, the nonfatal suboption is also set, so this suboption is the equivalent of specifying -Xshareclasses:bootClassesOnly,nonfatal .",
+ "title": "bootClassesOnly"
+ },
+ {
"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 .",
+ "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 as follows. You must have sufficient permissions in <directory> : /tmp/javasharedresources The user's home directory, unless the groupAccess parameter is specified, in which case it is /tmp/javasharedresources , because some members of the group might not have access to the user's home directory. 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. For persistent caches, the directory must not be on an NFS mount. 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"
},
{
@@ -3466,6 +3471,11 @@
"title": "expire (Cache utility)"
},
{
+ "location": "/xshareclasses/#fatal",
+ "text": "-Xshareclasses:fatal The VM does not start if class data sharing fails, for example because there was an error when accessing the cache directory. An error message is generated. This suboption is specified by default unless you use the bootClassesOnly suboption, which is equivalent to -Xshareclasses:bootClassesOnly,nonfatal . You can override this behavior by specifying -Xshareclasses:bootClassesOnly,fatal . See also nonfatal .",
+ "title": "fatal"
+ },
+ {
"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)"
@@ -3527,7 +3537,7 @@
},
{
"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.",
+ "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. See also fatal .",
"title": "nonfatal"
},
{
diff --git a/sitemap.xml b/sitemap.xml
index 17da7d3..cac54a1 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -4,7 +4,7 @@
<url>
<loc>https://www.eclipse.org/openj9/docs/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -12,7 +12,7 @@
<url>
<loc>https://www.eclipse.org/openj9/docs/introduction/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -21,19 +21,19 @@
<url>
<loc>https://www.eclipse.org/openj9/docs/version0.10/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://www.eclipse.org/openj9/docs/version0.9/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://www.eclipse.org/openj9/docs/version0.8/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -42,7 +42,7 @@
<url>
<loc>https://www.eclipse.org/openj9/docs/gc/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -50,7 +50,7 @@
<url>
<loc>https://www.eclipse.org/openj9/docs/jit/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -58,7 +58,7 @@
<url>
<loc>https://www.eclipse.org/openj9/docs/aot/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -66,7 +66,7 @@
<url>
<loc>https://www.eclipse.org/openj9/docs/shrc/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -75,25 +75,25 @@
<url>
<loc>https://www.eclipse.org/openj9/docs/diag_overview/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://www.eclipse.org/openj9/docs/dump_javadump/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://www.eclipse.org/openj9/docs/dump_heapdump/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://www.eclipse.org/openj9/docs/dump_systemdump/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -103,19 +103,19 @@
<url>
<loc>https://www.eclipse.org/openj9/docs/cmdline_specifying/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://www.eclipse.org/openj9/docs/cmdline_general/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://www.eclipse.org/openj9/docs/cmdline_migration/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -143,19 +143,19 @@
<url>
<loc>https://www.eclipse.org/openj9/docs/tool_jdmpview/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://www.eclipse.org/openj9/docs/tool_traceformat/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://www.eclipse.org/openj9/docs/tool_builder/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -165,31 +165,31 @@
<url>
<loc>https://www.eclipse.org/openj9/docs/openj9_support/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://www.eclipse.org/openj9/docs/openj9_defaults/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://www.eclipse.org/openj9/docs/openj9_directories/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://www.eclipse.org/openj9/docs/messages_intro/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://www.eclipse.org/openj9/docs/env_var/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
@@ -198,7 +198,7 @@
<url>
<loc>https://www.eclipse.org/openj9/docs/legal/</loc>
- <lastmod>2018-10-16</lastmod>
+ <lastmod>2018-10-17</lastmod>
<changefreq>daily</changefreq>
</url>
diff --git a/xshareclasses/index.html b/xshareclasses/index.html
index d8c68fd..e13f8c0 100644
--- a/xshareclasses/index.html
+++ b/xshareclasses/index.html
@@ -1993,6 +1993,13 @@
</li>
<li class="md-nav__item">
+ <a href="#bootclassesonly" title="bootClassesOnly" class="md-nav__link">
+ bootClassesOnly
+ </a>
+
+</li>
+
+ <li class="md-nav__item">
<a href="#cachedir" title="cacheDir" class="md-nav__link">
cacheDir
</a>
@@ -2063,6 +2070,13 @@
</li>
<li class="md-nav__item">
+ <a href="#fatal" title="fatal" class="md-nav__link">
+ fatal
+ </a>
+
+</li>
+
+ <li class="md-nav__item">
<a href="#findaotmethods-cache-utility" title="findAotMethods (Cache utility)" class="md-nav__link">
findAotMethods (Cache utility)
</a>
@@ -3199,6 +3213,13 @@
</li>
<li class="md-nav__item">
+ <a href="#bootclassesonly" title="bootClassesOnly" class="md-nav__link">
+ bootClassesOnly
+ </a>
+
+</li>
+
+ <li class="md-nav__item">
<a href="#cachedir" title="cacheDir" class="md-nav__link">
cacheDir
</a>
@@ -3269,6 +3290,13 @@
</li>
<li class="md-nav__item">
+ <a href="#fatal" title="fatal" class="md-nav__link">
+ fatal
+ </a>
+
+</li>
+
+ <li class="md-nav__item">
<a href="#findaotmethods-cache-utility" title="findAotMethods (Cache utility)" class="md-nav__link">
findAotMethods (Cache utility)
</a>
@@ -3599,6 +3627,14 @@
<dl>
<dd>Allows a VM to store classpaths into an existing shared cache that was created by using the <code>restrictClasspaths</code> option.</dd>
</dl>
+<h3 id="bootclassesonly"><code>bootClassesOnly</code></h3>
+<div class="codehilite"><pre><span></span> -Xshareclasses:bootClassesOnly
+</pre></div>
+
+
+<dl>
+<dd>Disables caching of classes that are loaded by class loaders other than the bootstrap class loader. If you use this suboption, the <code>nonfatal</code> suboption is also set, so this suboption is the equivalent of specifying <code>-Xshareclasses:bootClassesOnly,nonfatal</code>.</dd>
+</dl>
<h3 id="cachedir"><code>cacheDir</code></h3>
<div class="codehilite"><pre><span></span> -Xshareclasses:cacheDir=<directory>
</pre></div>
@@ -3608,12 +3644,16 @@
<dd>
<p>Sets the directory in which cache data is read and written. The following defaults apply:</p>
<ul>
-<li>On Windows™ systems, <code><directory></code> is the user's <code>C:\\Documents and Settings\<username>\Local Settings\Application Data\javasharedresources</code> directory.</li>
-<li>On AIX®, Linux™, and z/OS® systems, <code><directory></code> is <code>/tmp/javasharedresources</code>. You must have sufficient permissions in <code><directory></code>. For AIX, the directory must not be on an NFS mount for persistent caches.</li>
+<li>On Windows™ systems, <code><directory></code> is the user's <code>C:\Documents and Settings\<username>\Local Settings\Application Data\javasharedresources</code> directory.</li>
+<li>On AIX®, Linux™, and z/OS® systems, <code><directory></code> is as follows. You must have sufficient permissions in <code><directory></code>:<ul>
+<li><img alt="Start of content that applies only to Java 8 (LTS)" src="../cr/java8.png" /> <code>/tmp/javasharedresources</code> <img alt="End of content that applies only to Java 8 (LTS)" src="../cr/java_close_lts.png" /></li>
+<li><img alt="Start of content that applies only to Java 11 (LTS)" src="../cr/java11.png" /> The user's home directory, unless the <code>groupAccess</code> parameter is specified, in which case it is <code>/tmp/javasharedresources</code>, because some members of the group might not have access to the user's home directory. <img alt="End of content that applies only to Java 11 (LTS)" src="../cr/java_close_lts.png" /></li>
+</ul>
+</li>
</ul>
</dd>
<dd>
-<p>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.</p>
+<p>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. For persistent caches, the directory must not be on an NFS mount.</p>
</dd>
<dd>
<p>Nonpersistent caches are stored in shared memory and have control files that describe the location of the memory. Control files are stored in a <code>javasharedresources</code> subdirectory of the <code>cacheDir</code> specified. Do not move or delete control files in this directory. The <code>listAllCaches</code> utility, the <code>destroyAll</code> utility, and the <code>expire</code> suboption work only in the scope of a given <code>cacheDir</code>.</p>
@@ -3746,6 +3786,14 @@
<dl>
<dd>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 <code>expire</code> option is accurate to the nearest hour.</dd>
</dl>
+<h3 id="fatal"><code>fatal</code></h3>
+<div class="codehilite"><pre><span></span> -Xshareclasses:fatal
+</pre></div>
+
+
+<dl>
+<dd>The VM does not start if class data sharing fails, for example because there was an error when accessing the cache directory. An error message is generated. This suboption is specified by default unless you use the <code>bootClassesOnly</code> suboption, which is equivalent to <code>-Xshareclasses:bootClassesOnly,nonfatal</code>. You can override this behavior by specifying <code>-Xshareclasses:bootClassesOnly,fatal</code>. See also <a href="#nonfatal"><code>nonfatal</code></a>.</dd>
+</dl>
<h3 id="findaotmethods-cache-utility"><code>findAotMethods</code> (Cache utility)</h3>
<div class="codehilite"><pre><span></span> -Xshareclasses:findAotMethods=<method_specification>
-Xshareclasses:findAotMethods=help
@@ -3924,7 +3972,7 @@
<dl>
-<dd>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 <code>nonfatal</code> 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.</dd>
+<dd>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 <code>nonfatal</code> 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. See also <a href="#fatal"><code>fatal</code></a>.</dd>
</dl>
<h3 id="nonpersistent"><code>nonpersistent</code></h3>
<div class="codehilite"><pre><span></span> -Xshareclasses:nonpersistent
