Command Line Arguments

About

JVM (Java Virtual Machine) options are command-line arguments that modify the behavior of the JVM at runtime. They control memory management, garbage collection, performance tuning, debugging, and container-aware settings.

JVM options are passed when starting a Java application like this:

java [JVM_OPTIONS] -jar myapp.jar

For example:

java -Xms512m -Xmx1024m -XX:+UseG1GC -jar myapp.jar

Types of JVM Options

JVM options are classified into following categories:

1. Standard Options (-option)

These Options are supported across all Java versions. They are mostly for general settings like classpath and debugging.

Option	Description
-version	Prints Java version and exits.
-classpath or -cp	Specifies where to look for class files.
-Dproperty=value	Sets system properties.
-jar myapp.jar	Runs a JAR file.
-verbose	Prints debugging information.

Example:

java -Denv=production -jar myapp.jar

This sets a system property env=production that can be accessed in Java via:

System.getProperty("env");

2. Non-Standard Options (-Xoption)

Non-standard JVM options (-X options) are JVM-specific and may vary across different Java versions and JVM implementations (e.g., Oracle HotSpot, OpenJDK, GraalVM). These options are not guaranteed to remain consistent across JVM versions.

2.1 Memory Management Options

These options control the heap, stack, and garbage collection memory allocation.

Option	Description	Examples
-Xms<size>	Sets the initial heap size when JVM starts.	-Xms512m → 512MB initial heap. -Xms1g → 1GB initial heap.
-Xmx<size>	Sets the maximum heap size that JVM can use.	-Xmx2g → Max heap = 2GB. -Xmx4g → Max heap = 4GB.
-Xmn<size>	Sets Young Generation (Eden + Survivor spaces) size.	-Xmn512m → 512MB for Young Gen. -Xmn2g → 2GB for Young Gen.
-Xss<size>	Sets stack size per thread, affecting recursion depth.	-Xss256k → 256KB per thread. -Xss1m → 1MB per thread.
-Xnoclassgc	Disables class unloading, preventing JVM from reclaiming memory from unused classes.	-Xnoclassgc (Prevents unloading classes, useful for long-running apps).

Use Cases:

• High-performance apps → Use -Xms = -Xmx to prevent heap resizing overhead.

• Deep recursion (e.g., parsers, AI algorithms) → Increase -Xss to avoid StackOverflowError.

• Memory-intensive workloads → Tune -Xmn for GC efficiency.

2.2 Garbage Collection (GC) Tuning Options

These options optimize garbage collection algorithms and behavior.

Option	Description	Examples
-Xloggc:<file>	Logs GC events and pauses to a file.	-Xloggc:/var/logs/gc.log
-XX:+PrintGC	Prints basic GC info to console.	-XX:+PrintGC (Shows minor/major GC events).
-XX:+PrintGCDetails	Prints detailed GC logs, including memory usage before/after collection.	-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps	Adds timestamps to GC logs.	-XX:+PrintGCTimeStamps
-XX:+UseG1GC	Uses G1 Garbage Collector (default in Java 9+).	-XX:+UseG1GC
-XX:+UseParallelGC	Enables Parallel GC, useful for multi-core CPUs.	-XX:+UseParallelGC
-XX:+UseShenandoahGC	Enables Shenandoah GC, a low-pause GC.	-XX:+UseShenandoahGC

Use Cases:

• Large memory apps (4GB+) → Use -XX:+UseG1GC for predictable pause times.

• Multi-threaded apps → Use -XX:+UseParallelGC to leverage CPU cores.

• Low-latency apps (e.g., trading systems) → Use -XX:+UseShenandoahGC.

2.3 Class Loading & Verification

These options affect how Java loads and verifies classes.

Option	Description	Examples
-Xverify:none	Disables bytecode verification, reducing startup time.	-Xverify:none (Skips class verification, useful for trusted codebases).
-Xnoclassgc	Prevents class unloading from memory.	-Xnoclassgc (Useful for long-lived apps).
-Xbootclasspath:<path>	Specifies bootstrap classpath (higher priority than app classpath).	-Xbootclasspath:/libs/custom.jar
-Xfuture	Enables strict bytecode verification.	-Xfuture (Forcing strict checks on old bytecode).

Use Cases:

• Faster startup → -Xverify:none is useful for microservices.

• Custom JVM environments → -Xbootclasspath for overriding standard libraries.

2.4 Performance & Compilation Options

These options optimize Just-In-Time (JIT) compilation and execution speed.

