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