Java Parameters Matrix Table
|JVM Parameters||Enable?||References / Details|
|-XX:+UseG1GC||Enabled by default in Java 8u191+||Most important defaults specific to G1 and their default values.
Alternative: Shenandoah GC
|-XX:+UseShenandoahGC||Alternative to G1GC.||Shenandoah Garbage Collector: experimental in Java 8, newer than G1GC, available in some OpenJDK 8 and newer releases.
|-XX:+UseZGC||Yes (JDK 11+)||Z GC : Better Garbage Collector Algorithm than G1 or Shenandoah. JDK 11+ required.
The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector designed to meet the following goals:
· Pause times do not exceed 10ms (*)
· Pause times do not increase with the heap or live-set size
· Handle heaps ranging from a 8MB to 16TB in size
At a glance, ZGC is:
· Using colored pointers
· Using load barriers
At its core, ZGC is a concurrent garbage collector, meaning all heavy lifting work is done while Java threads continue to execute. This greatly limits the impact garbage collection will have on your application’s response time.
7 JVM Arguments of Highly Effective Applications
|-XX:MaxRAMPercentage||Yes||Java 8u191+ required.
The old (and somewhat broken) flags -XX:https://medium.com/adorsys/usecontainersupport-to-the-rescue-e77d6cfea712
|-XX:+UseContainerSupport||Enabled by default||Java 8u191+ required (enabled by default in Linux)
Please note that setting -Xmx and -Xms disables the automatic heap sizing.
# check if +UseContainerSupport is enabled
$ java -XX:+PrintFlagsFinal -version
|-XshowSettings:vm||Yes||This is a priceless feature to display all the settings of the JVM, together with -XX:+PrintCommandLineFlags it can show a world of hidden stuff.
|-XX:MaxRAMFraction||No (deprecated)||Requires JDK 8u131+
-XX:MaxRAMFraction deprecated since Java 8u191+ (use -XX:MaxRAMPercentage instead)
|-XX:+UseCGroupMemoryLimitForHeap||No (deprecated)||JDK 8u131+ required
Deprecated in Java10 & Java8u191+
Java memory management and configuration is still complex. Although the JVM can read cgroup memory limits and adapt memory usage accordingly since Java 9/8u131,
it’s not a golden bullet. You need to know what -XX:+UseCGroupMemoryLimitForHeap does and you need to fine tune some parameters for every deployment.
Otherwise you risk wasting resources and money or getting your containers killed at the worst time possible. -XX:MaxRAMFraction=1 is especially dangerous.
Java 10+ brings a lot of improvements but still needs manual configuration. To be safe, load test your stuff.
|Yes||When running a JVM in a docker container it is probably wise to use the HeapDumpOnOutOfMemoryError option so if you ever run out of memmory the jvm will write a dump of the heap to disk.
|-Xss||Test||Increase the thread’s stack size limit by passing the -Xss argument.
Each application will have tens, hundreds, thousands of threads. Each thread will have its own stack. Each one of them consumes memory.
If their consumption goes beyond a certain limit, then a StackOverflowError is thrown. More details about StackOverflowError and solutions to resolve it can be found in this article.
Linux 64-bit JVM Default thread stack size = 1024k
-Xss2m : This will set the thread’s stack size to 2mb
|Enable GC Logging||Check||JDK 8: -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1|