We have a job in our CI that kicks off our Java app and run some test (the test acts as a client to the app). The app is started with what I think is the correct JVM option to do continuous flight recording:
-XX:+UnlockCommercialFeatures -XX:+UnlockDiagnosticVMOptions -XX:+FlightRecorder -XX:FlightRecorderOptions=dumponexit=true,dumponexitpath=/tmp/application-flightRecorder.jfr -XX:StartFlightRecording=defaultrecording=true,settings=customSetting -XX:+DebugNonSafepoints
It is producing the JFR file fine, and I can open it in Java Mission Control. In addition to the JVM option above, we also have the option to enable GC logging:
-XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintFlagsFinal -XX:+PrintHeapAtGC -XX:+PrintReferenceGC -XX:+PrintTenuringDistribution -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 -XX:+LogVMOutput -XX:LogFile=/tmp/application-safepoint.log -Xloggc:/tmp/application-gc.log
Which is also fine. The gc log & safepoint log files are produced. However, I noticed that the GC stats in mission control doesnt list all the GCs that have occurred during the applciation lifetime. E.g. if I open the gc log using GCViewer (https://github.com/chewiebug/GCViewer), there is significantly more GCs happening.
Have I missed something here? Or does mission control only print "significant" gc ?
Thanks in advance!
JFR uses a ring buffer, so at some point events for old GCs are flushed out, but you should not get a gap.
I noticed that you use a custom JFC-file, could it be that you have disabled some GC events, for instance, young collections?
You may want to consider writing the recording to disk (disk=true) and set maxage=1h (or what you need) to ensure that old events are not flushed out.