From 5fdaf036262ea40f001623b79771bcef072a40e6 Mon Sep 17 00:00:00 2001 From: Mike Millson Date: Fri, 31 Mar 2017 16:17:29 -0400 Subject: [PATCH] Clarify heap initiated gc warning. --- src/main/resources/META-INF/analysis.properties | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/main/resources/META-INF/analysis.properties b/src/main/resources/META-INF/analysis.properties index 214065e0..221f4350 100644 --- a/src/main/resources/META-INF/analysis.properties +++ b/src/main/resources/META-INF/analysis.properties @@ -66,7 +66,7 @@ warn.fast.unordered.timestamps=Fast unordered timestamps are enabled with -XX:+U warn.g1.mixed.gc.live.thrshld.prcnt=The occupancy threshold for a region to be considered as a candidate region for a G1_CLEANUP collection is being specified with the -XX:G1MixedGCLiveThresholdPercent=NN (default 65% JDK7/JDK8 < u40, 85% JDK8u40+). Consider removing this experimental option unless there is a valid use case (e.g. JDK8 < u40: https://bugs.openjdk.java.net/browse/JDK-8059452), and testing has shown it does not introduce any issues. warn.gc.log.file.num.rotation.disabled=Number of GC log files is defined (-XX:NumberOfGCLogFiles), yet GC log file rotation is disabled. Either remove -XX:NumberOfGCLogFiles or enable GC log file rotation with -XX:+UseGCLogFileRotation. warn.gc.stopped.ratio=A significant amount of stopped time (>20%) is not GC related. Check for inverted parallelism, debugging enabled, or other JVM operations that require a safepoint: Deoptimization, PrintThreads, PrintJNI, FindDeadlock, ThreadDump, EnableBiasLocking, RevokeBias, HeapDumper, GetAllStackTrace. -warn.heap.dump.initiated.gc=A full garbage collection was initiated by a heap dump request. A heap dump significantly impacts JVM performance and should be limited to troubleshooting issues that require this heavyweight data. +warn.heap.dump.initiated.gc=A garbage collection was initiated by a heap dump specifying that only live objects be included (e.g. jmap -J-d64 -dump:live,format=b,file=heap.hprof ). A heap dump significantly impacts JVM performance as it requires the JVM to be at a safepoint (all threads stopped) and should be limited to troubleshooting issues that require this heavyweight data. If a heapdump is required, consider including both live and dead objects (e.g. jmap -J-d64 -dump:format=b,file=heap.hprof ) to avoid extra, unnecessary garbage collections. warn.heap.dump.on.oome.disabled=Remove -XX:-HeapDumpOnOutOfMemoryError and add -XX:+HeapDumpOnOutOfMemoryError instead (notice "+" vs. "-") for a heap dump to be generated when the first thread throws OutOfMemoryError. Generally this JVM argument should always be used, as it provides critical information in case of a memory error. warn.heap.dump.on.oome.missing=Add -XX:+HeapDumpOnOutOfMemoryError. This option does not impact performance (until the heap is actually written out); it is simply a flag to indicate that a heap dump should be generated when the first thread throws OutOfMemoryError. Generally this JVM argument should always be used, as it provides critical information in case of a memory error. warn.heap.inspection.initiated.gc=A tool such as Flight Recorder is initiating full garbage collections in order to monitor heap usage. If monitoring is excessive, it can significantly impact JVM performance (throughput).