manpagez: man pages & more
man java(1)
Home | html | info | man
java(1)                          JDK Commands                          java(1)




NAME

       java - launch a Java application


SYNOPSIS

       To launch a class file:

       java [options] mainclass [args ...]

       To launch the main class in a JAR file:

       java [options] -jar jarfile [args ...]

       To launch the main class in a module:

       java [options] -m module[/mainclass] [args ...]

       or

       java [options] --module module[/mainclass] [args ...]

       To launch a single source-file program:

       java [options] source-file [args ...]

       options
              Optional:  Specifies  command-line  options separated by spaces.
              See Overview of Java Options for a description of available  op-
              tions.

       mainclass
              Specifies  the  name  of the class to be launched.  Command-line
              entries following classname  are  the  arguments  for  the  main
              method.

       -jar jarfile
              Executes  a program encapsulated in a JAR file.  The jarfile ar-
              gument is the name of a JAR file with a manifest that contains a
              line  in  the  form  Main-Class:classname that defines the class
              with  the  public static void main(String[] args)  method   that
              serves as your application's starting point.  When you use -jar,
              the specified JAR file is the source of all  user  classes,  and
              other  class  path  settings  are  ignored.  If you're using JAR
              files, then see jar.

       -m or --module module[/mainclass]
              Executes the main class in a module specified by mainclass if it
              is  given,  or, if it is not given, the value in the module.  In
              other words, mainclass can be used when it is not  specified  by
              the module, or to override the value when it is specified.

              See Standard Options for Java.

       source-file
              Only used to launch a single source-file program.  Specifies the
              source file that contains the main class when using  source-file
              mode.    See   Using  Source-File  Mode  to  Launch  Single-File
              Source-Code Programs

       args ...
              Optional:  Arguments  following  mainclass,  source-file,   -jar
              jarfile, and -m or --module module/mainclass are passed as argu-
              ments to the main class.


DESCRIPTION

       The java command starts a Java application.  It does this  by  starting
       the  Java Virtual Machine (JVM), loading the specified class, and call-
       ing that class's main() method.  The method must be declared public and
       static, it must not return any value, and it must accept a String array
       as a parameter.  The method declaration has the following form:

              public static void main(String[] args)

       In source-file mode, the java command can launch a class declared in  a
       source   file.   See  Using  Source-File  Mode  to  Launch  Single-File
       Source-Code Programs for a description of using the source-file mode.

              Note: You can  use  the  JDK_JAVA_OPTIONS  launcher  environment
              variable  to  prepend  its content to the actual command line of
              the java launcher.  See Using the JDK_JAVA_OPTIONS Launcher  En-
              vironment Variable.

       By default, the first argument that isn't an option of the java command
       is the fully qualified name of the class to  be  called.   If  -jar  is
       specified,  then  its  argument  is the name of the JAR file containing
       class and resource files for the application.  The startup  class  must
       be indicated by the Main-Class manifest header in its manifest file.

       Arguments  after the class file name or the JAR file name are passed to
       the main() method.

   javaw
       Windows: The javaw command is identical to java, except that with javaw
       there's  no associated console window.  Use javaw when you don't want a
       command prompt window to appear.  The  javaw  launcher  will,  however,
       display a dialog box with error information if a launch fails.


USING SOURCE-FILE MODE TO LAUNCH SINGLE-FILE SOURCE-CODE PROGRAMS

       To  launch  a class declared in a source file, run the java launcher in
       source-file mode.  Entering source-file mode is determined by two items
       on the java command line:

       o The  first  item on the command line that is not an option or part of
         an option.  In other words, the item in the command line  that  would
         otherwise be the main class name.

       o The --source version option, if present.

       If the class identifies an existing file that has a .java extension, or
       if the --source option is specified, then source-file mode is selected.
       The  source  file is then compiled and run.  The --source option can be
       used to specify the source version or N of the source code.   This  de-
       termines  the  API  that can be used.  When you set --source N, you can
       only use the public API that was defined in JDK N.

              Note: The valid values of N change for each  release,  with  new
              values  added  and old values removed.  You'll get an error mes-
              sage if you use a value of N that is no longer  supported.   The
              supported values of N are the current Java SE release (15) and a
              limited number  of  previous  releases,  detailed  in  the  com-
              mand-line  help  for javac, under the --source and --release op-
              tions.

       If the file does not have the .java extension, the --source option must
       be  used  to  tell  the  java command to use the source-file mode.  The
       --source option is used for cases when the source file is a "script" to
       be  executed and the name of the source file does not follow the normal
       naming conventions for Java source files.

       In source-file mode, the effect is as though the source  file  is  com-
       piled into memory, and the first class found in the source file is exe-
       cuted.  Any arguments placed after the name of the source file  in  the
       original  command line are passed to the compiled class when it is exe-
       cuted.

       For example, if a file were named HelloWorld.java and contained a class
       named  hello.World,  then  the  source-file  mode command to launch the
       class would be:

              java HelloWorld.java

       The example illustrates that the class can be in a named  package,  and
       does  not  need  to be in the unnamed package.  This use of source-file
       mode is informally equivalent to using the following two commands where
       hello.World is the name of the class in the package:

              javac -d <memory> HelloWorld.java
              java -cp <memory> hello.World

       In  source-file mode, any additional command-line options are processed
       as follows:

       o The launcher scans the options specified before the source  file  for
         any that are relevant in order to compile the source file.

         This includes: --class-path, --module-path, --add-exports, --add-mod-
         ules, --limit-modules, --patch-module, --upgrade-module-path, and any
         variant  forms  of  those  options.   It  also includes the new --en-
         able-preview option, described in JEP 12.

       o No provision is made to pass any additional options to the  compiler,
         such as -processor or -Werror.

       o Command-line  argument  files  (@-files)  may be used in the standard
         way.  Long lists of arguments for either the VM or the program  being
         invoked  may be placed in files specified on the command-line by pre-
         fixing the filename with an @ character.

       In source-file mode, compilation proceeds as follows:

       o Any command-line options that are relevant to the  compilation  envi-
         ronment are taken into account.

       o No  other  source files are found and compiled, as if the source path
         is set to an empty value.

       o Annotation processing is disabled, as if -proc:none is in effect.

       o If a version is specified, via the --source option, the value is used
         as the argument for an implicit --release option for the compilation.
         This sets both the source version accepted by compiler and the system
         API that may be used by the code in the source file.

       o The source file is compiled in the context of an unnamed module.

       o The  source  file  should  contain one or more top-level classes, the
         first of which is taken as the class to be executed.

       o The compiler does not enforce the optional restriction defined at the
         end  of  JLS  ??7.6, that a type in a named package should exist in a
         file whose name is composed from the type name followed by the  .java
         extension.

       o If  the  source  file contains errors, appropriate error messages are
         written to the standard error stream, and the launcher exits  with  a
         non-zero exit code.

       In source-file mode, execution proceeds as follows:

       o The  class  to  be executed is the first top-level class found in the
         source file.  It must contain a  declaration  of  the  standard  pub-
         lic static void main(String[]) method.

       o The  compiled classes are loaded by a custom class loader, that dele-
         gates to the application class loader.  This implies that classes ap-
         pearing on the application class path cannot refer to any classes de-
         clared in the source file.

       o The compiled classes are executed in the context of an  unnamed  mod-
         ule,  as  though  --add-modules=ALL-DEFAULT is in effect.  This is in
         addition to any other --add-module options  that  may  be  have  been
         specified on the command line.

       o Any  arguments  appearing  after  the name of the file on the command
         line are passed to the standard main method in the obvious way.

       o It is an error if there is a class  on  the  application  class  path
         whose name is the same as that of the class to be executed.

       See  JEP  330:  Launch  Single-File  Source-Code Programs [http://open-
       jdk.java.net/jeps/330] for complete details.