Option	Description	Examples
-Xbatch	Forces compilation in the foreground (instead of background).	-Xbatch (Useful for benchmarking).
-Xcomp	Compiles all methods at startup using JIT.	-Xcomp (May increase startup time but speeds up execution).
-Xint	Runs in interpreter-only mode, disabling JIT.	-Xint (Slower execution, useful for debugging).
-Xmixed	Uses both interpreted and JIT execution (default mode).	-Xmixed (Balances startup and execution speed).

Use Cases:

• JIT tuning → Use -Xcomp for optimizing CPU-bound applications.

• Debugging → -Xint ensures consistent behavior without optimizations.

2.5 Debugging & Troubleshooting

These options help diagnose JVM crashes, memory leaks, and performance issues.

Option	Description	Examples
-Xdebug	Enables debugging mode(deprecated in Java 9+).	-Xdebug
-Xrunjdwp:<options>	Enables remote debuggingvia JDWP.	-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
-XX:+HeapDumpOnOutOfMemoryError	Dumps heap to analyze memory leaks.	-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=<file>	Specifies heap dump file location.	-XX:HeapDumpPath=/var/dumps/heap.hprof

Use Cases:

• Remote debugging → Use -Xrunjdwp to attach debuggers like IntelliJ or Eclipse.

• Memory analysis → Use -XX:+HeapDumpOnOutOfMemoryError with tools like Eclipse MAT.

2.6 Container-Specific Options

These JVM options are critical when running Java applications inside containers (Docker, Kubernetes, OpenShift). By default, JVM is not aware of container limits and may consume more memory or CPU than allowed, leading to OutOfMemoryErrors (OOMs) or performance issues.

Option	Description	Examples	Use Cases
-XX:+UseContainerSupport (Java 10+)	Enables container awareness, making JVM respect cgroups limits for CPU and memory. (Enabled by default in Java 11+)	-XX:+UseContainerSupport	Essential for all containerized apps to prevent JVM from exceeding allocated memory.
-XX:MaxRAMPercentage=<value> (Java 11+)	JVM sets heap memory as a percentage of total container memory instead of using fixed -Xmx values.	-XX:MaxRAMPercentage=75.0 → Uses 75% of container memory for heap.	Kubernetes/OpenShift apps → Automatically adjust heap based on container limits. Dynamic workloads → Adjust heap for autoscaling environments.
-XX:InitialRAMPercentage=<value>(Java 11+)	Sets initial heap size(-Xms) as a percentage of total container memory.	-XX:InitialRAMPercentage=50.0 → Allocates 50% of container memory at startup.	Cloud-native apps→ Ensures JVM starts with a reasonable heap size.
-XX:MinRAMPercentage=<value> (Java 11+)	Specifies the minimum heap allocation as a percentage of total RAM.	-XX:MinRAMPercentage=30.0 → Ensures at least 30% of RAM is used for heap.	Memory-sensitive apps → Ensures JVM doesn’t start with too little memory.
-XX:ActiveProcessorCount=<N> (Java 8+)	Manually sets the number of CPU coresthe JVM should use, overriding cgroups detection.	-XX:ActiveProcessorCount=2 → Restricts JVM to 2 CPU cores.	Multi-threaded apps → Ensures correct thread pool size inside containers.
-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap(Java 8 Update 191-251)	(Deprecated in Java 11+) Makes JVM respect container memory limits for heap calculations. (Replaced by -XX:MaxRAMPercentagein Java 11)	-XX:+UseCGroupMemoryLimitForHeap	For Java 8 users in containers who cannot upgrade to Java 11+.
-XX:+ExitOnOutOfMemoryError	Immediately terminates JVM when an OutOfMemoryErroroccurs (instead of continuing execution with errors).	-XX:+ExitOnOutOfMemoryError	Kubernetes/OpenShift→ Ensures the pod restarts when JVM runs out of memory instead of becoming unresponsive.
-XX:+CrashOnOutOfMemoryError	Generates a core dump and crashes the JVM when an OutOfMemoryErroroccurs.	-XX:+CrashOnOutOfMemoryError	Forensic analysis→ Useful for debugging memory leaks in production.
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=<path>	Dumps heap memoryto a file when JVM runs out of memory.	-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/dumps/heap.hprof	Post-mortem debugging → Analyze memory leaks using Eclipse MAT or VisualVM.
-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=<port>	Enables JMX monitoring for containers.	-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9010	Monitor JVM metrics inside Kubernetes/OpenShiftvia Prometheus/Grafana.
-XX:+AlwaysPreTouch	JVM pre-allocates heap memory upfront, reducing page faults.	-XX:+AlwaysPreTouch	High-performance apps → Reduces startup latency.