1java(1) Basic Tools java(1)
2
3
4
6 java - Launches a Java application.
7
9 java [options] classname [args]
10
11 java [options] -jar filename [args]
12
13 options
14 Command-line options separated by spaces. See Options.
15
16 classname
17 The name of the class to be launched.
18
19 filename
20 The name of the Java Archive (JAR) file to be called. Used only
21 with the -jar option.
22
23 args
24 The arguments passed to the main() method separated by spaces.
25
27 The java command starts a Java application. It does this by starting
28 the Java Runtime Environment (JRE), loading the specified class, and
29 calling that class's main() method. The method must be declared public
30 and static, it must not return any value, and it must accept a String
31 array as a parameter. The method declaration has the following form:
32
33 public static void main(String[] args)
34
35
36 The java command can be used to launch a JavaFX application by loading
37 a class that either has a main() method or that extends
38 javafx.application.Application. In the latter case, the launcher
39 constructs an instance of the Application class, calls its init()
40 method, and then calls the start(javafx.stage.Stage) method.
41
42 By default, the first argument that is not an option of the java
43 command is the fully qualified name of the class to be called. If the
44 -jar option is specified, its argument is the name of the JAR file
45 containing class and resource files for the application. The startup
46 class must be indicated by the Main-Class manifest header in its source
47 code.
48
49 The JRE searches for the startup class (and other classes used by the
50 application) in three sets of locations: the bootstrap class path, the
51 installed extensions, and the user’s class path.
52
53 Arguments after the class file name or the JAR file name are passed to
54 the main() method.
55
57 The java command supports a wide range of options that can be divided
58 into the following categories:
59
60 · Standard Options
61
62 · Non-Standard Options
63
64 · Advanced Runtime Options
65
66 · Advanced JIT Compiler Options
67
68 · Advanced Serviceability Options
69
70 · Advanced Garbage Collection Options
71
72 Standard options are guaranteed to be supported by all implementations
73 of the Java Virtual Machine (JVM). They are used for common actions,
74 such as checking the version of the JRE, setting the class path,
75 enabling verbose output, and so on.
76
77 Non-standard options are general purpose options that are specific to
78 the Java HotSpot Virtual Machine, so they are not guaranteed to be
79 supported by all JVM implementations, and are subject to change. These
80 options start with -X.
81
82 Advanced options are not recommended for casual use. These are
83 developer options used for tuning specific areas of the Java HotSpot
84 Virtual Machine operation that often have specific system requirements
85 and may require privileged access to system configuration parameters.
86 They are also not guaranteed to be supported by all JVM
87 implementations, and are subject to change. Advanced options start with
88 -XX.
89
90 To keep track of the options that were deprecated or removed in the
91 latest release, there is a section named Deprecated and Removed Options
92 at the end of the document.
93
94 Boolean options are used to either enable a feature that is disabled by
95 default or disable a feature that is enabled by default. Such options
96 do not require a parameter. Boolean -XX options are enabled using the
97 plus sign (-XX:+OptionName) and disabled using the minus sign
98 (-XX:-OptionName).
99
100 For options that require an argument, the argument may be separated
101 from the option name by a space, a colon (:), or an equal sign (=), or
102 the argument may directly follow the option (the exact syntax differs
103 for each option). If you are expected to specify the size in bytes, you
104 can use no suffix, or use the suffix k or K for kilobytes (KB), m or M
105 for megabytes (MB), g or G for gigabytes (GB). For example, to set the
106 size to 8 GB, you can specify either 8g, 8192m, 8388608k, or 8589934592
107 as the argument. If you are expected to specify the percentage, use a
108 number from 0 to 1 (for example, specify 0.25 for 25%).
109
110 Standard Options
111 These are the most commonly used options that are supported by all
112 implementations of the JVM.
113
114 -agentlib:libname[=options]
115 Loads the specified native agent library. After the library name, a
116 comma-separated list of options specific to the library can be
117 used.
118
119 If the option -agentlib:foo is specified, then the JVM attempts to
120 load the library named libfoo.so in the location specified by the
121 LD_LIBRARY_PATH system variable (on OS X this variable is
122 DYLD_LIBRARY_PATH).
123
124 The following example shows how to load the heap profiling tool
125 (HPROF) library and get sample CPU information every 20 ms, with a
126 stack depth of 3:
127
128 -agentlib:hprof=cpu=samples,interval=20,depth=3
129
130 The following example shows how to load the Java Debug Wire
131 Protocol (JDWP) library and listen for the socket connection on
132 port 8000, suspending the JVM before the main class loads:
133
134 -agentlib:jdwp=transport=dt_socket,server=y,address=8000
135
136 For more information about the native agent libraries, refer to the
137 following:
138
139 · The java.lang.instrument package description at
140 http://docs.oracle.com/javase/8/docs/api/java/lang/instrument/package-summary.html
141
142 · Agent Command Line Options in the JVM Tools Interface guide at
143 http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#starting
144
145 -agentpath:pathname[=options]
146 Loads the native agent library specified by the absolute path name.
147 This option is equivalent to -agentlib but uses the full path and
148 file name of the library.
149
150 -client
151 Selects the Java HotSpot Client VM. The 64-bit version of the Java
152 SE Development Kit (JDK) currently ignores this option and instead
153 uses the Server JVM.
154
155 For default JVM selection, see Server-Class Machine Detection at
156 http://docs.oracle.com/javase/8/docs/technotes/guides/vm/server-class.html
157
158 -Dproperty=value
159 Sets a system property value. The property variable is a string
160 with no spaces that represents the name of the property. The value
161 variable is a string that represents the value of the property. If
162 value is a string with spaces, then enclose it in quotation marks
163 (for example -Dfoo="foo bar").
164
165 -d32
166 Runs the application in a 32-bit environment. If a 32-bit
167 environment is not installed or is not supported, then an error
168 will be reported. By default, the application is run in a 32-bit
169 environment unless a 64-bit system is used.
170
171 -d64
172 Runs the application in a 64-bit environment. If a 64-bit
173 environment is not installed or is not supported, then an error
174 will be reported. By default, the application is run in a 32-bit
175 environment unless a 64-bit system is used.
176
177 Currently only the Java HotSpot Server VM supports 64-bit
178 operation, and the -server option is implicit with the use of -d64.
179 The -client option is ignored with the use of -d64. This is subject
180 to change in a future release.
181
182 -disableassertions[:[packagename]...|:classname]
183 -da[:[packagename]...|:classname]
184 Disables assertions. By default, assertions are disabled in all
185 packages and classes.
186
187 With no arguments, -disableassertions (-da) disables assertions in
188 all packages and classes. With the packagename argument ending in
189 ..., the switch disables assertions in the specified package and
190 any subpackages. If the argument is simply ..., then the switch
191 disables assertions in the unnamed package in the current working
192 directory. With the classname argument, the switch disables
193 assertions in the specified class.
194
195 The -disableassertions (-da) option applies to all class loaders
196 and to system classes (which do not have a class loader). There is
197 one exception to this rule: if the option is provided with no
198 arguments, then it does not apply to system classes. This makes it
199 easy to disable assertions in all classes except for system
200 classes. The -disablesystemassertions option enables you to disable
201 assertions in all system classes.
202
203 To explicitly enable assertions in specific packages or classes,
204 use the -enableassertions (-ea) option. Both options can be used at
205 the same time. For example, to run the MyClass application with
206 assertions enabled in package com.wombat.fruitbat (and any
207 subpackages) but disabled in class com.wombat.fruitbat.Brickbat,
208 use the following command:
209
210 java -ea:com.wombat.fruitbat... -da:com.wombat.fruitbat.Brickbat MyClass
211
212
213 -disablesystemassertions
214 -dsa
215 Disables assertions in all system classes.
216
217 -enableassertions[:[packagename]...|:classname]
218 -ea[:[packagename]...|:classname]
219 Enables assertions. By default, assertions are disabled in all
220 packages and classes.
221
222 With no arguments, -enableassertions (-ea) enables assertions in
223 all packages and classes. With the packagename argument ending in
224 ..., the switch enables assertions in the specified package and any
225 subpackages. If the argument is simply ..., then the switch enables
226 assertions in the unnamed package in the current working directory.
227 With the classname argument, the switch enables assertions in the
228 specified class.
229
230 The -enableassertions (-ea) option applies to all class loaders and
231 to system classes (which do not have a class loader). There is one
232 exception to this rule: if the option is provided with no
233 arguments, then it does not apply to system classes. This makes it
234 easy to enable assertions in all classes except for system classes.
235 The -enablesystemassertions option provides a separate switch to
236 enable assertions in all system classes.
237
238 To explicitly disable assertions in specific packages or classes,
239 use the -disableassertions (-da) option. If a single command
240 contains multiple instances of these switches, then they are
241 processed in order before loading any classes. For example, to run
242 the MyClass application with assertions enabled only in package
243 com.wombat.fruitbat (and any subpackages) but disabled in class
244 com.wombat.fruitbat.Brickbat, use the following command:
245
246 java -ea:com.wombat.fruitbat... -da:com.wombat.fruitbat.Brickbat MyClass
247
248
249 -enablesystemassertions
250 -esa
251 Enables assertions in all system classes.
252
253 -help
254 -?
255 Displays usage information for the java command without actually
256 running the JVM.
257
258 -jar filename
259 Executes a program encapsulated in a JAR file. The filename
260 argument is the name of a JAR file with a manifest that contains a
261 line in the form Main-Class:classname that defines the class with
262 the public static void main(String[] args) method that serves as
263 your application's starting point.
264
265 When you use the -jar option, the specified JAR file is the source
266 of all user classes, and other class path settings are ignored.
267
268 For more information about JAR files, see the following resources:
269
270 · jar(1)
271
272 · The Java Archive (JAR) Files guide at
273 http://docs.oracle.com/javase/8/docs/technotes/guides/jar/index.html
274
275 · Lesson: Packaging Programs in JAR Files at
276
277 http://docs.oracle.com/javase/tutorial/deployment/jar/index.html
278
279 -javaagent:jarpath[=options]
280 Loads the specified Java programming language agent. For more
281 information about instrumenting Java applications, see the
282 java.lang.instrument package description in the Java API
283 documentation at
284 http://docs.oracle.com/javase/8/docs/api/java/lang/instrument/package-summary.html
285
286 -jre-restrict-search
287 Includes user-private JREs in the version search.
288
289 -no-jre-restrict-search
290 Excludes user-private JREs from the version search.
291
292 -server
293 Selects the Java HotSpot Server VM. The 64-bit version of the JDK
294 supports only the Server VM, so in that case the option is
295 implicit.
296
297 For default JVM selection, see Server-Class Machine Detection at
298 http://docs.oracle.com/javase/8/docs/technotes/guides/vm/server-class.html
299
300 -showversion
301 Displays version information and continues execution of the
302 application. This option is equivalent to the -version option
303 except that the latter instructs the JVM to exit after displaying
304 version information.
305
306 -splash:imgname
307 Shows the splash screen with the image specified by imgname. For
308 example, to show the splash.gif file from the images directory when
309 starting your application, use the following option:
310
311 -splash:images/splash.gif
312
313
314 -verbose:class
315 Displays information about each loaded class.
316
317 -verbose:gc
318 Displays information about each garbage collection (GC) event.
319
320 -verbose:jni
321 Displays information about the use of native methods and other Java
322 Native Interface (JNI) activity.
323
324 -version
325 Displays version information and then exits. This option is
326 equivalent to the -showversion option except that the latter does
327 not instruct the JVM to exit after displaying version information.
328
329 -version:release
330 Specifies the release version to be used for running the
331 application. If the version of the java command called does not
332 meet this specification and an appropriate implementation is found
333 on the system, then the appropriate implementation will be used.
334
335 The release argument specifies either the exact version string, or
336 a list of version strings and ranges separated by spaces. A version
337 string is the developer designation of the version number in the
338 following form: 1.x.0_u (where x is the major version number, and u
339 is the update version number). A version range is made up of a
340 version string followed by a plus sign (+) to designate this
341 version or later, or a part of a version string followed by an
342 asterisk (*) to designate any version string with a matching
343 prefix. Version strings and ranges can be combined using a space
344 for a logical OR combination, or an ampersand (&) for a logical AND
345 combination of two version strings/ranges. For example, if running
346 the class or JAR file requires either JRE 6u13 (1.6.0_13), or any
347 JRE 6 starting from 6u10 (1.6.0_10), specify the following:
348
349 -version:"1.6.0_13 1.6* & 1.6.0_10+"
350
351 Quotation marks are necessary only if there are spaces in the
352 release parameter.
353
354 For JAR files, the preference is to specify version requirements in
355 the JAR file manifest rather than on the command line.
356
357 Non-Standard Options
358 These options are general purpose options that are specific to the Java
359 HotSpot Virtual Machine.
360
361 -X
362 Displays help for all available -X options.
363
364 -Xbatch
365 Disables background compilation. By default, the JVM compiles the
366 method as a background task, running the method in interpreter mode
367 until the background compilation is finished. The -Xbatch flag
368 disables background compilation so that compilation of all methods
369 proceeds as a foreground task until completed.
370
371 This option is equivalent to -XX:-BackgroundCompilation.
372
373 -Xbootclasspath:path
374 Specifies a list of directories, JAR files, and ZIP archives
375 separated by colons (:) to search for boot class files. These are
376 used in place of the boot class files included in the JDK.
377
378 Do not deploy applications that use this option to override a class
379 in rt.jar, because this violates the JRE binary code license.
380
381 -Xbootclasspath/a:path
382 Specifies a list of directories, JAR files, and ZIP archives
383 separated by colons (:) to append to the end of the default
384 bootstrap class path.
385
386 Do not deploy applications that use this option to override a class
387 in rt.jar, because this violates the JRE binary code license.
388
389 -Xbootclasspath/p:path
390 Specifies a list of directories, JAR files, and ZIP archives
391 separated by colons (:) to prepend to the front of the default
392 bootstrap class path.
393
394 Do not deploy applications that use this option to override a class
395 in rt.jar, because this violates the JRE binary code license.
396
397 -Xcheck:jni
398 Performs additional checks for Java Native Interface (JNI)
399 functions. Specifically, it validates the parameters passed to the
400 JNI function and the runtime environment data before processing the
401 JNI request. Any invalid data encountered indicates a problem in
402 the native code, and the JVM will terminate with an irrecoverable
403 error in such cases. Expect a performance degradation when this
404 option is used.
405
406 -Xcomp
407 Forces compilation of methods on first invocation. By default, the
408 Client VM (-client) performs 1,000 interpreted method invocations
409 and the Server VM (-server) performs 10,000 interpreted method
410 invocations to gather information for efficient compilation.
411 Specifying the -Xcomp option disables interpreted method
412 invocations to increase compilation performance at the expense of
413 efficiency.
414
415 You can also change the number of interpreted method invocations
416 before compilation using the -XX:CompileThreshold option.
417
418 -Xdebug
419 Does nothing. Provided for backward compatibility.
420
421 -Xdiag
422 Shows additional diagnostic messages.
423
424 -Xfuture
425 Enables strict class-file format checks that enforce close
426 conformance to the class-file format specification. Developers are
427 encouraged to use this flag when developing new code because the
428 stricter checks will become the default in future releases.
429
430 -Xint
431 Runs the application in interpreted-only mode. Compilation to
432 native code is disabled, and all bytecode is executed by the
433 interpreter. The performance benefits offered by the just in time
434 (JIT) compiler are not present in this mode.
435
436 -Xinternalversion
437 Displays more detailed JVM version information than the -version
438 option, and then exits.
439
440 -Xloggc:filename
441 Sets the file to which verbose GC events information should be
442 redirected for logging. The information written to this file is
443 similar to the output of -verbose:gc with the time elapsed since
444 the first GC event preceding each logged event. The -Xloggc option
445 overrides -verbose:gc if both are given with the same java command.
446
447 Example:
448
449 -Xloggc:garbage-collection.log
450
451
452 -Xmaxjitcodesize=size
453 Specifies the maximum code cache size (in bytes) for JIT-compiled
454 code. Append the letter k or K to indicate kilobytes, m or M to
455 indicate megabytes, g or G to indicate gigabytes. The default
456 maximum code cache size is 240 MB; if you disable tiered
457 compilation with the option -XX:-TieredCompilation, then the
458 default size is 48 MB:
459
460 -Xmaxjitcodesize=240m
461
462 This option is equivalent to -XX:ReservedCodeCacheSize.
463
464 -Xmixed
465 Executes all bytecode by the interpreter except for hot methods,
466 which are compiled to native code.
467
468 -Xmnsize
469 Sets the initial and maximum size (in bytes) of the heap for the
470 young generation (nursery). Append the letter k or K to indicate
471 kilobytes, m or M to indicate megabytes, g or G to indicate
472 gigabytes.
473
474 The young generation region of the heap is used for new objects. GC
475 is performed in this region more often than in other regions. If
476 the size for the young generation is too small, then a lot of minor
477 garbage collections will be performed. If the size is too large,
478 then only full garbage collections will be performed, which can
479 take a long time to complete. Oracle recommends that you keep the
480 size for the young generation between a half and a quarter of the
481 overall heap size.
482
483 The following examples show how to set the initial and maximum size
484 of young generation to 256 MB using various units:
485
486 -Xmn256m
487 -Xmn262144k
488 -Xmn268435456
489
490 Instead of the -Xmn option to set both the initial and maximum size
491 of the heap for the young generation, you can use -XX:NewSize to
492 set the initial size and -XX:MaxNewSize to set the maximum size.
493
494 -Xmssize
495 Sets the initial size (in bytes) of the heap. This value must be a
496 multiple of 1024 and greater than 1 MB. Append the letter k or K to
497 indicate kilobytes, m or M to indicate megabytes, g or G to
498 indicate gigabytes.
499
500 The following examples show how to set the size of allocated memory
501 to 6 MB using various units:
502
503 -Xms6291456
504 -Xms6144k
505 -Xms6m
506
507 If you do not set this option, then the initial size will be set as
508 the sum of the sizes allocated for the old generation and the young
509 generation. The initial size of the heap for the young generation
510 can be set using the -Xmn option or the -XX:NewSize option.
511
512 -Xmxsize
513 Specifies the maximum size (in bytes) of the memory allocation pool
514 in bytes. This value must be a multiple of 1024 and greater than 2
515 MB. Append the letter k or K to indicate kilobytes, m or M to
516 indicate megabytes, g or G to indicate gigabytes. The default value
517 is chosen at runtime based on system configuration. For server
518 deployments, -Xms and -Xmx are often set to the same value. See the
519 section "Ergonomics" in Java SE HotSpot Virtual Machine Garbage
520 Collection Tuning Guide at
521 http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/index.html.
522
523 The following examples show how to set the maximum allowed size of
524 allocated memory to 80 MB using various units:
525
526 -Xmx83886080
527 -Xmx81920k
528 -Xmx80m
529
530 The -Xmx option is equivalent to -XX:MaxHeapSize.
531
532 -Xnoclassgc
533 Disables garbage collection (GC) of classes. This can save some GC
534 time, which shortens interruptions during the application run.
535
536 When you specify -Xnoclassgc at startup, the class objects in the
537 application will be left untouched during GC and will always be
538 considered live. This can result in more memory being permanently
539 occupied which, if not used carefully, will throw an out of memory
540 exception.
541
542 -Xprof
543 Profiles the running program and sends profiling data to standard
544 output. This option is provided as a utility that is useful in
545 program development and is not intended to be used in production
546 systems.
547
548 -Xrs
549 Reduces the use of operating system signals by the JVM.
550
551 Shutdown hooks enable orderly shutdown of a Java application by
552 running user cleanup code (such as closing database connections) at
553 shutdown, even if the JVM terminates abruptly.
554
555 The JVM catches signals to implement shutdown hooks for unexpected
556 termination. The JVM uses SIGHUP, SIGINT, and SIGTERM to initiate
557 the running of shutdown hooks.
558
559 The JVM uses a similar mechanism to implement the feature of
560 dumping thread stacks for debugging purposes. The JVM uses SIGQUIT
561 to perform thread dumps.
562
563 Applications embedding the JVM frequently need to trap signals such
564 as SIGINT or SIGTERM, which can lead to interference with the JVM
565 signal handlers. The -Xrs option is available to address this
566 issue. When -Xrs is used, the signal masks for SIGINT, SIGTERM,
567 SIGHUP, and SIGQUIT are not changed by the JVM, and signal handlers
568 for these signals are not installed.
569
570 There are two consequences of specifying -Xrs:
571
572 · SIGQUIT thread dumps are not available.
573
574 · User code is responsible for causing shutdown hooks to run, for
575 example, by calling System.exit() when the JVM is to be
576 terminated.
577
578 -Xshare:mode
579 Sets the class data sharing (CDS) mode. Possible mode arguments for
580 this option include the following:
581
582 auto
583 Use CDS if possible. This is the default value for Java HotSpot
584 32-Bit Client VM.
585
586 on
587 Require the use of CDS. Print an error message and exit if
588 class data sharing cannot be used.
589
590 off
591 Do not use CDS. This is the default value for Java HotSpot
592 32-Bit Server VM, Java HotSpot 64-Bit Client VM, and Java
593 HotSpot 64-Bit Server VM.
594
595 dump
596 Manually generate the CDS archive. Specify the application
597 class path as described in "Setting the Class Path ".
598
599 You should regenerate the CDS archive with each new JDK
600 release.
601
602 -XshowSettings:category
603 Shows settings and continues. Possible category arguments for this
604 option include the following:
605
606 all
607 Shows all categories of settings. This is the default value.
608
609 locale
610 Shows settings related to locale.
611
612 properties
613 Shows settings related to system properties.
614
615 vm
616 Shows the settings of the JVM.
617
618 -Xsssize
619 Sets the thread stack size (in bytes). Append the letter k or K to
620 indicate KB, m or M to indicate MB, g or G to indicate GB. The
621 default value depends on the platform:
622
623 · Linux/ARM (32-bit): 320 KB
624
625 · Linux/i386 (32-bit): 320 KB
626
627 · Linux/x64 (64-bit): 1024 KB
628
629 · OS X (64-bit): 1024 KB
630
631 · Oracle Solaris/i386 (32-bit): 320 KB
632
633 · Oracle Solaris/x64 (64-bit): 1024 KB
634
635 The following examples set the thread stack size to 1024 KB in
636 different units:
637
638 -Xss1m
639 -Xss1024k
640 -Xss1048576
641
642 This option is equivalent to -XX:ThreadStackSize.
643
644 -Xusealtsigs
645 Use alternative signals instead of SIGUSR1 and SIGUSR2 for JVM
646 internal signals. This option is equivalent to -XX:+UseAltSigs.
647
648 -Xverify:mode
649 Sets the mode of the bytecode verifier. Bytecode verification helps
650 to troubleshoot some problems, but it also adds overhead to the
651 running application. Possible mode arguments for this option
652 include the following:
653
654 none
655 Do not verify the bytecode. This reduces startup time and also
656 reduces the protection provided by Java.
657
658 remote
659 Verify those classes that are not loaded by the bootstrap class
660 loader. This is the default behavior if you do not specify the
661 -Xverify option.
662
663 all
664 Verify all classes.
665
666 Advanced Runtime Options
667 These options control the runtime behavior of the Java HotSpot VM.
668
669 -XX:+CheckEndorsedAndExtDirs
670 Enables the option to prevent the java command from running a Java
671 application if it uses the endorsed-standards override mechanism or
672 the extension mechanism. This option checks if an application is
673 using one of these mechanisms by checking the following:
674
675 · The java.ext.dirs or java.endorsed.dirs system property is set.
676
677 · The lib/endorsed directory exists and is not empty.
678
679 · The lib/ext directory contains any JAR files other than those
680 of the JDK.
681
682 · The system-wide platform-specific extension directory contains
683 any JAR files.
684
685 -XX:+DisableAttachMechanism
686 Enables the option that disables the mechanism that lets tools
687 attach to the JVM. By default, this option is disabled, meaning
688 that the attach mechanism is enabled and you can use tools such as
689 jcmd, jstack, jmap, and jinfo.
690
691 -XX:ErrorFile=filename
692 Specifies the path and file name to which error data is written
693 when an irrecoverable error occurs. By default, this file is
694 created in the current working directory and named
695 hs_err_pidpid.log where pid is the identifier of the process that
696 caused the error. The following example shows how to set the
697 default log file (note that the identifier of the process is
698 specified as %p):
699
700 -XX:ErrorFile=./hs_err_pid%p.log
701
702 The following example shows how to set the error log to
703 /var/log/java/java_error.log:
704
705 -XX:ErrorFile=/var/log/java/java_error.log
706
707 If the file cannot be created in the specified directory (due to
708 insufficient space, permission problem, or another issue), then the
709 file is created in the temporary directory for the operating
710 system. The temporary directory is /tmp.
711
712 -XX:+FailOverToOldVerifier
713 Enables automatic failover to the old verifier when the new type
714 checker fails. By default, this option is disabled and it is
715 ignored (that is, treated as disabled) for classes with a recent
716 bytecode version. You can enable it for classes with older versions
717 of the bytecode.
718
719 -XX:LargePageSizeInBytes=size
720 On Solaris, sets the maximum size (in bytes) for large pages used
721 for Java heap. The size argument must be a power of 2 (2, 4, 8, 16,
722 ...). Append the letter k or K to indicate kilobytes, m or M to
723 indicate megabytes, g or G to indicate gigabytes. By default, the
724 size is set to 0, meaning that the JVM chooses the size for large
725 pages automatically.
726
727 The following example illustrates how to set the large page size to
728 4 megabytes (MB):
729
730 -XX:LargePageSizeInBytes=4m
731
732
733 -XX:MaxDirectMemorySize=size
734 Sets the maximum total size (in bytes) of the New I/O (the java.nio
735 package) direct-buffer allocations. Append the letter k or K to
736 indicate kilobytes, m or M to indicate megabytes, g or G to
737 indicate gigabytes. By default, the size is set to 0, meaning that
738 the JVM chooses the size for NIO direct-buffer allocations
739 automatically.
740
741 The following examples illustrate how to set the NIO size to 1024
742 KB in different units:
743
744 -XX:MaxDirectMemorySize=1m
745 -XX:MaxDirectMemorySize=1024k
746 -XX:MaxDirectMemorySize=1048576
747
748
749 -XX:NativeMemoryTracking=mode
750 Specifies the mode for tracking JVM native memory usage. Possible
751 mode arguments for this option include the following:
752
753 off
754 Do not track JVM native memory usage. This is the default
755 behavior if you do not specify the -XX:NativeMemoryTracking
756 option.
757
758 summary
759 Only track memory usage by JVM subsystems, such as Java heap,
760 class, code, and thread.
761
762 detail
763 In addition to tracking memory usage by JVM subsystems, track
764 memory usage by individual CallSite, individual virtual memory
765 region and its committed regions.
766
767 -XX:ObjectAlignmentInBytes=alignment
768 Sets the memory alignment of Java objects (in bytes). By default,
769 the value is set to 8 bytes. The specified value should be a power
770 of two, and must be within the range of 8 and 256 (inclusive). This
771 option makes it possible to use compressed pointers with large Java
772 heap sizes.
773
774 The heap size limit in bytes is calculated as:
775
776 4GB * ObjectAlignmentInBytes
777
778 Note: As the alignment value increases, the unused space between
779 objects will also increase. As a result, you may not realize any
780 benefits from using compressed pointers with large Java heap sizes.
781
782 -XX:OnError=string
783 Sets a custom command or a series of semicolon-separated commands
784 to run when an irrecoverable error occurs. If the string contains
785 spaces, then it must be enclosed in quotation marks.
786
787 The following example shows how the -XX:OnError option can be used
788 to run the gcore command to create the core image, and the debugger
789 is started to attach to the process in case of an irrecoverable
790 error (the %p designates the current process):
791
792 -XX:OnError="gcore %p;dbx - %p"
793
794
795 -XX:OnOutOfMemoryError=string
796 Sets a custom command or a series of semicolon-separated commands
797 to run when an OutOfMemoryError exception is first thrown. If the
798 string contains spaces, then it must be enclosed in quotation
799 marks. For an example of a command string, see the description of
800 the -XX:OnError option.
801
802 -XX:+PerfDataSaveToFile
803 If enabled, saves jstat(1) binary data when the Java application
804 exits. This binary data is saved in a file named hsperfdata_<pid>,
805 where <pid> is the process identifier of the Java application you
806 ran. Use jstat to display the performance data contained in this
807 file as follows:
808
809 jstat -class file:///<path>/hsperfdata_<pid>
810 jstat -gc file:///<path>/hsperfdata_<pid>
811
812 -XX:+PrintCommandLineFlags
813 Enables printing of ergonomically selected JVM flags that appeared
814 on the command line. It can be useful to know the ergonomic values
815 set by the JVM, such as the heap space size and the selected
816 garbage collector. By default, this option is disabled and flags
817 are not printed.
818
819 -XX:+PrintNMTStatistics
820 Enables printing of collected native memory tracking data at JVM
821 exit when native memory tracking is enabled (see
822 -XX:NativeMemoryTracking). By default, this option is disabled and
823 native memory tracking data is not printed.
824
825 -XX:+RelaxAccessControlCheck
826 Decreases the amount of access control checks in the verifier. By
827 default, this option is disabled, and it is ignored (that is,
828 treated as disabled) for classes with a recent bytecode version.
829 You can enable it for classes with older versions of the bytecode.
830
831 -XX:+ShowMessageBoxOnError
832 Enables displaying of a dialog box when the JVM experiences an
833 irrecoverable error. This prevents the JVM from exiting and keeps
834 the process active so that you can attach a debugger to it to
835 investigate the cause of the error. By default, this option is
836 disabled.
837
838 -XX:ThreadStackSize=size
839 Sets the thread stack size (in bytes). Append the letter k or K to
840 indicate kilobytes, m or M to indicate megabytes, g or G to
841 indicate gigabytes. The default value depends on the platform:
842
843 · Linux/ARM (32-bit): 320 KB
844
845 · Linux/i386 (32-bit): 320 KB
846
847 · Linux/x64 (64-bit): 1024 KB
848
849 · OS X (64-bit): 1024 KB
850
851 · Oracle Solaris/i386 (32-bit): 320 KB
852
853 · Oracle Solaris/x64 (64-bit): 1024 KB
854
855 The following examples show how to set the thread stack size to
856 1024 KB in different units:
857
858 -XX:ThreadStackSize=1m
859 -XX:ThreadStackSize=1024k
860 -XX:ThreadStackSize=1048576
861
862 This option is equivalent to -Xss.
863
864 -XX:+TraceClassLoading
865 Enables tracing of classes as they are loaded. By default, this
866 option is disabled and classes are not traced.
867
868 -XX:+TraceClassLoadingPreorder
869 Enables tracing of all loaded classes in the order in which they
870 are referenced. By default, this option is disabled and classes are
871 not traced.
872
873 -XX:+TraceClassResolution
874 Enables tracing of constant pool resolutions. By default, this
875 option is disabled and constant pool resolutions are not traced.
876
877 -XX:+TraceClassUnloading
878 Enables tracing of classes as they are unloaded. By default, this
879 option is disabled and classes are not traced.
880
881 -XX:+TraceLoaderConstraints
882 Enables tracing of the loader constraints recording. By default,
883 this option is disabled and loader constraints recording is not
884 traced.
885
886 -XX:+UseAltSigs
887 Enables the use of alternative signals instead of SIGUSR1 and
888 SIGUSR2 for JVM internal signals. By default, this option is
889 disabled and alternative signals are not used. This option is
890 equivalent to -Xusealtsigs.
891
892 -XX:-UseBiasedLocking
893 Disables the use of biased locking. Some applications with
894 significant amounts of uncontended synchronization may attain
895 significant speedups with this flag enabled, whereas applications
896 with certain patterns of locking may see slowdowns. For more
897 information about the biased locking technique, see the example in
898 Java Tuning White Paper at
899 http://www.oracle.com/technetwork/java/tuning-139912.html#section4.2.5
900
901 By default, this option is enabled.
902
903 -XX:-UseCompressedOops
904 Disables the use of compressed pointers. By default, this option is
905 enabled, and compressed pointers are used when Java heap sizes are
906 less than 32 GB. When this option is enabled, object references are
907 represented as 32-bit offsets instead of 64-bit pointers, which
908 typically increases performance when running the application with
909 Java heap sizes less than 32 GB. This option works only for 64-bit
910 JVMs.
911
912 It is also possible to use compressed pointers when Java heap sizes
913 are greater than 32GB. See the -XX:ObjectAlignmentInBytes option.
914
915 -XX:+UseHugeTLBFS
916 This option for Linux is the equivalent of specifying
917 -XX:+UseLargePages. This option is disabled by default. This option
918 pre-allocates all large pages up-front, when memory is reserved;
919 consequently the JVM cannot dynamically grow or shrink large pages
920 memory areas; see -XX:UseTransparentHugePages if you want this
921 behavior.
922
923 For more information, see "Large Pages".
924
925 -XX:+UseLargePages
926 Enables the use of large page memory. By default, this option is
927 disabled and large page memory is not used.
928
929 For more information, see "Large Pages".
930
931 -XX:+UseMembar
932 Enables issuing of membars on thread state transitions. This option
933 is disabled by default on all platforms except ARM servers, where
934 it is enabled. (It is recommended that you do not disable this
935 option on ARM servers.)
936
937 -XX:+UsePerfData
938 Enables the perfdata feature. This option is enabled by default to
939 allow JVM monitoring and performance testing. Disabling it
940 suppresses the creation of the hsperfdata_userid directories. To
941 disable the perfdata feature, specify -XX:-UsePerfData.
942
943 -XX:+UseTransparentHugePages
944 On Linux, enables the use of large pages that can dynamically grow
945 or shrink. This option is disabled by default. You may encounter
946 performance problems with transparent huge pages as the OS moves
947 other pages around to create huge pages; this option is made
948 available for experimentation.
949
950 For more information, see "Large Pages".
951
952 -XX:+AllowUserSignalHandlers
953 Enables installation of signal handlers by the application. By
954 default, this option is disabled and the application is not allowed
955 to install signal handlers.
956
957 Advanced JIT Compiler Options
958 These options control the dynamic just-in-time (JIT) compilation
959 performed by the Java HotSpot VM.
960
961 -XX:+AggressiveOpts
962 Enables the use of aggressive performance optimization features,
963 which are expected to become default in upcoming releases. By
964 default, this option is disabled and experimental performance
965 features are not used.
966
967 -XX:AllocateInstancePrefetchLines=lines
968 Sets the number of lines to prefetch ahead of the instance
969 allocation pointer. By default, the number of lines to prefetch is
970 set to 1:
971
972 -XX:AllocateInstancePrefetchLines=1
973
974 Only the Java HotSpot Server VM supports this option.
975
976 -XX:AllocatePrefetchDistance=size
977 Sets the size (in bytes) of the prefetch distance for object
978 allocation. Memory about to be written with the value of new
979 objects is prefetched up to this distance starting from the address
980 of the last allocated object. Each Java thread has its own
981 allocation point.
982
983 Negative values denote that prefetch distance is chosen based on
984 the platform. Positive values are bytes to prefetch. Append the
985 letter k or K to indicate kilobytes, m or M to indicate megabytes,
986 g or G to indicate gigabytes. The default value is set to -1.
987
988 The following example shows how to set the prefetch distance to
989 1024 bytes:
990
991 -XX:AllocatePrefetchDistance=1024
992
993 Only the Java HotSpot Server VM supports this option.
994
995 -XX:AllocatePrefetchInstr=instruction
996 Sets the prefetch instruction to prefetch ahead of the allocation
997 pointer. Only the Java HotSpot Server VM supports this option.
998 Possible values are from 0 to 3. The actual instructions behind the
999 values depend on the platform. By default, the prefetch instruction
1000 is set to 0:
1001
1002 -XX:AllocatePrefetchInstr=0
1003
1004 Only the Java HotSpot Server VM supports this option.
1005
1006 -XX:AllocatePrefetchLines=lines
1007 Sets the number of cache lines to load after the last object
1008 allocation by using the prefetch instructions generated in compiled
1009 code. The default value is 1 if the last allocated object was an
1010 instance, and 3 if it was an array.
1011
1012 The following example shows how to set the number of loaded cache
1013 lines to 5:
1014
1015 -XX:AllocatePrefetchLines=5
1016
1017 Only the Java HotSpot Server VM supports this option.
1018
1019 -XX:AllocatePrefetchStepSize=size
1020 Sets the step size (in bytes) for sequential prefetch instructions.
1021 Append the letter k or K to indicate kilobytes, m or M to indicate
1022 megabytes, g or G to indicate gigabytes. By default, the step size
1023 is set to 16 bytes:
1024
1025 -XX:AllocatePrefetchStepSize=16
1026
1027 Only the Java HotSpot Server VM supports this option.
1028
1029 -XX:AllocatePrefetchStyle=style
1030 Sets the generated code style for prefetch instructions. The style
1031 argument is an integer from 0 to 3:
1032
1033 0
1034 Do not generate prefetch instructions.
1035
1036 1
1037 Execute prefetch instructions after each allocation. This is
1038 the default parameter.
1039
1040 2
1041 Use the thread-local allocation block (TLAB) watermark pointer
1042 to determine when prefetch instructions are executed.
1043
1044 3
1045 Use BIS instruction on SPARC for allocation prefetch.
1046
1047 Only the Java HotSpot Server VM supports this option.
1048
1049 -XX:+BackgroundCompilation
1050 Enables background compilation. This option is enabled by default.
1051 To disable background compilation, specify
1052 -XX:-BackgroundCompilation (this is equivalent to specifying
1053 -Xbatch).
1054
1055 -XX:CICompilerCount=threads
1056 Sets the number of compiler threads to use for compilation. By
1057 default, the number of threads is set to 2 for the server JVM, to 1
1058 for the client JVM, and it scales to the number of cores if tiered
1059 compilation is used. The following example shows how to set the
1060 number of threads to 2:
1061
1062 -XX:CICompilerCount=2
1063
1064
1065 -XX:CodeCacheMinimumFreeSpace=size
1066 Sets the minimum free space (in bytes) required for compilation.
1067 Append the letter k or K to indicate kilobytes, m or M to indicate
1068 megabytes, g or G to indicate gigabytes. When less than the minimum
1069 free space remains, compiling stops. By default, this option is set
1070 to 500 KB. The following example shows how to set the minimum free
1071 space to 1024 MB:
1072
1073 -XX:CodeCacheMinimumFreeSpace=1024m
1074
1075
1076 -XX:CompileCommand=command,method[,option]
1077 Specifies a command to perform on a method. For example, to exclude
1078 the indexOf() method of the String class from being compiled, use
1079 the following:
1080
1081 -XX:CompileCommand=exclude,java/lang/String.indexOf
1082
1083 Note that the full class name is specified, including all packages
1084 and subpackages separated by a slash (/). For easier cut and paste
1085 operations, it is also possible to use the method name format
1086 produced by the -XX:+PrintCompilation and -XX:+LogCompilation
1087 options:
1088
1089 -XX:CompileCommand=exclude,java.lang.String::indexOf
1090
1091 If the method is specified without the signature, the command will
1092 be applied to all methods with the specified name. However, you can
1093 also specify the signature of the method in the class file format.
1094 In this case, you should enclose the arguments in quotation marks,
1095 because otherwise the shell treats the semicolon as command end.
1096 For example, if you want to exclude only the indexOf(String) method
1097 of the String class from being compiled, use the following:
1098
1099 -XX:CompileCommand="exclude,java/lang/String.indexOf,(Ljava/lang/String;)I"
1100
1101 You can also use the asterisk (*) as a wildcard for class and
1102 method names. For example, to exclude all indexOf() methods in all
1103 classes from being compiled, use the following:
1104
1105 -XX:CompileCommand=exclude,*.indexOf
1106
1107 The commas and periods are aliases for spaces, making it easier to
1108 pass compiler commands through a shell. You can pass arguments to
1109 -XX:CompileCommand using spaces as separators by enclosing the
1110 argument in quotation marks:
1111
1112 -XX:CompileCommand="exclude java/lang/String indexOf"
1113
1114 Note that after parsing the commands passed on the command line
1115 using the -XX:CompileCommand options, the JIT compiler then reads
1116 commands from the .hotspot_compiler file. You can add commands to
1117 this file or specify a different file using the
1118 -XX:CompileCommandFile option.
1119
1120 To add several commands, either specify the -XX:CompileCommand
1121 option multiple times, or separate each argument with the newline
1122 separator (\n). The following commands are available:
1123
1124 break
1125 Set a breakpoint when debugging the JVM to stop at the
1126 beginning of compilation of the specified method.
1127
1128 compileonly
1129 Exclude all methods from compilation except for the specified
1130 method. As an alternative, you can use the -XX:CompileOnly
1131 option, which allows to specify several methods.
1132
1133 dontinline
1134 Prevent inlining of the specified method.
1135
1136 exclude
1137 Exclude the specified method from compilation.
1138
1139 help
1140 Print a help message for the -XX:CompileCommand option.
1141
1142 inline
1143 Attempt to inline the specified method.
1144
1145 log
1146 Exclude compilation logging (with the -XX:+LogCompilation
1147 option) for all methods except for the specified method. By
1148 default, logging is performed for all compiled methods.
1149
1150 option
1151 This command can be used to pass a JIT compilation option to
1152 the specified method in place of the last argument (option).
1153 The compilation option is set at the end, after the method
1154 name. For example, to enable the BlockLayoutByFrequency option
1155 for the append() method of the StringBuffer class, use the
1156 following:
1157
1158 -XX:CompileCommand=option,java/lang/StringBuffer.append,BlockLayoutByFrequency
1159
1160 You can specify multiple compilation options, separated by
1161 commas or spaces.
1162
1163 print
1164 Print generated assembler code after compilation of the
1165 specified method.
1166
1167 quiet
1168 Do not print the compile commands. By default, the commands
1169 that you specify with the -XX:CompileCommand option are
1170 printed; for example, if you exclude from compilation the
1171 indexOf() method of the String class, then the following will
1172 be printed to standard output:
1173
1174 CompilerOracle: exclude java/lang/String.indexOf
1175
1176 You can suppress this by specifying the
1177 -XX:CompileCommand=quiet option before other -XX:CompileCommand
1178 options.
1179
1180 -XX:CompileCommandFile=filename
1181 Sets the file from which JIT compiler commands are read. By
1182 default, the .hotspot_compiler file is used to store commands
1183 performed by the JIT compiler.
1184
1185 Each line in the command file represents a command, a class name,
1186 and a method name for which the command is used. For example, this
1187 line prints assembly code for the toString() method of the String
1188 class:
1189
1190 print java/lang/String toString
1191
1192 For more information about specifying the commands for the JIT
1193 compiler to perform on methods, see the -XX:CompileCommand option.
1194
1195 -XX:CompileOnly=methods
1196 Sets the list of methods (separated by commas) to which compilation
1197 should be restricted. Only the specified methods will be compiled.
1198 Specify each method with the full class name (including the
1199 packages and subpackages). For example, to compile only the
1200 length() method of the String class and the size() method of the
1201 List class, use the following:
1202
1203 -XX:CompileOnly=java/lang/String.length,java/util/List.size
1204
1205 Note that the full class name is specified, including all packages
1206 and subpackages separated by a slash (/). For easier cut and paste
1207 operations, it is also possible to use the method name format
1208 produced by the -XX:+PrintCompilation and -XX:+LogCompilation
1209 options:
1210
1211 -XX:CompileOnly=java.lang.String::length,java.util.List::size
1212
1213 Although wildcards are not supported, you can specify only the
1214 class or package name to compile all methods in that class or
1215 package, as well as specify just the method to compile methods with
1216 this name in any class:
1217
1218 -XX:CompileOnly=java/lang/String
1219 -XX:CompileOnly=java/lang
1220 -XX:CompileOnly=.length
1221
1222
1223 -XX:CompileThreshold=invocations
1224 Sets the number of interpreted method invocations before
1225 compilation. By default, in the server JVM, the JIT compiler
1226 performs 10,000 interpreted method invocations to gather
1227 information for efficient compilation. For the client JVM, the
1228 default setting is 1,500 invocations. This option is ignored when
1229 tiered compilation is enabled; see the option
1230 -XX:+TieredCompilation. The following example shows how to set the
1231 number of interpreted method invocations to 5,000:
1232
1233 -XX:CompileThreshold=5000
1234
1235 You can completely disable interpretation of Java methods before
1236 compilation by specifying the -Xcomp option.
1237
1238 -XX:+DoEscapeAnalysis
1239 Enables the use of escape analysis. This option is enabled by
1240 default. To disable the use of escape analysis, specify
1241 -XX:-DoEscapeAnalysis. Only the Java HotSpot Server VM supports
1242 this option.
1243
1244 -XX:InitialCodeCacheSize=size
1245 Sets the initial code cache size (in bytes). Append the letter k or
1246 K to indicate kilobytes, m or M to indicate megabytes, g or G to
1247 indicate gigabytes. The default value is set to 500 KB. The initial
1248 code cache size should be not less than the system's minimal memory
1249 page size. The following example shows how to set the initial code
1250 cache size to 32 KB:
1251
1252 -XX:InitialCodeCacheSize=32k
1253
1254
1255 -XX:+Inline
1256 Enables method inlining. This option is enabled by default to
1257 increase performance. To disable method inlining, specify
1258 -XX:-Inline.
1259
1260 -XX:InlineSmallCode=size
1261 Sets the maximum code size (in bytes) for compiled methods that
1262 should be inlined. Append the letter k or K to indicate kilobytes,
1263 m or M to indicate megabytes, g or G to indicate gigabytes. Only
1264 compiled methods with the size smaller than the specified size will
1265 be inlined. By default, the maximum code size is set to 1000 bytes:
1266
1267 -XX:InlineSmallCode=1000
1268
1269
1270 -XX:+LogCompilation
1271 Enables logging of compilation activity to a file named hotspot.log
1272 in the current working directory. You can specify a different log
1273 file path and name using the -XX:LogFile option.
1274
1275 By default, this option is disabled and compilation activity is not
1276 logged. The -XX:+LogCompilation option has to be used together with
1277 the -XX:UnlockDiagnosticVMOptions option that unlocks diagnostic
1278 JVM options.
1279
1280 You can enable verbose diagnostic output with a message printed to
1281 the console every time a method is compiled by using the
1282 -XX:+PrintCompilation option.
1283
1284 -XX:MaxInlineSize=size
1285 Sets the maximum bytecode size (in bytes) of a method to be
1286 inlined. Append the letter k or K to indicate kilobytes, m or M to
1287 indicate megabytes, g or G to indicate gigabytes. By default, the
1288 maximum bytecode size is set to 35 bytes:
1289
1290 -XX:MaxInlineSize=35
1291
1292
1293 -XX:MaxNodeLimit=nodes
1294 Sets the maximum number of nodes to be used during single method
1295 compilation. By default, the maximum number of nodes is set to
1296 65,000:
1297
1298 -XX:MaxNodeLimit=65000
1299
1300
1301 -XX:MaxTrivialSize=size
1302 Sets the maximum bytecode size (in bytes) of a trivial method to be
1303 inlined. Append the letter k or K to indicate kilobytes, m or M to
1304 indicate megabytes, g or G to indicate gigabytes. By default, the
1305 maximum bytecode size of a trivial method is set to 6 bytes:
1306
1307 -XX:MaxTrivialSize=6
1308
1309
1310 -XX:+OptimizeStringConcat
1311 Enables the optimization of String concatenation operations. This
1312 option is enabled by default. To disable the optimization of String
1313 concatenation operations, specify -XX:-OptimizeStringConcat. Only
1314 the Java HotSpot Server VM supports this option.
1315
1316 -XX:+PrintAssembly
1317 Enables printing of assembly code for bytecoded and native methods
1318 by using the external disassembler.so library. This enables you to
1319 see the generated code, which may help you to diagnose performance
1320 issues.
1321
1322 By default, this option is disabled and assembly code is not
1323 printed. The -XX:+PrintAssembly option has to be used together with
1324 the -XX:UnlockDiagnosticVMOptions option that unlocks diagnostic
1325 JVM options.
1326
1327 -XX:+PrintCompilation
1328 Enables verbose diagnostic output from the JVM by printing a
1329 message to the console every time a method is compiled. This
1330 enables you to see which methods actually get compiled. By default,
1331 this option is disabled and diagnostic output is not printed.
1332
1333 You can also log compilation activity to a file by using the
1334 -XX:+LogCompilation option.
1335
1336 -XX:+PrintInlining
1337 Enables printing of inlining decisions. This enables you to see
1338 which methods are getting inlined.
1339
1340 By default, this option is disabled and inlining information is not
1341 printed. The -XX:+PrintInlining option has to be used together with
1342 the -XX:+UnlockDiagnosticVMOptions option that unlocks diagnostic
1343 JVM options.
1344
1345 -XX:ReservedCodeCacheSize=size
1346 Sets the maximum code cache size (in bytes) for JIT-compiled code.
1347 Append the letter k or K to indicate kilobytes, m or M to indicate
1348 megabytes, g or G to indicate gigabytes. The default maximum code
1349 cache size is 240 MB; if you disable tiered compilation with the
1350 option -XX:-TieredCompilation, then the default size is 48 MB. This
1351 option has a limit of 2 GB; otherwise, an error is generated. The
1352 maximum code cache size should not be less than the initial code
1353 cache size; see the option -XX:InitialCodeCacheSize. This option is
1354 equivalent to -Xmaxjitcodesize.
1355
1356 -XX:RTMAbortRatio=abort_ratio
1357 The RTM abort ratio is specified as a percentage (%) of all
1358 executed RTM transactions. If a number of aborted transactions
1359 becomes greater than this ratio, then the compiled code will be
1360 deoptimized. This ratio is used when the -XX:+UseRTMDeopt option is
1361 enabled. The default value of this option is 50. This means that
1362 the compiled code will be deoptimized if 50% of all transactions
1363 are aborted.
1364
1365 -XX:RTMRetryCount=number_of_retries
1366 RTM locking code will be retried, when it is aborted or busy, the
1367 number of times specified by this option before falling back to the
1368 normal locking mechanism. The default value for this option is 5.
1369 The -XX:UseRTMLocking option must be enabled.
1370
1371 -XX:-TieredCompilation
1372 Disables the use of tiered compilation. By default, this option is
1373 enabled. Only the Java HotSpot Server VM supports this option.
1374
1375 -XX:+UseAES
1376 Enables hardware-based AES intrinsics for Intel, AMD, and SPARC
1377 hardware. Intel Westmere (2010 and newer), AMD Bulldozer (2011 and
1378 newer), and SPARC (T4 and newer) are the supported hardware. UseAES
1379 is used in conjunction with UseAESIntrinsics.
1380
1381 -XX:+UseAESIntrinsics
1382 UseAES and UseAESIntrinsics flags are enabled by default and are
1383 supported only for Java HotSpot Server VM 32-bit and 64-bit. To
1384 disable hardware-based AES intrinsics, specify -XX:-UseAES
1385 -XX:-UseAESIntrinsics. For example, to enable hardware AES, use the
1386 following flags:
1387
1388 -XX:+UseAES -XX:+UseAESIntrinsics
1389
1390 To support UseAES and UseAESIntrinsics flags for 32-bit and 64-bit
1391 use -server option to choose Java HotSpot Server VM. These flags
1392 are not supported on Client VM.
1393
1394 -XX:+UseCodeCacheFlushing
1395 Enables flushing of the code cache before shutting down the
1396 compiler. This option is enabled by default. To disable flushing of
1397 the code cache before shutting down the compiler, specify
1398 -XX:-UseCodeCacheFlushing.
1399
1400 -XX:+UseCondCardMark
1401 Enables checking of whether the card is already marked before
1402 updating the card table. This option is disabled by default and
1403 should only be used on machines with multiple sockets, where it
1404 will increase performance of Java applications that rely heavily on
1405 concurrent operations. Only the Java HotSpot Server VM supports
1406 this option.
1407
1408 -XX:+UseRTMDeopt
1409 Auto-tunes RTM locking depending on the abort ratio. This ratio is
1410 specified by -XX:RTMAbortRatio option. If the number of aborted
1411 transactions exceeds the abort ratio, then the method containing
1412 the lock will be deoptimized and recompiled with all locks as
1413 normal locks. This option is disabled by default. The
1414 -XX:+UseRTMLocking option must be enabled.
1415
1416 -XX:+UseRTMLocking
1417 Generate Restricted Transactional Memory (RTM) locking code for all
1418 inflated locks, with the normal locking mechanism as the fallback
1419 handler. This option is disabled by default. Options related to RTM
1420 are only available for the Java HotSpot Server VM on x86 CPUs that
1421 support Transactional Synchronization Extensions (TSX).
1422
1423 RTM is part of Intel's TSX, which is an x86 instruction set
1424 extension and facilitates the creation of multithreaded
1425 applications. RTM introduces the new instructions XBEGIN, XABORT,
1426 XEND, and XTEST. The XBEGIN and XEND instructions enclose a set of
1427 instructions to run as a transaction. If no conflict is found when
1428 running the transaction, the memory and register modifications are
1429 committed together at the XEND instruction. The XABORT instruction
1430 can be used to explicitly abort a transaction and the XEND
1431 instruction to check if a set of instructions are being run in a
1432 transaction.
1433
1434 A lock on a transaction is inflated when another thread tries to
1435 access the same transaction, thereby blocking the thread that did
1436 not originally request access to the transaction. RTM requires that
1437 a fallback set of operations be specified in case a transaction
1438 aborts or fails. An RTM lock is a lock that has been delegated to
1439 the TSX's system.
1440
1441 RTM improves performance for highly contended locks with low
1442 conflict in a critical region (which is code that must not be
1443 accessed by more than one thread concurrently). RTM also improves
1444 the performance of coarse-grain locking, which typically does not
1445 perform well in multithreaded applications. (Coarse-grain locking
1446 is the strategy of holding locks for long periods to minimize the
1447 overhead of taking and releasing locks, while fine-grained locking
1448 is the strategy of trying to achieve maximum parallelism by locking
1449 only when necessary and unlocking as soon as possible.) Also, for
1450 lightly contended locks that are used by different threads, RTM can
1451 reduce false cache line sharing, also known as cache line
1452 ping-pong. This occurs when multiple threads from different
1453 processors are accessing different resources, but the resources
1454 share the same cache line. As a result, the processors repeatedly
1455 invalidate the cache lines of other processors, which forces them
1456 to read from main memory instead of their cache.
1457
1458 -XX:+UseSHA
1459 Enables hardware-based intrinsics for SHA crypto hash functions for
1460 SPARC hardware. UseSHA is used in conjunction with the
1461 UseSHA1Intrinsics, UseSHA256Intrinsics, and UseSHA512Intrinsics
1462 options.
1463
1464 The UseSHA and UseSHA*Intrinsics flags are enabled by default, and
1465 are supported only for Java HotSpot Server VM 64-bit on SPARC T4
1466 and newer.
1467
1468 This feature is only applicable when using the
1469 sun.security.provider.Sun provider for SHA operations.
1470
1471 To disable all hardware-based SHA intrinsics, specify -XX:-UseSHA.
1472 To disable only a particular SHA intrinsic, use the appropriate
1473 corresponding option. For example: -XX:-UseSHA256Intrinsics.
1474
1475 -XX:+UseSHA1Intrinsics
1476 Enables intrinsics for SHA-1 crypto hash function.
1477
1478 -XX:+UseSHA256Intrinsics
1479 Enables intrinsics for SHA-224 and SHA-256 crypto hash functions.
1480
1481 -XX:+UseSHA512Intrinsics
1482 Enables intrinsics for SHA-384 and SHA-512 crypto hash functions.
1483
1484 -XX:+UseSuperWord
1485 Enables the transformation of scalar operations into superword
1486 operations. This option is enabled by default. To disable the
1487 transformation of scalar operations into superword operations,
1488 specify -XX:-UseSuperWord. Only the Java HotSpot Server VM supports
1489 this option.
1490
1491 Advanced Serviceability Options
1492 These options provide the ability to gather system information and
1493 perform extensive debugging.
1494
1495 -XX:+ExtendedDTraceProbes
1496 Enables additional dtrace tool probes that impact the performance.
1497 By default, this option is disabled and dtrace performs only
1498 standard probes.
1499
1500 -XX:+HeapDumpOnOutOfMemory
1501 Enables the dumping of the Java heap to a file in the current
1502 directory by using the heap profiler (HPROF) when a
1503 java.lang.OutOfMemoryError exception is thrown. You can explicitly
1504 set the heap dump file path and name using the -XX:HeapDumpPath
1505 option. By default, this option is disabled and the heap is not
1506 dumped when an OutOfMemoryError exception is thrown.
1507
1508 -XX:HeapDumpPath=path
1509 Sets the path and file name for writing the heap dump provided by
1510 the heap profiler (HPROF) when the -XX:+HeapDumpOnOutOfMemoryError
1511 option is set. By default, the file is created in the current
1512 working directory, and it is named java_pidpid.hprof where pid is
1513 the identifier of the process that caused the error. The following
1514 example shows how to set the default file explicitly (%p represents
1515 the current process identificator):
1516
1517 -XX:HeapDumpPath=./java_pid%p.hprof
1518
1519 The following example shows how to set the heap dump file to
1520 /var/log/java/java_heapdump.hprof:
1521
1522 -XX:HeapDumpPath=/var/log/java/java_heapdump.hprof
1523
1524
1525 -XX:LogFile=path
1526 Sets the path and file name where log data is written. By default,
1527 the file is created in the current working directory, and it is
1528 named hotspot.log.
1529
1530 The following example shows how to set the log file to
1531 /var/log/java/hotspot.log:
1532
1533 -XX:LogFile=/var/log/java/hotspot.log
1534
1535
1536 -XX:+PrintClassHistogram
1537 Enables printing of a class instance histogram after a Control+C
1538 event (SIGTERM). By default, this option is disabled.
1539
1540 Setting this option is equivalent to running the jmap -histo
1541 command, or the jcmd pid GC.class_histogram command, where pid is
1542 the current Java process identifier.
1543
1544 -XX:+PrintConcurrentLocks
1545 Enables printing of locks after a event. By default, this option is
1546 disabled.
1547
1548 Enables printing of java.util.concurrent locks after a Control+C
1549 event (SIGTERM). By default, this option is disabled.
1550
1551 Setting this option is equivalent to running the jstack -l command
1552 or the jcmd pid Thread.print -l command, where pid is the current
1553 Java process identifier.
1554
1555 -XX:+UnlockDiagnosticVMOptions
1556 Unlocks the options intended for diagnosing the JVM. By default,
1557 this option is disabled and diagnostic options are not available.
1558
1559 Advanced Garbage Collection Options
1560 These options control how garbage collection (GC) is performed by the
1561 Java HotSpot VM.
1562
1563 -XX:+AggressiveHeap
1564 Enables Java heap optimization. This sets various parameters to be
1565 optimal for long-running jobs with intensive memory allocation,
1566 based on the configuration of the computer (RAM and CPU). By
1567 default, the option is disabled and the heap is not optimized.
1568
1569 -XX:+AlwaysPreTouch
1570 Enables touching of every page on the Java heap during JVM
1571 initialization. This gets all pages into the memory before entering
1572 the main() method. The option can be used in testing to simulate a
1573 long-running system with all virtual memory mapped to physical
1574 memory. By default, this option is disabled and all pages are
1575 committed as JVM heap space fills.
1576
1577 -XX:+CMSClassUnloadingEnabled
1578 Enables class unloading when using the concurrent mark-sweep (CMS)
1579 garbage collector. This option is enabled by default. To disable
1580 class unloading for the CMS garbage collector, specify
1581 -XX:-CMSClassUnloadingEnabled.
1582
1583 -XX:CMSExpAvgFactor=percent
1584 Sets the percentage of time (0 to 100) used to weight the current
1585 sample when computing exponential averages for the concurrent
1586 collection statistics. By default, the exponential averages factor
1587 is set to 25%. The following example shows how to set the factor to
1588 15%:
1589
1590 -XX:CMSExpAvgFactor=15
1591
1592
1593 -XX:CMSInitiatingOccupancyFraction=percent
1594 Sets the percentage of the old generation occupancy (0 to 100) at
1595 which to start a CMS collection cycle. The default value is set to
1596 -1. Any negative value (including the default) implies that
1597 -XX:CMSTriggerRatio is used to define the value of the initiating
1598 occupancy fraction.
1599
1600 The following example shows how to set the occupancy fraction to
1601 20%:
1602
1603 -XX:CMSInitiatingOccupancyFraction=20
1604
1605
1606 -XX:+CMSScavengeBeforeRemark
1607 Enables scavenging attempts before the CMS remark step. By default,
1608 this option is disabled.
1609
1610 -XX:CMSTriggerRatio=percent
1611 Sets the percentage (0 to 100) of the value specified by
1612 -XX:MinHeapFreeRatio that is allocated before a CMS collection
1613 cycle commences. The default value is set to 80%.
1614
1615 The following example shows how to set the occupancy fraction to
1616 75%:
1617
1618 -XX:CMSTriggerRatio=75
1619
1620
1621 -XX:ConcGCThreads=threads
1622 Sets the number of threads used for concurrent GC. The default
1623 value depends on the number of CPUs available to the JVM.
1624
1625 For example, to set the number of threads for concurrent GC to 2,
1626 specify the following option:
1627
1628 -XX:ConcGCThreads=2
1629
1630
1631 -XX:+DisableExplicitGC
1632 Enables the option that disables processing of calls to
1633 System.gc(). This option is disabled by default, meaning that calls
1634 to System.gc() are processed. If processing of calls to System.gc()
1635 is disabled, the JVM still performs GC when necessary.
1636
1637 -XX:+ExplicitGCInvokesConcurrent
1638 Enables invoking of concurrent GC by using the System.gc() request.
1639 This option is disabled by default and can be enabled only together
1640 with the -XX:+UseConcMarkSweepGC option.
1641
1642 -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
1643 Enables invoking of concurrent GC by using the System.gc() request
1644 and unloading of classes during the concurrent GC cycle. This
1645 option is disabled by default and can be enabled only together with
1646 the -XX:+UseConcMarkSweepGC option.
1647
1648 -XX:G1HeapRegionSize=size
1649 Sets the size of the regions into which the Java heap is subdivided
1650 when using the garbage-first (G1) collector. The value can be
1651 between 1 MB and 32 MB. The default region size is determined
1652 ergonomically based on the heap size.
1653
1654 The following example shows how to set the size of the subdivisions
1655 to 16 MB:
1656
1657 -XX:G1HeapRegionSize=16m
1658
1659
1660 -XX:+G1PrintHeapRegions
1661 Enables the printing of information about which regions are
1662 allocated and which are reclaimed by the G1 collector. By default,
1663 this option is disabled.
1664
1665 -XX:G1ReservePercent=percent
1666 Sets the percentage of the heap (0 to 50) that is reserved as a
1667 false ceiling to reduce the possibility of promotion failure for
1668 the G1 collector. By default, this option is set to 10%.
1669
1670 The following example shows how to set the reserved heap to 20%:
1671
1672 -XX:G1ReservePercent=20
1673
1674
1675 -XX:InitialHeapSize=size
1676 Sets the initial size (in bytes) of the memory allocation pool.
1677 This value must be either 0, or a multiple of 1024 and greater than
1678 1 MB. Append the letter k or K to indicate kilobytes, m or M to
1679 indicate megabytes, g or G to indicate gigabytes. The default value
1680 is chosen at runtime based on system configuration. See the section
1681 "Ergonomics" in Java SE HotSpot Virtual Machine Garbage Collection
1682 Tuning Guide at
1683 http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/index.html.
1684
1685 The following examples show how to set the size of allocated memory
1686 to 6 MB using various units:
1687
1688 -XX:InitialHeapSize=6291456
1689 -XX:InitialHeapSize=6144k
1690 -XX:InitialHeapSize=6m
1691
1692 If you set this option to 0, then the initial size will be set as
1693 the sum of the sizes allocated for the old generation and the young
1694 generation. The size of the heap for the young generation can be
1695 set using the -XX:NewSize option.
1696
1697 -XX:InitialSurvivorRatio=ratio
1698 Sets the initial survivor space ratio used by the throughput
1699 garbage collector (which is enabled by the -XX:+UseParallelGC
1700 and/or -XX:+UseParallelOldGC options). Adaptive sizing is enabled
1701 by default with the throughput garbage collector by using the
1702 -XX:+UseParallelGC and -XX:+UseParallelOldGC options, and survivor
1703 space is resized according to the application behavior, starting
1704 with the initial value. If adaptive sizing is disabled (using the
1705 -XX:-UseAdaptiveSizePolicy option), then the -XX:SurvivorRatio
1706 option should be used to set the size of the survivor space for the
1707 entire execution of the application.
1708
1709 The following formula can be used to calculate the initial size of
1710 survivor space (S) based on the size of the young generation (Y),
1711 and the initial survivor space ratio (R):
1712
1713 S=Y/(R+2)
1714
1715 The 2 in the equation denotes two survivor spaces. The larger the
1716 value specified as the initial survivor space ratio, the smaller
1717 the initial survivor space size.
1718
1719 By default, the initial survivor space ratio is set to 8. If the
1720 default value for the young generation space size is used (2 MB),
1721 the initial size of the survivor space will be 0.2 MB.
1722
1723 The following example shows how to set the initial survivor space
1724 ratio to 4:
1725
1726 -XX:InitialSurvivorRatio=4
1727
1728
1729 -XX:InitiatingHeapOccupancyPercent=percent
1730 Sets the percentage of the heap occupancy (0 to 100) at which to
1731 start a concurrent GC cycle. It is used by garbage collectors that
1732 trigger a concurrent GC cycle based on the occupancy of the entire
1733 heap, not just one of the generations (for example, the G1 garbage
1734 collector).
1735
1736 By default, the initiating value is set to 45%. A value of 0
1737 implies nonstop GC cycles. The following example shows how to set
1738 the initiating heap occupancy to 75%:
1739
1740 -XX:InitiatingHeapOccupancyPercent=75
1741
1742
1743 -XX:MaxGCPauseMillis=time
1744 Sets a target for the maximum GC pause time (in milliseconds). This
1745 is a soft goal, and the JVM will make its best effort to achieve
1746 it. By default, there is no maximum pause time value.
1747
1748 The following example shows how to set the maximum target pause
1749 time to 500 ms:
1750
1751 -XX:MaxGCPauseMillis=500
1752
1753
1754 -XX:MaxHeapSize=size
1755 Sets the maximum size (in byes) of the memory allocation pool. This
1756 value must be a multiple of 1024 and greater than 2 MB. Append the
1757 letter k or K to indicate kilobytes, m or M to indicate megabytes,
1758 g or G to indicate gigabytes. The default value is chosen at
1759 runtime based on system configuration. For server deployments,
1760 -XX:InitialHeapSize and -XX:MaxHeapSize are often set to the same
1761 value. See the section "Ergonomics" in Java SE HotSpot Virtual
1762 Machine Garbage Collection Tuning Guide at
1763 http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/index.html.
1764
1765 The following examples show how to set the maximum allowed size of
1766 allocated memory to 80 MB using various units:
1767
1768 -XX:MaxHeapSize=83886080
1769 -XX:MaxHeapSize=81920k
1770 -XX:MaxHeapSize=80m
1771
1772 On Oracle Solaris 7 and Oracle Solaris 8 SPARC platforms, the upper
1773 limit for this value is approximately 4,000 MB minus overhead
1774 amounts. On Oracle Solaris 2.6 and x86 platforms, the upper limit
1775 is approximately 2,000 MB minus overhead amounts. On Linux
1776 platforms, the upper limit is approximately 2,000 MB minus overhead
1777 amounts.
1778
1779 The -XX:MaxHeapSize option is equivalent to -Xmx.
1780
1781 -XX:MaxHeapFreeRatio=percent
1782 Sets the maximum allowed percentage of free heap space (0 to 100)
1783 after a GC event. If free heap space expands above this value, then
1784 the heap will be shrunk. By default, this value is set to 70%.
1785
1786 The following example shows how to set the maximum free heap ratio
1787 to 75%:
1788
1789 -XX:MaxHeapFreeRatio=75
1790
1791
1792 -XX:MaxMetaspaceSize=size
1793 Sets the maximum amount of native memory that can be allocated for
1794 class metadata. By default, the size is not limited. The amount of
1795 metadata for an application depends on the application itself,
1796 other running applications, and the amount of memory available on
1797 the system.
1798
1799 The following example shows how to set the maximum class metadata
1800 size to 256 MB:
1801
1802 -XX:MaxMetaspaceSize=256m
1803
1804
1805 -XX:MaxNewSize=size
1806 Sets the maximum size (in bytes) of the heap for the young
1807 generation (nursery). The default value is set ergonomically.
1808
1809 -XX:MaxTenuringThreshold=threshold
1810 Sets the maximum tenuring threshold for use in adaptive GC sizing.
1811 The largest value is 15. The default value is 15 for the parallel
1812 (throughput) collector, and 6 for the CMS collector.
1813
1814 The following example shows how to set the maximum tenuring
1815 threshold to 10:
1816
1817 -XX:MaxTenuringThreshold=10
1818
1819
1820 -XX:MetaspaceSize=size
1821 Sets the size of the allocated class metadata space that will
1822 trigger a garbage collection the first time it is exceeded. This
1823 threshold for a garbage collection is increased or decreased
1824 depending on the amount of metadata used. The default size depends
1825 on the platform.
1826
1827 -XX:MinHeapFreeRatio=percent
1828 Sets the minimum allowed percentage of free heap space (0 to 100)
1829 after a GC event. If free heap space falls below this value, then
1830 the heap will be expanded. By default, this value is set to 40%.
1831
1832 The following example shows how to set the minimum free heap ratio
1833 to 25%:
1834
1835 -XX:MinHeapFreeRatio=25
1836
1837
1838 -XX:NewRatio=ratio
1839 Sets the ratio between young and old generation sizes. By default,
1840 this option is set to 2. The following example shows how to set the
1841 young/old ratio to 1:
1842
1843 -XX:NewRatio=1
1844
1845
1846 -XX:NewSize=size
1847 Sets the initial size (in bytes) of the heap for the young
1848 generation (nursery). Append the letter k or K to indicate
1849 kilobytes, m or M to indicate megabytes, g or G to indicate
1850 gigabytes.
1851
1852 The young generation region of the heap is used for new objects. GC
1853 is performed in this region more often than in other regions. If
1854 the size for the young generation is too low, then a large number
1855 of minor GCs will be performed. If the size is too high, then only
1856 full GCs will be performed, which can take a long time to complete.
1857 Oracle recommends that you keep the size for the young generation
1858 between a half and a quarter of the overall heap size.
1859
1860 The following examples show how to set the initial size of young
1861 generation to 256 MB using various units:
1862
1863 -XX:NewSize=256m
1864 -XX:NewSize=262144k
1865 -XX:NewSize=268435456
1866
1867 The -XX:NewSize option is equivalent to -Xmn.
1868
1869 -XX:ParallelGCThreads=threads
1870 Sets the number of threads used for parallel garbage collection in
1871 the young and old generations. The default value depends on the
1872 number of CPUs available to the JVM.
1873
1874 For example, to set the number of threads for parallel GC to 2,
1875 specify the following option:
1876
1877 -XX:ParallelGCThreads=2
1878
1879
1880 -XX:+ParallelRefProcEnabled
1881 Enables parallel reference processing. By default, this option is
1882 disabled.
1883
1884 -XX:+PrintAdaptiveSizePolicy
1885 Enables printing of information about adaptive generation sizing.
1886 By default, this option is disabled.
1887
1888 -XX:+PrintGC
1889 Enables printing of messages at every GC. By default, this option
1890 is disabled.
1891
1892 -XX:+PrintGCApplicationConcurrentTime
1893 Enables printing of how much time elapsed since the last pause (for
1894 example, a GC pause). By default, this option is disabled.
1895
1896 -XX:+PrintGCApplicationStoppedTime
1897 Enables printing of how much time the pause (for example, a GC
1898 pause) lasted. By default, this option is disabled.
1899
1900 -XX:+PrintGCDateStamps
1901 Enables printing of a date stamp at every GC. By default, this
1902 option is disabled.
1903
1904 -XX:+PrintGCDetails
1905 Enables printing of detailed messages at every GC. By default, this
1906 option is disabled.
1907
1908 -XX:+PrintGCTaskTimeStamps
1909 Enables printing of time stamps for every individual GC worker
1910 thread task. By default, this option is disabled.
1911
1912 -XX:+PrintGCTimeStamps
1913 Enables printing of time stamps at every GC. By default, this
1914 option is disabled.
1915
1916 -XX:+PrintStringDeduplicationStatistics
1917 Prints detailed deduplication statistics. By default, this option
1918 is disabled. See the -XX:+UseStringDeduplication option.
1919
1920 -XX:+PrintTenuringDistribution
1921 Enables printing of tenuring age information. The following is an
1922 example of the output:
1923
1924 Desired survivor size 48286924 bytes, new threshold 10 (max 10)
1925 - age 1: 28992024 bytes, 28992024 total
1926 - age 2: 1366864 bytes, 30358888 total
1927 - age 3: 1425912 bytes, 31784800 total
1928 ...
1929
1930 Age 1 objects are the youngest survivors (they were created after
1931 the previous scavenge, survived the latest scavenge, and moved from
1932 eden to survivor space). Age 2 objects have survived two scavenges
1933 (during the second scavenge they were copied from one survivor
1934 space to the next). And so on.
1935
1936 In the preceding example, 28 992 024 bytes survived one scavenge
1937 and were copied from eden to survivor space, 1 366 864 bytes are
1938 occupied by age 2 objects, etc. The third value in each row is the
1939 cumulative size of objects of age n or less.
1940
1941 By default, this option is disabled.
1942
1943 -XX:+ScavengeBeforeFullGC
1944 Enables GC of the young generation before each full GC. This option
1945 is enabled by default. Oracle recommends that you do not disable
1946 it, because scavenging the young generation before a full GC can
1947 reduce the number of objects reachable from the old generation
1948 space into the young generation space. To disable GC of the young
1949 generation before each full GC, specify -XX:-ScavengeBeforeFullGC.
1950
1951 -XX:SoftRefLRUPolicyMSPerMB=time
1952 Sets the amount of time (in milliseconds) a softly reachable object
1953 is kept active on the heap after the last time it was referenced.
1954 The default value is one second of lifetime per free megabyte in
1955 the heap. The -XX:SoftRefLRUPolicyMSPerMB option accepts integer
1956 values representing milliseconds per one megabyte of the current
1957 heap size (for Java HotSpot Client VM) or the maximum possible heap
1958 size (for Java HotSpot Server VM). This difference means that the
1959 Client VM tends to flush soft references rather than grow the heap,
1960 whereas the Server VM tends to grow the heap rather than flush soft
1961 references. In the latter case, the value of the -Xmx option has a
1962 significant effect on how quickly soft references are garbage
1963 collected.
1964
1965 The following example shows how to set the value to 2.5 seconds:
1966
1967 -XX:SoftRefLRUPolicyMSPerMB=2500
1968
1969
1970 -XX:StringDeduplicationAgeThreshold=threshold
1971 String objects reaching the specified age are considered candidates
1972 for deduplication. An object's age is a measure of how many times
1973 it has survived garbage collection. This is sometimes referred to
1974 as tenuring; see the -XX:+PrintTenuringDistribution option. Note
1975 that String objects that are promoted to an old heap region before
1976 this age has been reached are always considered candidates for
1977 deduplication. The default value for this option is 3. See the
1978 -XX:+UseStringDeduplication option.
1979
1980 -XX:SurvivorRatio=ratio
1981 Sets the ratio between eden space size and survivor space size. By
1982 default, this option is set to 8. The following example shows how
1983 to set the eden/survivor space ratio to 4:
1984
1985 -XX:SurvivorRatio=4
1986
1987
1988 -XX:TargetSurvivorRatio=percent
1989 Sets the desired percentage of survivor space (0 to 100) used after
1990 young garbage collection. By default, this option is set to 50%.
1991
1992 The following example shows how to set the target survivor space
1993 ratio to 30%:
1994
1995 -XX:TargetSurvivorRatio=30
1996
1997
1998 -XX:TLABSize=size
1999 Sets the initial size (in bytes) of a thread-local allocation
2000 buffer (TLAB). Append the letter k or K to indicate kilobytes, m or
2001 M to indicate megabytes, g or G to indicate gigabytes. If this
2002 option is set to 0, then the JVM chooses the initial size
2003 automatically.
2004
2005 The following example shows how to set the initial TLAB size to 512
2006 KB:
2007
2008 -XX:TLABSize=512k
2009
2010
2011 -XX:+UseAdaptiveSizePolicy
2012 Enables the use of adaptive generation sizing. This option is
2013 enabled by default. To disable adaptive generation sizing, specify
2014 -XX:-UseAdaptiveSizePolicy and set the size of the memory
2015 allocation pool explicitly (see the -XX:SurvivorRatio option).
2016
2017 -XX:+UseCMSInitiatingOccupancyOnly
2018 Enables the use of the occupancy value as the only criterion for
2019 initiating the CMS collector. By default, this option is disabled
2020 and other criteria may be used.
2021
2022 -XX:+UseConcMarkSweepGC
2023 Enables the use of the CMS garbage collector for the old
2024 generation. Oracle recommends that you use the CMS garbage
2025 collector when application latency requirements cannot be met by
2026 the throughput (-XX:+UseParallelGC) garbage collector. The G1
2027 garbage collector (-XX:+UseG1GC) is another alternative.
2028
2029 By default, this option is disabled and the collector is chosen
2030 automatically based on the configuration of the machine and type of
2031 the JVM. When this option is enabled, the -XX:+UseParNewGC option
2032 is automatically set and you should not disable it, because the
2033 following combination of options has been deprecated in JDK 8:
2034 -XX:+UseConcMarkSweepGC -XX:-UseParNewGC.
2035
2036 -XX:+UseG1GC
2037 Enables the use of the garbage-first (G1) garbage collector. It is
2038 a server-style garbage collector, targeted for multiprocessor
2039 machines with a large amount of RAM. It meets GC pause time goals
2040 with high probability, while maintaining good throughput. The G1
2041 collector is recommended for applications requiring large heaps
2042 (sizes of around 6 GB or larger) with limited GC latency
2043 requirements (stable and predictable pause time below 0.5 seconds).
2044
2045 By default, this option is disabled and the collector is chosen
2046 automatically based on the configuration of the machine and type of
2047 the JVM.
2048
2049 -XX:+UseGCOverheadLimit
2050 Enables the use of a policy that limits the proportion of time
2051 spent by the JVM on GC before an OutOfMemoryError exception is
2052 thrown. This option is enabled, by default and the parallel GC will
2053 throw an OutOfMemoryError if more than 98% of the total time is
2054 spent on garbage collection and less than 2% of the heap is
2055 recovered. When the heap is small, this feature can be used to
2056 prevent applications from running for long periods of time with
2057 little or no progress. To disable this option, specify
2058 -XX:-UseGCOverheadLimit.
2059
2060 -XX:+UseNUMA
2061 Enables performance optimization of an application on a machine
2062 with nonuniform memory architecture (NUMA) by increasing the
2063 application's use of lower latency memory. By default, this option
2064 is disabled and no optimization for NUMA is made. The option is
2065 only available when the parallel garbage collector is used
2066 (-XX:+UseParallelGC).
2067
2068 -XX:+UseParallelGC
2069 Enables the use of the parallel scavenge garbage collector (also
2070 known as the throughput collector) to improve the performance of
2071 your application by leveraging multiple processors.
2072
2073 By default, this option is disabled and the collector is chosen
2074 automatically based on the configuration of the machine and type of
2075 the JVM. If it is enabled, then the -XX:+UseParallelOldGC option is
2076 automatically enabled, unless you explicitly disable it.
2077
2078 -XX:+UseParallelOldGC
2079 Enables the use of the parallel garbage collector for full GCs. By
2080 default, this option is disabled. Enabling it automatically enables
2081 the -XX:+UseParallelGC option.
2082
2083 -XX:+UseParNewGC
2084 Enables the use of parallel threads for collection in the young
2085 generation. By default, this option is disabled. It is
2086 automatically enabled when you set the -XX:+UseConcMarkSweepGC
2087 option. Using the -XX:+UseParNewGC option without the
2088 -XX:+UseConcMarkSweepGC option was deprecated in JDK 8.
2089
2090 -XX:+UseSerialGC
2091 Enables the use of the serial garbage collector. This is generally
2092 the best choice for small and simple applications that do not
2093 require any special functionality from garbage collection. By
2094 default, this option is disabled and the collector is chosen
2095 automatically based on the configuration of the machine and type of
2096 the JVM.
2097
2098 -XX:+UseSHM
2099 On Linux, enables the JVM to use shared memory to setup large
2100 pages.
2101
2102 For more information, see "Large Pages".
2103
2104 -XX:+UseStringDeduplication
2105 Enables string deduplication. By default, this option is disabled.
2106 To use this option, you must enable the garbage-first (G1) garbage
2107 collector. See the -XX:+UseG1GC option.
2108
2109 String deduplication reduces the memory footprint of String objects
2110 on the Java heap by taking advantage of the fact that many String
2111 objects are identical. Instead of each String object pointing to
2112 its own character array, identical String objects can point to and
2113 share the same character array.
2114
2115 -XX:+UseTLAB
2116 Enables the use of thread-local allocation blocks (TLABs) in the
2117 young generation space. This option is enabled by default. To
2118 disable the use of TLABs, specify -XX:-UseTLAB.
2119
2120 Deprecated and Removed Options
2121 These options were included in the previous release, but have since
2122 been considered unnecessary.
2123
2124 -Xincgc
2125 Enables incremental garbage collection. This option was deprecated
2126 in JDK 8 with no replacement.
2127
2128 -Xrunlibname
2129 Loads the specified debugging/profiling library. This option was
2130 superseded by the -agentlib option.
2131
2132 -XX:CMSIncrementalDutyCycle=percent
2133 Sets the percentage of time (0 to 100) between minor collections
2134 that the concurrent collector is allowed to run. This option was
2135 deprecated in JDK 8 with no replacement, following the deprecation
2136 of the -XX:+CMSIncrementalMode option.
2137
2138 -XX:CMSIncrementalDutyCycleMin=percent
2139 Sets the percentage of time (0 to 100) between minor collections
2140 that is the lower bound for the duty cycle when
2141 -XX:+CMSIncrementalPacing is enabled. This option was deprecated in
2142 JDK 8 with no replacement, following the deprecation of the
2143 -XX:+CMSIncrementalMode option.
2144
2145 -XX:+CMSIncrementalMode
2146 Enables the incremental mode for the CMS collector. This option was
2147 deprecated in JDK 8 with no replacement, along with other options
2148 that start with CMSIncremental.
2149
2150 -XX:CMSIncrementalOffset=percent
2151 Sets the percentage of time (0 to 100) by which the incremental
2152 mode duty cycle is shifted to the right within the period between
2153 minor collections. This option was deprecated in JDK 8 with no
2154 replacement, following the deprecation of the
2155 -XX:+CMSIncrementalMode option.
2156
2157 -XX:+CMSIncrementalPacing
2158 Enables automatic adjustment of the incremental mode duty cycle
2159 based on statistics collected while the JVM is running. This option
2160 was deprecated in JDK 8 with no replacement, following the
2161 deprecation of the -XX:+CMSIncrementalMode option.
2162
2163 -XX:CMSIncrementalSafetyFactor=percent
2164 Sets the percentage of time (0 to 100) used to add conservatism
2165 when computing the duty cycle. This option was deprecated in JDK 8
2166 with no replacement, following the deprecation of the
2167 -XX:+CMSIncrementalMode option.
2168
2169 -XX:CMSInitiatingPermOccupancyFraction=percent
2170 Sets the percentage of the permanent generation occupancy (0 to
2171 100) at which to start a GC. This option was deprecated in JDK 8
2172 with no replacement.
2173
2174 -XX:MaxPermSize=size
2175 Sets the maximum permanent generation space size (in bytes). This
2176 option was deprecated in JDK 8, and superseded by the
2177 -XX:MaxMetaspaceSize option.
2178
2179 -XX:PermSize=size
2180 Sets the space (in bytes) allocated to the permanent generation
2181 that triggers a garbage collection if it is exceeded. This option
2182 was deprecated un JDK 8, and superseded by the -XX:MetaspaceSize
2183 option.
2184
2185 -XX:+UseSplitVerifier
2186 Enables splitting of the verification process. By default, this
2187 option was enabled in the previous releases, and verification was
2188 split into two phases: type referencing (performed by the compiler)
2189 and type checking (performed by the JVM runtime). This option was
2190 deprecated in JDK 8, and verification is now split by default
2191 without a way to disable it.
2192
2193 -XX:+UseStringCache
2194 Enables caching of commonly allocated strings. This option was
2195 removed from JDK 8 with no replacement.
2196
2198 The following examples show how to use experimental tuning flags to
2199 either optimize throughput or to provide lower response time.
2200
2201 Example 1 Tuning for Higher Throughput
2202
2203 java -d64 -server -XX:+AggressiveOpts -XX:+UseLargePages -Xmn10g -Xms26g -Xmx26g
2204
2205
2206 Example 2 Tuning for Lower Response Time
2207
2208 java -d64 -XX:+UseG1GC -Xms26g Xmx26g -XX:MaxGCPauseMillis=500 -XX:+PrintGCTimeStamp
2209
2210
2212 Also known as huge pages, large pages are memory pages that are
2213 significantly larger than the standard memory page size (which varies
2214 depending on the processor and operating system). Large pages optimize
2215 processor Translation-Lookaside Buffers.
2216
2217 A Translation-Lookaside Buffer (TLB) is a page translation cache that
2218 holds the most-recently used virtual-to-physical address translations.
2219 TLB is a scarce system resource. A TLB miss can be costly as the
2220 processor must then read from the hierarchical page table, which may
2221 require multiple memory accesses. By using a larger memory page size, a
2222 single TLB entry can represent a larger memory range. There will be
2223 less pressure on TLB, and memory-intensive applications may have better
2224 performance.
2225
2226 However, large pages page memory can negatively affect system
2227 performance. For example, when a large mount of memory is pinned by an
2228 application, it may create a shortage of regular memory and cause
2229 excessive paging in other applications and slow down the entire system.
2230 Also, a system that has been up for a long time could produce excessive
2231 fragmentation, which could make it impossible to reserve enough large
2232 page memory. When this happens, either the OS or JVM reverts to using
2233 regular pages.
2234
2235 Large Pages Support
2236 Solaris and Linux support large pages.
2237
2238 Solaris
2239 Solaris 9 and later include Multiple Page Size Support (MPSS); no
2240 additional configuration is necessary. See
2241 http://www.oracle.com/technetwork/server-storage/solaris10/overview/solaris9-features-scalability-135663.html.
2242
2243 Linux
2244 The 2.6 kernel supports large pages. Some vendors have backported
2245 the code to their 2.4-based releases. To check if your system can
2246 support large page memory, try the following:
2247
2248 # cat /proc/meminfo | grep Huge
2249 HugePages_Total: 0
2250 HugePages_Free: 0
2251 Hugepagesize: 2048 kB
2252
2253
2254 If the output shows the three "Huge" variables, then your system
2255 can support large page memory but it needs to be configured. If the
2256 command prints nothing, then your system does not support large
2257 pages. To configure the system to use large page memory, login as
2258 root, and then follow these steps:
2259
2260 1. If you are using the option -XX:+UseSHM (instead of
2261 -XX:+UseHugeTLBFS), then increase the SHMMAX value. It must be
2262 larger than the Java heap size. On a system with 4 GB of
2263 physical RAM (or less), the following will make all the memory
2264 sharable:
2265
2266 # echo 4294967295 > /proc/sys/kernel/shmmax
2267
2268
2269 2. If you are using the option -XX:+UseSHM or -XX:+UseHugeTLBFS,
2270 then specify the number of large pages. In the following
2271 example, 3 GB of a 4 GB system are reserved for large pages
2272 (assuming a large page size of 2048kB, then 3 GB = 3 * 1024 MB
2273 = 3072 MB = 3072 * 1024 kB = 3145728 kB and 3145728 kB / 2048
2274 kB = 1536):
2275
2276 # echo 1536 > /proc/sys/vm/nr_hugepages
2277
2278
2279 Note
2280 ┌──────────────────────────────────────────────┐
2281 │ │
2282 │ · Note that the values │
2283 │ contained in /proc │
2284 │ will reset after you │
2285 │ reboot your system, │
2286 │ so may want to set │
2287 │ them in an │
2288 │ initialization │
2289 │ script (for example, │
2290 │ rc.local or │
2291 │ sysctl.conf). │
2292 │ │
2293 │ · If you configure (or │
2294 │ resize) the OS │
2295 │ kernel parameters │
2296 │ /proc/sys/kernel/shmmax │
2297 │ or │
2298 │ /proc/sys/vm/nr_hugepages, │
2299 │ Java processes may │
2300 │ allocate large pages │
2301 │ for areas in │
2302 │ addition to the Java │
2303 │ heap. These steps │
2304 │ can allocate large │
2305 │ pages for the │
2306 │ following areas: │
2307 │ │
2308 │ · Java heap │
2309 │ │
2310 │ · Code cache │
2311 │ │
2312 │ · The marking │
2313 │ bitmap data │
2314 │ structure for │
2315 │ the parallel GC │
2316 │ │
2317 │ Consequently, if you │
2318 │ configure the │
2319 │ nr_hugepages │
2320 │ parameter to the │
2321 │ size of the Java │
2322 │ heap, then the JVM │
2323 │ can fail in │
2324 │ allocating the code │
2325 │ cache areas on large │
2326 │ pages because these │
2327 │ areas are quite │
2328 │ large in size. │
2329 └──────────────────────────────────────────────┘
2330
2332 The following exit values are typically returned by the launcher when
2333 the launcher is called with the wrong arguments, serious errors, or
2334 exceptions thrown by the JVM. However, a Java application may choose to
2335 return any value by using the API call System.exit(exitValue). The
2336 values are:
2337
2338 · 0: Successful completion
2339
2340 · >0: An error occurred
2341
2343 · javac(1)
2344
2345 · jdb(1)
2346
2347 · javah(1)
2348
2349 · jar(1)
2350
2351 · jstat(1)
2352
2353
2354
2355JDK 8 03 March 2015 java(1)