USING THE JDK_JAVA_OPTIONS LAUNCHER ENVIRONMENT VARIABLE

       JDK_JAVA_OPTIONS prepends its content to the options  parsed  from  the
       command line.  The content of the JDK_JAVA_OPTIONS environment variable
       is a list of arguments separated by white-space characters  (as  deter-
       mined by isspace()).  These are prepended to the command line arguments
       passed to java launcher.  The encoding requirement for the  environment
       variable  is  the same as the java command line on the system.  JDK_JA-
       VA_OPTIONS environment variable content is treated in the  same  manner
       as that specified in the command line.

       Single  (')  or double (") quotes can be used to enclose arguments that
       contain whitespace characters.  All content between the open quote  and
       the  first  matching  close  quote are preserved by simply removing the
       pair of quotes.  In case a matching quote is not  found,  the  launcher
       will  abort  with  an error message.  @-files are supported as they are
       specified in the command line.  However, as in @-files, use of a  wild-
       card  is  not  supported.   In  order  to  mitigate potential misuse of
       JDK_JAVA_OPTIONS behavior, options that specify the main class (such as
       -jar)  or  cause  the  java launcher to exit without executing the main
       class (such as -h) are disallowed in the environment variable.  If  any
       of  these options appear in the environment variable, the launcher will
       abort with an error message.  When JDK_JAVA_OPTIONS is set, the launch-
       er prints a message to stderr as a reminder.

       Example:

              $ export JDK_JAVA_OPTIONS='-g @file1 -Dprop=value @file2 -Dws.prop="white spaces"'
              $ java -Xint @file3

       is equivalent to the command line:

              java -g @file1 -Dprop=value @file2 -Dws.prop="white spaces" -Xint @file3


OVERVIEW OF JAVA OPTIONS

       The java command supports a wide range of options in the following cat-
       egories:

       o Standard Options for Java: Options guaranteed to be supported by  all
         implementations  of the Java Virtual Machine (JVM).  They're used for
         common actions, such as checking the version of the JRE, setting  the
         class path, enabling verbose output, and so on.

       o Extra  Options for Java: General purpose options that are specific to
         the Java HotSpot Virtual Machine.  They aren't guaranteed to be  sup-
         ported  by all JVM implementations, and are subject to change.  These
         options start with -X.

       The advanced options aren't recommended for casual use.  These are  de-
       veloper options used for tuning specific areas of the Java HotSpot Vir-
       tual Machine operation that often have specific system requirements and
       may require privileged access to system configuration parameters.  Sev-
       eral examples of performance tuning are provided in Performance  Tuning
       Examples.   These  options aren't guaranteed to be supported by all JVM
       implementations and are subject to change.  Advanced options start with
       -XX.

       o Advanced  Runtime  Options  for Java: Control the runtime behavior of
         the Java HotSpot VM.

       o Advanced  JIT  Compiler  Options  for  java:  Control   the   dynamic
         just-in-time (JIT) compilation performed by the Java HotSpot VM.

       o Advanced Serviceability Options for Java: Enable gathering system in-
         formation and performing extensive debugging.

       o Advanced Garbage Collection Options for  Java:  Control  how  garbage
         collection (GC) is performed by the Java HotSpot

       Boolean  options are used to either enable a feature that's disabled by
       default or disable a feature that's enabled by default.   Such  options
       don't  require  a parameter.  Boolean -XX options are enabled using the
       plus sign (-XX:+OptionName) and disabled using the minus sign (-XX:-Op-
       tionName).

       For  options  that  require  an argument, the argument may be separated
       from the option name by a space, a colon (:), or an equal sign (=),  or
       the  argument  may directly follow the option (the exact syntax differs
       for each option).  If you're expected to specify  the  size  in  bytes,
       then  you  can  use  no  suffix, or use the suffix k or K for kilobytes
       (KB), m or M for megabytes (MB), or g or G for gigabytes (GB).  For ex-
       ample,  to  set  the  size  to  8 GB, you can specify either 8g, 8192m,
       8388608k, or 8589934592 as the argument.  If you are expected to speci-
       fy the percentage, then use a number from 0 to 1.  For example, specify
       0.25 for 25%.

       The following sections describe the options that are  obsolete,  depre-
       cated, and removed:

       o Deprecated Java Options: Accepted and acted upon --- a warning is is-
         sued when they're used.

       o Obsolete Java Options: Accepted but ignored --- a warning  is  issued
         when they're used.

       o Removed Java Options: Removed --- using them results in an error.


STANDARD OPTIONS FOR JAVA

       These  are  the most commonly used options supported by all implementa-
       tions of the JVM.

              Note: To specify an argument for a long option, you can use  ei-
              ther --name=value or --name value.

       -agentlib:libname[=options]
              Loads  the  specified  native  agent library.  After the library
              name, a comma-separated list of options specific to the  library
              can be used.

              o Linux  and  macOS:  If  the option -agentlib:foo is specified,
                then the JVM attempts to load the library named  libfoo.so  in
                the  location specified by the LD_LIBRARY_PATH system variable
                (on macOS this variable is DYLD_LIBRARY_PATH).

              o Windows: If the option -agentlib:foo is  specified,  then  the
                JVM attempts to load the library named foo.dll in the location
                specified by the PATH system variable.

                The following example shows how to load the  Java  Debug  Wire
                Protocol  (JDWP)  library and listen for the socket connection
                on port 8000, suspending the JVM before the main class loads:

                       -agentlib:jdwp=transport=dt_socket,server=y,ad-
                       dress=8000

       -agentpath:pathname[=options]
              Loads  the  native  agent library specified by the absolute path
              name.  This option is equivalent to -agentlib but uses the  full
              path and file name of the library.

       --class-path classpath, -classpath classpath, or -cp classpath
              A semicolon (;) separated list of directories, JAR archives, and
              ZIP archives to search for class files.

              Specifying classpath overrides any setting of the CLASSPATH  en-
              vironment  variable.   If  the  class path option isn't used and
              classpath isn't set, then the user class path  consists  of  the
              current directory (.).

              As  a  special convenience, a class path element that contains a
              base name of an asterisk (*) is considered equivalent to  speci-
              fying  a  list of all the files in the directory with the exten-
              sion .jar or .JAR .  A Java program can't  tell  the  difference
              between  the two invocations.  For example, if the directory my-
              dir contains a.jar and b.JAR, then the class  path  element  my-
              dir/*  is  expanded to A.jar:b.JAR, except that the order of JAR
              files is unspecified.  All .jar files in the specified  directo-
              ry,  even  hidden  ones, are included in the list.  A class path
              entry consisting of an asterisk (*) expands to a list of all the
              jar  files  in the current directory.  The CLASSPATH environment
              variable, where defined, is similarly expanded.  Any class  path
              wildcard  expansion  that  occurs before the Java VM is started.
              Java programs never see wildcards that aren't expanded except by
              querying    the   environment,   such   as   by   calling   Sys-
              tem.getenv("CLASSPATH").

       --disable-@files
              Can be used anywhere on the command line, including in an  argu-
              ment  file, to prevent further @filename expansion.  This option
              stops expanding @-argfiles after the option.

       --enable-preview
              Allows classes to depend on preview features  [https://docs.ora-
              cle.com/en/java/javase/12/language/index.html#JS-
              LAN-GUID-5A82FE0E-0CA4-4F1F-B075-564874FE2823] of the release.

       --module-path modulepath... or -p modulepath
              A semicolon (;) separated list of directories in which each  di-
              rectory is a directory of modules.

       --upgrade-module-path modulepath...
              A  semicolon (;) separated list of directories in which each di-
              rectory is a directory of modules that replace upgradeable  mod-
              ules in the runtime image.

       --add-modules module[,module...]
              Specifies the root modules to resolve in addition to the initial
              module.   module  also  can  be  ALL-DEFAULT,  ALL-SYSTEM,   and
              ALL-MODULE-PATH.

       --list-modules
              Lists the observable modules and then exits.

       -d module_name or --describe-module module_name
              Describes a specified module and then exits.

       --dry-run
              Creates  the  VM  but  doesn't  execute  the  main method.  This
              --dry-run option might be useful for validating the command-line
              options such as the module system configuration.

       --validate-modules
              Validates  all  modules  and  exit.   This option is helpful for
              finding conflicts and other errors with modules  on  the  module
              path.

       -Dproperty=value
              Sets a system property value.  The property variable is a string
              with no spaces that represents the name of  the  property.   The
              value  variable  is  a  string  that represents the value of the
              property.  If value is a string with spaces, then enclose it  in
              quotation marks (for example -Dfoo="foo bar").

       -disableassertions[:[packagename]...|:classname]    or   -da[:[package-
       name]...|:classname]
              Disables assertions.  By default, assertions are disabled in all
              packages and classes.   With  no  arguments,  -disableassertions
              (-da) disables assertions in all packages and classes.  With the
              packagename argument ending in ..., the switch  disables  asser-
              tions  in the specified package and any subpackages.  If the ar-
              gument is simply ..., then the switch disables assertions in the
              unnamed  package  in  the  current  working directory.  With the
              classname argument, the switch disables assertions in the speci-
              fied class.

              The -disableassertions (-da) option applies to all class loaders
              and to  system  classes  (which  don't  have  a  class  loader).
              There's  one  exception  to this rule: If the option is provided
              with no arguments, then it  doesn't  apply  to  system  classes.
              This  makes  it easy to disable assertions in all classes except
              for system classes.  The -disablesystemassertions option enables
              you  to disable assertions in all system classes.  To explicitly
              enable assertions in specific packages or classes, use the  -en-
              ableassertions  (-ea)  option.   Both options can be used at the
              same time.  For example, to run the MyClass application with as-
              sertions  enabled  in  the  package com.wombat.fruitbat (and any
              subpackages)  but  disabled  in  the   class   com.wombat.fruit-
              bat.Brickbat, use the following command:

                     java -ea:com.wombat.fruitbat... -da:com.wombat.fruit-
                     bat.Brickbat MyClass

       -disablesystemassertions or -dsa
              Disables assertions in all system classes.

       -enableassertions[:[packagename]...|:classname]    or    -ea[:[package-
       name]...|:classname]
              Enables assertions.  By default, assertions are disabled in  all
              packages  and  classes.   With  no  arguments, -enableassertions
              (-ea) enables assertions in all packages and classes.  With  the
              packagename  argument  ending  in ..., the switch enables asser-
              tions in the specified package and any subpackages.  If the  ar-
              gument  is simply ..., then the switch enables assertions in the
              unnamed package in the  current  working  directory.   With  the
              classname  argument, the switch enables assertions in the speci-
              fied class.

              The -enableassertions (-ea) option applies to all class  loaders
              and  to  system  classes  (which  don't  have  a  class loader).
              There's one exception to this rule: If the  option  is  provided
              with  no  arguments,  then  it  doesn't apply to system classes.
              This makes it easy to enable assertions in  all  classes  except
              for system classes.  The -enablesystemassertions option provides
              a separate switch to enable assertions in  all  system  classes.
              To  explicitly disable assertions in specific packages or class-
              es, use the -disableassertions (-da) option.  If a  single  com-
              mand contains multiple instances of these switches, then they're
              processed in order, before loading any classes.  For example, to
              run  the MyClass application with assertions enabled only in the
              package com.wombat.fruitbat (and any subpackages)  but  disabled
              in  the  class  com.wombat.fruitbat.Brickbat,  use the following
              command:

                     java -ea:com.wombat.fruitbat... -da:com.wombat.fruit-
                     bat.Brickbat MyClass

       -enablesystemassertions or -esa
              Enables assertions in all system classes.

       -help, -h, or -?
              Prints the help message to the error stream.

       --help Prints the help message to the output stream.

       -javaagent:jarpath[=options]
              Loads  the  specified  Java programming language agent.  See ja-
              va.lang.instrument.

       --show-version
              Prints the product version to the output stream and continues.

       -showversion
              Prints the product version to the error stream and continues.

       --show-module-resolution
              Shows module resolution output during startup.

       -splash:imagepath
              Shows the splash screen with the image specified  by  imagepath.
              HiDPI  scaled  images  are  automatically  supported and used if
              available.  The unscaled image file  name,  such  as  image.ext,
              should  always  be passed as the argument to the -splash option.
              The most appropriate scaled image provided is picked up automat-
              ically.

              For  example, to show the splash.gif file from the images direc-
              tory when starting your application, use the following option:

                     -splash:images/splash.gif

              See the SplashScreen API documentation for more information.

       -verbose:class
              Displays information about each loaded class.

       -verbose:gc
              Displays information about each garbage collection (GC) event.

       -verbose:jni
              Displays information about the use of native methods  and  other
              Java Native Interface (JNI) activity.

       -verbose:module
              Displays information about the modules in use.

       --version
              Prints product version to the output stream and exits.

       -version
              Prints product version to the error stream and exits.

       -X     Prints the help on extra options to the error stream.

       --help-extra
              Prints the help on extra options to the output stream.

       @argfile
              Specifies  one  or more argument files prefixed by @ used by the
              java command.  It isn't uncommon for the java command line to be
              very  long  because  of  the .jar files needed in the classpath.
              The @argfile option overcomes command-line length limitations by
              enabling  the  launcher to expand the contents of argument files
              after shell expansion, but before argument processing.  Contents
              in the argument files are expanded because otherwise, they would
              be specified on the command line until the --disable-@files  op-
              tion was encountered.

              The  argument files can also contain the main class name and all
              options.  If an argument file contains all of  the  options  re-
              quired  by  the java command, then the command line could simply
              be:

                     java @argfile

              See java Command-Line Argument Files for a description and exam-
              ples of using @-argfiles.


EXTRA OPTIONS FOR JAVA

       The following java options are general purpose options that are specif-
       ic to the Java HotSpot Virtual Machine.

       -Xbatch
              Disables background compilation.  By default, the  JVM  compiles
              the  method  as  a background task, running the method in inter-
              preter mode until the background compilation is  finished.   The
              -Xbatch flag disables background compilation so that compilation
              of all methods proceeds as a foreground  task  until  completed.
              This option is equivalent to -XX:-BackgroundCompilation.

       -Xbootclasspath/a:directories|zip|JAR-files
              Specifies  a list of directories, JAR files, and ZIP archives to
              append to the end of the default bootstrap class path.

              Linux and macOS: Colons (:) separate entities in this list.

              Windows: Semicolons (;) separate entities in this list.

       -Xcheck:jni
              Performs additional checks for Java Native Interface (JNI) func-
              tions.   Specifically, it validates the parameters passed to the
              JNI function and the runtime environment data before  processing
              the  JNI request.  It also checks for pending exceptions between
              JNI calls.  Any invalid data encountered indicates a problem  in
              the  native  code,  and the JVM terminates with an irrecoverable
              error in such cases.  Expect a performance degradation when this
              option is used.

       -Xdebug
              Does nothing.  Provided for backward compatibility.

       -Xdiag Shows additional diagnostic messages.

       -Xint  Runs  the  application in interpreted-only mode.  Compilation to
              native code is disabled, and all bytecode is executed by the in-
              terpreter.  The performance benefits offered by the just-in-time
              (JIT) compiler aren't present in this mode.

       -Xinternalversion
              Displays more detailed JVM version information than the -version
              option, and then exits.

       -Xlog:option
              Configure  or enable logging with the Java Virtual Machine (JVM)
              unified logging framework.  See Enable Logging with the JVM Uni-
              fied Logging Framework.

       -Xmixed
              Executes all bytecode by the interpreter except for hot methods,
              which are compiled to native code.  On by default.  Use -Xint to
              switch off.

       -Xmn size
              Sets the initial and maximum size (in bytes) of the heap for the
              young generation (nursery) in the generational collectors.   Ap-
              pend the letter k or K to indicate kilobytes, m or M to indicate
              megabytes, or g or G to indicate gigabytes.  The  young  genera-
              tion  region  of  the  heap is used for new objects.  GC is per-
              formed in this region more often than in other regions.  If  the
              size  for the young generation is too small, then a lot of minor
              garbage collections are performed.  If the size  is  too  large,
              then only full garbage collections are performed, which can take
              a long time to complete.  It is recommended that you do not  set
              the size for the young generation for the G1 collector, and keep
              the size for the young generation greater than 25% and less than
              50%  of the overall heap size for other collectors.  The follow-
              ing examples show how to set the initial  and  maximum  size  of
              young generation to 256 MB using various units:

                     -Xmn256m
                     -Xmn262144k
                     -Xmn268435456

              Instead  of  the -Xmn option to set both the initial and maximum
              size of the heap for the young generation, you can use  -XX:New-
              Size to set the initial size and -XX:MaxNewSize to set the maxi-
              mum size.

       -Xms size
              Sets the minimum and initial size (in bytes) of the heap.   This
              value  must be a multiple of 1024 and greater than 1 MB.  Append
              the letter k or K to indicate kilobytes,  m  or  M  to  indicate
              megabytes, g or G to indicate gigabytes.  The following examples
              show how to set the size of allocated memory to 6 MB using vari-
              ous units:

                     -Xms6291456
                     -Xms6144k
                     -Xms6m

              Instead  of  the -Xms option to set both the minimum and initial
              size of the heap, you can use -XX:MinHeapSize to set the minimum
              size and -XX:InitialHeapSize to set the initial size.

              If you don't set this option, the initial size is set as the sum
              of the sizes allocated for the old generation and the young gen-
              eration.   The initial size of the heap for the young generation
              can be set using the -Xmn option or the -XX:NewSize option.

       -Xmx size
              Specifies the maximum size (in bytes) of the heap.   This  value
              must  be  a  multiple of 1024 and greater than 2 MB.  Append the
              letter k or  K  to  indicate  kilobytes,  m  or  M  to  indicate
              megabytes,  or  g or G to indicate gigabytes.  The default value
              is chosen at runtime based on system configuration.  For  server
              deployments, -Xms and -Xmx are often set to the same value.  The
              following examples show how to set the maximum allowed  size  of
              allocated memory to 80 MB using various units:

                     -Xmx83886080
                     -Xmx81920k
                     -Xmx80m

              The -Xmx option is equivalent to -XX:MaxHeapSize.

       -Xnoclassgc
              Disables garbage collection (GC) of classes.  This can save some
              GC time, which shortens  interruptions  during  the  application
              run.  When you specify -Xnoclassgc at startup, the class objects
              in the application are left untouched during GC and  are  always
              be considered live.  This can result in more memory being perma-
              nently  occupied  which,  if  not  used  carefully,  throws   an
              out-of-memory exception.

       -Xrs   Reduces  the  use of operating system signals by the JVM.  Shut-
              down hooks enable the orderly shutdown of a Java application  by
              running user cleanup code (such as closing database connections)
              at shutdown, even if the JVM terminates abruptly.

              o Linux and macOS:

                o The JVM catches signals to implement shutdown hooks for  un-
                  expected  termination.   The  JVM  uses  SIGHUP, SIGINT, and
                  SIGTERM to initiate the running of shutdown hooks.

                o Applications embedding the JVM frequently need to trap  sig-
                  nals  such as SIGINT or SIGTERM, which can lead to interfer-
                  ence with the JVM  signal  handlers.   The  -Xrs  option  is
                  available  to  address  this  issue.  When -Xrs is used, the
                  signal masks for SIGINT, SIGTERM, SIGHUP, and SIGQUIT aren't
                  changed  by  the  JVM, and signal handlers for these signals
                  aren't installed.

              o Windows:

                o The JVM watches for  console  control  events  to  implement
                  shutdown  hooks  for  unexpected termination.  Specifically,
                  the JVM registers a  console  control  handler  that  begins
                  shutdown-hook  processing and returns TRUE for CTRL_C_EVENT,
                  CTRL_CLOSE_EVENT,    CTRL_LOGOFF_EVENT,    and    CTRL_SHUT-
                  DOWN_EVENT.

                o The JVM uses a similar mechanism to implement the feature of
                  dumping thread stacks for debugging purposes.  The JVM  uses
                  CTRL_BREAK_EVENT to perform thread dumps.

                o If  the  JVM  is run as a service (for example, as a servlet
                  engine for a web  server),  then  it  can  receive  CTRL_LO-
                  GOFF_EVENT but shouldn't initiate shutdown because the oper-
                  ating system doesn't actually  terminate  the  process.   To
                  avoid  possible  interference  such as this, the -Xrs option
                  can be used.  When the -Xrs option is used, the JVM  doesn't
                  install  a console control handler, implying that it doesn't
                  watch  for  or   process   CTRL_C_EVENT,   CTRL_CLOSE_EVENT,
                  CTRL_LOGOFF_EVENT, or CTRL_SHUTDOWN_EVENT.

              There are two consequences of specifying -Xrs:

              o Linux and macOS: SIGQUIT thread dumps aren't available.

              o Windows: Ctrl + Break thread dumps aren't available.

              User  code is responsible for causing shutdown hooks to run, for
              example, by calling the System.exit() when the JVM is to be ter-
              minated.

       -Xshare:mode
              Sets the class data sharing (CDS) mode.

              Possible mode arguments for this option include the following:

              auto   Use shared class data if possible (default).

              on     Require using shared class data, otherwise fail.

                     Note:  The -Xshare:on option is used for testing purposes
                     only and may cause intermittent failures due to  the  use
                     of  address  space  layout randomization by the operation
                     system.  This option should not be used in production en-
                     vironments.

              off    Do not attempt to use shared class data.

       -XshowSettings
              Shows all settings and then continues.

       -XshowSettings:category
              Shows  settings  and continues.  Possible category arguments for
              this option include the following:

              all    Shows all categories of settings.  This  is  the  default
                     value.

              locale Shows settings related to locale.

              properties
                     Shows settings related to system properties.

              vm     Shows the settings of the JVM.

              system Linux:  Shows  host system or container configuration and
                     continues.

       -Xss size
              Sets the thread stack size (in bytes).  Append the letter k or K
              to indicate KB, m or M to indicate MB, or g or G to indicate GB.
              The default value depends on the platform:

              o Linux/x64 (64-bit): 1024 KB

              o macOS (64-bit): 1024 KB

              o Windows: The default value depends on virtual memory

              The following examples set the thread stack size to 1024  KB  in
              different units:

                     -Xss1m
                     -Xss1024k
                     -Xss1048576

              This option is similar to -XX:ThreadStackSize.

       --add-reads module=target-module(,target-module)*
              Updates module to read the target-module, regardless of the mod-
              ule declaration.  target-module can be all unnamed to  read  all
              unnamed modules.

       --add-exports module/package=target-module(,target-module)*
              Updates module to export package to target-module, regardless of
              module declaration.  The target-module can be all unnamed to ex-
              port to all unnamed modules.

       --add-opens module/package=target-module(,target-module)*
              Updates  module  to open package to target-module, regardless of
              module declaration.

       --illegal-access=parameter
              When present at run time, --illegal-access= takes a keyword  pa-
              rameter to specify a mode of operation:

                     Note: This option will be removed in a future release.

              o permit:  This  mode  opens  each package in each module in the
                run-time image to code in all unnamed modules ( such  as  code
                on  the  class  path), if that package existed in JDK 8.  This
                enables both static access, (for example,  by  compiled  byte-
                code, and deep reflective access) through the platform's vari-
                ous reflection APIs.  The first reflective-access operation to
                any  such  package causes a warning to be issued.  However, no
                warnings are issued after the first occurrence.   This  single
                warning  describes  how to enable further warnings.  This mode
                is the default for the current JDK but will change in a future
                release.

              o warn:  This  mode is identical to permit except that a warning
                message is issued for each  illegal  reflective-access  opera-
                tion.

              o debug: This mode is identical to warn except that both a warn-
                ing message and a stack trace are issued for each illegal  re-
                flective-access operation.

              o deny:  This mode disables all illegal-access operations except
                for those enabled  by  other  command-line  options,  such  as
                --add-opens.   This  mode  will become the default in a future
                release.

              The default mode, --illegal-access=permit, is intended  to  make
              you  aware  of code on the class path that reflectively accesses
              any JDK-internal APIs at least once.  To learn  about  all  such
              accesses, you can use the warn or the debug modes.  For each li-
              brary or framework on the class path that requires  illegal  ac-
              cess, you have two options:

              o If  the  component's maintainers have already released a fixed
                version that no longer uses JDK-internal  APIs  then  you  can
                consider upgrading to that version.

              o If the component still needs to be fixed, then you can contact
                its maintainers and ask them to replace their use  of  JDK-in-
                ternal APIs with the proper exported APIs.

              If  you  must  continue to use a component that requires illegal
              access, then you can eliminate the warning messages by using one
              or more --add-opens options to open only those internal packages
              to which access is required.

              To verify that your application is ready for a future version of
              the JDK, run it with --illegal-access=deny along with any neces-
              sary --add-opens options.  Any remaining  illegal-access  errors
              will  most likely be due to static references from compiled code
              to JDK-internal APIs.  You can identify  those  by  running  the
              jdeps  tool  with  the  --jdk-internals option.  For performance
              reasons, the current JDK does not  issue  warnings  for  illegal
              static-access operations.

       --limit-modules module[,module...]
              Specifies the limit of the universe of observable modules.

       --patch-module module=file(;file)*
              Overrides or augments a module with classes and resources in JAR
              files or directories.

       --source version
              Sets the version of the source in source-file mode.


EXTRA OPTIONS FOR MACOS

       The following extra options are macOS specific.

       -XstartOnFirstThread
              Runs the main() method on the first (AppKit) thread.

       -Xdock:name=application_name
              Overrides the default application name displayed in dock.

       -Xdock:icon=path_to_icon_file
              Overrides the default icon displayed in dock.


ADVANCED OPTIONS FOR JAVA

       These java options can be used to enable other advanced options.

       -XX:+UnlockDiagnosticVMOptions
              Unlocks the options intended for diagnosing  the  JVM.   By  de-
              fault,  this  option  is  disabled and diagnostic options aren't
              available.

              Command line options that are enabled with the use of  this  op-
              tion are not supported.  If you encounter issues while using any
              of these options, it is very likely that you will be required to
              reproduce the problem without using any of these unsupported op-
              tions before Oracle Support can assist  with  an  investigation.
              It  is also possible that any of these options may be removed or
              their behavior changed without any warning.

       -XX:+UnlockExperimentalVMOptions
              Unlocks the options that provide experimental  features  in  the
              JVM.   By default, this option is disabled and experimental fea-
              tures aren't available.


ADVANCED RUNTIME OPTIONS FOR JAVA

       These java options control the runtime behavior of the Java HotSpot VM.

       -XX:ActiveProcessorCount=x
              Overrides  the  number of CPUs that the VM will use to calculate
              the size of thread pools it will use for various operations such
              as Garbage Collection and ForkJoinPool.

              The  VM  normally  determines the number of available processors
              from the operating system.  This flag can be useful  for  parti-
              tioning  CPU  resources  when running multiple Java processes in
              docker containers.  This flag is honored even  if  UseContainer-
              Support  is not enabled.  See -XX:-UseContainerSupport for a de-
              scription of enabling and disabling container support.

       -XX:AllocateHeapAt=path
              Takes a path to the file system and uses memory mapping to allo-
              cate  the  object  heap on the memory device.  Using this option
              enables the HotSpot VM to allocate the Java object  heap  on  an
              alternative  memory device, such as an NV-DIMM, specified by the
              user.

              Alternative memory devices that have the same semantics as DRAM,
              including  the  semantics  of atomic operations, can be used in-
              stead of DRAM for the object heap without changing the  existing
              application code.  All other memory structures (such as the code
              heap, metaspace, and thread stacks) continue to reside in  DRAM.

              Some  operating  systems expose non-DRAM memory through the file
              system.  Memory-mapped files in these file  systems  bypass  the
              page cache and provide a direct mapping of virtual memory to the
              physical memory on the device.  The existing heap related  flags
              (such  as  -Xmx  and  -Xms) and garbage-collection related flags
              continue to work as before.

       -XX:-CompactStrings
              Disables the Compact Strings feature.  By default,  this  option
              is  enabled.  When this option is enabled, Java Strings contain-
              ing only single-byte characters are internally  represented  and
              stored  as  single-byte-per-character Strings using ISO-8859-1 /
              Latin-1 encoding.  This reduces, by 50%, the amount of space re-
              quired  for Strings containing only single-byte characters.  For
              Java Strings containing at least one multibyte character:  these
              are represented and stored as 2 bytes per character using UTF-16
              encoding.  Disabling the Compact Strings feature forces the  use
              of  UTF-16  encoding as the internal representation for all Java
              Strings.

              Cases where it may be beneficial to disable Compact Strings  in-
              clude the following:

              o When it's known that an application overwhelmingly will be al-
                locating multibyte character Strings

              o In the unexpected event where a performance regression is  ob-
                served  in migrating from Java SE 8 to Java SE 9 and an analy-
                sis shows that Compact Strings introduces the regression

              In both of these  scenarios,  disabling  Compact  Strings  makes
              sense.

       -XX:ErrorFile=filename
              Specifies  the path and file name to which error data is written
              when an irrecoverable error occurs.  By default,  this  file  is
              created  in  the current working directory and named hs_err_pid-
              pid.log where pid is the identifier of the process that  encoun-
              tered the error.

              The  following  example  shows  how  to set the default log file
              (note that the identifier of the process is specified as %p):

                     -XX:ErrorFile=./hs_err_pid%p.log

              o Linux and macOS: The following example shows how  to  set  the
                error log to /var/log/java/java_error.log:

                       -XX:ErrorFile=/var/log/java/java_error.log

              o Windows:  The following example shows how to set the error log
                file to C:/log/java/java_error.log:

                       -XX:ErrorFile=C:/log/java/java_error.log

              If the file exists, and is writeable, then it will be  overwrit-
              ten.   Otherwise,  if the file can't be created in the specified
              directory (due to insufficient space, permission problem, or an-
              other issue), then the file is created in the temporary directo-
              ry for the operating system:

              o Linux and macOS: The temporary directory is /tmp.

              o Windows: The temporary directory is specified by the value  of
                the  TMP  environment  variable;  if that environment variable
                isn't defined, then the value of the TEMP environment variable
                is used.

       -XX:+ExtensiveErrorReports
              Enables the reporting of more extensive error information in the
              ErrorFile.  This option can be turned on in  environments  where
              maximal  information is desired - even if the resulting logs may
              be quite large and/or contain information that might be  consid-
              ered  sensitive.   The  information can vary from release to re-
              lease, and across different platforms.  By default  this  option
              is disabled.

       -XX:FlightRecorderOptions=parameter=value     (or)-XX:FlightRecorderOp-
       tions:parameter=value
              Sets the parameters that control the behavior of JFR.

              The  following  list  contains the available JFR parameter=value
              entries:

              globalbuffersize=size
                     Specifies the total amount of primary memory used for da-
                     ta  retention.   The  default value is based on the value
                     specified for memorysize.  Change the memorysize  parame-
                     ter to alter the size of global buffers.

              maxchunksize=size
                     Specifies  the maximum size (in bytes) of the data chunks
                     in a recording.  Append m or M to  specify  the  size  in
                     megabytes  (MB),  or  g or G to specify the size in giga-
                     bytes (GB).  By default, the maximum size of data  chunks
                     is set to 12 MB.  The minimum allowed is 1 MB.

              memorysize=size
                     Determines  how  much  buffer  memory should be used, and
                     sets the globalbuffersize and numglobalbuffers parameters
                     based  on  the  size specified.  Append m or M to specify
                     the size in megabytes (MB), or g or G to specify the size
                     in gigabytes (GB).  By default, the memory size is set to
                     10 MB.

              numglobalbuffers
                     Specifies the number of global buffers used.  The default
                     value  is based on the memory size specified.  Change the
                     memorysize  parameter  to  alter  the  number  of  global
                     buffers.

              old-object-queue-size=number-of-objects
                     Maximum  number of old objects to track.  By default, the
                     number of objects is set to 256.

              repository=path
                     Specifies the repository (a directory) for temporary disk
                     storage.  By default, the system's temporary directory is
                     used.

              retransform={true|false}
                     Specifies whether event classes should  be  retransformed
                     using  JVMTI.   If  false,  instrumentation is added when
                     event classes are loaded.  By default, this parameter  is
                     enabled.

              samplethreads={true|false}
                     Specifies  whether  thread  sampling  is enabled.  Thread
                     sampling occurs only if the  sampling  event  is  enabled
                     along with this parameter.  By default, this parameter is
                     enabled.

              stackdepth=depth
                     Stack depth for stack traces.  By default, the  depth  is
                     set  to  64  method  calls.  The maximum is 2048.  Values
                     greater than 64 could create significant overhead and re-
                     duce performance.

              threadbuffersize=size
                     Specifies  the  per-thread  local buffer size (in bytes).
                     By default, the local buffer size is set to 8  kilobytes,
                     with a minimum value of 4 kilobytes.  Overriding this pa-
                     rameter could reduce performance and is not  recommended.

              You  can  specify  values  for multiple parameters by separating
              them with a comma.

       -XX:LargePageSizeInBytes=size
              Sets the maximum size (in bytes) for large pages  used  for  the
              Java heap.  The size argument must be a power of 2 (2, 4, 8, 16,
              and so on).  Append the letter k or K to indicate  kilobytes,  m
              or M to indicate megabytes, or g or G to indicate gigabytes.  By
              default, the size is set to 0, meaning that the JVM chooses  the
              size for large pages automatically.  See Large Pages.

              The  following  example describes how to set the large page size
              to 4 megabytes (MB):

                     -XX:LargePageSizeInBytes=4m

       -XX:MaxDirectMemorySize=size
              Sets the maximum total size (in bytes) of the java.nio  package,
              direct-buffer allocations.  Append the letter k or K to indicate
              kilobytes, m or M to indicate megabytes, or g or G  to  indicate
              gigabytes.   By  default, the size is set to 0, meaning that the
              JVM chooses the size for NIO direct-buffer allocations automati-
              cally.

              The  following  examples  illustrate  how to set the NIO size to
              1024 KB in different units:

                     -XX:MaxDirectMemorySize=1m
                     -XX:MaxDirectMemorySize=1024k
                     -XX:MaxDirectMemorySize=1048576

       -XX:-MaxFDLimit
              Disables the attempt to set the soft limit  for  the  number  of
              open  file  descriptors to the hard limit.  By default, this op-
              tion is enabled on all platforms, but  is  ignored  on  Windows.
              The  only  time  that you may need to disable this is on Mac OS,
              where its use imposes a maximum of 10240, which  is  lower  than
              the actual system maximum.

       -XX:NativeMemoryTracking=mode
              Specifies the mode for tracking JVM native memory usage.  Possi-
              ble mode arguments for this option include the following:

              off    Instructs not to track JVM native memory usage.  This  is
                     the default behavior if you don't specify the -XX:Native-
                     MemoryTracking option.

              summary
                     Tracks memory usage only by JVM subsystems, such as  Java
                     heap, class, code, and thread.

              detail In  addition  to tracking memory usage by JVM subsystems,
                     track memory usage  by  individual  CallSite,  individual
                     virtual memory region and its committed regions.

       -XX:ObjectAlignmentInBytes=alignment
              Sets  the  memory  alignment of Java objects (in bytes).  By de-
              fault, the value is set to 8 bytes.  The specified value  should
              be  a power of 2, and must be within the range of 8 and 256 (in-
              clusive).  This option  makes  it  possible  to  use  compressed
              pointers with large Java heap sizes.

              The heap size limit in bytes is calculated as:

                     4GB * ObjectAlignmentInBytes

                     Note:  As the alignment value increases, the unused space
                     between objects also increases.  As a result, you may not
                     realize  any benefits from using compressed pointers with
                     large Java heap sizes.

       -XX:OnError=string
              Sets a custom command or a series  of  semicolon-separated  com-
              mands  to run when an irrecoverable error occurs.  If the string
              contains spaces, then it must be enclosed in quotation marks.

              o Linux and macOS: The following example shows how  the  -XX:On-
                Error  option can be used to run the gcore command to create a
                core image, and start  the  gdb  debugger  to  attach  to  the
                process  in  case of an irrecoverable error (the %p designates
                the current process identifier):

                       -XX:OnError="gcore %p;gdb -p %p"

              o Windows: The following example shows how the  -XX:OnError  op-
                tion  can  be used to run the userdump.exe utility to obtain a
                crash dump in case of an irrecoverable error  (the  %p  desig-
                nates  the  current process identifier).  This example assumes
                that the path to the userdump.exe utility is specified in  the
                PATH environment variable:

                       -XX:OnError="userdump.exe %p"

       -XX:OnOutOfMemoryError=string
              Sets  a  custom  command or a series of semicolon-separated com-
              mands to run when an OutOfMemoryError exception is first thrown.
              If  the string contains spaces, then it must be enclosed in quo-
              tation marks.  For an example of a command string, see  the  de-
              scription of the -XX:OnError option.

       -XX:+PrintCommandLineFlags
              Enables  printing  of  ergonomically selected JVM flags that ap-
              peared on the command line.  It can be useful to  know  the  er-
              gonomic  values  set by the JVM, such as the heap space size and
              the selected garbage collector.  By default, this option is dis-
              abled and flags aren't printed.

       -XX:+PreserveFramePointer
              Selects between using the RBP register as a general purpose reg-
              ister (-XX:-PreserveFramePointer) and using the RBP register  to
              hold  the  frame  pointer  of  the  currently  executing  method
              (-XX:+PreserveFramePointer .  If the frame pointer is available,
              then external profiling tools (for example, Linux perf) can con-
              struct more accurate stack traces.

       -XX:+PrintNMTStatistics
              Enables printing of collected native memory tracking data at JVM
              exit when native memory tracking is enabled (see -XX:NativeMemo-
              ryTracking).  By default, this option  is  disabled  and  native
              memory tracking data isn't printed.

       -XX:SharedArchiveFile=path
              Specifies  the path and name of the class data sharing (CDS) ar-
              chive file

              See Application Class Data Sharing.

       -XX:SharedArchiveConfigFile=shared_config_file
              Specifies additional shared data added to the archive file.

       -XX:SharedClassListFile=file_name
              Specifies the text file that contains the names of  the  classes
              to  store  in  the  class data sharing (CDS) archive.  This file
              contains the full name of one class per line, except slashes (/)
              replace  dots  (.).   For  example,  to  specify the classes ja-
              va.lang.Object and hello.Main, create a text file that  contains
              the following two lines:

                     java/lang/Object
                     hello/Main

              The  classes  that  you specify in this text file should include
              the classes that are commonly used by the application.  They may
              include  any  classes  from the application, extension, or boot-
              strap class paths.

              See Application Class Data Sharing.

       -XX:+ShowCodeDetailsInExceptionMessages
              Enables  printing  of  improved  NullPointerException  messages.
              When  an  application  throws a NullPointerException, the option
              enables the JVM to analyze the program's  bytecode  instructions
              to  determine  precisely  which reference is null, and describes
              the source with a null-detail message.  The null-detail  message
              is calculated and returned by NullPointerException.getMessage(),
              and will be printed as the  exception  message  along  with  the
              method,  filename,  and line number.  By default, this option is
              enabled.

       -XX:+ShowMessageBoxOnError
              Enables the display of a dialog box when the JVM experiences  an
              irrecoverable  error.   This  prevents  the JVM from exiting and
              keeps the process active so that you can attach a debugger to it
              to  investigate the cause of the error.  By default, this option
              is disabled.

       -XX:StartFlightRecording=parameter=value
              Starts a JFR recording for the Java application.  This option is
              equivalent  to  the  JFR.start  diagnostic command that starts a
              recording during runtime.  You can  set  the  following  parame-
              ter=value entries when starting a JFR recording:

              delay=time
                     Specifies  the  delay between the Java application launch
                     time and the start of the recording.  Append s to specify
                     the time in seconds, m for minutes, h for hours, or d for
                     days (for example, specifying 10m means 10 minutes).   By
                     default,  there's  no delay, and this parameter is set to
                     0.

              disk={true|false}
                     Specifies whether to write data to disk while  recording.
                     By default, this parameter is enabled.

              dumponexit={true|false}
                     Specifies if the running recording is dumped when the JVM
                     shuts down.  If enabled and a filename  is  not  entered,
                     the recording is written to a file in the directory where
                     the process was started.  The file name is a  system-gen-
                     erated  name  that contains the process ID, recording ID,
                     and       current       timestamp,       similar       to
                     hotspot-pid-47496-id-1-2018_01_25_19_10_41.jfr.   By  de-
                     fault, this parameter is disabled.

              duration=time
                     Specifies the duration of the  recording.   Append  s  to
                     specify  the time in seconds, m for minutes, h for hours,
                     or d for days (for example, specifying 5h means 5 hours).
                     By  default, the duration isn't limited, and this parame-
                     ter is set to 0.

              filename=path
                     Specifies the path and name of  the  file  to  which  the
                     recording  is  written when the recording is stopped, for
                     example:

                     o recording.jfr

                     o /home/user/recordings/recording.jfr

                     o c:\recordings\recording.jfr

              name=identifier
                     Takes both the name and the identifier of a recording.

              maxage=time
                     Specifies the maximum age of disk data to  keep  for  the
                     recording.   This  parameter  is valid only when the disk
                     parameter is set to true.  Append s to specify  the  time
                     in  seconds,  m  for  minutes, h for hours, or d for days
                     (for example, specifying 30s means 30 seconds).   By  de-
                     fault,  the maximum age isn't limited, and this parameter
                     is set to 0s.

              maxsize=size
                     Specifies the maximum size (in bytes)  of  disk  data  to
                     keep  for  the  recording.   This parameter is valid only
                     when the disk parameter is set to true.  The  value  must
                     not be less than the value for the maxchunksize parameter
                     set with -XX:FlightRecorderOptions.  Append  m  or  M  to
                     specify  the  size in megabytes, or g or G to specify the
                     size in gigabytes.  By default, the maximum size of  disk
                     data isn't limited, and this parameter is set to 0.

              path-to-gc-roots={true|false}
                     Specifies  whether to collect the path to garbage collec-
                     tion (GC) roots at the end of a recording.   By  default,
                     this parameter is disabled.

                     The  path to GC roots is useful for finding memory leaks,
                     but collecting it is time-consuming.  Enable this  option
                     only  when  you start a recording for an application that
                     you suspect has a memory leak.  If the settings parameter
                     is  set to profile, the stack trace from where the poten-
                     tial leaking object was allocated is included in the  in-
                     formation collected.

              settings=path
                     Specifies  the  path  and name of the event settings file
                     (of type JFC).  By default, the default.jfc file is used,
                     which is located in JAVA_HOME/lib/jfr.  This default set-
                     tings file collects a predefined set of information  with
                     low overhead, so it has minimal impact on performance and
                     can be used with recordings that run continuously.

                     A second settings file  is  also  provided,  profile.jfc,
                     which  provides more data than the default configuration,
                     but can have more overhead and impact  performance.   Use
                     this  configuration  for  short periods of time when more
                     information is needed.

              You can specify values for  multiple  parameters  by  separating
              them with a comma.

       -XX:ThreadStackSize=size
              Sets  the Java thread stack size (in kilobytes).  Use of a scal-
              ing suffix, such as k, results in the scaling of  the  kilobytes
              value  so that -XX:ThreadStackSize=1k sets the Java thread stack
              size to 1024*1024 bytes or 1 megabyte.  The  default  value  de-
              pends on the platform:

              o Linux/x64 (64-bit): 1024 KB

              o macOS (64-bit): 1024 KB

              o Windows: The default value depends on virtual memory

              The  following examples show how to set the thread stack size to
              1 megabyte in different units:

                     -XX:ThreadStackSize=1k
                     -XX:ThreadStackSize=1024

              This option is similar to -Xss.

       -XX:-UseCompressedOops
              Disables the use of compressed pointers.  By default,  this  op-
              tion  is  enabled,  and compressed pointers are used.  This will
              automatically limit the maximum  ergonomically  determined  Java
              heap size to the maximum amount of memory that can be covered by
              compressed pointers.  By default this range is 32 GB.

              With compressed oops enabled, object references are  represented
              as  32-bit  offsets  instead of 64-bit pointers, which typically
              increases performance when running  the  application  with  Java
              heap sizes smaller than the compressed oops pointer range.  This
              option works only for 64-bit JVMs.

              It's possible to use compressed pointers with  Java  heap  sizes
              greater  than 32 GB.  See the -XX:ObjectAlignmentInBytes option.

       -XX:-UseContainerSupport
              The VM now provides automatic container detection support, which
              allows  the  VM  to determine the amount of memory and number of
              processors that are available to a Java process running in dock-
              er  containers.  It uses this information to allocate system re-
              sources.  This support is only available on Linux x64 platforms.
              If  supported,  the default for this flag is true, and container
              support  is  enabled  by  default.   It  can  be  disabled  with
              -XX:-UseContainerSupport.

              Unified  Logging is available to help to diagnose issues related
              to this support.

              Use -Xlog:os+container=trace for maximum  logging  of  container
              information.   See  Enable  Logging with the JVM Unified Logging
              Framework for a description of using Unified Logging.

       -XX:+UseHugeTLBFS
              Linux  only:  This  option  is  the  equivalent  of   specifying
              -XX:+UseLargePages.   This  option is disabled by default.  This
              option pre-allocates all large pages up-front,  when  memory  is
              reserved;  consequently the JVM can't dynamically grow or shrink
              large pages memory areas; see -XX:UseTransparentHugePages if you
              want this behavior.

              See Large Pages.

       -XX:+UseLargePages
              Enables  the  use of large page memory.  By default, this option
              is disabled and large page memory isn't used.

              See Large Pages.

       -XX:+UseTransparentHugePages
              Linux only: Enables the use of large pages that can  dynamically
              grow  or  shrink.   This option is disabled by default.  You may
              encounter performance problems with transparent  huge  pages  as
              the  OS  moves other pages around to create huge pages; this op-
              tion is made available for experimentation.

       -XX:+AllowUserSignalHandlers
              Enables installation of signal handlers by the application.   By
              default,  this  option is disabled and the application isn't al-
              lowed to install signal handlers.

       -XX:VMOptionsFile=filename
              Allows user to specify VM options in a file,  for  example,  ja-
              va -XX:VMOptionsFile=/var/my_vm_options HelloWorld.


ADVANCED JIT COMPILER OPTIONS FOR JAVA

       These  java  options control the dynamic just-in-time (JIT) compilation
       performed by the Java HotSpot VM.

       -XX:AllocateInstancePrefetchLines=lines
              Sets the number of lines to prefetch ahead of the instance allo-
              cation  pointer.  By default, the number of lines to prefetch is
              set to 1:

                     -XX:AllocateInstancePrefetchLines=1

       -XX:AllocatePrefetchDistance=size
              Sets the size (in bytes) of the prefetch distance for object al-
              location.   Memory about to be written with the value of new ob-
              jects is prefetched up to this distance starting  from  the  ad-
              dress  of  the  last allocated object.  Each Java thread has its
              own allocation point.

              Negative values denote that prefetch distance is chosen based on
              the  platform.   Positive  values are bytes to prefetch.  Append
              the letter k or K to indicate kilobytes,  m  or  M  to  indicate
              megabytes,  or  g or G to indicate gigabytes.  The default value
              is set to -1.

              The following example shows how to set the prefetch distance  to
              1024 bytes:

                     -XX:AllocatePrefetchDistance=1024

       -XX:AllocatePrefetchInstr=instruction
              Sets  the  prefetch instruction to prefetch ahead of the alloca-
              tion pointer.  Possible values are from 0 to 3.  The actual  in-
              structions  behind  the  values  depend on the platform.  By de-
              fault, the prefetch instruction is set to 0:

                     -XX:AllocatePrefetchInstr=0

       -XX:AllocatePrefetchLines=lines
              Sets the number of cache lines to load after the last object al-
              location  by  using  the prefetch instructions generated in com-
              piled code.  The default value is 1 if the last allocated object
              was an instance, and 3 if it was an array.

              The  following  example  shows  how  to set the number of loaded
              cache lines to 5:

                     -XX:AllocatePrefetchLines=5

       -XX:AllocatePrefetchStepSize=size
              Sets the step size (in bytes) for sequential  prefetch  instruc-
              tions.   Append  the letter k or K to indicate kilobytes, m or M
              to indicate megabytes, g or G to  indicate  gigabytes.   By  de-
              fault, the step size is set to 16 bytes:

                     -XX:AllocatePrefetchStepSize=16

       -XX:AllocatePrefetchStyle=style
              Sets  the  generated  code style for prefetch instructions.  The
              style argument is an integer from 0 to 3:

              0      Don't generate prefetch instructions.

              1      Execute  prefetch  instructions  after  each  allocation.
                     This is the default setting.

              2      Use  the  thread-local  allocation block (TLAB) watermark
                     pointer to determine when prefetch instructions are  exe-
                     cuted.

              3      Generate one prefetch instruction per cache line.

       -XX:+BackgroundCompilation
              Enables  background  compilation.  This option is enabled by de-
              fault.  To disable background  compilation,  specify  -XX:-Back-
              groundCompilation (this is equivalent to specifying -Xbatch).

       -XX:CICompilerCount=threads
              Sets  the number of compiler threads to use for compilation.  By
              default, the number of compiler threads is selected automatical-
              ly depending on the number of CPUs and memory available for com-
              piled code.  The following example shows how to set  the  number
              of threads to 2:

                     -XX:CICompilerCount=2

       -XX:+UseDynamicNumberOfCompilerThreads
              Dynamically  create compiler thread up to the limit specified by
              -XX:CICompilerCount.  This option is enabled by default.

       -XX:CompileCommand=command,method[,option]
              Specifies a command to perform on a method.  For example, to ex-
              clude  the  indexOf() method of the String class from being com-
              piled, use the following:

                     -XX:CompileCommand=exclude,java/lang/String.indexOf

              Note that the full class name is specified, including all  pack-
              ages  and  subpackages  separated  by  a  slash (/).  For easier
              cut-and-paste operations, it's also possible to use  the  method
              name  format produced by the -XX:+PrintCompilation and -XX:+Log-
              Compilation options:

                     -XX:CompileCommand=exclude,java.lang.String::indexOf

              If the method is specified without the signature, then the  com-
              mand  is applied to all methods with the specified name.  Howev-
              er, you can also specify the signature  of  the  method  in  the
              class  file  format.  In this case, you should enclose the argu-
              ments in quotation marks, because otherwise the shell treats the
              semicolon as a command end.  For example, if you want to exclude
              only the indexOf(String) method of the String class  from  being
              compiled, use the following:

                     -XX:CompileCommand="exclude,java/lang/String.index-
                     Of,(Ljava/lang/String;)I"

              You can also use the asterisk (*) as a wildcard  for  class  and
              method  names.  For example, to exclude all indexOf() methods in
              all classes from being compiled, use the following:

                     -XX:CompileCommand=exclude,*.indexOf

              The commas and periods are aliases for spaces, making it  easier
              to  pass  compiler commands through a shell.  You can pass argu-
              ments to -XX:CompileCommand using spaces as  separators  by  en-
              closing the argument in quotation marks:

                     -XX:CompileCommand="exclude java/lang/String indexOf"

              Note  that after parsing the commands passed on the command line
              using the -XX:CompileCommand  options,  the  JIT  compiler  then
              reads  commands  from  the  .hotspot_compiler file.  You can add
              commands to this file or specify  a  different  file  using  the
              -XX:CompileCommandFile option.

              To  add  several commands, either specify the -XX:CompileCommand
              option multiple times, or separate each argument  with  the  new
              line separator (\n).  The following commands are available:

              break  Sets  a  breakpoint when debugging the JVM to stop at the
                     beginning of compilation of the specified method.

              compileonly
                     Excludes all methods  from  compilation  except  for  the
                     specified  method.   As  an  alternative, you can use the
                     -XX:CompileOnly option, which lets  you  specify  several
                     methods.

              dontinline
                     Prevents inlining of the specified method.

              exclude
                     Excludes the specified method from compilation.

              help   Prints  a help message for the -XX:CompileCommand option.

              inline Attempts to inline the specified method.

              log    Excludes compilation logging (with  the  -XX:+LogCompila-
                     tion  option)  for  all  methods except for the specified
                     method.  By default, logging is performed  for  all  com-
                     piled methods.

              option Passes  a  JIT compilation option to the specified method
                     in place of the last argument (option).  The  compilation
                     option is set at the end, after the method name.  For ex-
                     ample, to enable the  BlockLayoutByFrequency  option  for
                     the  append()  method  of the StringBuffer class, use the
                     following:

                            -XX:CompileCommand=option,java/lang/String-
                            Buffer.append,BlockLayoutByFrequency

                     You  can  specify multiple compilation options, separated
                     by commas or spaces.

              print  Prints generated assembler code after compilation of  the
                     specified method.

              quiet  Instructs not to print the compile commands.  By default,
                     the commands that you specify with the -XX:CompileCommand
                     option are printed; for example, if you exclude from com-
                     pilation the indexOf() method of the String  class,  then
                     the following is printed to standard output:

                            CompilerOracle: exclude java/lang/String.indexOf

                     You  can  suppress this by specifying the -XX:CompileCom-
                     mand=quiet option  before  other  -XX:CompileCommand  op-
                     tions.

       -XX:CompileCommandFile=filename
              Sets the file from which JIT compiler commands are read.  By de-
              fault, the .hotspot_compiler file is used to store commands per-
              formed by the JIT compiler.

              Each  line  in  the  command  file represents a command, a class
              name, and a method name for which the command is used.  For  ex-
              ample,  this line prints assembly code for the toString() method
              of the String class:

                     print java/lang/String toString

              If you're using commands for the  JIT  compiler  to  perform  on
              methods, then see the -XX:CompileCommand option.

       -XX:CompilerDirectivesFile=file
              Adds  directives from a file to the directives stack when a pro-
              gram   starts.    See   Compiler   Control    [https://docs.ora-
              cle.com/en/java/javase/12/vm/compiler-con-
              trol1.html#GUID-94AD8194-786A-4F19-BFFF-278F8E237F3A].

              The -XX:CompilerDirectivesFile option has to  be  used  together
              with the -XX:UnlockDiagnosticVMOptions option that unlocks diag-
              nostic JVM options.

       -XX:+CompilerDirectivesPrint
              Prints the directives stack when the program starts  or  when  a
              new directive is added.

              The  -XX:+CompilerDirectivesPrint option has to be used together
              with the -XX:UnlockDiagnosticVMOptions option that unlocks diag-
              nostic JVM options.

       -XX:CompileOnly=methods
              Sets the list of methods (separated by commas) to which compila-
              tion should be restricted.  Only the specified methods are  com-
              piled.   Specify each method with the full class name (including
              the packages and subpackages).  For example, to compile only the
              length() method of the String class and the size() method of the
              List class, use the following:

                     -XX:CompileOnly=java/lang/String.length,ja-
                     va/util/List.size

              Note  that the full class name is specified, including all pack-
              ages and subpackages separated by a slash (/).  For  easier  cut
              and  paste operations, it's also possible to use the method name
              format produced by the -XX:+PrintCompilation and  -XX:+LogCompi-
              lation options:

                     -XX:CompileOnly=java.lang.String::length,ja-
                     va.util.List::size

              Although wildcards aren't supported, you can  specify  only  the
              class  or  package  name to compile all methods in that class or
              package, as well as specify just the method to  compile  methods
              with this name in any class:

                     -XX:CompileOnly=java/lang/String
                     -XX:CompileOnly=java/lang
                     -XX:CompileOnly=.length

       -XX:CompileThresholdScaling=scale
              Provides unified control of first compilation.  This option con-
              trols when methods are first compiled for both  the  tiered  and
              the  nontiered  modes of operation.  The CompileThresholdScaling
              option has a floating point value between 0 and +Inf and  scales
              the  thresholds  corresponding  to the current mode of operation
              (both tiered and nontiered).  Setting CompileThresholdScaling to
              a  value less than 1.0 results in earlier compilation while val-
              ues greater than 1.0 delay compilation.  Setting  CompileThresh-
              oldScaling to 0 is equivalent to disabling compilation.

       -XX:+DoEscapeAnalysis
              Enables  the  use of escape analysis.  This option is enabled by
              default.   To  disable  the  use  of  escape  analysis,  specify
              -XX:-DoEscapeAnalysis.

       -XX:InitialCodeCacheSize=size
              Sets  the initial code cache size (in bytes).  Append the letter
              k or K to indicate kilobytes, m or M to indicate megabytes, or g
              or  G  to  indicate gigabytes.  The default value depends on the
              platform.  The initial code cache size shouldn't  be  less  than
              the  system's  minimal  memory page size.  The following example
              shows how to set the initial code cache size to 32 KB:

                     -XX:InitialCodeCacheSize=32k

       -XX:+Inline
              Enables method inlining.  This option is enabled by  default  to
              increase  performance.   To  disable  method  inlining,  specify
              -XX:-Inline.

       -XX:InlineSmallCode=size
              Sets the maximum code size (in bytes) for already compiled meth-
              ods  that may be inlined.  This flag only applies to the C2 com-
              piler.  Append the letter k or K to indicate kilobytes, m  or  M
              to indicate megabytes, or g or G to indicate gigabytes.  The de-
              fault value depends on the platform and on whether tiered compi-
              lation  is  enabled.  In the following example it is set to 1000
              bytes:

                     -XX:InlineSmallCode=1000

       -XX:+LogCompilation
              Enables  logging  of  compilation  activity  to  a  file   named
              hotspot.log in the current working directory.  You can specify a
              different log file path and name using the -XX:LogFile option.

              By default, this option is  disabled  and  compilation  activity
              isn't logged.  The -XX:+LogCompilation option has to be used to-
              gether with the -XX:UnlockDiagnosticVMOptions  option  that  un-
              locks diagnostic JVM options.

              You  can enable verbose diagnostic output with a message printed
              to the console every time a method  is  compiled  by  using  the
              -XX:+PrintCompilation option.

       -XX:FreqInlineSize=size
              Sets  the maximum bytecode size (in bytes) of a hot method to be
              inlined.  This flag only applies to the C2 compiler.  Append the
              letter  k  or  K  to  indicate  kilobytes,  m  or  M to indicate
              megabytes, or g or G to indicate gigabytes.  The  default  value
              depends  on the platform.  In the following example it is set to
              325 bytes:

                     -XX:FreqInlineSize=325

       -XX:MaxInlineSize=size
              Sets the maximum bytecode size (in bytes) of a cold method to be
              inlined.  This flag only applies to the C2 compiler.  Append the
              letter k or  K  to  indicate  kilobytes,  m  or  M  to  indicate
              megabytes,  or  g  or  G to indicate gigabytes.  By default, the
              maximum bytecode size is set to 35 bytes:

                     -XX:MaxInlineSize=35

       -XX:C1MaxInlineSize=size
              Sets the maximum bytecode size (in bytes) of a cold method to be
              inlined.  This flag only applies to the C1 compiler.  Append the
              letter k or  K  to  indicate  kilobytes,  m  or  M  to  indicate
              megabytes,  or  g  or  G to indicate gigabytes.  By default, the
              maximum bytecode size is set to 35 bytes:

                     -XX:MaxInlineSize=35

       -XX:MaxTrivialSize=size
              Sets the maximum bytecode size (in bytes) of a trivial method to
              be  inlined.  This flag only applies to the C2 compiler.  Append
              the letter k or K to indicate kilobytes,  m  or  M  to  indicate
              megabytes,  or  g  or  G to indicate gigabytes.  By default, the
              maximum bytecode size of a trivial method is set to 6 bytes:

                     -XX:MaxTrivialSize=6

       -XX:C1MaxTrivialSize=size
              Sets the maximum bytecode size (in bytes) of a trivial method to
              be  inlined.  This flag only applies to the C1 compiler.  Append
              the letter k or K to indicate kilobytes,  m  or  M  to  indicate
              megabytes,  or  g  or  G to indicate gigabytes.  By default, the
              maximum bytecode size of a trivial method is set to 6 bytes:

                     -XX:MaxTrivialSize=6

       -XX:MaxNodeLimit=nodes
              Sets the maximum number of nodes to be used during single method
              compilation.   By  default the value depends on the features en-
              abled.  In the following example the maximum number of nodes  is
              set to 100,000:

                     -XX:MaxNodeLimit=100000

       -XX:NonNMethodCodeHeapSize=size
              Sets  the size in bytes of the code segment containing nonmethod
              code.

              A nonmethod code segment containing nonmethod code, such as com-
              piler  buffers  and  the  bytecode  interpreter.  This code type
              stays in the code cache forever.  This  flag  is  used  only  if
              -XX:SegmentedCodeCache is enabled.

       -XX:NonProfiledCodeHeapSize=size
              Sets  the  size  in bytes of the code segment containing nonpro-
              filed methods.  This flag is used only if -XX:SegmentedCodeCache
              is enabled.

       -XX:+OptimizeStringConcat
              Enables  the  optimization  of  String concatenation operations.
              This option is enabled by default.  To disable the  optimization
              of String concatenation operations, specify -XX:-OptimizeString-
              Concat.

       -XX:+PrintAssembly
              Enables printing of assembly code for bytecoded and native meth-
              ods  by using the external hsdis-<arch>.so or .dll library.  For
              64-bit VM on Windows, it's hsdis-amd64.dll.  This  lets  you  to
              see  the  generated code, which may help you to diagnose perfor-
              mance issues.

              By default, this option is  disabled  and  assembly  code  isn't
              printed.   The -XX:+PrintAssembly option has to be used together
              with the -XX:UnlockDiagnosticVMOptions option that unlocks diag-
              nostic JVM options.

       -XX:ProfiledCodeHeapSize=size
              Sets  the  size in bytes of the code segment containing profiled
              methods.  This flag is used only  if  -XX:SegmentedCodeCache  is
              enabled.

       -XX:+PrintCompilation
              Enables  verbose  diagnostic  output  from the JVM by printing a
              message to the console every time a method  is  compiled.   This
              lets  you  to  see  which methods actually get compiled.  By de-
              fault, this option  is  disabled  and  diagnostic  output  isn't
              printed.

              You  can  also  log  compilation activity to a file by using the
              -XX:+LogCompilation option.

       -XX:+PrintInlining
              Enables printing of inlining  decisions.   This  let's  you  see
              which methods are getting inlined.

              By  default,  this  option  is disabled and inlining information
              isn't printed.  The -XX:+PrintInlining option has to be used to-
              gether  with  the -XX:+UnlockDiagnosticVMOptions option that un-
              locks diagnostic JVM options.

       -XX:ReservedCodeCacheSize=size
              Sets the maximum code cache size  (in  bytes)  for  JIT-compiled
              code.  Append the letter k or K to indicate kilobytes, m or M to
              indicate megabytes, or g or G to indicate  gigabytes.   The  de-
              fault  maximum  code cache size is 240 MB; if you disable tiered
              compilation with the option -XX:-TieredCompilation, then the de-
              fault  size  is  48 MB.  This option has a limit of 2 GB; other-
              wise, an error  is  generated.   The  maximum  code  cache  size
              shouldn't  be less than the initial code cache size; see the op-
              tion -XX:InitialCodeCacheSize.

       -XX:RTMAbortRatio=abort_ratio
              Specifies the RTM abort ratio is specified as a  percentage  (%)
              of all executed RTM transactions.  If a number of aborted trans-
              actions becomes greater than this ratio, then the compiled  code
              is  deoptimized.   This  ratio is used when the -XX:+UseRTMDeopt
              option is enabled.  The default value  of  this  option  is  50.
              This  means  that the compiled code is deoptimized if 50% of all
              transactions are aborted.

       -XX:RTMRetryCount=number_of_retries
              Specifies the number of times that the RTM locking code  is  re-
              tried,  when  it  is aborted or busy, before falling back to the
              normal locking mechanism.  The default value for this option  is
              5.  The -XX:UseRTMLocking option must be enabled.

       -XX:+SegmentedCodeCache
              Enables  segmentation  of the code cache.  Without the -XX:+Seg-
              mentedCodeCache, the code cache consists of one  large  segment.
              With -XX:+SegmentedCodeCache, we have separate segments for non-
              method, profiled method, and  nonprofiled  method  code.   These
              segments  aren't  resized at runtime.  The feature is enabled by
              default if tiered compilation is enabled (-XX:+TieredCompilation
              )  and  -XX:ReservedCodeCacheSize >= 240 MB.  The advantages are
              better control of the memory footprint, reduced code  fragmenta-
              tion,  and better iTLB/iCache behavior due to improved locality.
              iTLB/iCache is a CPU-specific term meaning Instruction  Transla-
              tion Lookaside Buffer (ITLB).  ICache is an instruction cache in
              theCPU.  The implementation of the code cache can  be  found  in
              the file: /share/vm/code/codeCache.cpp.

       -XX:StartAggressiveSweepingAt=percent
              Forces  stack  scanning of active methods to aggressively remove
              unused code when only the given percentage of the code cache  is
              free.  The default value is 10%.

       -XX:-TieredCompilation
              Disables the use of tiered compilation.  By default, this option
              is enabled.

       -XX:UseSSE=version
              Enables the use of SSE instruction set of a  specified  version.
              Is  set  by  default  to the highest supported version available
              (x86 only).

       -XX:UseAVX=version
              Enables the use of AVX instruction set of a  specified  version.
              Is  set  by  default  to the highest supported version available
              (x86 only).

       -XX:+UseAES
              Enables hardware-based AES intrinsics for hardware that supports
              it.   This option is on by default on hardware that has the nec-
              essary instructions.  The -XX:+UseAES  is  used  in  conjunction
              with  UseAESIntrinsics.   Flags  that control intrinsics now re-
              quire the option -XX:+UnlockDiagnosticVMOptions.

       -XX:+UseAESIntrinsics
              Enables  AES  intrinsics.   Specifying-XX:+UseAESIntrinsics   is
              equivalent  to  also  enabling  -XX:+UseAES.   To  disable hard-
              ware-based AES  intrinsics,  specify  -XX:-UseAES -XX:-UseAESIn-
              trinsics.   For example, to enable hardware AES, use the follow-
              ing flags:

                     -XX:+UseAES -XX:+UseAESIntrinsics

              Flags that control intrinsics now require  the  option  -XX:+Un-
              lockDiagnosticVMOptions.

       -XX:+UseAESCTRIntrinsics
              Analogous to -XX:+UseAESIntrinsics enables AES/CTR intrinsics.

       -XX:+UseGHASHIntrinsics
              Controls  the  use  of  GHASH intrinsics.  Enabled by default on
              platforms that support the  corresponding  instructions.   Flags
              that  control intrinsics now require the option -XX:+UnlockDiag-
              nosticVMOptions.

       -XX:+UseBASE64Intrinsics
              Controls the use of accelerated BASE64 encoding routines for ja-
              va.util.Base64.   Enabled  by  default on platforms that support
              it.  Flags  that  control  intrinsics  now  require  the  option
              -XX:+UnlockDiagnosticVMOptions.

       -XX:+UseAdler32Intrinsics
              Controls the use of Adler32 checksum algorithm intrinsic for ja-
              va.util.zip.Adler32.  Enabled by default on platforms that  sup-
              port  it.   Flags that control intrinsics now require the option
              -XX:+UnlockDiagnosticVMOptions.

       -XX:+UseCRC32Intrinsics
              Controls the use of CRC32  intrinsics  for  java.util.zip.CRC32.
              Enabled  by  default  on  platforms that support it.  Flags that
              control intrinsics now require  the  option  -XX:+UnlockDiagnos-
              ticVMOptions.

       -XX:+UseCRC32CIntrinsics
              Controls  the use of CRC32C intrinsics for java.util.zip.CRC32C.
              Enabled by default on platforms that  support  it.   Flags  that
              control  intrinsics  now  require the option -XX:+UnlockDiagnos-
              ticVMOptions.

       -XX:+UseSHA
              Enables hardware-based intrinsics for SHA crypto hash  functions
              for  some  hardware.   The  UseSHA option is used in conjunction
              with  the  UseSHA1Intrinsics,  UseSHA256Intrinsics,   and   Use-
              SHA512Intrinsics options.

              The UseSHA and UseSHA*Intrinsics flags are enabled by default on
              machines that support the corresponding instructions.

              This feature is  applicable  only  when  using  the  sun.securi-
              ty.provider.Sun provider for SHA operations.  Flags that control
              intrinsics now  require  the  option  -XX:+UnlockDiagnosticVMOp-
              tions.

              To  disable  all  hardware-based  SHA  intrinsics,  specify  the
              -XX:-UseSHA.  To disable only a particular  SHA  intrinsic,  use
              the  appropriate  corresponding  option.  For example: -XX:-Use-
              SHA256Intrinsics.

       -XX:+UseSHA1Intrinsics
              Enables intrinsics for SHA-1 crypto hash function.   Flags  that
              control  intrinsics  now  require the option -XX:+UnlockDiagnos-
              ticVMOptions.

       -XX:+UseSHA256Intrinsics
              Enables intrinsics for SHA-224 and  SHA-256  crypto  hash  func-
              tions.   Flags  that  control  intrinsics now require the option
              -XX:+UnlockDiagnosticVMOptions.

       -XX:+UseSHA512Intrinsics
              Enables intrinsics for SHA-384 and  SHA-512  crypto  hash  func-
              tions.   Flags  that  control  intrinsics now require the option
              -XX:+UnlockDiagnosticVMOptions.

       -XX:+UseMathExactIntrinsics
              Enables  intrinsification  of  various   java.lang.Math.*Exact()
              functions.   Enabled  by default.  Flags that control intrinsics
              now require the option -XX:+UnlockDiagnosticVMOptions.

       -XX:+UseMultiplyToLenIntrinsic
              Enables intrinsification of BigInteger.multiplyToLen().  Enabled
              by default on platforms that support it.  Flags that control in-
              trinsics now require the option  -XX:+UnlockDiagnosticVMOptions.

       -XX:+UseSquareToLenIntrinsic
              Enables  intrinsification  of BigInteger.squareToLen().  Enabled
              by default on platforms that support it.  Flags that control in-
              trinsics  now require the option -XX:+UnlockDiagnosticVMOptions.

       -XX:+UseMulAddIntrinsic
              Enables intrinsification of BigInteger.mulAdd().  Enabled by de-
              fault  on platforms that support it.  Flags that control intrin-
              sics now require the option -XX:+UnlockDiagnosticVMOptions.

       -XX:+UseMontgomeryMultiplyIntrinsic
              Enables  intrinsification  of   BigInteger.montgomeryMultiply().
              Enabled  by  default  on  platforms that support it.  Flags that
              control intrinsics now require  the  option  -XX:+UnlockDiagnos-
              ticVMOptions.

       -XX:+UseMontgomerySquareIntrinsic
              Enables  intrinsification of BigInteger.montgomerySquare().  En-
              abled by default on platforms that support it.  Flags that  con-
              trol  intrinsics  now require the option -XX:+UnlockDiagnosticV-
              MOptions.

       -XX:+UseCMoveUnconditionally
              Generates CMove (scalar and vector) instructions  regardless  of
              profitability analysis.

       -XX:+UseCodeCacheFlushing
              Enables flushing of the code cache before shutting down the com-
              piler.  This option is enabled by default.  To disable  flushing
              of  the  code  cache  before shutting down the compiler, specify
              -XX:-UseCodeCacheFlushing.

       -XX:+UseCondCardMark
              Enables checking if the card is already marked  before  updating
              the  card table.  This option is disabled by default.  It should
              be used only on machines with multiple  sockets,  where  it  in-
              creases  the  performance of Java applications that rely on con-
              current operations.

       -XX:+UseCountedLoopSafepoints
              Keeps safepoints in counted loops.  Its default value depends on
              whether  the  selected  garbage  collector  requires low latency
              safepoints.

       -XX:LoopStripMiningIter=number_of_iterations
              Controls the number of iterations in the inner strip mined loop.
              Strip  mining  transforms  counted  loops  into two level nested
              loops.  Safepoints are kept in the outer loop  while  the  inner
              loop  can execute at full speed.  This option controls the maxi-
              mum number of iterations in the inner loop.  The  default  value
              is 1,000.

       -XX:LoopStripMiningIterShortLoop=number_of_iterations
              Controls  loop strip mining optimization.  Loops with the number
              of iterations less than specified will not  have  safepoints  in
              them.  Default value is 1/10th of -XX:LoopStripMiningIter.

       -XX:+UseFMA
              Enables hardware-based FMA intrinsics for hardware where FMA in-
              structions are available (such as, Intel and  ARM64).   FMA  in-
              trinsics are generated for the java.lang.Math.fma(a, b, c) meth-
              ods that calculate the value of ( a * b + c ) expressions.

       -XX:+UseRTMDeopt
              Autotunes RTM locking depending on the abort ratio.  This  ratio
              is  specified by the -XX:RTMAbortRatio option.  If the number of
              aborted transactions exceeds the abort ratio,  then  the  method
              containing the lock is deoptimized and recompiled with all locks
              as normal locks.  This  option  is  disabled  by  default.   The
              -XX:+UseRTMLocking option must be enabled.

       -XX:+UseRTMLocking
              Generates Restricted Transactional Memory (RTM) locking code for
              all inflated locks, with the normal  locking  mechanism  as  the
              fallback  handler.  This option is disabled by default.  Options
              related to RTM are available  only  on  x86  CPUs  that  support
              Transactional Synchronization Extensions (TSX).

              RTM  is part of Intel's TSX, which is an x86 instruction set ex-
              tension and facilitates the creation of  multithreaded  applica-
              tions.   RTM  introduces  the  new  instructions XBEGIN, XABORT,
              XEND, and XTEST.  The XBEGIN and XEND instructions enclose a set
              of  instructions  to  run  as  a transaction.  If no conflict is
              found when running the transaction, then the memory and register
              modifications  are  committed  together at the XEND instruction.
              The XABORT instruction can be used to explicitly abort a  trans-
              action and the XTEST instruction checks if a set of instructions
              is being run in a transaction.

              A lock on a transaction is inflated when another thread tries to
              access  the  same  transaction, thereby blocking the thread that
              didn't originally request access to the  transaction.   RTM  re-
              quires  that a fallback set of operations be specified in case a
              transaction aborts or fails.  An RTM lock is  a  lock  that  has
              been delegated to the TSX's system.

              RTM  improves  performance  for  highly contended locks with low
              conflict in a critical region (which is code that  must  not  be
              accessed  by  more  than one thread concurrently).  RTM also im-
              proves the performance of coarse-grain locking, which  typically
              doesn't    perform    well    in   multithreaded   applications.
              (Coarse-grain locking is the strategy of holding locks for  long
              periods  to minimize the overhead of taking and releasing locks,
              while fine-grained locking is the strategy of trying to  achieve
              maximum parallelism by locking only when necessary and unlocking
              as soon as possible.) Also, for lightly contended locks that are
              used by different threads, RTM can reduce false cache line shar-
              ing, also known as cache line ping-pong.  This occurs when  mul-
              tiple  threads from different processors are accessing different
              resources, but the resources share the same cache  line.   As  a
              result,  the processors repeatedly invalidate the cache lines of
              other processors, which forces them to read from main memory in-
              stead of their cache.

       -XX:+UseSuperWord
              Enables  the  transformation of scalar operations into superword
              operations.  Superword is a  vectorization  optimization.   This
              option  is enabled by default.  To disable the transformation of
              scalar operations into superword operations, specify -XX:-UseSu-
              perWord.


ADVANCED SERVICEABILITY OPTIONS FOR JAVA

       These java options provide the ability to gather system information and
       perform extensive debugging.

       -XX:+DisableAttachMechanism
              Disables the mechanism that lets tools attach to  the  JVM.   By
              default, this option is disabled, meaning that the attach mecha-
              nism is enabled and you can use diagnostics and  troubleshooting
              tools such as jcmd, jstack, jmap, and jinfo.

                     Note:  The  tools  such  as jcmd, jinfo, jmap, and jstack
                     shipped with the JDK  aren't  supported  when  using  the
                     tools  from  one  JDK version to troubleshoot a different
                     JDK version.

       -XX:+ExtendedDTraceProbes
              Linux and macOS: Enables additional dtrace tool probes that  af-
              fect  the  performance.  By default, this option is disabled and
              dtrace performs only standard probes.

       -XX:+HeapDumpOnOutOfMemoryError
              Enables the dumping of the Java heap to a file  in  the  current
              directory  by  using  the  heap  profiler  (HPROF)  when  a  ja-
              va.lang.OutOfMemoryError exception is thrown.  You can explicit-
              ly  set the heap dump file path and name using the -XX:HeapDump-
              Path option.  By default, this option is disabled and  the  heap
              isn't dumped when an OutOfMemoryError exception is thrown.

       -XX:HeapDumpPath=path
              Sets  the  path and file name for writing the heap dump provided
              by the heap profiler (HPROF) when the  -XX:+HeapDumpOnOutOfMemo-
              ryError  option  is set.  By default, the file is created in the
              current working directory, and  it's  named  java_pid<pid>.hprof
              where <pid> is the identifier of the process that caused the er-
              ror.  The following example shows how to set  the  default  file
              explicitly (%p represents the current process identifier):

                     -XX:HeapDumpPath=./java_pid%p.hprof

              o Linux  and  macOS:  The following example shows how to set the
                heap dump file to /var/log/java/java_heapdump.hprof:

                       -XX:HeapDumpPath=/var/log/java/java_heapdump.hprof

              o Windows: The following example shows how to set the heap  dump
                file to C:/log/java/java_heapdump.log:

                       -XX:HeapDumpPath=C:/log/java/java_heapdump.log

       -XX:LogFile=path
              Sets  the  path  and file name to where log data is written.  By
              default, the file is created in the current  working  directory,
              and it's named hotspot.log.

              o Linux  and  macOS:  The following example shows how to set the
                log file to /var/log/java/hotspot.log:

                       -XX:LogFile=/var/log/java/hotspot.log

              o Windows: The following example shows how to set the  log  file
                to C:/log/java/hotspot.log:

                       -XX:LogFile=C:/log/java/hotspot.log

       -XX:+PrintClassHistogram
              Enables  printing of a class instance histogram after one of the
              following events:

              o Linux and macOS: Control+Break

              o Windows: Control+C (SIGTERM)

              By default, this option is disabled.

              Setting this option is equivalent  to  running  the  jmap -histo
              command,  or  the jcmd pid GC.class_histogram command, where pid
              is the current Java process identifier.

       -XX:+PrintConcurrentLocks
              Enables printing of java.util.concurrent locks after one of  the
              following events:

              o Linux and macOS: Control+Break

              o Windows: Control+C (SIGTERM)

              By default, this option is disabled.

              Setting  this option is equivalent to running the jstack -l com-
              mand or the jcmd pid Thread.print -l command, where pid  is  the
              current Java process identifier.

       -XX:+PrintFlagsRanges
              Prints  the  range specified and allows automatic testing of the
              values.  See Validate Java Virtual Machine Flag Arguments.

       -XX:+PerfDataSaveToFile
              If enabled, saves jstat binary data when  the  Java  application
              exits.   This  binary  data  is  saved in a file named hsperfda-
              ta_pid, where pid is the process identifier of the Java applica-
              tion that you ran.  Use the jstat command to display the perfor-
              mance data contained in this file as follows:

                     jstat -class file:///path/hsperfdata_pid

                     jstat -gc file:///path/hsperfdata_pid

       -XX:+UsePerfData
              Enables the perfdata feature.  This option is enabled by default
              to  allow  JVM monitoring and performance testing.  Disabling it
              suppresses the creation of  the  hsperfdata_userid  directories.
              To disable the perfdata feature, specify -XX:-UsePerfData.


ADVANCED GARBAGE COLLECTION OPTIONS FOR JAVA

       These  java options control how garbage collection (GC) is performed by
       the Java HotSpot VM.

       -XX:+AggressiveHeap
              Enables Java heap optimization.  This sets various parameters to
              be  optimal  for long-running jobs with intensive memory alloca-
              tion, based on the configuration of the computer (RAM and  CPU).
              By  default,  the option is disabled and the heap sizes are con-
              figured less aggressively.

       -XX:+AlwaysPreTouch
              Requests the VM to touch every page on the Java heap  after  re-
              questing  it from the operating system and before handing memory
              out to the application.  By default, this option is disabled and
              all  pages are committed as the application uses the heap space.

       -XX:ConcGCThreads=threads
              Sets the number of threads used for concurrent GC.  Sets threads
              to  approximately  1/4 of the number of parallel garbage collec-
              tion threads.  The default value depends on the number  of  CPUs
              available to the JVM.

              For  example,  to set the number of threads for concurrent GC to
              2, specify the following option:

                     -XX:ConcGCThreads=2

       -XX:+DisableExplicitGC
              Enables the option that disables processing of calls to the Sys-
              tem.gc()  method.   This  option is disabled by default, meaning
              that calls to System.gc() are processed.  If processing of calls
              to  System.gc() is disabled, then the JVM still performs GC when
              necessary.

       -XX:+ExplicitGCInvokesConcurrent
              Enables invoking of concurrent GC by using the  System.gc()  re-
              quest.   This  option  is disabled by default and can be enabled
              only with the -XX:+UseG1GC option.

       -XX:G1AdaptiveIHOPNumInitialSamples=number
              When -XX:UseAdaptiveIHOP is enabled, this option sets the number
              of  completed  marking  cycles  used  to gather samples until G1
              adaptively determines the optimum value of -XX:InitiatingHeapOc-
              cupancyPercent.   Before,  G1  uses  the  value  of -XX:Initiat-
              ingHeapOccupancyPercent directly for this purpose.  The  default
              value is 3.

       -XX:G1HeapRegionSize=size
              Sets  the size of the regions into which the Java heap is subdi-
              vided when using the garbage-first (G1) collector.  The value is
              a  power of 2 and can range from 1 MB to 32 MB.  The default re-
              gion size is determined ergonomically based  on  the  heap  size
              with a goal of approximately 2048 regions.

              The  following  example  sets the size of the subdivisions to 16
              MB:

                     -XX:G1HeapRegionSize=16m

       -XX:G1HeapWastePercent=percent
              Sets the percentage of heap that you're willing to  waste.   The
              Java  HotSpot  VM  doesn't initiate the mixed garbage collection
              cycle when the reclaimable percentage  is  less  than  the  heap
              waste percentage.  The default is 5 percent.

       -XX:G1MaxNewSizePercent=percent
              Sets  the  percentage of the heap size to use as the maximum for
              the young generation size.  The default value is 60  percent  of
              your Java heap.

              This is an experimental flag.  This setting replaces the -XX:De-
              faultMaxNewGenPercent setting.

       -XX:G1MixedGCCountTarget=number
              Sets the target number of  mixed  garbage  collections  after  a
              marking  cycle  to  collect  old  regions with at most G1MixedG-
              CLIveThresholdPercent live data.  The default is 8 mixed garbage
              collections.   The  goal  for  mixed collections is to be within
              this target number.

       -XX:G1MixedGCLiveThresholdPercent=percent
              Sets the occupancy threshold for an old region to be included in
              a  mixed  garbage collection cycle.  The default occupancy is 85
              percent.

              This  is  an  experimental  flag.   This  setting  replaces  the
              -XX:G1OldCSetRegionLiveThresholdPercent setting.

       -XX:G1NewSizePercent=percent
              Sets  the  percentage  of the heap to use as the minimum for the
              young generation size.  The default value is 5 percent  of  your
              Java heap.

              This is an experimental flag.  This setting replaces the -XX:De-
              faultMinNewGenPercent setting.

       -XX:G1OldCSetRegionThresholdPercent=percent
              Sets an upper limit on the number of old regions to be collected
              during a mixed garbage collection cycle.  The default is 10 per-
              cent of the Java heap.

       -XX:G1ReservePercent=percent
              Sets the percentage of the heap (0 to 50) that's reserved  as  a
              false ceiling to reduce the possibility of promotion failure for
              the G1 collector.  When you increase or decrease the percentage,
              ensure  that  you adjust the total Java heap by the same amount.
              By default, this option is set to 10%.

              The following example sets the reserved heap to 20%:

                     -XX:G1ReservePercent=20

       -XX:+G1UseAdaptiveIHOP
              Controls adaptive calculation of the old generation occupancy to
              start  background  work  preparing for an old generation collec-
              tion.  If enabled,  G1  uses  -XX:InitiatingHeapOccupancyPercent
              for the first few times as specified by the value of -XX:G1Adap-
              tiveIHOPNumInitialSamples, and after that adaptively  calculates
              a  new optimum value for the initiating occupancy automatically.
              Otherwise, the old generation collection process  always  starts
              at  the  old  generation  occupancy  determined  by -XX:Initiat-
              ingHeapOccupancyPercent.

              The default is enabled.

       -XX:InitialHeapSize=size
              Sets the initial size (in bytes) of the memory allocation  pool.
              This  value  must be either 0, or a multiple of 1024 and greater
              than 1 MB.  Append the letter k or K to indicate kilobytes, m or
              M  to  indicate megabytes, or g or G to indicate gigabytes.  The
              default value is selected at run time based on the  system  con-
              figuration.

              The  following  examples  show  how to set the size of allocated
              memory to 6 MB using various units:

                     -XX:InitialHeapSize=6291456
                     -XX:InitialHeapSize=6144k
                     -XX:InitialHeapSize=6m

              If you set this option to 0, then the initial size is set as the
              sum  of the sizes allocated for the old generation and the young
              generation.  The size of the heap for the young  generation  can
              be set using the -XX:NewSize option.

       -XX:InitialRAMPercentage=percent
              Sets  the initial amount of memory that the JVM will use for the
              Java heap before applying ergonomics heuristics as a  percentage
              of  the maximum amount determined as described in the -XX:MaxRAM
              option.  The default value is 1.5625 percent.

              The following example shows how to set  the  percentage  of  the
              initial amount of memory used for the Java heap:

                     -XX:InitialRAMPercentage=5

       -XX:InitialSurvivorRatio=ratio
              Sets  the  initial  survivor  space ratio used by the throughput
              garbage collector (which is enabled  by  the  -XX:+UseParallelGC
              option).   Adaptive  sizing  is  enabled  by  default  with  the
              throughput garbage collector by using the -XX:+UseParallelGC op-
              tion,  and the survivor space is resized according to the appli-
              cation behavior, starting with the initial value.   If  adaptive
              sizing  is  disabled  (using  the -XX:-UseAdaptiveSizePolicy op-
              tion), then the -XX:SurvivorRatio option should be used  to  set
              the  size  of the survivor space for the entire execution of the
              application.

              The following formula can be used to calculate the initial  size
              of  survivor space (S) based on the size of the young generation
              (Y), and the initial survivor space ratio (R):

                     S=Y/(R+2)

              The 2 in the equation denotes two survivor spaces.   The  larger
              the  value  specified  as  the initial survivor space ratio, the
              smaller the initial survivor space size.

              By default, the initial survivor space ratio is set  to  8.   If
              the default value for the young generation space size is used (2
              MB), then the initial size of the survivor space is 0.2 MB.

              The following example shows how  to  set  the  initial  survivor
              space ratio to 4:

                     -XX:InitialSurvivorRatio=4

       -XX:InitiatingHeapOccupancyPercent=percent
              Sets  the  percentage of the old generation occupancy (0 to 100)
              at which to start the first few concurrent  marking  cycles  for
              the G1 garbage collector.

              By  default,  the  initiating value is set to 45%.  A value of 0
              implies nonstop concurrent GC cycles from the beginning until G1
              adaptively sets this value.

              See also the -XX:G1UseAdaptiveIHOP and -XX:G1AdaptiveIHOPNumIni-
              tialSamples options.

              The following example shows how to set the initiating heap occu-
              pancy to 75%:

                     -XX:InitiatingHeapOccupancyPercent=75

       -XX:MaxGCPauseMillis=time
              Sets  a  target for the maximum GC pause time (in milliseconds).
              This is a soft goal, and the JVM will make its  best  effort  to
              achieve  it.   The  specified  value  doesn't adapt to your heap
              size.  By default, for G1 the maximum pause time target  is  200
              milliseconds.   The  other  generational collectors do not use a
              pause time goal by default.

              The following example shows how to set the maximum target  pause
              time to 500 ms:

                     -XX:MaxGCPauseMillis=500

       -XX:MaxHeapSize=size
              Sets  the  maximum size (in byes) of the memory allocation pool.
              This value must be a multiple of 1024 and  greater  than  2  MB.
              Append  the letter k or K to indicate kilobytes, m or M to indi-
              cate megabytes, or g or G to indicate  gigabytes.   The  default
              value is selected at run time based on the system configuration.
              For server  deployments,  the  options  -XX:InitialHeapSize  and
              -XX:MaxHeapSize are often set to the same value.

              The  following examples show how to set the maximum allowed size
              of allocated memory to 80 MB using various units:

                     -XX:MaxHeapSize=83886080
                     -XX:MaxHeapSize=81920k
                     -XX:MaxHeapSize=80m

              The -XX:MaxHeapSize option is equivalent to -Xmx.

       -XX:MaxHeapFreeRatio=percent
              Sets the maximum allowed percentage of free  heap  space  (0  to
              100)  after  a  GC event.  If free heap space expands above this
              value, then the heap is shrunk.  By default, this value  is  set
              to 70%.

              Minimize the Java heap size by lowering the values of the param-
              eters MaxHeapFreeRatio (default value is 70%) and MinHeapFreeRa-
              tio  (default  value  is  40%)  with  the  command-line  options
              -XX:MaxHeapFreeRatio and  -XX:MinHeapFreeRatio.   Lowering  Max-
              HeapFreeRatio  to  as  low as 10% and MinHeapFreeRatio to 5% has
              successfully reduced the heap size without too much  performance
              regression;  however, results may vary greatly depending on your
              application.  Try different values for  these  parameters  until
              they're  as  low as possible yet still retain acceptable perfor-
              mance.

                     -XX:MaxHeapFreeRatio=10 -XX:MinHeapFreeRatio=5

              Customers trying to keep the heap small should also add the  op-
              tion  -XX:-ShrinkHeapInSteps.   See  Performance Tuning Examples
              for a description of using this option to  keep  the  Java  heap
              small  by  reducing  the dynamic footprint for embedded applica-
              tions.

       -XX:MaxMetaspaceSize=size
              Sets the maximum amount of native memory that can  be  allocated
              for  class  metadata.   By default, the size isn't limited.  The
              amount of metadata for an application depends on the application
              itself,  other  running  applications,  and the amount of memory
              available on the system.

              The following example shows how to set the maximum class metada-
              ta size to 256 MB:

                     -XX:MaxMetaspaceSize=256m

       -XX:MaxNewSize=size
              Sets  the maximum size (in bytes) of the heap for the young gen-
              eration (nursery).  The default value is set ergonomically.

       -XX:MaxRAM=size
              Sets the maximum amount of memory that the JVM may use  for  the
              Java  heap  before  applying ergonomics heuristics.  The default
              value is the maximum amount  of  available  memory  to  the  JVM
              process or 128 GB, whichever is lower.

              The maximum amount of available memory to the JVM process is the
              minimum of the machine's physical memory and any constraints set
              by the environment (e.g.  container).

              Specifying this option disables automatic use of compressed oops
              if the combined result of this and other options influencing the
              maximum  amount of memory is larger than the range of memory ad-
              dressable by compressed  oops.   See  -XX:UseCompressedOops  for
              further information about compressed oops.

              The  following  example  shows  how to set the maximum amount of
              available memory for sizing the Java heap to 2 GB:

                     -XX:MaxRAM=2G

       -XX:MaxRAMPercentage=percent
              Sets the maximum amount of memory that the JVM may use  for  the
              Java  heap before applying ergonomics heuristics as a percentage
              of the maximum amount determined as described in the  -XX:MaxRAM
              option.  The default value is 25 percent.

              Specifying this option disables automatic use of compressed oops
              if the combined result of this and other options influencing the
              maximum  amount of memory is larger than the range of memory ad-
              dressable by compressed  oops.   See  -XX:UseCompressedOops  for
              further information about compressed oops.

              The  following  example  shows  how to set the percentage of the
              maximum amount of memory used for the Java heap:

                     -XX:MaxRAMPercentage=75

       -XX:MinRAMPercentage=percent
              Sets the maximum amount of memory that the JVM may use  for  the
              Java  heap before applying ergonomics heuristics as a percentage
              of the maximum amount determined as described in the  -XX:MaxRAM
              option for small heaps.  A small heap is a heap of approximately
              125 MB.  The default value is 50 percent.

              The following example shows how to set  the  percentage  of  the
              maximum amount of memory used for the Java heap for small heaps:

                     -XX:MinRAMPercentage=75

       -XX:MaxTenuringThreshold=threshold
              Sets the maximum tenuring threshold for use in adaptive GC  siz-
              ing.   The largest value is 15.  The default value is 15 for the
              parallel (throughput) collector.

              The following example shows how  to  set  the  maximum  tenuring
              threshold to 10:

                     -XX:MaxTenuringThreshold=10

       -XX:MetaspaceSize=size
              Sets  the  size of the allocated class metadata space that trig-
              gers a garbage collection the first time  it's  exceeded.   This
              threshold for a garbage collection is increased or decreased de-
              pending on the amount of metadata used.  The  default  size  de-
              pends on the platform.

       -XX:MinHeapFreeRatio=percent
              Sets  the  minimum  allowed  percentage of free heap space (0 to
              100) after a GC event.  If free heap space falls below this val-
              ue, then the heap is expanded.  By default, this value is set to
              40%.

              Minimize Java heap size by lowering the values of the parameters
              MaxHeapFreeRatio  (default  value  is  70%) and MinHeapFreeRatio
              (default value is 40%) with the  command-line  options  -XX:Max-
              HeapFreeRatio and -XX:MinHeapFreeRatio.  Lowering MaxHeapFreeRa-
              tio to as low as 10% and MinHeapFreeRatio to 5% has successfully
              reduced  the  heap size without too much performance regression;
              however, results may vary greatly depending on your application.
              Try  different  values for these parameters until they're as low
              as possible, yet still retain acceptable performance.

                     -XX:MaxHeapFreeRatio=10 -XX:MinHeapFreeRatio=5

              Customers trying to keep the heap small should also add the  op-
              tion  -XX:-ShrinkHeapInSteps.   See  Performance Tuning Examples
              for a description of using this option to  keep  the  Java  heap
              small  by  reducing  the dynamic footprint for embedded applica-
              tions.

       -XX:MinHeapSize=size
              Sets the minimum size (in bytes) of the memory allocation  pool.
              This  value  must be either 0, or a multiple of 1024 and greater
              than 1 MB.  Append the letter k or K to indicate kilobytes, m or
              M  to  indicate megabytes, or g or G to indicate gigabytes.  The
              default value is selected at run time based on the  system  con-
              figuration.

              The following examples show how to set the mimimum size of allo-
              cated memory to 6 MB using various units:

                     -XX:MinHeapSize=6291456
                     -XX:MinHeapSize=6144k
                     -XX:MinHeapSize=6m

              If you set this option to 0, then the minimum size is set to the
              same value as the initial size.

       -XX:NewRatio=ratio
              Sets  the  ratio between young and old generation sizes.  By de-
              fault, this option is set to 2.  The following example shows how
              to set the young-to-old ratio to 1:

                     -XX:NewRatio=1

       -XX:NewSize=size
              Sets  the initial size (in bytes) of the heap for the young gen-
              eration (nursery).  Append the letter k or K to  indicate  kilo-
              bytes, m or M to indicate megabytes, or g or G to indicate giga-
              bytes.

              The young generation region of the heap is used for new objects.
              GC is performed in this region more often than in other regions.
              If the size for the young generation is too low,  then  a  large
              number  of  minor  GCs  are performed.  If the size is too high,
              then only full GCs are performed, which can take a long time  to
              complete.   It  is  recommended  that  you keep the size for the
              young generation greater than 25% and less than 50% of the over-
              all heap size.

              The  following  examples show how to set the initial size of the
              young generation to 256 MB using various units:

                     -XX:NewSize=256m
                     -XX:NewSize=262144k
                     -XX:NewSize=268435456

              The -XX:NewSize option is equivalent to -Xmn.

       -XX:ParallelGCThreads=threads
              Sets the number of the stop-the-world (STW) worker threads.  The
              default value depends on the number of CPUs available to the JVM
              and the garbage collector selected.

              For example, to set the number of threads for G1 GC to 2, speci-
              fy the following option:

                     -XX:ParallelGCThreads=2

       -XX:+ParallelRefProcEnabled
              Enables  parallel reference processing.  By default, this option
              is disabled.

       -XX:+PrintAdaptiveSizePolicy
              Enables printing of information about  adaptive-generation  siz-
              ing.  By default, this option is disabled.

       -XX:+ScavengeBeforeFullGC
              Enables  GC  of  the young generation before each full GC.  This
              option is enabled by default.  It is recommended that you  don't
              disable  it,  because  scavenging  the young generation before a
              full GC can reduce the number of objects reachable from the  old
              generation space into the young generation space.  To disable GC
              of the young generation before each full GC, specify the  option
              -XX:-ScavengeBeforeFullGC.

       -XX:SoftRefLRUPolicyMSPerMB=time
              Sets the amount of time (in milliseconds) a softly reachable ob-
              ject is kept active on the heap after the last time it was  ref-
              erenced.   The  default value is one second of lifetime per free
              megabyte in the heap.   The  -XX:SoftRefLRUPolicyMSPerMB  option
              accepts   integer   values  representing  milliseconds  per  one
              megabyte of the current heap size (for Java HotSpot  Client  VM)
              or  the maximum possible heap size (for Java HotSpot Server VM).
              This difference means that the Client VM  tends  to  flush  soft
              references  rather  than  grow  the  heap, whereas the Server VM
              tends to grow the heap rather than flush  soft  references.   In
              the  latter case, the value of the -Xmx option has a significant
              effect on how quickly soft references are garbage collected.

              The following example shows how to set the value to 2.5 seconds:

              -XX:SoftRefLRUPolicyMSPerMB=2500

       -XX:-ShrinkHeapInSteps
              Incrementally  reduces  the Java heap to the target size, speci-
              fied by the option -XX:MaxHeapFreeRatio.  This option is enabled
              by  default.   If disabled, then it immediately reduces the Java
              heap to the target size instead of  requiring  multiple  garbage
              collection  cycles.  Disable this option if you want to minimize
              the Java heap  size.   You  will  likely  encounter  performance
              degradation when this option is disabled.

              See  Performance  Tuning Examples for a description of using the
              MaxHeapFreeRatio option to keep the Java heap small by  reducing
              the dynamic footprint for embedded applications.

       -XX:StringDeduplicationAgeThreshold=threshold
              Identifies  String  objects  reaching the specified age that are
              considered candidates for deduplication.  An object's age  is  a
              measure  of  how  many times it has survived garbage collection.
              This is sometimes referred to as tenuring.

                     Note: String objects that are promoted to an old heap re-
                     gion  before this age has been reached are always consid-
                     ered candidates for deduplication.  The default value for
                     this  option  is  3.  See the -XX:+UseStringDeduplication
                     option.

       -XX:SurvivorRatio=ratio
              Sets the ratio between eden space size and survivor space  size.
              By  default,  this  option  is  set to 8.  The following example
              shows how to set the eden/survivor space ratio to 4:

                     -XX:SurvivorRatio=4

       -XX:TargetSurvivorRatio=percent
              Sets the desired percentage of survivor space (0  to  100)  used
              after  young garbage collection.  By default, this option is set
              to 50%.

              The following example shows how to set the target survivor space
              ratio to 30%:

                     -XX:TargetSurvivorRatio=30

       -XX:TLABSize=size
              Sets  the  initial  size (in bytes) of a thread-local allocation
              buffer (TLAB).  Append the letter k or K to indicate  kilobytes,
              m  or  M to indicate megabytes, or g or G to indicate gigabytes.
              If this option is set to 0, then the  JVM  selects  the  initial
              size automatically.

              The  following example shows how to set the initial TLAB size to
              512 KB:

                     -XX:TLABSize=512k

       -XX:+UseAdaptiveSizePolicy
              Enables the use of adaptive generation sizing.  This  option  is
              enabled  by  default.   To  disable  adaptive generation sizing,
              specify -XX:-UseAdaptiveSizePolicy and set the size of the memo-
              ry  allocation  pool  explicitly.  See the -XX:SurvivorRatio op-
              tion.

       -XX:+UseG1GC
              Enables the use of the  garbage-first  (G1)  garbage  collector.
              It's a server-style garbage collector, targeted for multiproces-
              sor machines with a large amount of RAM.  This option  meets  GC
              pause  time  goals with high probability, while maintaining good
              throughput.  The G1 collector is  recommended  for  applications
              requiring large heaps (sizes of around 6 GB or larger) with lim-
              ited GC latency requirements (a  stable  and  predictable  pause
              time below 0.5 seconds).  By default, this option is enabled and
              G1 is used as the default garbage collector.

       -XX:+UseGCOverheadLimit
              Enables the use of a policy that limits the proportion  of  time
              spent  by  the JVM on GC before an OutOfMemoryError exception is
              thrown.  This option is enabled, by default, and the parallel GC
              will  throw  an  OutOfMemoryError  if more than 98% of the total
              time is spent on garbage collection and less than 2% of the heap
              is  recovered.  When the heap is small, this feature can be used
              to prevent applications from running for long  periods  of  time
              with little or no progress.  To disable this option, specify the
              option -XX:-UseGCOverheadLimit.

       -XX:+UseNUMA
              Enables performance optimization of an application on a  machine
              with nonuniform memory architecture (NUMA) by increasing the ap-
              plication's use of lower latency memory.  By default,  this  op-
              tion  is disabled and no optimization for NUMA is made.  The op-
              tion is available only when the parallel  garbage  collector  is
              used (-XX:+UseParallelGC).

       -XX:+UseParallelGC
              Enables the use of the parallel scavenge garbage collector (also
              known as the throughput collector) to improve the performance of
              your application by leveraging multiple processors.

              By default, this option is disabled and the default collector is
              used.

       -XX:+UseSerialGC
              Enables the use of the serial garbage collector.  This is gener-
              ally  the  best  choice  for  small and simple applications that
              don't require any special functionality from garbage collection.
              By default, this option is disabled and the default collector is
              used.

       -XX:+UseSHM
              Linux only: Enables the JVM to use shared memory to set up large
              pages.

              See Large Pages for setting up large pages.

       -XX:+UseStringDeduplication
              Enables  string  deduplication.  By default, this option is dis-
              abled.  To use this option, you must  enable  the  garbage-first
              (G1) garbage collector.

              String  deduplication reduces the memory footprint of String ob-
              jects on the Java heap by taking advantage of the fact that many
              String  objects  are  identical.   Instead of each String object
              pointing to its own character array,  identical  String  objects
              can point to and share the same character array.

       -XX:+UseTLAB
              Enables the use of thread-local allocation blocks (TLABs) in the
              young generation space.  This option is enabled by default.   To
              disable the use of TLABs, specify the option -XX:-UseTLAB.

       -XX:+UseZGC
              Enables the use of the Z garbage collector (ZGC).  This is a low
              latency garbage collector, providing max pause times  of  a  few
              milliseconds, at some throughput cost.  Pause times are indepen-
              dent of what heap size is used.  Supports heap sizes from 8MB to
              16TB.

       -XX:ZAllocationSpikeTolerance=factor
              Sets  the  allocation spike tolerance for ZGC.  By default, this
              option is set to 2.0.  This factor describes the level of  allo-
              cation  spikes  to  expect.   For example, using a factor of 3.0
              means the current allocation rate can be expected to  triple  at
              any time.

       -XX:ZCollectionInterval=seconds
              Sets  the  maximum  interval  (in seconds) between two GC cycles
              when using ZGC.  By default, this option is set to 0 (disabled).

       -XX:ZFragmentationLimit=percent
              Sets  the maximum acceptable heap fragmentation (in percent) for
              ZGC.  By default, this option is set to 25.  Using a lower value
              will  cause  the  heap to be compacted more aggressively, to re-
              claim more memory at the cost of using more CPU time.

       -XX:+ZProactive
              Enables proactive GC cycles when using ZGC.   By  default,  this
              option is enabled.  ZGC will start a proactive GC cycle if doing
              so is expected to have minimal impact on  the  running  applica-
              tion.  This is useful if the application is mostly idle or allo-
              cates very few objects, but you still want to keep the heap size
              down  and  allow  reference processing to happen even when there
              are a lot of free space on the heap.

       -XX:+ZUncommit
              Enables uncommitting of unused heap memory when using  ZGC.   By
              default, this option is enabled.  Uncommitting unused heap memo-
              ry will lower the memory footprint of the  JVM,  and  make  that
              memory available for other processes to use.

       -XX:ZUncommitDelay=seconds
              Sets  the amount of time (in seconds) that heap memory must have
              been unused before being uncommitted.  By default,  this  option
              is  set  to 300 (5 minutes).  Committing and uncommitting memory
              are relatively expensive operations.  Using a lower  value  will
              cause heap memory to be uncommitted earlier, at the risk of soon
              having to commit it again.


DEPRECATED JAVA OPTIONS

       These java options are deprecated and might be removed in a future  JDK
       release.   They're  still accepted and acted upon, but a warning is is-
       sued when they're used.

       -Xfuture
              Enables strict class-file format checks that enforce close  con-
              formance  to  the  class-file  format specification.  Developers
              should use this flag when developing new code.  Stricter  checks
              may become the default in future releases.

       -Xloggc:filename
              Sets  the  file to which verbose GC events information should be
              redirected for logging.   The  -Xloggc  option  overrides  -ver-
              bose:gc  if  both  are given with the same java command.  -Xlog-
              gc:filename is replaced by -Xlog:gc:filename.  See  Enable  Log-
              ging with the JVM Unified Logging Framework.

              Example:

              -Xlog:gc:garbage-collection.log

       -XX:+FlightRecorder
              Enables the use of Java Flight Recorder (JFR) during the runtime
              of the application.  Since JDK 8u40 this option has not been re-
              quired to use JFR.

       -XX:InitialRAMFraction=ratio
              Sets  the  initial amount of memory that the JVM may use for the
              Java heap before applying ergonomics heuristics as  a  ratio  of
              the maximum amount determined as described in the -XX:MaxRAM op-
              tion.  The default value is 64.

              Use the option -XX:InitialRAMPercentage instead.

       -XX:MaxRAMFraction=ratio
              Sets the maximum amount of memory that the JVM may use  for  the
              Java heap before applying ergonomics heuristics as a fraction of
              the maximum amount determined as described in the -XX:MaxRAM op-
              tion.  The default value is 4.

              Specifying this option disables automatic use of compressed oops
              if the combined result of this and other options influencing the
              maximum  amount of memory is larger than the range of memory ad-
              dressable by compressed  oops.   See  -XX:UseCompressedOops  for
              further information about compressed oops.

              Use the option -XX:MaxRAMPercentage instead.

       -XX:MinRAMFraction=ratio
              Sets  the  maximum amount of memory that the JVM may use for the
              Java heap before applying ergonomics heuristics as a fraction of
              the maximum amount determined as described in the -XX:MaxRAM op-
              tion for small heaps.  A small heap is a heap  of  approximately
              125 MB.  The default value is 2.

              Use the option -XX:MinRAMPercentage instead.

       -XX:+TraceClassLoading
              Enables tracing of classes as they are loaded.  By default, this
              option is disabled and classes aren't traced.

              The replacement Unified Logging syntax is  -Xlog:class+load=lev-
              el.  See Enable Logging with the JVM Unified Logging Framework

              Use level=info for regular information, or level=debug for addi-
              tional information.  In Unified Logging  syntax,  -verbose:class
              equals -Xlog:class+load=info,class+unload=info.

       -XX:+TraceClassLoadingPreorder
              Enables  tracing  of  all  loaded  classes in the order in which
              they're referenced.  By default, this  option  is  disabled  and
              classes aren't traced.

              The  replacement  Unified  Logging  syntax  is  -Xlog:class+pre-
              order=debug.  See Enable Logging with the  JVM  Unified  Logging
              Framework.

       -XX:+TraceClassResolution
              Enables  tracing of constant pool resolutions.  By default, this
              option is disabled and constant pool resolutions aren't  traced.

              The   replacement  Unified  Logging  syntax  is  -Xlog:class+re-
              solve=debug.  See Enable Logging with the  JVM  Unified  Logging
              Framework.

       -XX:+TraceLoaderConstraints
              Enables  tracing  of  the  loader constraints recording.  By de-
              fault, this option is disabled and loader constraints  recording
              isn't traced.

              The  replacement  Unified  Logging  syntax  is -Xlog:class+load-
              er+constraints=info.  See Enable Logging with  the  JVM  Unified
              Logging Framework.

       -XX:+UseBiasedLocking
              Enables  the use of biased locking.  Some applications with sig-
              nificant amounts of uncontended synchronization may attain  sig-
              nificant  speedups with this flag enabled, but applications with
              certain patterns of locking may see slowdowns.

              By default, this option is disabled.


OBSOLETE JAVA OPTIONS

       These java options are still accepted but ignored, and a warning is is-
       sued when they're used.

       -XX:+UseMembar
              Enabled  issuing  membars on thread-state transitions.  This op-
              tion was  disabled  by  default  on  all  platforms  except  ARM
              servers, where it was enabled.

       -XX:MaxPermSize=size
              Sets  the  maximum  permanent  generation space size (in bytes).
              This option was deprecated  in  JDK  8  and  superseded  by  the
              -XX:MaxMetaspaceSize option.

       -XX:PermSize=size
              Sets  the space (in bytes) allocated to the permanent generation
              that triggers a garbage collection if it's exceeded.   This  op-
              tion  was  deprecated  in JDK 8 and superseded by the -XX:Metas-
              paceSize option.

       -XX:+UseParallelOldGC
              Enables the use of the parallel garbage collector for full  GCs.
              By  default, this option is disabled.  Enabling it automatically
              enables the -XX:+UseParallelGC option.


REMOVED JAVA OPTIONS

       These java options have been removed in JDK 15 and using  them  results
       in an error of:

              Unrecognized VM option option-name

       -XX:+FailOverToOldVerifier
              Enables automatic failover to the old verifier when the new type
              checker fails.  By default, this option is disabled and it's ig-
              nored  (that  is, treated as disabled) for classes with a recent
              bytecode version.  You can enable it only for classes with older
              versions of the bytecode.

       -XX:+UseConcMarkSweepGC
              Enables the use of the CMS garbage collector for the old genera-
              tion.  CMS is an alternative to the  default  garbage  collector
              (G1), which also focuses on meeting application latency require-
              ments.  By default, this option is disabled and the collector is
              selected automatically based on the configuration of the machine
              and type of the JVM.

       For the lists and descriptions of options removed in previous  releases
       see the Removed Java Options section in:

       o Java   Platform,   Standard   Edition  Tools  Reference,  Release  14
         [https://docs.oracle.com/en/java/javase/14/docs/specs/man/java.html]

       o Java  Platform,  Standard  Edition  Tools   Reference,   Release   13
         [https://docs.oracle.com/en/java/javase/13/docs/specs/man/java.html]

       o Java   Platform,   Standard   Edition  Tools  Reference,  Release  12
         [https://docs.oracle.com/en/java/javase/12/tools/ja-
         va.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE]

       o Java   Platform,   Standard   Edition  Tools  Reference,  Release  11
         [https://docs.oracle.com/en/java/javase/11/tools/ja-
         va.html#GUID-741FC470-AA3E-494A-8D2B-1B1FE4A990D1]

       o Java   Platform,   Standard   Edition  Tools  Reference,  Release  10
         [https://docs.oracle.com/javase/10/tools/java.htm#JSWOR624]

       o Java  Platform,  Standard  Edition   Tools   Reference,   Release   9
         [https://docs.oracle.com/javase/9/tools/java.htm#JSWOR624]

       o Java Platform, Standard Edition Tools Reference, Release 8 for Oracle
         JDK    on    Windows     [https://docs.oracle.com/javase/8/docs/tech-
         notes/tools/windows/java.html#BGBCIEFC]

       o Java Platform, Standard Edition Tools Reference, Release 8 for Oracle
         JDK    on    Solaris,    Linux,    and    macOS    [https://docs.ora-
         cle.com/javase/8/docs/technotes/tools/unix/java.html#BGBCIEFC]


JAVA COMMAND-LINE ARGUMENT FILES

       You  can shorten or simplify the java command by using @ argument files
       to specify one or more text files that contain arguments, such  as  op-
       tions  and  class  names,  which  are passed to the java command.  This
       let's you to create java commands of any length on any  operating  sys-
       tem.

       In the command line, use the at sign (@) prefix to identify an argument
       file that contains java options and class names.  When the java command
       encounters  a  file beginning with the at sign (@), it expands the con-
       tents of that file into an argument list just as they would  be  speci-
       fied on the command line.

       The  java  launcher expands the argument file contents until it encoun-
       ters the --disable-@files option.  You can use the --disable-@files op-
       tion  anywhere  on  the command line, including in an argument file, to
       stop @ argument files expansion.

       The following items describe the syntax of java argument files:

       o The argument file must contain only ASCII characters or characters in
         system default encoding that's ASCII friendly, such as UTF-8.

       o The  argument file size must not exceed MAXINT (2,147,483,647) bytes.

       o The launcher doesn't expand wildcards that are present within an  ar-
         gument file.

       o Use white space or new line characters to separate arguments included
         in the file.

       o White space includes a white space character, \t, \n, \r, and \f.

         For example, it is possible to have a path  with  a  space,  such  as
         c:\Program Files  that can be specified as either "c:\\Program Files"
         or, to avoid an escape, c:\Program" "Files.

       o Any option that contains spaces, such as a path  component,  must  be
         within  quotation  marks  using quotation ('"') characters in its en-
         tirety.

       o A string within quotation marks may contain the  characters  \n,  \r,
         \t, and \f.  They are converted to their respective ASCII codes.

       o If a file name contains embedded spaces, then put the whole file name
         in double quotation marks.

       o File names in an argument file are relative to the current directory,
         not to the location of the argument file.

       o Use the number sign # in the argument file to identify comments.  All
         characters following the # are ignored until the end of line.

       o Additional at sign @ prefixes to @ prefixed options act as an escape,
         (the  first  @ is removed and the rest of the arguments are presented
         to the launcher literally).

       o Lines may be continued using the continuation character  (\)  at  the
         end-of-line.   The  two lines are concatenated with the leading white
         spaces trimmed.  To prevent trimming the leading white spaces, a con-
         tinuation character (\) may be placed at the first column.

       o Because  backslash  (\) is an escape character, a backslash character
         must be escaped with another backslash character.

       o Partial quote is allowed and is closed by an end-of-file.

       o An open quote stops at end-of-line unless \ is  the  last  character,
         which  then  joins  the next line by removing all leading white space
         characters.

       o Wildcards (*) aren't allowed in these lists (such as specifying *.ja-
         va).

       o Use  of the at sign (@) to recursively interpret files isn't support-
         ed.

   Example of Open or Partial Quotes in an Argument File
       In the argument file,

              -cp "lib/
              cool/
              app/
              jars

       this is interpreted as:

              -cp lib/cool/app/jars

   Example of a Backslash Character Escaped with Another Backslash
       Character in an Argument File

       To output the following:

              -cp c:\Program Files (x86)\Java\jre\lib\ext;c:\Program Files\Ja-
              va\jre9\lib\ext

       The backslash character must be specified in the argument file as:

              -cp "c:\\Program Files (x86)\\Java\\jre\\lib\\ext;c:\\Pro-
              gram Files\\Java\\jre9\\lib\\ext"

   Example of an EOL Escape Used to Force Concatenation of Lines in an
       Argument File

       In the argument file,

              -cp "/lib/cool app/jars:\
                  /lib/another app/jars"

       This is interpreted as:

              -cp /lib/cool app/jars:/lib/another app/jars

   Example of Line Continuation with Leading Spaces in an Argument File
       In the argument file,

              -cp "/lib/cool\
              \app/jars???

       This is interpreted as:

       -cp /lib/cool app/jars

   Examples of Using Single Argument File
       You can use a single argument file, such as myargumentfile in the  fol-
       lowing example, to hold all required java arguments:

              java @myargumentfile

   Examples of Using Argument Files with Paths
       You can include relative paths in argument files; however, they're rel-
       ative to the current working directory and not to the paths of the  ar-
       gument  files  themselves.  In the following example, path1/options and
       path2/options represent argument files with different paths.  Any rela-
       tive paths that they contain are relative to the current working direc-
       tory and not to the argument files:

              java @path1/options @path2/classes


CODE HEAP STATE ANALYTICS

   Overview
       There are occasions when having insight into the current state  of  the
       JVM code heap would be helpful to answer questions such as:

       o Why was the JIT turned off and then on again and again?

       o Where has all the code heap space gone?

       o Why is the method sweeper not working effectively?

       To  provide  this insight, a code heap state analytics feature has been
       implemented that enables on-the-fly analysis of the code heap.  The an-
       alytics process is divided into two parts.  The first part examines the
       entire code heap and aggregates all information that is believed to  be
       useful  or  important.  The second part consists of several independent
       steps that print the collected information with an emphasis on  differ-
       ent  aspects  of the data.  Data collection and printing are done on an
       "on request" basis.

   Syntax
       Requests for real-time, on-the-fly analysis can be issued with the fol-
       lowing command:

              jcmd pid Compiler.CodeHeap_Analytics [function] [granularity]

       If  you  are only interested in how the code heap looks like after run-
       ning a sample workload, you can use the command line option:

              -Xlog:codecache=Trace

       To see the code heap state when a "CodeCache  full"  condition  exists,
       start the VM with the command line option:

              -Xlog:codecache=Debug

       See   CodeHeap   State  Analytics  (OpenJDK)  [https://bugs.openjdk.ja-
       va.net/secure/attachment/75649/JVM_CodeHeap_StateAnalytics_V2.pdf]  for
       a  detailed  description  of the code heap state analytics feature, the
       supported functions, and the granularity options.


ENABLE LOGGING WITH THE JVM UNIFIED LOGGING FRAMEWORK

       You use the -Xlog option to configure or enable logging with  the  Java
       Virtual Machine (JVM) unified logging framework.

   Synopsis
              -Xlog[:[what][:[output][:[decorators][:output-options[,...]]]]]

       what   Specifies  a  combination  of  tags  and  levels  of  the   form
              tag1[+tag2...][*][=level][,...].   Unless  the  wildcard  (*) is
              specified, only log messages tagged with exactly the tags speci-
              fied are matched.  See -Xlog Tags and Levels.

       output Sets  the  type of output.  Omitting the output type defaults to
              stdout.  See -Xlog Output.

       decorators
              Configures the output to use a custom set of decorators.   Omit-
              ting  decorators defaults to uptime, level, and tags.  See Deco-
              rations.

       output-options
              Sets the -Xlog logging output options.

   Description
       The Java Virtual Machine (JVM) unified  logging  framework  provides  a
       common  logging  system  for all components of the JVM.  GC logging for
       the JVM has been changed to use the new logging framework.  The mapping
       of  old  GC  flags  to  the corresponding new Xlog configuration is de-
       scribed in Convert GC Logging Flags to Xlog.  In addition, runtime log-
       ging  has  also  been changed to use the JVM unified logging framework.
       The mapping of legacy runtime logging flags to  the  corresponding  new
       Xlog  configuration  is  described  in Convert Runtime Logging Flags to
       Xlog.

       The following provides quick reference to the -Xlog command and  syntax
       for options:

       -Xlog  Enables JVM logging on an info level.

       -Xlog:help
              Prints  -Xlog usage syntax and available tags, levels, and deco-
              rators along with example command lines with explanations.

       -Xlog:disable
              Turns off all logging and clears all configuration of  the  log-
              ging  framework including the default configuration for warnings
              and errors.

       -Xlog[:option]
              Applies multiple arguments in the order that they appear on  the
              command  line.   Multiple  -Xlog  arguments  for the same output
              override each other in their given order.

              The option is set as:

                     [tag-selection][:[output][:[decorators][:output-op-
                     tions]]]

              Omitting  the  tag-selection  defaults to a tag-set of all and a
              level of info.

                     tag[+...] all

              The all tag is a meta tag consisting of all tag-sets  available.
              The  asterisk  *  in a tag set definition denotes a wildcard tag
              match.  Matching with a wildcard selects all tag sets that  con-
              tain  at  least  the specified tags.  Without the wildcard, only
              exact matches of the specified tag sets are selected.

              output-options is

                     filecount=file-count filesize=file size with optional  K,
                     M or G suffix

   Default Configuration
       When  the  -Xlog  option  and  nothing else is specified on the command
       line, the default configuration is  used.   The  default  configuration
       logs all messages with a level that matches either warning or error re-
       gardless of what tags the message is associated with.  The default con-
       figuration is equivalent to entering the following on the command line:

              -Xlog:all=warning:stdout:uptime,level,tags

   Controlling Logging at Runtime
       Logging can also be controlled at run time through Diagnostic  Commands
       (with  the jcmd utility).  Everything that can be specified on the com-
       mand line can also be specified dynamically with  the  VM.log  command.
       As the diagnostic commands are automatically exposed as MBeans, you can
       use JMX to change logging configuration at run time.

   -Xlog Tags and Levels
       Each log message has a level and a tag set  associated  with  it.   The
       level of the message corresponds to its details, and the tag set corre-
       sponds to what the message contains or which JVM component it  involves
       (such  as, gc, jit, or os).  Mapping GC flags to the Xlog configuration
       is described in Convert GC Logging Flags to Xlog.  Mapping legacy  run-
       time logging flags to the corresponding Xlog configuration is described
       in Convert Runtime Logging Flags to Xlog.

       Available log levels:

       o off

       o trace

       o debug

       o info

       o warning

       o error

       Available log tags:

       There are literally dozens of log tags, which  in  the  right  combina-
       tions,  will  enable a range of logging output.  The full set of avail-
       able log tags can be seen using -Xlog:help.  Specifying all instead  of
       a tag combination matches all tag combinations.

   -Xlog Output
       The -Xlog option supports the following types of outputs:

       o stdout --- Sends output to stdout

       o stderr --- Sends output to stderr

       o file=filename --- Sends output to text file(s).

       When  using file=filename, specifying %p and/or %t in the file name ex-
       pands to the JVM's PID and startup timestamp,  respectively.   You  can
       also  configure  text  files to handle file rotation based on file size
       and a number of files to rotate.  For example, to rotate the  log  file
       every  10  MB  and  keep 5 files in rotation, specify the options file-
       size=10M, filecount=5.  The target size of the files  isn't  guaranteed
       to  be exact, it's just an approximate value.  Files are rotated by de-
       fault with up to 5 rotated files of target size 20 MB,  unless  config-
       ured  otherwise.   Specifying  filecount=0  means  that  the  log  file
       shouldn't be rotated.  There's a possibility of  the  pre-existing  log
       file getting overwritten.

   Decorations
       Logging messages are decorated with information about the message.  You
       can configure each output to use a custom set of decorators.  The order
       of  the output is always the same as listed in the table.  You can con-
       figure the decorations  to  be  used  at  run  time.   Decorations  are
       prepended to the log message.  For example:

              [6.567s][info][gc,old] Old collection complete

       Omitting decorators defaults to uptime, level, and tags.  The none dec-
       orator is special and is used to turn off all decorations.

       time (t), utctime (utc),  uptime  (u),  timemillis  (tm),  uptimemillis
       (um),  timenanos  (tn),  uptimenanos  (un), hostname (hn), pid (p), tid
       (ti), level (l), tags (tg) decorators can also be specified as none for
       no decoration.


       Decorations       Description
       --------------------------------------------------------------------------
       time or t         Current time and date in ISO-8601 format.
       utctime or utc    Universal  Time  Coordinated  or  Coordinated Universal
                         Time.
       uptime or u       Time since the start of the JVM  in  seconds  and  mil-
                         liseconds.  For example, 6.567s.
       timemillis   or   The same value as generated  by  System.currentTimeMil-
       tm                lis()
       uptimemillis or   Milliseconds since the JVM started.
       um
       timenanos or tn   The same value generated by System.nanoTime().
       uptimenanos  or   Nanoseconds since the JVM started.
       un
       hostname or hn    The host name.
       pid or p          The process identifier.
       tid or ti         The thread identifier.
       level or l        The level associated with the log message.

       tags or tg        The tag-set associated with the log message.

   Convert GC Logging Flags to Xlog
       Legacy Garbage Collec-   Xlog  Configura-             Comment
       tion (GC) Flag           tion
       ---------------------------------------------------------------------------------------
       G1PrintHeapRegions       -Xlog:gc+re-                 Not Applicable
                                gion=trace
       GCLogFileSize            No configuration             Log rotation is handled by  the
                                available                    framework.
       NumberOfGCLogFiles       Not Applicable               Log  rotation is handled by the
                                                             framework.
       PrintAdaptiveSizePoli-   -Xlog:gc+er-                 Use a level of debug  for  most
       cy                       go*=level                    of  the information, or a level
                                                             of trace for all  of  what  was
                                                             logged    for    PrintAdaptive-
                                                             SizePolicy.
       PrintGC                  -Xlog:gc                     Not Applicable
       PrintGCApplicationCon-   -Xlog:safepoint              Note  that  PrintGCApplication-
       currentTime                                           ConcurrentTime  and  PrintGCAp-
                                                             plicationStoppedTime are logged
                                                             on the same tag and aren't sep-
                                                             arated in the new logging.
       PrintGCApplication-      -Xlog:safepoint              Note  that  PrintGCApplication-
       StoppedTime                                           ConcurrentTime  and  PrintGCAp-
                                                             plicationStoppedTime are logged
                                                             on  the  same tag and not sepa-
                                                             rated in the new logging.
       PrintGCCause             Not Applicable               GC cause is now always  logged.
       PrintGCDateStamps        Not Applicable               Date  stamps  are logged by the
                                                             framework.
       PrintGCDetails           -Xlog:gc*                    Not Applicable
       PrintGCID                Not Applicable               GC ID is now always logged.
       PrintGCTaskTimeStamps    -Xlog:gc+task*=de-           Not Applicable
                                bug
       PrintGCTimeStamps        Not Applicable               Time  stamps  are logged by the
                                                             framework.
       PrintHeapAtGC            -Xlog:gc+heap=trace          Not Applicable
       PrintReferenceGC         -Xlog:gc+ref*=debug          Note that in the  old  logging,
                                                             PrintReferenceGC  had an effect
                                                             only if PrintGCDetails was also
                                                             enabled.
       PrintStringDeduplica-    `-Xlog:gc+stringdedup*=de-   ` Not Applicable
       tionStatistics           bug
       PrintTenuringDistribu-   -Xlog:gc+age*=level          Use a level of  debug  for  the
       tion                                                  most relevant information, or a
                                                             level of trace for all of  what
                                                             was   logged   for  PrintTenur-
                                                             ingDistribution.
       UseGCLogFileRotation     Not Applicable               What was logged for PrintTenur-
                                                             ingDistribution.

   Convert Runtime Logging Flags to Xlog
       Legacy  Runtime   Xlog Configuration      Comment
       Flag
       ------------------------------------------------------------------------------
       TraceExceptions   -Xlog:exceptions=in-    Not Applicable
                         fo
       TraceClassLoad-   -Xlog:class+load=lev-   Use level=info for regular informa-
       ing               el                      tion, or level=debug for additional
                                                 information.   In  Unified  Logging
                                                 syntax,    -verbose:class    equals
                                                 -Xlog:class+load=info,class+un-
                                                 load=info.
       TraceClassLoad-   -Xlog:class+pre-        Not Applicable
       ingPreorder       order=debug
       TraceClassUn-     -Xlog:class+un-         Use level=info for regular informa-
       loading           load=level              tion, or level=trace for additional
                                                 information.   In  Unified  Logging
                                                 syntax,    -verbose:class    equals
                                                 -Xlog:class+load=info,class+un-
                                                 load=info.
       VerboseVerifi-    -Xlog:verifica-         Not Applicable
       cation            tion=info

       TraceClassPaths   -Xlog:class+path=info   Not Applicable
       TraceClassReso-   -Xlog:class+re-         Not Applicable
       lution            solve=debug
       TraceClassIni-    -Xlog:class+init=info   Not Applicable
       tialization
       TraceLoaderCon-   -Xlog:class+load-       Not Applicable
       straints          er+constraints=info
       TraceClassLoad-   -Xlog:class+load-       Use level=debug for regular  infor-
       erData            er+data=level           mation or level=trace for addition-
                                                 al information.
       TraceSafepoint-   -Xlog:safe-             Not Applicable
       CleanupTime       point+cleanup=info
       TraceSafepoint    -Xlog:safepoint=debug   Not Applicable
       TraceMonitorIn-   -Xlog:monitorinfla-     Not Applicable
       flation           tion=debug
       TraceBiased-      -Xlog:biasedlock-       Use level=info for regular informa-
       Locking           ing=level               tion, or level=trace for additional
                                                 information.
       TraceRede-        -Xlog:rede-             level=info,  debug,  and trace pro-
       fineClasses       fine+class*=level       vide increasing amounts of informa-
                                                 tion.

   -Xlog Usage Examples
       The following are -Xlog examples.

       -Xlog  Logs all messages by using the info level to stdout with uptime,
              levels, and tags decorations.  This is equivalent to using:

                     -Xlog:all=info:stdout:uptime,levels,tags

       -Xlog:gc
              Logs messages tagged with the gc tag using info level to stdout.
              The  default configuration for all other messages at level warn-
              ing is in effect.

       -Xlog:gc,safepoint
              Logs messages tagged either with the gc or safepoint tags,  both
              using the info level, to stdout, with default decorations.  Mes-
              sages tagged with both gc and safepoint won't be logged.

       -Xlog:gc+ref=debug
              Logs messages tagged with both gc and ref tags, using the  debug
              level to stdout, with default decorations.  Messages tagged only
              with one of the two tags won't be logged.

       -Xlog:gc=debug:file=gc.txt:none
              Logs messages tagged with the gc tag using the debug level to  a
              file  called gc.txt with no decorations.  The default configura-
              tion for all other messages at level warning is still in effect.

       -Xlog:gc=trace:file=gctrace.txt:uptimemillis,pids:filecount=5,file-
       size=1024
              Logs  messages tagged with the gc tag using the trace level to a
              rotating file set with 5 files with size 1 MB with the base name
              gctrace.txt and uses decorations uptimemillis and pid.

              The  default configuration for all other messages at level warn-
              ing is still in effect.

       -Xlog:gc::uptime,tid
              Logs messages tagged with the gc tag using  the  default  'info'
              level  to  default the output stdout and uses decorations uptime
              and tid.  The default configuration for all  other  messages  at
              level warning is still in effect.

       -Xlog:gc*=info,safepoint*=off
              Logs  messages tagged with at least gc using the info level, but
              turns off logging of messages tagged with  safepoint.   Messages
              tagged with both gc and safepoint won't be logged.

       -Xlog:disable -Xlog:safepoint=trace:safepointtrace.txt
              Turns  off  all logging, including warnings and errors, and then
              enables messages tagged with safepointusing  tracelevel  to  the
              file  safepointtrace.txt.  The default configuration doesn't ap-
              ply, because the command line started with -Xlog:disable.

   Complex -Xlog Usage Examples
       The following describes a few complex examples of using the  -Xlog  op-
       tion.

       -Xlog:gc+class*=debug
              Logs  messages  tagged with at least gc and class tags using the
              debug level to stdout.  The default configuration for all  other
              messages at the level warning is still in effect

       -Xlog:gc+meta*=trace,class*=off:file=gcmetatrace.txt
              Logs  messages  tagged  with at least the gc and meta tags using
              the trace level to the file metatrace.txt but turns off all mes-
              sages  tagged  with  class.   Messages tagged with gc, meta, and
              class aren't be logged as class* is set  to  off.   The  default
              configuration  for all other messages at level warning is in ef-
              fect except for those that include class.

       -Xlog:gc+meta=trace
              Logs messages tagged with exactly the gc and meta tags using the
              trace  level to stdout.  The default configuration for all other
              messages at level warning is still be in effect.

       -Xlog:gc+class+heap*=debug,meta*=warning,threads*=off
              Logs messages tagged with at least gc, class, and heap tags  us-
              ing  the trace level to stdout but only log messages tagged with
              meta with level.  The default configuration for all  other  mes-
              sages  at  the  level warning is in effect except for those that
              include threads.


VALIDATE JAVA VIRTUAL MACHINE FLAG ARGUMENTS

       You use values provided to all Java Virtual Machine (JVM)  command-line
       flags   for   validation   and,  if  the  input  value  is  invalid  or
       out-of-range, then an appropriate error message is displayed.

       Whether they're set ergonomically, in a command line, by an input tool,
       or  through the APIs (for example, classes contained in the package ja-
       va.lang.management) the values provided to  all  Java  Virtual  Machine
       (JVM)  command-line  flags  are validated.  Ergonomics are described in
       Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collec-
       tion Tuning Guide.

       Range  and  constraints  are validated either when all flags have their
       values set during JVM initialization or a flag's value is changed  dur-
       ing  runtime  (for example using the jcmd tool).  The JVM is terminated
       if a value violates either the range or constraint check and an  appro-
       priate error message is printed on the error stream.

       For example, if a flag violates a range or a constraint check, then the
       JVM exits with an error:

              java -XX:AllocatePrefetchStyle=5 -version
              intx AllocatePrefetchStyle=5 is outside the allowed range [ 0 ... 3 ]
              Improperly specified VM option 'AllocatePrefetchStyle=5'
              Error: Could not create the Java Virtual Machine.
              Error: A fatal exception has occurred. Program will exit.

       The flag -XX:+PrintFlagsRanges prints the range of all the flags.  This
       flag  allows  automatic  testing of the flags by the values provided by
       the ranges.  For the flags that have the ranges  specified,  the  type,
       name, and the actual range is printed in the output.

       For example,

              intx   ThreadStackSize [ 0 ... 9007199254740987 ] {pd product}

       For  the  flags  that don't have the range specified, the values aren't
       displayed in the print out.  For example:

              size_t NewSize         [   ...                  ] {product}

       This helps to identify the flags that need to be implemented.  The  au-
       tomatic  testing  framework can skip those flags that don't have values
       and aren't implemented.


LARGE PAGES

       You use large pages, also known as huge pages, as memory pages that are
       significantly  larger  than the standard memory page size (which varies
       depending on the processor and operating system).  Large pages optimize
       processor Translation-Lookaside Buffers.

       A  Translation-Lookaside  Buffer (TLB) is a page translation cache that
       holds the most-recently used virtual-to-physical address  translations.
       A  TLB  is  a scarce system resource.  A TLB miss can be costly because
       the processor must then read from the hierarchical  page  table,  which
       may  require  multiple  memory accesses.  By using a larger memory page
       size, a single TLB entry can represent a larger memory range.  This re-
       sults  in less pressure on a TLB, and memory-intensive applications may
       have better performance.

       However, large pages page memory can negatively affect  system  perfor-
       mance.   For  example, when a large mount of memory is pinned by an ap-
       plication, it may create a shortage of regular memory and cause  exces-
       sive paging in other applications and slow down the entire system.  Al-
       so, a system that has been up for a long time could  produce  excessive
       fragmentation,  which  could make it impossible to reserve enough large
       page memory.  When this happens, either the OS or JVM reverts to  using
       regular pages.

       Linux and Windows support large pages.

   Large Pages Support for Linux
       The  2.6 kernel supports large pages.  Some vendors have backported the
       code to their 2.4-based releases.  To check if your system can  support
       large page memory, try the following:

              # cat /proc/meminfo | grep Huge
              HugePages_Total: 0
              HugePages_Free: 0
              Hugepagesize: 2048 kB

       If  the  output  shows the three "Huge" variables, then your system can
       support large page memory but it needs to be configured.  If  the  com-
       mand  prints nothing, then your system doesn't support large pages.  To
       configure the system to use large page memory, login as root, and  then
       follow these steps:

       1. If  you're  using  the  option  -XX:+UseSHM  (instead  of  -XX:+Use-
          HugeTLBFS), then increase the SHMMAX value.  It must be larger  than
          the  Java  heap  size.   On  a  system with 4 GB of physical RAM (or
          less), the following makes all the memory sharable:

                  # echo 4294967295 > /proc/sys/kernel/shmmax

       2. If you're using the option -XX:+UseSHM  or  -XX:+UseHugeTLBFS,  then
          specify  the  number of large pages.  In the following example, 3 GB
          of a 4 GB system are reserved for large pages (assuming a large page
          size of 2048kB, then 3 GB = 3 * 1024 MB = 3072 MB = 3072 * 1024 kB =
          3145728 kB and 3145728 kB / 2048 kB = 1536):

                  # echo 1536 > /proc/sys/vm/nr_hugepages

                  Note: The values contained in /proc resets after you  reboot
                  your  system,  so  may want to set them in an initialization
                  script (for example, rc.local or sysctl.conf).

       o If you configure (or resize) the OS kernel parameters  /proc/sys/ker-
         nel/shmmax  or /proc/sys/vm/nr_hugepages, Java processes may allocate
         large pages for areas in addition to the Java heap.  These steps  can
         allocate large pages for the following areas:

         o Java heap

         o Code cache

         o The marking bitmap data structure for the parallel GC

         Consequently, if you configure the nr_hugepages parameter to the size
         of the Java heap, then the JVM can fail in allocating the code  cache
         areas on large pages because these areas are quite large in size.

   Large Pages Support for Windows
       To use large pages support on Windows, the administrator must first as-
       sign additional privileges to the user who is running the application:

       1. Select Control Panel, Administrative Tools, and then Local  Security
          Policy.

       2. Select Local Policies and then User Rights Assignment.

       3. Double-click Lock pages in memory, then add users and/or groups.

       4. Reboot your system.

       Note that these steps are required even if it's the administrator who's
       running the application, because administrators by default  don't  have
       the privilege to lock pages in memory.


APPLICATION CLASS DATA SHARING

       Application  Class  Data  Sharing  (AppCDS)  extends class data sharing
       (CDS) to enable application classes to be placed in a shared archive.

       In addition to the core library classes,  AppCDS  supports  Class  Data
       Sharing  [https://docs.oracle.com/en/java/javase/12/vm/class-data-shar-
       ing.html#GUID-7EAA3411-8CF0-4D19-BD05-DF5E1780AA91] from the  following
       locations:

       o Platform classes from the runtime image

       o Application classes from the runtime image

       o Application classes from the class path

       o Application classes from the module path

       Archiving application classes provides better start up time at runtime.
       When running multiple JVM processes, AppCDS also  reduces  the  runtime
       footprint with memory sharing for read-only metadata.

       CDS/AppCDS supports archiving classes from JAR files only.

       Prior to JDK 11, a non-empty directory was reported as a fatal error in
       the following conditions:

       o For base CDS, a non-empty directory cannot exist in the  -Xbootclass-
         path/a path

       o With  -XX:+UseAppCDS,  a  non-empty  directory could not exist in the
         -Xbootclasspath/a path, class path, and module path.

       In JDK 11 and later, -XX:+UseAppCDS is obsolete and the behavior for  a
       non-empty  directory  is  based on the class types in the classlist.  A
       non-empty directory is reported as a fatal error in the following  con-
       ditions:

       o If  application classes or platform classes are not loaded, dump time
         only reports an error if a non-empty directory exists in -Xbootclass-
         path/a path

       o If  application classes or platform classes are loaded, dump time re-
         ports an error for a non-empty directory that exists in  -Xbootclass-
         path/a path, class path, or module path

       In  JDK 11 and later, using -XX:DumpLoadedClassList=class_list_file re-
       sults a generated classlist  with  all  classes  (both  system  library
       classes and application classes) included.  You no longer have to spec-
       ify -XX:+UseAppCDS with -XX:DumpLoadedClassList to produce  a  complete
       class list.

       In  JDK  11 and later, because UseAppCDS is obsolete, SharedArchiveFile
       becomes a product flag by default.   Specifying  +UnlockDiagnosticVMOp-
       tions for SharedArchiveFile is no longer needed in any configuration.

       Class Data Sharing (CDS)/AppCDS does not support archiving array class-
       es in a class list.  When an array in the class  list  is  encountered,
       CDS dump time gives the explicit error message:

              Preload Warning: Cannot find array_name

       Although  an array in the class list is not allowed, some array classes
       can still be created at CDS/AppCDS dump time.  Those arrays are created
       during  the  execution  of the Java code used by the Java class loaders
       (PlatformClassLoader and the system class loader) to  load  classes  at
       dump time.  The created arrays are archived with the rest of the loaded
       classes.

   Extending Class Data Sharing to Support the Module Path
       In JDK 11, Class Data Sharing (CDS) has been improved  to  support  ar-
       chiving classes from the module path.

       o To  create  a  CDS archive using the --module-path VM option, use the
         following command line syntax:

                java -Xshare:dump -XX:SharedClassListFile=class_list_file
                -XX:SharedArchiveFile=shared_archive_file               --mod-
                ule-path=path_to_modular_jar -m module_name

       o To run with a CDS archive using the --module-path VM option, use  the
         following the command line syntax:

                java -XX:SharedArchiveFile=shared_archive_file          --mod-
                ule-path=path_to_modular_jar -m module_name

       The following table describes how the  VM  options  related  to  module
       paths can be used along with the -Xshare option.


       Option                -Xshare:dump          -Xshare:{on,auto}
       ----------------------------------------------------------------
       --module-path[1] mp   Allowed               Allowed[2]
       --module              Allowed               Allowed
       --add-module          Allowed               Allowed
       --upgrade-mod-        Disallowed   (exits   Allowed   (disables
       ule-path[3]           if specified)         CDS)
       --patch-module[4]     Disallowed   (exits   Allowed   (disables
                             if specified)         CDS)
       --limit-modules[5]    Disallowed   (exits   Allowed   (disables
                             if specified)         CDS)

       [1]  Although  there  are  two  ways of specifying a module in a --mod-
       ule-path, that is, modular JAR or exploded module,  only  modular  JARs
       are supported.

       [2] Different mp can be specified during dump time versus run time.  If
       an archived class K was loaded from mp1.jar at dump time,  but  changes
       in  mp  cause  it to be available from a different mp2.jar at run time,
       then the archived version of K will be disregarded at run time; K  will
       be loaded dynamically.

       [3]  Currently,  only two system modules are upgradeable (java.compiler
       and jdk.internal.vm.compiler).  However, these modules are  seldom  up-
       graded in production software.

       [4] As documented in JEP 261, using --patch-module is strongly discour-
       aged for production use.

       [5] --limit-modules is intended for testing  purposes.   It  is  seldom
       used in production software.

       If  --upgrade-module-path, --patch-module, or --limit-modules is speci-
       fied at dump time, an error will be printed and the JVM will exit.  For
       example,  if  the --limit-modules option is specified at dump time, the
       user will see the following error:

              Error occurred during initialization of VM
              Cannot use the following option when dumping the shared archive: --limit-modules

       If --upgrade-module-path, --patch-module, or --limit-modules is  speci-
       fied at run time, a warning message will be printed indicating that CDS
       is disabled.  For example, if the --limit-modules options is  specified
       at run time, the user will see the following warning:

              Java HotSpot(TM) 64-Bit Server VM warning: CDS is disabled when the --limit-modules option is specified.

       Several other noteworthy things include:

       o Any valid combinations of -cp and --module-path are supported.

       o A  non-empty  directory in the module path causes a fatal error.  The
         user will see the following error messages:

                Error: non-empty directory <directory> Hint: enable -Xlog:class+path=info to diagnose the failure Error occurred during initialization of VM Cannot have non-empty directory in paths

       o Unlike the class path, there's no restriction that the module path at
         dump  time  must be equal to or be a prefix of the module path at run
         time.

       o The archive is invalidated if an existing JAR in the module  path  is
         updated after archive generation.

       o Removing  a  JAR  from the module path does not invalidate the shared
         archive.  Archived classes from the removed JAR are not used at  run-
         time.

   Dynamic CDS archive
       Dynamic CDS archive extends AppCDS to allow archiving of classes when a
       Java application exits.  It improves the usability of AppCDS by  elimi-
       nating  the  trial run step for creating a class list for each applica-
       tion.  The archived classes include all loaded application classes  and
       library  classes  that are not present in the default CDS archive which
       is included in the JDK.

       A base archive is required when creating a  dynamic  archive.   If  the
       base  archive  is not specified, the default CDS archive is used as the
       base archive.

       To create a dynamic CDS archive with the default  CDS  archive  as  the
       base  archive,  just add the -XX:ArchiveClassesAtExit=<dynamic archive>
       option to the command line for running the Java application.

       If the default CDS archive does not exist, the VM will  exit  with  the
       following error:

              ArchiveClassesAtExit not supported when base CDS archive is not loaded

       To  run  the Java application using a dynamic CDS archive, just add the
       -XX:SharedArchiveFile=<dynamic archive> option to the command line  for
       running the Java application.

       The  base  archive is not required to be specified in the command line.
       The base archive information, including its name and full path, will be
       retrieved  from  the  dynamic archive header.  Note that the user could
       also use the -XX:SharedArchiveFile option for specifying a regular  Ap-
       pCDS    archive.     Therefore,    the   specified   archive   in   the
       -XX:SharedArchiveFile option could be either a regular or  dynamic  ar-
       chive.   During  VM start up the specified archive header will be read.
       If -XX:SharedArchiveFile refers to a regular archive, then the behavior
       will  be  unchanged.   If -XX:SharedArchiveFile refers to a dynamic ar-
       chive, the VM will retrieve the base archive location from the  dynamic
       archive.   If  the dynamic archive was created with the default CDS ar-
       chive, then the current default CDS archive will be used, and  will  be
       found relative to the current run time environment.

       Please      refer      to     JDK-8221706     [https://bugs.openjdk.ja-
       va.net/browse/JDK-8221706] for details on error checking during dynamic
       CDS archive dump time and run time.

   Creating a Shared Archive File and Using It to Run an Application
   AppCDS archive
       The  following steps create a shared archive file that contains all the
       classes used by the test.Hello application.  The last step runs the ap-
       plication with the shared archive file.

       1. Create  a  list  of  all classes used by the test.Hello application.
          The following command creates a file named hello.classlist that con-
          tains a list of all classes used by this application:

                  java -Xshare:off -XX:DumpLoadedClassList=hel-
                  lo.classlist -cp hello.jar test.Hello

           Note that the classpath specified by the -cp parameter must contain
           only JAR files.

       2. Create  a  shared  archive,  named  hello.jsa, that contains all the
          classes in hello.classlist:

                  java -Xshare:dump -XX:SharedArchiveFile=hel-
                  lo.jsa -XX:SharedClassListFile=hello.classlist -cp hello.jar

           Note that the classpath used at archive creation time must  be  the
           same as (or a prefix of) the classpath used at run time.

       3. Run the application test.Hello with the shared archive hello.jsa:

                  java -XX:SharedArchiveFile=hello.jsa -cp hello.jar test.Hel-
                  lo

       4. Optional Verify that the test.Hello application is using  the  class
          contained in the hello.jsa shared archive:

                  java -XX:SharedArchiveFile=hello.jsa -cp hello.jar -ver-
                  bose:class test.Hello

           The output of this command should contain the following text:

                  Loaded test.Hello from shared objects file by sun/misc/Launcher$AppClassLoader

   Dynamic CDS archive
       The following steps create a dynamic CDS archive file that contains the
       classes  used by the test.Hello application and are not included in the
       default CDS archive.  The second step runs the application with the dy-
       namic CDS archive.

       1. Create a dynamic CDS archive, named hello.jsa, that contains all the
          classes in hello.jar loaded by the application test.Hello:

                  java -XX:ArchiveClassesAtExit=hello.jsa -cp hello.jar Hello

           Note that the classpath used at archive creation time must  be  the
           same as (or a prefix of) the classpath used at run time.

       2. Run the application test.Hello with the shared archive hello.jsa:

                  java -XX:SharedArchiveFile=hello.jsa -cp hello.jar test.Hel-
                  lo

       3. Optional Repeat step 4 of the previous section to  verify  that  the
          test.Hello application is using the class contained in the hello.jsa
          shared archive.

       To automate the above steps 1 and 2, one can write a script such as the
       following:

                  ARCHIVE=hello.jsa
                  if test -f $ARCHIVE; then
                      FLAG="-XX:SharedArchiveFile=$ARCHIVE"
                  else
                      FLAG="-XX:ArchiveClassesAtExit=$ARCHIVE"
                  fi
                  $JAVA_HOME/bin/java -cp hello.jar $FLAG test.Hello

       Like an AppCDS archive, the archive needs to be re-generated if the Ja-
       va version has changed.  The above script could be adjusted to  account
       for the Java version as follows:

                  ARCHIVE=hello.jsa
                  VERSION=foo.version
                  if test -f $ARCHIVE -a -f $VERSION && cmp -s $VERSION $JAVA_HOME/release; then
                      FLAG="-XX:SharedArchiveFile=$ARCHIVE"
                  else
                      FLAG="-XX:ArchiveClassesAtExit=$ARCHIVE"
                      cp -f $JAVA_HOME/release $VERSION
                  fi
                  $JAVA_HOME/bin/java -cp hello.jar $FLAG test.Hello

       Currently,  we  don't support concurrent dumping operations to the same
       CDS archive.  Care should be taken to avoid  multiple  writers  to  the
       same CDS archive.

       The  user  could also create a dynamic CDS archive with a specific base
       archive, e.g.  named as base.jsa as follows:

              java -XX:SharedArchiveFile=base.jsa -XX:ArchiveClassesAtEx-
              it=hello.jsa -cp hello.jar Hello

       To  run  the  application using the dynamic CDS archive hello.jsa and a
       specific base CDS archive base.jsa:

              java -XX:SharedArchiveFile=base.jsa:hello.jsa -cp hello.jar Hel-
              lo

       Note  that  on  Windows,  the above path delimiter : should be replaced
       with ;.

       The above command for specifying a base archive is useful if  the  base
       archive  used for creating the dynamic archive has been moved.  Normal-
       ly, just specifying the dynamic archive should be sufficient since  the
       base archive info can be retrieved from the dynamic archive header.

   Sharing a Shared Archive Across Multiple Application Processes
       You  can  share the same archive file across multiple applications pro-
       cesses.  This reduces memory usage because the archive is memory-mapped
       into the address space of the processes.  The operating system automat-
       ically shares the read-only pages across these processes.

       The following steps demonstrate how to create a common archive that can
       be  shared  by  different  applications.  Classes from common.jar, hel-
       lo.jar and hi.jar are archived in the common.jsa because they  are  all
       in the classpath during the archiving step (step 3).

       To  include  classes  from hello.jar and hi.jar, the .jar files must be
       added to the classpath specified by the -cp parameter.

       1. Create a list of all classes used by the Hello application  and  an-
          other list for the Hi application:

                  java -XX:DumpLoadedClassList=hello.classlist -cp com-
                  mon.jar:hello.jar Hello

                  java -XX:DumpLoadedClassList=hi.classlist -cp com-
                  mon.jar:hi.jar Hi

       2. Create  a  single  list of classes used by all the applications that
          will share the shared archive file.

           Linux and macOS The  following  commands  combine  the  files  hel-
           lo.classlist and hi.classlist into one file, common.classlist:

                  cat hello.classlist hi.classlist > common.classlist

           Windows  The  following  commands combine the files hello.classlist
           and hi.classlist into one file, common.classlist:

                  type hello.classlist hi.classlist > common.classlist

       3. Create a shared archive  named  common.jsa  that  contains  all  the
          classes in common.classlist:

                  java -Xshare:dump -XX:SharedArchiveFile=com-
                  mon.jsa -XX:SharedClassListFile=common.classlist -cp com-
                  mon.jar:hello.jar:hi.jar

           The classpath parameter used is the common class path prefix shared
           by the Hello and Hi applications.

       4. Run the Hello and Hi applications with the same shared archive:

                  java -XX:SharedArchiveFile=common.jsa -cp common.jar:hel-
                  lo.jar:hi.jar Hello

                  java -XX:SharedArchiveFile=common.jsa -cp common.jar:hel-
                  lo.jar:hi.jar Hi

   Specifying Additional Shared Data Added to an Archive File
       The SharedArchiveConfigFile option is used to specify additional shared
       data to add to the archive file.

              -XX:SharedArchiveConfigFile=shared_config_file

       JDK  9  and later supports adding both symbols and string objects to an
       archive for memory sharing when you have multiple JVM processes running
       on  the same host.  An example of this is having multiple JVM processes
       that use the same set of Java EE classes.  When  these  common  classes
       are  loaded  and used, new symbols and strings may be created and added
       to the JVM's internal "symbol" and "string" tables.   At  runtime,  the
       symbols  or  string  objects mapped from the archive file can be shared
       across multiple JVM processes, resulting in a reduction of overall mem-
       ory  usage.  In addition, archiving strings also provides added perfor-
       mance benefits in both startup time and runtime execution.

       In JDK 10 and later, CONSTANT_String entries in  archived  classes  are
       resolved  to  interned  String  objects  at dump time, and all interned
       String objects are archived.  However, even though all  CONSTANT_String
       literals  in  all archived classes are resolved, it might still benefi-
       cial to add additional strings that are not string  literals  in  class
       files, but are likely to be used by your application at run time.

       Symbol data should be generated by the jcmd tool attaching to a running
       JVM process.  See jcmd.

       The following is an example of the symbol dumping command in jcmd:

              jcmd pid VM.symboltable -verbose

              Note: The first line (process ID) and  the  second  line  (@VER-
              SION ...)  of  this jcmd output should be excluded from the con-
              figuration file.

   Example of a Configuration File
       The following is an example of a configuration file:

              VERSION: 1.0
              @SECTION: Symbol
              10 -1: linkMethod

       In the configuration file example, the @SECTION: Symbol entry uses  the
       following format:

              length refcount: symbol

       The refcount for a shared symbol is always -1.

       @SECTION  specifies  the type of the section that follows it.  All data
       within the section must be the same type that's specified by  @SECTION.
       Different  types  of data can't be mixed.  Multiple separated data sec-
       tions for the same type specified by  different  @SECTION  are  allowed
       within one shared_config_file .


PERFORMANCE TUNING EXAMPLES

       You  can  use the Java advanced runtime options to optimize the perfor-
       mance of your applications.

   Tuning for Higher Throughput
       Use the following commands  and  advanced  options  to  achieve  higher
       throughput performance for your application:

              java -server -XX:+UseParallelGC -XX:+Use-
              LargePages -Xmn10g  -Xms26g -Xmx26g

   Tuning for Lower Response Time
       Use the following commands and advanced options to  achieve  lower  re-
       sponse times for your application:

              java -XX:+UseG1GC -XX:MaxGCPauseMillis=100

   Keeping the Java Heap Small and Reducing the Dynamic Footprint of
       Embedded Applications

       Use  the following advanced runtime options to keep the Java heap small
       and reduce the dynamic footprint of embedded applications:

              -XX:MaxHeapFreeRatio=10 -XX:MinHeapFreeRatio=5

              Note: The defaults for these two options are 70% and 40% respec-
              tively.   Because  performance  sacrifices  can occur when using
              these small settings, you should optimize for a small  footprint
              by reducing these settings as much as possible without introduc-
              ing unacceptable performance degradation.


EXIT STATUS

       The following exit values are typically returned by the  launcher  when
       the launcher is called with the wrong arguments, serious errors, or ex-
       ceptions thrown by the JVM.  However, a Java application may choose  to
       return  any  value  by  using the API call System.exit(exitValue).  The
       values are:

       o 0: Successful completion

       o >0: An error occurred



JDK 15                               2020                              java(1)

openjdk 15.0.2 - Generated Tue Feb 23 16:03:14 CST 2021
© manpagez.com 2000-2021
Individual documents may contain additional copyright information.