<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<reportcollection>
    <report>
        <file>allocation_10s_before.jfr</file>
        <rule>
            <id>Allocations.class</id>
            <severity>Information</severity>
            <summary>The most allocated type is likely ''java.lang.Integer'', most commonly allocated by: &lt;ul&gt;&lt;li&gt;Integer java.lang.Integer.valueOf(int)&lt;/li&gt;&lt;li&gt;void Allocator.go()&lt;/li&gt;&lt;li&gt;void Allocator.main(String[])&lt;/li&gt;&lt;/ul&gt;</summary>
            <explanation>Frequently allocated types are good places to start when trying to reduce garbage collections. Look at where the most common types are being allocated to see if many instances are created along the same call path. Try to reduce the number of instances created by invoking the most commonly taken paths less.</explanation>
        </rule>
        <rule>
            <id>Allocations.thread</id>
            <severity>Information</severity>
            <summary>The most allocations were likely done by thread ''main'' at: &lt;ul&gt;&lt;li&gt;Integer java.lang.Integer.valueOf(int)&lt;/li&gt;&lt;li&gt;void Allocator.go()&lt;/li&gt;&lt;li&gt;void Allocator.main(String[])&lt;/li&gt;&lt;/ul&gt;</summary>
            <explanation>Many allocations performed by the same thread might indicate a problem in a multi-threaded program. Look at the stack traces for the thread with the highest allocation rate. See if the allocation rate can be brought down, or balanced among the active threads.</explanation>
        </rule>
        <rule>
            <id>ApplicationHalts</id>
            <severity>OK</severity>
            <summary>Application efficiency was not highly affected by halts.</summary>
            <explanation>The highest ratio of application halts to execution time was 0.192 % during 4/26/2018 12:10:29.000 PM – 12:11:29 PM. 28.1 % of the halts were for reasons other than GC. The halts ratio for the entire recording was 1.16 %. 28.1 % of the total halts were for reasons other than GC.</explanation>
        </rule>
        <rule>
            <id>BufferLost</id>
            <severity>OK</severity>
            <summary>No Flight Recorder buffers were lost during the recording.</summary>
        </rule>
        <rule>
            <id>BytecodeVerification</id>
            <severity>OK</severity>
            <summary>The application ran with bytecode verification enabled.</summary>
        </rule>
        <rule>
            <id>ClassLeak</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ClassLoading</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CodeCache</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompareCpu</id>
            <severity>OK</severity>
            <summary>An average CPU load of 1 % was caused by other processes for during 4/26/2018 12:10:33.000 PM – 12:10:34 PM.</summary>
            <explanation>The application performance can be affected when the machine is under heavy load and there are other processes that use CPU or other resources on the same computer. To profile representatively or get higher throughput, shut down other resource intensive processes running on the machine.</explanation>
        </rule>
        <rule>
            <id>CompressedOops</id>
            <severity>OK</severity>
            <summary>The settings for Compressed Oops were OK.</summary>
        </rule>
        <rule>
            <id>ContextSwitch</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DMSIncident</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DebugNonSafepoints</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DiscouragedVmOptions</id>
            <severity>OK</severity>
            <summary>No problems were found with the VM options.</summary>
        </rule>
        <rule>
            <id>DumpReason</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DuplicateFlags</id>
            <severity>OK</severity>
            <summary>There were no duplicate JVM flags on the command line.</summary>
        </rule>
        <rule>
            <id>Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Exceptions</id>
            <severity>OK</severity>
            <summary>The program generated 0 exceptions per second during 4/26/2018 12:10:30.000 PM – 12:10:31 PM.</summary>
            <explanation>Throwing exceptions is more expensive than normal code execution, which means that they should only be used for exceptional situations. Investigate the thrown exceptions to see if any of them can be avoided with a non-exceptional control flow.</explanation>
        </rule>
        <rule>
            <id>Fatal Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FewSampledThreads</id>
            <severity>Information</severity>
            <summary>There are fewer sampled threads than the total number of hardware threads (cores).</summary>
            <explanation>1 threads with at least 4 method samples were found, but the machine has 32 hardware threads (cores). The application might benefit from a higher level of parallelism. This could also be caused by threads doing something else than running Java code, for example running native code or spending time in the JVM internals.</explanation>
        </rule>
        <rule>
            <id>FileRead</id>
            <severity>OK</severity>
            <summary>There are no file read events in this recording.</summary>
        </rule>
        <rule>
            <id>FileWrite</id>
            <severity>OK</severity>
            <summary>There are no file write events in this recording.</summary>
        </rule>
        <rule>
            <id>FlightRecordingSupport</id>
            <severity>OK</severity>
            <summary>The JVM version used for this recording has full Flight Recorder support.</summary>
        </rule>
        <rule>
            <id>JfrPeriodicEventsFix</id>
            <severity>OK</severity>
            <summary>The version of Java you are running is not affected by a performance issue related to periodic events.</summary>
        </rule>
        <rule>
            <id>FullGc</id>
            <severity>OK</severity>
            <summary>No Stop-the-World, Full GC events detected.</summary>
        </rule>
        <rule>
            <id>GarbageCollectionInfoRule</id>
            <severity>OK</severity>
        </rule>
        <rule>
            <id>GcFreedRatio</id>
            <severity>Information</severity>
            <summary>The ratio between memory freed by garbage collections per second and liveset is 6,501 %. This may be excessive.</summary>
            <explanation>242 MiB per second was freed by garbage collections during 4/26/2018 12:10:29.000 PM – 12:10:39 PM. The average liveset was 3.72 MiB. This may be excessive.
If the garbage collector can free a lot of memory, it may be because the application allocates a lot of short lived objects. Investigate the allocation stack traces to see which code paths cause the most allocations, and see if they can be reduced.
This recording is only 9.903 s long, consider creating a recording longer than 20 s for improved rule accuracy.</explanation>
        </rule>
        <rule>
            <id>GcLocker</id>
            <severity>OK</severity>
            <summary>No GCs were affected by the GC Locker.</summary>
        </rule>
        <rule>
            <id>GcOptions</id>
            <severity>OK</severity>
            <summary>No problems were found with the GC configuration.</summary>
        </rule>
        <rule>
            <id>GcPauseRatio</id>
            <severity>OK</severity>
            <summary>Application efficiency was not highly affected by GC pauses.</summary>
            <explanation>The highest ratio between garbage collection pauses and execution time was 0.138 % during 4/26/2018 12:10:29.000 PM – 12:11:29 PM. The garbage collection pause ratio of the entire recording was 0.836 %.</explanation>
            <solution>Pause times may be reduced by increasing the heap size or by trying to reduce allocation.</solution>
        </rule>
        <rule>
            <id>GcStall</id>
            <severity>OK</severity>
            <summary>No indications that the garbage collector could not keep up with the workload were detected.</summary>
        </rule>
        <rule>
            <id>HeapContent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapDump</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapInspectionGc</id>
            <severity>OK</severity>
            <summary>The JVM did not perform any heap inspection GCs.</summary>
            <explanation>This is good since they usually take a lot of time.</explanation>
        </rule>
        <rule>
            <id>HighGc</id>
            <severity>OK</severity>
            <summary>The JVM was paused for 100 % during 4/26/2018 12:10:36.933.000 PM – .944</summary>
            <explanation>The time spent performing garbage collection may be reduced by increasing the heap size or by trying to reduce allocation.</explanation>
        </rule>
        <rule>
            <id>HighJvmCpu</id>
            <severity>OK</severity>
            <summary>The JVM does not seem to cause a lot of CPU load.</summary>
        </rule>
        <rule>
            <id>IncreasingLiveSet</id>
            <severity>OK</severity>
            <summary>No memory leaks were detected.</summary>
        </rule>
        <rule>
            <id>IncreasingMetaSpaceLiveSet</id>
            <severity>OK</severity>
            <summary>The class data does not seem to increase during the recording.</summary>
        </rule>
        <rule>
            <id>JavaBlocking</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LongGcPause</id>
            <severity>OK</severity>
            <summary>The longest GC pause was 11.003 ms.</summary>
            <explanation/>
        </rule>
        <rule>
            <id>LowOnPhysicalMemory</id>
            <severity>OK</severity>
            <summary>The system did not run low on physical memory during this recording.</summary>
        </rule>
        <rule>
            <id>ManagementAgent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ManyRunningProcesses</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>MetaspaceOom</id>
            <severity>OK</severity>
            <summary>The metaspace was not exhausted during this recording.</summary>
        </rule>
        <rule>
            <id>MethodProfiling</id>
            <severity>OK</severity>
            <summary>No methods where optimization would be particularly efficient could be detected.</summary>
        </rule>
        <rule>
            <id>Options</id>
            <severity>OK</severity>
            <summary>No undocumented, deprecated or non-recommended option flags were detected.</summary>
        </rule>
        <rule>
            <id>OverAggressiveRecordingSetting</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInArguments</id>
            <severity>OK</severity>
            <summary>The recording does not seem to contain passwords in the application arguments.</summary>
        </rule>
        <rule>
            <id>PasswordsInEnvironment</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInSystemProperties</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PrimitiveToObjectConversion</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ProcessStarted</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketRead</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketWrite</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>StackdepthSetting</id>
            <severity>OK</severity>
            <summary>No stack traces were truncated in this recording.</summary>
        </rule>
        <rule>
            <id>StringDeduplication</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SystemGc</id>
            <severity>OK</severity>
            <summary>No garbage collections were caused by System.gc().</summary>
        </rule>
        <rule>
            <id>TlabAllocationRatio</id>
            <severity>OK</severity>
            <summary>No object allocations outside of TLABs detected.</summary>
        </rule>
        <rule>
            <id>VMOperations</id>
            <severity>OK</severity>
            <summary>No excessively long VM operations were found in this recording (the longest was 30.318 ms).</summary>
        </rule>
        <rule>
            <id>biasedLockingRevocation</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>biasedLockingRevocationPause</id>
            <severity>OK</severity>
            <summary>No revocation of biased locks found.</summary>
        </rule>
    </report>
    <report>
        <file>allocation_10s_fixed.jfr</file>
        <rule>
            <id>Allocations.class</id>
            <severity>OK</severity>
            <summary>The most allocated type is likely ''java.util.HashMap$ValueIterator'', most commonly allocated by: &lt;ul&gt;&lt;li&gt;Iterator java.util.HashMap$Values.iterator()&lt;/li&gt;&lt;li&gt;void Allocator.go()&lt;/li&gt;&lt;li&gt;void Allocator.main(String[])&lt;/li&gt;&lt;/ul&gt;</summary>
            <explanation>Frequently allocated types are good places to start when trying to reduce garbage collections. Look at where the most common types are being allocated to see if many instances are created along the same call path. Try to reduce the number of instances created by invoking the most commonly taken paths less.</explanation>
        </rule>
        <rule>
            <id>Allocations.thread</id>
            <severity>OK</severity>
            <summary>The most allocations were likely done by thread ''main'' at: &lt;ul&gt;&lt;li&gt;Iterator java.util.HashMap$Values.iterator()&lt;/li&gt;&lt;li&gt;void Allocator.go()&lt;/li&gt;&lt;li&gt;void Allocator.main(String[])&lt;/li&gt;&lt;/ul&gt;</summary>
            <explanation>Many allocations performed by the same thread might indicate a problem in a multi-threaded program. Look at the stack traces for the thread with the highest allocation rate. See if the allocation rate can be brought down, or balanced among the active threads.</explanation>
        </rule>
        <rule>
            <id>ApplicationHalts</id>
            <severity>OK</severity>
            <summary>Application efficiency was not highly affected by halts.</summary>
            <explanation>The highest ratio of application halts to execution time was 0.0309 % during 4/26/2018 12:12:46.000 PM – 12:13:46 PM. 100 % of the halts were for reasons other than GC. The halts ratio for the entire recording was 0.187 %. 100 % of the total halts were for reasons other than GC.</explanation>
        </rule>
        <rule>
            <id>BufferLost</id>
            <severity>OK</severity>
            <summary>No Flight Recorder buffers were lost during the recording.</summary>
        </rule>
        <rule>
            <id>BytecodeVerification</id>
            <severity>OK</severity>
            <summary>The application ran with bytecode verification enabled.</summary>
        </rule>
        <rule>
            <id>ClassLeak</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ClassLoading</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CodeCache</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompareCpu</id>
            <severity>OK</severity>
            <summary>An average CPU load of 7 % was caused by other processes for during 4/26/2018 12:12:47.000 PM – 12:12:48 PM.</summary>
            <explanation>The application performance can be affected when the machine is under heavy load and there are other processes that use CPU or other resources on the same computer. To profile representatively or get higher throughput, shut down other resource intensive processes running on the machine.</explanation>
        </rule>
        <rule>
            <id>CompressedOops</id>
            <severity>OK</severity>
            <summary>The settings for Compressed Oops were OK.</summary>
        </rule>
        <rule>
            <id>ContextSwitch</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DMSIncident</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DebugNonSafepoints</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DiscouragedVmOptions</id>
            <severity>OK</severity>
            <summary>No problems were found with the VM options.</summary>
        </rule>
        <rule>
            <id>DumpReason</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DuplicateFlags</id>
            <severity>OK</severity>
            <summary>There were no duplicate JVM flags on the command line.</summary>
        </rule>
        <rule>
            <id>Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Exceptions</id>
            <severity>OK</severity>
            <summary>The program generated 0 exceptions per second during 4/26/2018 12:12:47.000 PM – 12:12:48 PM.</summary>
            <explanation>Throwing exceptions is more expensive than normal code execution, which means that they should only be used for exceptional situations. Investigate the thrown exceptions to see if any of them can be avoided with a non-exceptional control flow.</explanation>
        </rule>
        <rule>
            <id>Fatal Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FewSampledThreads</id>
            <severity>Information</severity>
            <summary>There are fewer sampled threads than the total number of hardware threads (cores).</summary>
            <explanation>1 threads with at least 4 method samples were found, but the machine has 32 hardware threads (cores). The application might benefit from a higher level of parallelism. This could also be caused by threads doing something else than running Java code, for example running native code or spending time in the JVM internals.</explanation>
        </rule>
        <rule>
            <id>FileRead</id>
            <severity>OK</severity>
            <summary>There are no file read events in this recording.</summary>
        </rule>
        <rule>
            <id>FileWrite</id>
            <severity>OK</severity>
            <summary>There are no file write events in this recording.</summary>
        </rule>
        <rule>
            <id>FlightRecordingSupport</id>
            <severity>OK</severity>
            <summary>The JVM version used for this recording has full Flight Recorder support.</summary>
        </rule>
        <rule>
            <id>JfrPeriodicEventsFix</id>
            <severity>OK</severity>
            <summary>The version of Java you are running is not affected by a performance issue related to periodic events.</summary>
        </rule>
        <rule>
            <id>FullGc</id>
            <severity>OK</severity>
            <summary>No Stop-the-World, Full GC events detected.</summary>
        </rule>
        <rule>
            <id>GarbageCollectionInfoRule</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcFreedRatio</id>
            <severity>OK</severity>
            <summary>Only 0 heap summary events were found, this rule requires at least 10 events to be able to calculate a relevant result. This likely means that only a few garbage collections occurred during the recording. Having few garbage collections is generally a good sign.</summary>
        </rule>
        <rule>
            <id>GcOptions</id>
            <severity>OK</severity>
            <summary>No problems were found with the GC configuration.</summary>
        </rule>
        <rule>
            <id>GcPauseRatio</id>
            <severity>OK</severity>
            <summary>Application efficiency was not highly affected by GC pauses.</summary>
            <explanation>The highest ratio between garbage collection pauses and execution time was 0 % during 4/26/2018 12:12:46.000 PM – 12:13:46 PM. The garbage collection pause ratio of the entire recording was 0 %.</explanation>
            <solution>Pause times may be reduced by increasing the heap size or by trying to reduce allocation.</solution>
        </rule>
        <rule>
            <id>HeapContent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapDump</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HighGc</id>
            <severity>OK</severity>
            <summary>The runtime did not spend much time performing garbage collections.</summary>
        </rule>
        <rule>
            <id>HighJvmCpu</id>
            <severity>OK</severity>
            <summary>The JVM does not seem to cause a lot of CPU load.</summary>
        </rule>
        <rule>
            <id>IncreasingLiveSet</id>
            <severity>Not Applicable</severity>
            <summary>Too few events to calculate the result.</summary>
        </rule>
        <rule>
            <id>IncreasingMetaSpaceLiveSet</id>
            <severity>OK</severity>
            <summary>The class data does not seem to increase during the recording.</summary>
        </rule>
        <rule>
            <id>JavaBlocking</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LongGcPause</id>
            <severity>OK</severity>
            <summary>The application did not cause any long GC pause times.</summary>
        </rule>
        <rule>
            <id>LowOnPhysicalMemory</id>
            <severity>OK</severity>
            <summary>The system did not run low on physical memory during this recording.</summary>
        </rule>
        <rule>
            <id>ManagementAgent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ManyRunningProcesses</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>MetaspaceOom</id>
            <severity>OK</severity>
            <summary>The metaspace was not exhausted during this recording.</summary>
        </rule>
        <rule>
            <id>MethodProfiling</id>
            <severity>OK</severity>
            <summary>No methods where optimization would be particularly efficient could be detected.</summary>
        </rule>
        <rule>
            <id>Options</id>
            <severity>OK</severity>
            <summary>No undocumented, deprecated or non-recommended option flags were detected.</summary>
        </rule>
        <rule>
            <id>OverAggressiveRecordingSetting</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInArguments</id>
            <severity>OK</severity>
            <summary>The recording does not seem to contain passwords in the application arguments.</summary>
        </rule>
        <rule>
            <id>PasswordsInEnvironment</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInSystemProperties</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PrimitiveToObjectConversion</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ProcessStarted</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketRead</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketWrite</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>StackdepthSetting</id>
            <severity>OK</severity>
            <summary>No stack traces were truncated in this recording.</summary>
        </rule>
        <rule>
            <id>StringDeduplication</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>TlabAllocationRatio</id>
            <severity>OK</severity>
            <summary>No object allocations outside of TLABs detected.</summary>
        </rule>
        <rule>
            <id>VMOperations</id>
            <severity>OK</severity>
            <summary>No excessively long VM operations were found in this recording (the longest was 17.957 ms).</summary>
        </rule>
        <rule>
            <id>biasedLockingRevocation</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>biasedLockingRevocationPause</id>
            <severity>OK</severity>
            <summary>No revocation of biased locks found.</summary>
        </rule>
    </report>
    <report>
        <file>crash_jdk9.jfr</file>
        <rule>
            <id>Allocations.class</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Allocations.thread</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ApplicationHalts</id>
            <severity>OK</severity>
            <summary>Application efficiency was not highly affected by halts.</summary>
            <explanation>The highest ratio of application halts to execution time was 0 % during 4/24/2018 10:16:27.000 AM – 10:17:27 AM. 0 % of the halts were for reasons other than GC. The halts ratio for the entire recording was 0 %. 0 % of the total halts were for reasons other than GC.</explanation>
        </rule>
        <rule>
            <id>BufferLost</id>
            <severity>OK</severity>
            <summary>No Flight Recorder buffers were lost during the recording.</summary>
        </rule>
        <rule>
            <id>BytecodeVerification</id>
            <severity>OK</severity>
            <summary>The application ran with bytecode verification enabled.</summary>
        </rule>
        <rule>
            <id>ClassLeak</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ClassLoading</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CodeCache</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompareCpu</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompressedOops</id>
            <severity>OK</severity>
            <summary>The settings for Compressed Oops were OK.</summary>
        </rule>
        <rule>
            <id>ContextSwitch</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DMSIncident</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DebugNonSafepoints</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DiscouragedVmOptions</id>
            <severity>OK</severity>
            <summary>No problems were found with the VM options.</summary>
        </rule>
        <rule>
            <id>DumpReason</id>
            <severity>Warning</severity>
            <summary>This recording was dumped for an exceptional reason.</summary>
            <explanation>Recording was dumped due to a JVM crash. Some events are likely missing from the end of the recording.</explanation>
        </rule>
        <rule>
            <id>DuplicateFlags</id>
            <severity>OK</severity>
            <summary>There were no duplicate JVM flags on the command line.</summary>
        </rule>
        <rule>
            <id>Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Exceptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Fatal Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FewSampledThreads</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FileRead</id>
            <severity>OK</severity>
            <summary>There are no file read events in this recording.</summary>
        </rule>
        <rule>
            <id>FileWrite</id>
            <severity>OK</severity>
            <summary>There are no file write events in this recording.</summary>
        </rule>
        <rule>
            <id>FlightRecordingSupport</id>
            <severity>OK</severity>
            <summary>The JVM version used for this recording has full Flight Recorder support.</summary>
        </rule>
        <rule>
            <id>JfrPeriodicEventsFix</id>
            <severity>OK</severity>
            <summary>The version of Java you are running is not affected by a performance issue related to periodic events.</summary>
        </rule>
        <rule>
            <id>FullGc</id>
            <severity>OK</severity>
            <summary>No Stop-the-World, Full GC events detected.</summary>
        </rule>
        <rule>
            <id>GarbageCollectionInfoRule</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcFreedRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcOptions</id>
            <severity>OK</severity>
            <summary>No problems were found with the GC configuration.</summary>
        </rule>
        <rule>
            <id>GcPauseRatio</id>
            <severity>OK</severity>
            <summary>Application efficiency was not highly affected by GC pauses.</summary>
            <explanation>The highest ratio between garbage collection pauses and execution time was 0 % during 4/24/2018 10:16:27.000 AM – 10:17:27 AM. The garbage collection pause ratio of the entire recording was 0 %.</explanation>
            <solution>Pause times may be reduced by increasing the heap size or by trying to reduce allocation.</solution>
        </rule>
        <rule>
            <id>HeapContent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapDump</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HighGc</id>
            <severity>OK</severity>
            <summary>The runtime did not spend much time performing garbage collections.</summary>
        </rule>
        <rule>
            <id>HighJvmCpu</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>IncreasingLiveSet</id>
            <severity>Not Applicable</severity>
            <summary>Too few events to calculate the result.</summary>
        </rule>
        <rule>
            <id>IncreasingMetaSpaceLiveSet</id>
            <severity>OK</severity>
            <summary>The class data does not seem to increase during the recording.</summary>
        </rule>
        <rule>
            <id>JavaBlocking</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LongGcPause</id>
            <severity>OK</severity>
            <summary>The application did not cause any long GC pause times.</summary>
        </rule>
        <rule>
            <id>LowOnPhysicalMemory</id>
            <severity>Information</severity>
            <summary>The maximum amount of used memory was 88.9 % of the physical memory available.</summary>
            <explanation>The maximum amount of memory used was 28.4 GiB. This is 88.9 % of the 31.9 GiB of physical memory available. Having little free memory may lead to swapping, which is very expensive. To avoid this, either decrease the memory usage or increase the amount of available memory.</explanation>
        </rule>
        <rule>
            <id>ManagementAgent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ManyRunningProcesses</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>MetaspaceOom</id>
            <severity>OK</severity>
            <summary>The metaspace was not exhausted during this recording.</summary>
        </rule>
        <rule>
            <id>MethodProfiling</id>
            <severity>OK</severity>
            <summary>No methods where optimization would be particularly efficient could be detected.</summary>
        </rule>
        <rule>
            <id>Options</id>
            <severity>OK</severity>
            <summary>No undocumented, deprecated or non-recommended option flags were detected.</summary>
        </rule>
        <rule>
            <id>OverAggressiveRecordingSetting</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInArguments</id>
            <severity>OK</severity>
            <summary>The recording does not seem to contain passwords in the application arguments.</summary>
        </rule>
        <rule>
            <id>PasswordsInEnvironment</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInSystemProperties</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PrimitiveToObjectConversion</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ProcessStarted</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketRead</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketWrite</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>StackdepthSetting</id>
            <severity>OK</severity>
            <summary>No stack traces were truncated in this recording.</summary>
        </rule>
        <rule>
            <id>StringDeduplication</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>TlabAllocationRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>VMOperations</id>
            <severity>OK</severity>
            <summary>No excessively long VM operations were found in this recording (the longest was 0 s).</summary>
        </rule>
        <rule>
            <id>biasedLockingRevocation</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>biasedLockingRevocationPause</id>
            <severity>OK</severity>
            <summary>No revocation of biased locks found.</summary>
        </rule>
    </report>
    <report>
        <file>flight_recording_hidden.jfr</file>
        <rule>
            <id>Allocations.class</id>
            <severity>OK</severity>
            <summary>The most allocated type is likely ''byte[]'', most commonly allocated by: &lt;ul&gt;&lt;li&gt;void java.io.ByteArrayOutputStream.&amp;lt;init&amp;gt;(int)&lt;/li&gt;&lt;li&gt;void java.io.ByteArrayOutputStream.&amp;lt;init&amp;gt;()&lt;/li&gt;&lt;li&gt;void sun.management.jdp.JdpPacketWriter.&amp;lt;init&amp;gt;()&lt;/li&gt;&lt;li&gt;byte[] sun.management.jdp.JdpJmxPacket.getPacketData()&lt;/li&gt;&lt;li&gt;void sun.management.jdp.JdpBroadcaster.sendPacket(JdpPacket)&lt;/li&gt;&lt;li&gt;void sun.management.jdp.JdpController$JDPControllerRunner.run()&lt;/li&gt;&lt;/ul&gt;</summary>
            <explanation>Frequently allocated types are good places to start when trying to reduce garbage collections. Look at where the most common types are being allocated to see if many instances are created along the same call path. Try to reduce the number of instances created by invoking the most commonly taken paths less.</explanation>
        </rule>
        <rule>
            <id>Allocations.thread</id>
            <severity>OK</severity>
            <summary>The most allocations were likely done by thread ''AWT-EventQueue-0'' at: &lt;ul&gt;&lt;li&gt;void java.awt.EventQueue.dispatchEvent(AWTEvent)&lt;/li&gt;&lt;li&gt;void java.awt.EventDispatchThread.pumpOneEventForFilters(int)&lt;/li&gt;&lt;li&gt;void java.awt.EventDispatchThread.pumpEventsForFilter(int, Conditional, EventFilter)&lt;/li&gt;&lt;li&gt;void java.awt.EventDispatchThread.pumpEventsForHierarchy(int, Conditional, Component)&lt;/li&gt;&lt;li&gt;void java.awt.EventDispatchThread.pumpEvents(int, Conditional)&lt;/li&gt;&lt;li&gt;void java.awt.EventDispatchThread.pumpEvents(Conditional)&lt;/li&gt;&lt;/ul&gt;</summary>
            <explanation>Many allocations performed by the same thread might indicate a problem in a multi-threaded program. Look at the stack traces for the thread with the highest allocation rate. See if the allocation rate can be brought down, or balanced among the active threads.</explanation>
        </rule>
        <rule>
            <id>ApplicationHalts</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>BufferLost</id>
            <severity>OK</severity>
            <summary>No Flight Recorder buffers were lost during the recording.</summary>
        </rule>
        <rule>
            <id>BytecodeVerification</id>
            <severity>OK</severity>
            <summary>The application ran with bytecode verification enabled.</summary>
        </rule>
        <rule>
            <id>ClassLeak</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ClassLoading</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CodeCache</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompareCpu</id>
            <severity>Warning</severity>
            <summary>An average CPU load of 60 % was caused by other processes for during 4/25/2018 11:38:36.000 AM – 11:38:44 AM.</summary>
            <explanation>The application performance can be affected when the machine is under heavy load and there are other processes that use CPU or other resources on the same computer. To profile representatively or get higher throughput, shut down other resource intensive processes running on the machine.</explanation>
        </rule>
        <rule>
            <id>CompressedOops</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ContextSwitch</id>
            <severity>OK</severity>
            <summary>The program did not context switch excessively during the recording.</summary>
        </rule>
        <rule>
            <id>DMSIncident</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DebugNonSafepoints</id>
            <severity>Information</severity>
            <summary>DebugNonSafepoints was not enabled.</summary>
            <explanation>If DebugNonSafepoints is not enabled, the method profiling data will be less accurate as threads that are not at safepoints will not be correctly sampled. There is a slight performance overhead when enabling these flags. For more information see [HotSpot Runtime Overview/Thread Management](http://openjdk.java.net/groups/hotspot/docs/RuntimeOverview.html#Thread%20Management|outline]).</explanation>
            <solution>Use the following JVM flags to enable this: '-XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints'.</solution>
        </rule>
        <rule>
            <id>DiscouragedVmOptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DumpReason</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DuplicateFlags</id>
            <severity>OK</severity>
            <summary>There were no duplicate JVM flags on the command line.</summary>
        </rule>
        <rule>
            <id>Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Exceptions</id>
            <severity>OK</severity>
            <summary>The program generated 0 exceptions per second during 4/25/2018 11:38:36.000 AM – 11:38:37 AM.</summary>
            <explanation>Throwing exceptions is more expensive than normal code execution, which means that they should only be used for exceptional situations. Investigate the thrown exceptions to see if any of them can be avoided with a non-exceptional control flow.</explanation>
        </rule>
        <rule>
            <id>Fatal Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FewSampledThreads</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FileRead</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FileWrite</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FlightRecordingSupport</id>
            <severity>OK</severity>
            <summary>The JVM version used for this recording has full Flight Recorder support.</summary>
        </rule>
        <rule>
            <id>JfrPeriodicEventsFix</id>
            <severity>OK</severity>
            <summary>The version of Java you are running is not affected by a performance issue related to periodic events.</summary>
        </rule>
        <rule>
            <id>FullGc</id>
            <severity>Not Applicable</severity>
            <summary>This rule is only valid for CMS and G1 Garbage Collectors, neither of which were detected for this JVM.</summary>
        </rule>
        <rule>
            <id>GarbageCollectionInfoRule</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcFreedRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcOptions</id>
            <severity>OK</severity>
            <summary>No problems were found with the GC configuration.</summary>
        </rule>
        <rule>
            <id>GcPauseRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapContent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapDump</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HighGc</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HighJvmCpu</id>
            <severity>OK</severity>
            <summary>The JVM does not seem to cause a lot of CPU load.</summary>
        </rule>
        <rule>
            <id>IncreasingLiveSet</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>IncreasingMetaSpaceLiveSet</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>JavaBlocking</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LongGcPause</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LowOnPhysicalMemory</id>
            <severity>Warning</severity>
            <summary>The maximum amount of used memory was 99.8 % of the physical memory available.</summary>
            <explanation>The maximum amount of memory used was 16 GiB. This is 99.8 % of the 16 GiB of physical memory available. Having little free memory may lead to swapping, which is very expensive. To avoid this, either decrease the memory usage or increase the amount of available memory.</explanation>
        </rule>
        <rule>
            <id>ManagementAgent</id>
            <severity>OK</severity>
            <summary>No problems were found with the management agent settings.</summary>
        </rule>
        <rule>
            <id>ManyRunningProcesses</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>MetaspaceOom</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>MethodProfiling</id>
            <severity>OK</severity>
            <summary>No methods where optimization would be particularly efficient could be detected.</summary>
        </rule>
        <rule>
            <id>Options</id>
            <severity>OK</severity>
            <summary>No undocumented, deprecated or non-recommended option flags were detected.</summary>
        </rule>
        <rule>
            <id>OverAggressiveRecordingSetting</id>
            <severity>OK</severity>
            <summary>No problems were found with the recording settings.</summary>
        </rule>
        <rule>
            <id>PasswordsInArguments</id>
            <severity>OK</severity>
            <summary>The recording does not seem to contain passwords in the application arguments.</summary>
        </rule>
        <rule>
            <id>PasswordsInEnvironment</id>
            <severity>Warning</severity>
            <summary>The environment variables in the recording may contain passwords.</summary>
            <explanation>The following suspicious environment variables were found in this recording: &lt;ul&gt;&lt;li&gt;P4PASSWD&lt;/li&gt;&lt;/ul&gt;. The following regular expression was used to exclude strings from this rule: ''(passworld|passwise)''.</explanation>
            <solution>If you wish to keep having passwords in your environment variables, but want to be able to share recordings without also sharing the passwords, please disable the ''Initial Environment Variable'' event.</solution>
        </rule>
        <rule>
            <id>PasswordsInSystemProperties</id>
            <severity>OK</severity>
            <summary>The recording does not seem to contain passwords in the system properties.</summary>
        </rule>
        <rule>
            <id>PrimitiveToObjectConversion</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ProcessStarted</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketRead</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketWrite</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>StackdepthSetting</id>
            <severity>OK</severity>
            <summary>No stack traces were truncated in this recording.</summary>
        </rule>
        <rule>
            <id>StringDeduplication</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>TlabAllocationRatio</id>
            <severity>OK</severity>
            <summary>No object allocations outside of TLABs detected.</summary>
        </rule>
        <rule>
            <id>VMOperations</id>
            <severity>OK</severity>
            <summary>No excessively long VM operations were found in this recording (the longest was 67.887 ms).</summary>
        </rule>
        <rule>
            <id>biasedLockingRevocation</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>biasedLockingRevocationPause</id>
            <severity>OK</severity>
            <summary>No revocation of biased locks found.</summary>
        </rule>
    </report>
    <report>
        <file>full_gc_cms.jfr</file>
        <rule>
            <id>Allocations.class</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Allocations.thread</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ApplicationHalts</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>BufferLost</id>
            <severity>OK</severity>
            <summary>No Flight Recorder buffers were lost during the recording.</summary>
        </rule>
        <rule>
            <id>BytecodeVerification</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ClassLeak</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ClassLoading</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CodeCache</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompareCpu</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompressedOops</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ContextSwitch</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DMSIncident</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DebugNonSafepoints</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DiscouragedVmOptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DumpReason</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DuplicateFlags</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Exceptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Fatal Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FewSampledThreads</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FileRead</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FileWrite</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FlightRecordingSupport</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>JfrPeriodicEventsFix</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FullGc</id>
            <severity>Warning</severity>
            <summary>Full GC detected.</summary>
            <explanation>At least one Full, Stop-The-World Garbage Collection occurred during this recording. For the CMS and G1 collectors, Full GC events are a strong negative performance indicator. Tunable GC parameters can be used to allow the collector to operate in concurrent mode, avoiding Stop-The-World pauses and increasing GC and application performance.</explanation>
        </rule>
        <rule>
            <id>GarbageCollectionInfoRule</id>
            <severity>OK</severity>
        </rule>
        <rule>
            <id>GcFreedRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcLocker</id>
            <severity>OK</severity>
            <summary>No GCs were affected by the GC Locker.</summary>
        </rule>
        <rule>
            <id>GcOptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcPauseRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcStall</id>
            <severity>Warning</severity>
            <summary>The CMS garbage collector was used, but the JVM had to revert to do a Serial Old Collection.</summary>
            <explanation>The application used the Concurrent Mark Sweep garbage collector, but the JVM had to revert to a Serial Old Collection, which takes more time. This is because the Concurrent Collector could not keep up with the object allocations that happened during the collection. You can decrease the risk of this by lowering the value of [-XX:CMSInitiatingOccupancyFraction](https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html).</explanation>
        </rule>
        <rule>
            <id>HeapContent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapDump</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapInspectionGc</id>
            <severity>OK</severity>
            <summary>The JVM did not perform any heap inspection GCs.</summary>
            <explanation>This is good since they usually take a lot of time.</explanation>
        </rule>
        <rule>
            <id>HighGc</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HighJvmCpu</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>IncreasingLiveSet</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>IncreasingMetaSpaceLiveSet</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>JavaBlocking</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LongGcPause</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LowOnPhysicalMemory</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ManagementAgent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ManyRunningProcesses</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>MetaspaceOom</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>MethodProfiling</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Options</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>OverAggressiveRecordingSetting</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInArguments</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInEnvironment</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInSystemProperties</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PrimitiveToObjectConversion</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ProcessStarted</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketRead</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketWrite</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>StackdepthSetting</id>
            <severity>OK</severity>
            <summary>No stack traces were truncated in this recording.</summary>
        </rule>
        <rule>
            <id>StringDeduplication</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SystemGc</id>
            <severity>OK</severity>
            <summary>No garbage collections were caused by System.gc().</summary>
        </rule>
        <rule>
            <id>TlabAllocationRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>VMOperations</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>biasedLockingRevocation</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>biasedLockingRevocationPause</id>
            <severity>Not Applicable</severity>
        </rule>
    </report>
    <report>
        <file>full_gc_g1.jfr</file>
        <rule>
            <id>Allocations.class</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Allocations.thread</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ApplicationHalts</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>BufferLost</id>
            <severity>OK</severity>
            <summary>No Flight Recorder buffers were lost during the recording.</summary>
        </rule>
        <rule>
            <id>BytecodeVerification</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ClassLeak</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ClassLoading</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CodeCache</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompareCpu</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompressedOops</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ContextSwitch</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DMSIncident</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DebugNonSafepoints</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DiscouragedVmOptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DumpReason</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DuplicateFlags</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Exceptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Fatal Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FewSampledThreads</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FileRead</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FileWrite</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FlightRecordingSupport</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>JfrPeriodicEventsFix</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FullGc</id>
            <severity>Warning</severity>
            <summary>Full GC detected.</summary>
            <explanation>At least one Full, Stop-The-World Garbage Collection occurred during this recording. For the CMS and G1 collectors, Full GC events are a strong negative performance indicator. Tunable GC parameters can be used to allow the collector to operate in concurrent mode, avoiding Stop-The-World pauses and increasing GC and application performance.</explanation>
        </rule>
        <rule>
            <id>GarbageCollectionInfoRule</id>
            <severity>OK</severity>
        </rule>
        <rule>
            <id>GcFreedRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcLocker</id>
            <severity>OK</severity>
            <summary>No GCs were affected by the GC Locker.</summary>
        </rule>
        <rule>
            <id>GcOptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcPauseRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcStall</id>
            <severity>Warning</severity>
            <summary>There occurred Concurrent Mode failures during certain garbage collections.</summary>
            <explanation>Concurrent Mode failures means that the Garbage Collector hasn't been able to keep up with the Java Program. Try lowering the value of [-XX:InitiatingHeapOccupancyPercent](http://www.oracle.com/technetwork/articles/java/vmoptions-jsp-140102.html).</explanation>
        </rule>
        <rule>
            <id>HeapContent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapDump</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapInspectionGc</id>
            <severity>OK</severity>
            <summary>The JVM did not perform any heap inspection GCs.</summary>
            <explanation>This is good since they usually take a lot of time.</explanation>
        </rule>
        <rule>
            <id>HighGc</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HighJvmCpu</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>IncreasingLiveSet</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>IncreasingMetaSpaceLiveSet</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>JavaBlocking</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LongGcPause</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LowOnPhysicalMemory</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ManagementAgent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ManyRunningProcesses</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>MetaspaceOom</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>MethodProfiling</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Options</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>OverAggressiveRecordingSetting</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInArguments</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInEnvironment</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInSystemProperties</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PrimitiveToObjectConversion</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ProcessStarted</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketRead</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketWrite</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>StackdepthSetting</id>
            <severity>OK</severity>
            <summary>No stack traces were truncated in this recording.</summary>
        </rule>
        <rule>
            <id>StringDeduplication</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SystemGc</id>
            <severity>OK</severity>
            <summary>No garbage collections were caused by System.gc().</summary>
        </rule>
        <rule>
            <id>TlabAllocationRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>VMOperations</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>biasedLockingRevocation</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>biasedLockingRevocationPause</id>
            <severity>Not Applicable</severity>
        </rule>
    </report>
    <report>
        <file>jdk15.jfr</file>
        <rule>
            <id>Allocations.class</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Allocations.thread</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ApplicationHalts</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>BufferLost</id>
            <severity>OK</severity>
            <summary>No Flight Recorder buffers were lost during the recording.</summary>
        </rule>
        <rule>
            <id>BytecodeVerification</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ClassLeak</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ClassLoading</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CodeCache</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompareCpu</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompressedOops</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ContextSwitch</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DMSIncident</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DebugNonSafepoints</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DiscouragedVmOptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DumpReason</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DuplicateFlags</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Exceptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Fatal Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FewSampledThreads</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FileRead</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FileWrite</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FlightRecordingSupport</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>JfrPeriodicEventsFix</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FullGc</id>
            <severity>Warning</severity>
            <summary>Full GC detected.</summary>
            <explanation>At least one Full, Stop-The-World Garbage Collection occurred during this recording. For the CMS and G1 collectors, Full GC events are a strong negative performance indicator. Tunable GC parameters can be used to allow the collector to operate in concurrent mode, avoiding Stop-The-World pauses and increasing GC and application performance.</explanation>
        </rule>
        <rule>
            <id>GarbageCollectionInfoRule</id>
            <severity>OK</severity>
        </rule>
        <rule>
            <id>GcFreedRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcLocker</id>
            <severity>OK</severity>
            <summary>No GCs were affected by the GC Locker.</summary>
        </rule>
        <rule>
            <id>GcOptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcPauseRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcStall</id>
            <severity>Warning</severity>
            <summary>There occurred Concurrent Mode failures during certain garbage collections.</summary>
            <explanation>Concurrent Mode failures means that the Garbage Collector hasn't been able to keep up with the Java Program. Try lowering the value of [-XX:InitiatingHeapOccupancyPercent](http://www.oracle.com/technetwork/articles/java/vmoptions-jsp-140102.html).</explanation>
        </rule>
        <rule>
            <id>HeapContent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapDump</id>
            <severity>Information</severity>
            <summary>2 heap dump(s) performed.</summary>
        </rule>
        <rule>
            <id>HeapInspectionGc</id>
            <severity>OK</severity>
            <summary>The JVM did not perform any heap inspection GCs.</summary>
            <explanation>This is good since they usually take a lot of time.</explanation>
        </rule>
        <rule>
            <id>HighGc</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HighJvmCpu</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>IncreasingLiveSet</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>IncreasingMetaSpaceLiveSet</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>JavaBlocking</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LongGcPause</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LowOnPhysicalMemory</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ManagementAgent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ManyRunningProcesses</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>MetaspaceOom</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>MethodProfiling</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Options</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>OverAggressiveRecordingSetting</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInArguments</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInEnvironment</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInSystemProperties</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PrimitiveToObjectConversion</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ProcessStarted</id>
            <severity>Information</severity>
            <summary>1 process(es) started.</summary>
        </rule>
        <rule>
            <id>SocketRead</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketWrite</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>StackdepthSetting</id>
            <severity>OK</severity>
            <summary>No stack traces were truncated in this recording.</summary>
        </rule>
        <rule>
            <id>StringDeduplication</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SystemGc</id>
            <severity>OK</severity>
            <summary>No garbage collections were caused by System.gc().</summary>
        </rule>
        <rule>
            <id>TlabAllocationRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>VMOperations</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>biasedLockingRevocation</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>biasedLockingRevocationPause</id>
            <severity>Not Applicable</severity>
        </rule>
    </report>
    <report>
        <file>parallel-gc_cpu.jfr</file>
        <rule>
            <id>Allocations.class</id>
            <severity>OK</severity>
            <summary>The most allocated type is likely ''java.util.ArrayList'', most commonly allocated by: &lt;ul&gt;&lt;li&gt;Collection oracle.jrockit.jfr.JFRImpl.getRecordings()&lt;/li&gt;&lt;li&gt;void oracle.jrockit.jfr.MetaProducer.onNewChunk()&lt;/li&gt;&lt;li&gt;void oracle.jrockit.jfr.JFRImpl.onNewChunk()&lt;/li&gt;&lt;/ul&gt;</summary>
            <explanation>Frequently allocated types are good places to start when trying to reduce garbage collections. Look at where the most common types are being allocated to see if many instances are created along the same call path. Try to reduce the number of instances created by invoking the most commonly taken paths less.</explanation>
        </rule>
        <rule>
            <id>Allocations.thread</id>
            <severity>OK</severity>
            <summary>The most allocations were likely done by thread ''RMI TCP Connection(1)-127.0.0.1'' at: &lt;ul&gt;&lt;li&gt;void java.io.ObjectInputStream$BlockDataInputStream.&amp;lt;init&amp;gt;(ObjectInputStream, InputStream)&lt;/li&gt;&lt;li&gt;void java.io.ObjectInputStream.&amp;lt;init&amp;gt;(InputStream)&lt;/li&gt;&lt;li&gt;void sun.rmi.server.MarshalInputStream.&amp;lt;init&amp;gt;(InputStream)&lt;/li&gt;&lt;li&gt;void sun.rmi.transport.ConnectionInputStream.&amp;lt;init&amp;gt;(InputStream)&lt;/li&gt;&lt;li&gt;ObjectInput sun.rmi.transport.StreamRemoteCall.getInputStream()&lt;/li&gt;&lt;li&gt;boolean sun.rmi.transport.Transport.serviceCall(RemoteCall)&lt;/li&gt;&lt;/ul&gt;</summary>
            <explanation>Many allocations performed by the same thread might indicate a problem in a multi-threaded program. Look at the stack traces for the thread with the highest allocation rate. See if the allocation rate can be brought down, or balanced among the active threads.</explanation>
        </rule>
        <rule>
            <id>ApplicationHalts</id>
            <severity>OK</severity>
            <summary>Application efficiency was not highly affected by halts.</summary>
            <explanation>The highest ratio of application halts to execution time was 0 % during 4/4/2014 11:17:05.000 AM – 11:18:05 AM. 0 % of the halts were for reasons other than GC. The halts ratio for the entire recording was 0 %. 0 % of the total halts were for reasons other than GC.
Enabling the following event types would improve the accuracy of this rule: jdk.SafepointBegin</explanation>
        </rule>
        <rule>
            <id>BufferLost</id>
            <severity>OK</severity>
            <summary>No Flight Recorder buffers were lost during the recording.</summary>
        </rule>
        <rule>
            <id>BytecodeVerification</id>
            <severity>OK</severity>
            <summary>The application ran with bytecode verification enabled.</summary>
        </rule>
        <rule>
            <id>ClassLeak</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ClassLoading</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CodeCache</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompareCpu</id>
            <severity>OK</severity>
            <summary>An average CPU load of 0 % was caused by other processes for during 4/4/2014 11:17:07.000 AM – 11:17:08 AM.</summary>
            <explanation>The application performance can be affected when the machine is under heavy load and there are other processes that use CPU or other resources on the same computer. To profile representatively or get higher throughput, shut down other resource intensive processes running on the machine.</explanation>
        </rule>
        <rule>
            <id>CompressedOops</id>
            <severity>OK</severity>
            <summary>The settings for Compressed Oops were OK.</summary>
        </rule>
        <rule>
            <id>ContextSwitch</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DMSIncident</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DebugNonSafepoints</id>
            <severity>Information</severity>
            <summary>DebugNonSafepoints was not enabled.</summary>
            <explanation>If DebugNonSafepoints is not enabled, the method profiling data will be less accurate as threads that are not at safepoints will not be correctly sampled. There is a slight performance overhead when enabling these flags. For more information see [HotSpot Runtime Overview/Thread Management](http://openjdk.java.net/groups/hotspot/docs/RuntimeOverview.html#Thread%20Management|outline]).</explanation>
            <solution>Use the following JVM flags to enable this: '-XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints'.</solution>
        </rule>
        <rule>
            <id>DiscouragedVmOptions</id>
            <severity>OK</severity>
            <summary>No problems were found with the VM options.</summary>
        </rule>
        <rule>
            <id>DumpReason</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DuplicateFlags</id>
            <severity>OK</severity>
            <summary>There were no duplicate JVM flags on the command line.</summary>
        </rule>
        <rule>
            <id>Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Exceptions</id>
            <severity>OK</severity>
            <summary>The program generated 0 exceptions per second during 4/4/2014 11:17:06.152.000 AM – 11:17:07.152 AM.</summary>
            <explanation>Throwing exceptions is more expensive than normal code execution, which means that they should only be used for exceptional situations. Investigate the thrown exceptions to see if any of them can be avoided with a non-exceptional control flow.</explanation>
        </rule>
        <rule>
            <id>Fatal Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FewSampledThreads</id>
            <severity>OK</severity>
            <summary>There were no problems with the amount of sampled threads.</summary>
            <explanation>There are more sampled threads than the amount of hardware threads. This indicates that the application has enough parallelism for the available hardware.</explanation>
        </rule>
        <rule>
            <id>FileRead</id>
            <severity>OK</severity>
            <summary>There are no file read events in this recording.</summary>
        </rule>
        <rule>
            <id>FileWrite</id>
            <severity>OK</severity>
            <summary>There are no file write events in this recording.</summary>
        </rule>
        <rule>
            <id>FlightRecordingSupport</id>
            <severity>Warning</severity>
            <summary>The recording is from an early access build.</summary>
            <explanation>This recording is from an early access build of the JRE (Java HotSpot(TM) Client VM (25.20-b08) for linux-x86 JRE (1.8.0_20-ea-b08), built on Apr  1 2014 19:40:24 by &amp;#34;java_re&amp;#34; with gcc 4.3.0 20080428 (Red Hat 4.3.0-8)). The automated analysis is not supported, and you may see errors when attempting to analyze the recording.</explanation>
        </rule>
        <rule>
            <id>JfrPeriodicEventsFix</id>
            <severity>OK</severity>
            <summary>The version of Java you are running is not affected by a performance issue related to periodic events.</summary>
        </rule>
        <rule>
            <id>FullGc</id>
            <severity>OK</severity>
            <summary>No Stop-the-World, Full GC events detected.</summary>
        </rule>
        <rule>
            <id>GarbageCollectionInfoRule</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcFreedRatio</id>
            <severity>OK</severity>
            <summary>Only 0 heap summary events were found, this rule requires at least 10 events to be able to calculate a relevant result. This likely means that only a few garbage collections occurred during the recording. Having few garbage collections is generally a good sign.</summary>
        </rule>
        <rule>
            <id>GcOptions</id>
            <severity>Information</severity>
            <summary>The runtime used 2 GC threads on a machine with 1 CPU cores.</summary>
            <explanation>It's suboptimal to use more GC threads than available cores. Removing the '-XX:ParallelGCThreads' flag will allow the JVM to set the number of GC threads automatically.</explanation>
        </rule>
        <rule>
            <id>GcPauseRatio</id>
            <severity>OK</severity>
            <summary>Application efficiency was not highly affected by GC pauses.</summary>
            <explanation>The highest ratio between garbage collection pauses and execution time was 0 % during 4/4/2014 11:17:05.000 AM – 11:18:05 AM. The garbage collection pause ratio of the entire recording was 0 %.</explanation>
            <solution>Pause times may be reduced by increasing the heap size or by trying to reduce allocation.</solution>
        </rule>
        <rule>
            <id>HeapContent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapDump</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HighGc</id>
            <severity>OK</severity>
            <summary>The runtime did not spend much time performing garbage collections.</summary>
        </rule>
        <rule>
            <id>HighJvmCpu</id>
            <severity>Information</severity>
            <summary>This recording contains few profiling samples even though the CPU load is high.</summary>
            <explanation>The profiling data is thus likely not relevant. This might be because the application is running a lot JNI code or that the JVM is spending a lot of time in GC, class loading, JIT compilation etc.</explanation>
        </rule>
        <rule>
            <id>IncreasingLiveSet</id>
            <severity>Not Applicable</severity>
            <summary>Too few events to calculate the result.</summary>
        </rule>
        <rule>
            <id>IncreasingMetaSpaceLiveSet</id>
            <severity>OK</severity>
            <summary>The class data does not seem to increase during the recording.</summary>
        </rule>
        <rule>
            <id>JavaBlocking</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LongGcPause</id>
            <severity>OK</severity>
            <summary>The application did not cause any long GC pause times.</summary>
        </rule>
        <rule>
            <id>LowOnPhysicalMemory</id>
            <severity>OK</severity>
            <summary>The system did not run low on physical memory during this recording.</summary>
        </rule>
        <rule>
            <id>ManagementAgent</id>
            <severity>OK</severity>
            <summary>No problems were found with the management agent settings.</summary>
        </rule>
        <rule>
            <id>ManyRunningProcesses</id>
            <severity>OK</severity>
            <summary>137 processes were running while this Flight Recording was made.</summary>
            <explanation>At 4/4/14 11:17:10.326 AM, a total of 137 other processes were running on the host machine that this Flight Recording was made on.</explanation>
            <solution>If this is a server environment, it may be good to only run other critical processes on that machine.</solution>
        </rule>
        <rule>
            <id>MetaspaceOom</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>MethodProfiling</id>
            <severity>OK</severity>
            <summary>No methods where optimization would be particularly efficient could be detected.</summary>
        </rule>
        <rule>
            <id>Options</id>
            <severity>OK</severity>
            <summary>No undocumented, deprecated or non-recommended option flags were detected.</summary>
        </rule>
        <rule>
            <id>OverAggressiveRecordingSetting</id>
            <severity>OK</severity>
            <summary>No problems were found with the recording settings.</summary>
        </rule>
        <rule>
            <id>PasswordsInArguments</id>
            <severity>OK</severity>
            <summary>The recording does not seem to contain passwords in the application arguments.</summary>
        </rule>
        <rule>
            <id>PasswordsInEnvironment</id>
            <severity>OK</severity>
            <summary>The recording does not seem to contain passwords in the environment variables.</summary>
        </rule>
        <rule>
            <id>PasswordsInSystemProperties</id>
            <severity>OK</severity>
            <summary>The recording does not seem to contain passwords in the system properties.</summary>
        </rule>
        <rule>
            <id>PrimitiveToObjectConversion</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ProcessStarted</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketRead</id>
            <severity>OK</severity>
            <summary>SocketReadRuleFactory_TEXT_NO_EVENTS</summary>
            <explanation>Note that there are some socket read patterns with high duration reads that we consider to be normal and are therefore excluded. Such patterns include JMX RMI communication and MQ series.</explanation>
        </rule>
        <rule>
            <id>SocketWrite</id>
            <severity>OK</severity>
            <summary>There are no socket write events in this recording.</summary>
            <explanation>Note that there are some socket write patterns with high duration writes that we consider to be normal and are therefore excluded. Such patterns include JMX RMI communication.</explanation>
        </rule>
        <rule>
            <id>StackdepthSetting</id>
            <severity>OK</severity>
            <summary>No stack traces were truncated in this recording.</summary>
        </rule>
        <rule>
            <id>StringDeduplication</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>TlabAllocationRatio</id>
            <severity>OK</severity>
            <summary>No object allocations outside of TLABs detected.</summary>
        </rule>
        <rule>
            <id>VMOperations</id>
            <severity>OK</severity>
            <summary>No excessively long VM operations were found in this recording (the longest was 0 s).</summary>
        </rule>
        <rule>
            <id>biasedLockingRevocation</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>biasedLockingRevocationPause</id>
            <severity>OK</severity>
            <summary>No revocation of biased locks found.</summary>
        </rule>
    </report>
    <report>
        <file>parallel-on-singlecpu.jfr</file>
        <rule>
            <id>Allocations.class</id>
            <severity>OK</severity>
            <summary>The most allocated type is likely ''java.lang.Object[]'', most commonly allocated by: &lt;ul&gt;&lt;li&gt;Object[] java.util.AbstractCollection.toArray()&lt;/li&gt;&lt;li&gt;void java.util.ArrayList.&amp;lt;init&amp;gt;(Collection)&lt;/li&gt;&lt;li&gt;Collection oracle.jrockit.jfr.JFRImpl.getRecordings()&lt;/li&gt;&lt;li&gt;void oracle.jrockit.jfr.MetaProducer.onNewChunk()&lt;/li&gt;&lt;li&gt;void oracle.jrockit.jfr.JFRImpl.onNewChunk()&lt;/li&gt;&lt;/ul&gt;</summary>
            <explanation>Frequently allocated types are good places to start when trying to reduce garbage collections. Look at where the most common types are being allocated to see if many instances are created along the same call path. Try to reduce the number of instances created by invoking the most commonly taken paths less.</explanation>
        </rule>
        <rule>
            <id>Allocations.thread</id>
            <severity>OK</severity>
            <summary>The most allocations were likely done by thread ''RMI TCP Connection(1)-127.0.0.1'' at: &lt;ul&gt;&lt;li&gt;Throwable java.lang.Throwable.fillInStackTrace(int)&lt;/li&gt;&lt;li&gt;Throwable java.lang.Throwable.fillInStackTrace()&lt;/li&gt;&lt;li&gt;void java.lang.Throwable.&amp;lt;init&amp;gt;(String)&lt;/li&gt;&lt;li&gt;void java.lang.Exception.&amp;lt;init&amp;gt;(String)&lt;/li&gt;&lt;li&gt;void java.lang.ReflectiveOperationException.&amp;lt;init&amp;gt;(String)&lt;/li&gt;&lt;li&gt;void java.lang.NoSuchFieldException.&amp;lt;init&amp;gt;(String)&lt;/li&gt;&lt;/ul&gt;</summary>
            <explanation>Many allocations performed by the same thread might indicate a problem in a multi-threaded program. Look at the stack traces for the thread with the highest allocation rate. See if the allocation rate can be brought down, or balanced among the active threads.</explanation>
        </rule>
        <rule>
            <id>ApplicationHalts</id>
            <severity>OK</severity>
            <summary>Application efficiency was not highly affected by halts.</summary>
            <explanation>The highest ratio of application halts to execution time was 0 % during 4/4/2014 8:54:33.000 AM – 8:55:33 AM. 0 % of the halts were for reasons other than GC. The halts ratio for the entire recording was 0 %. 0 % of the total halts were for reasons other than GC.
Enabling the following event types would improve the accuracy of this rule: jdk.SafepointBegin</explanation>
        </rule>
        <rule>
            <id>BufferLost</id>
            <severity>OK</severity>
            <summary>No Flight Recorder buffers were lost during the recording.</summary>
        </rule>
        <rule>
            <id>BytecodeVerification</id>
            <severity>OK</severity>
            <summary>The application ran with bytecode verification enabled.</summary>
        </rule>
        <rule>
            <id>ClassLeak</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ClassLoading</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CodeCache</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompareCpu</id>
            <severity>OK</severity>
            <summary>An average CPU load of 0 % was caused by other processes for during 4/4/2014 8:54:36.000 AM – 8:54:37 AM.</summary>
            <explanation>The application performance can be affected when the machine is under heavy load and there are other processes that use CPU or other resources on the same computer. To profile representatively or get higher throughput, shut down other resource intensive processes running on the machine.</explanation>
        </rule>
        <rule>
            <id>CompressedOops</id>
            <severity>OK</severity>
            <summary>The settings for Compressed Oops were OK.</summary>
        </rule>
        <rule>
            <id>ContextSwitch</id>
            <severity>OK</severity>
            <summary>The program did not context switch excessively during the recording.</summary>
        </rule>
        <rule>
            <id>DMSIncident</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DebugNonSafepoints</id>
            <severity>Information</severity>
            <summary>DebugNonSafepoints was not enabled.</summary>
            <explanation>If DebugNonSafepoints is not enabled, the method profiling data will be less accurate as threads that are not at safepoints will not be correctly sampled. There is a slight performance overhead when enabling these flags. For more information see [HotSpot Runtime Overview/Thread Management](http://openjdk.java.net/groups/hotspot/docs/RuntimeOverview.html#Thread%20Management|outline]).</explanation>
            <solution>Use the following JVM flags to enable this: '-XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints'.</solution>
        </rule>
        <rule>
            <id>DiscouragedVmOptions</id>
            <severity>OK</severity>
            <summary>No problems were found with the VM options.</summary>
        </rule>
        <rule>
            <id>DumpReason</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DuplicateFlags</id>
            <severity>OK</severity>
            <summary>There were no duplicate JVM flags on the command line.</summary>
        </rule>
        <rule>
            <id>Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Exceptions</id>
            <severity>OK</severity>
            <summary>The program generated 0 exceptions per second during 4/4/2014 8:54:34.000 AM – 8:54:35 AM.</summary>
            <explanation>Throwing exceptions is more expensive than normal code execution, which means that they should only be used for exceptional situations. Investigate the thrown exceptions to see if any of them can be avoided with a non-exceptional control flow.</explanation>
        </rule>
        <rule>
            <id>Fatal Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FewSampledThreads</id>
            <severity>OK</severity>
            <summary>There were no problems with the amount of sampled threads.</summary>
            <explanation>There are more sampled threads than the amount of hardware threads. This indicates that the application has enough parallelism for the available hardware.</explanation>
        </rule>
        <rule>
            <id>FileRead</id>
            <severity>OK</severity>
            <summary>There are no file read events in this recording.</summary>
        </rule>
        <rule>
            <id>FileWrite</id>
            <severity>OK</severity>
            <summary>There are no file write events in this recording.</summary>
        </rule>
        <rule>
            <id>FlightRecordingSupport</id>
            <severity>Warning</severity>
            <summary>The recording is from an early access build.</summary>
            <explanation>This recording is from an early access build of the JRE (Java HotSpot(TM) Client VM (25.20-b08) for linux-x86 JRE (1.8.0_20-ea-b08), built on Apr  1 2014 19:40:24 by &amp;#34;java_re&amp;#34; with gcc 4.3.0 20080428 (Red Hat 4.3.0-8)). The automated analysis is not supported, and you may see errors when attempting to analyze the recording.</explanation>
        </rule>
        <rule>
            <id>JfrPeriodicEventsFix</id>
            <severity>OK</severity>
            <summary>The version of Java you are running is not affected by a performance issue related to periodic events.</summary>
        </rule>
        <rule>
            <id>FullGc</id>
            <severity>Not Applicable</severity>
            <summary>This rule is only valid for CMS and G1 Garbage Collectors, neither of which were detected for this JVM.</summary>
        </rule>
        <rule>
            <id>GarbageCollectionInfoRule</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcFreedRatio</id>
            <severity>OK</severity>
            <summary>Only 0 heap summary events were found, this rule requires at least 10 events to be able to calculate a relevant result. This likely means that only a few garbage collections occurred during the recording. Having few garbage collections is generally a good sign.</summary>
        </rule>
        <rule>
            <id>GcOptions</id>
            <severity>Information</severity>
            <summary>The runtime used a parallel GC on a single-core machine.</summary>
            <explanation>The runtime used a parallel GC on a single-core machine. This is not optimal. Use the [Serial Collector](https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/collectors.html) instead, which is optimized for single-core machines.</explanation>
        </rule>
        <rule>
            <id>GcPauseRatio</id>
            <severity>OK</severity>
            <summary>Application efficiency was not highly affected by GC pauses.</summary>
            <explanation>The highest ratio between garbage collection pauses and execution time was 0 % during 4/4/2014 8:54:33.000 AM – 8:55:33 AM. The garbage collection pause ratio of the entire recording was 0 %.</explanation>
            <solution>Pause times may be reduced by increasing the heap size or by trying to reduce allocation.</solution>
        </rule>
        <rule>
            <id>HeapContent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapDump</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HighGc</id>
            <severity>OK</severity>
            <summary>The runtime did not spend much time performing garbage collections.</summary>
        </rule>
        <rule>
            <id>HighJvmCpu</id>
            <severity>Information</severity>
            <summary>This recording contains few profiling samples even though the CPU load is high.</summary>
            <explanation>The profiling data is thus likely not relevant. This might be because the application is running a lot JNI code or that the JVM is spending a lot of time in GC, class loading, JIT compilation etc.</explanation>
        </rule>
        <rule>
            <id>IncreasingLiveSet</id>
            <severity>Not Applicable</severity>
            <summary>Too few events to calculate the result.</summary>
        </rule>
        <rule>
            <id>IncreasingMetaSpaceLiveSet</id>
            <severity>OK</severity>
            <summary>The class data does not seem to increase during the recording.</summary>
        </rule>
        <rule>
            <id>JavaBlocking</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LongGcPause</id>
            <severity>OK</severity>
            <summary>The application did not cause any long GC pause times.</summary>
        </rule>
        <rule>
            <id>LowOnPhysicalMemory</id>
            <severity>OK</severity>
            <summary>The system did not run low on physical memory during this recording.</summary>
        </rule>
        <rule>
            <id>ManagementAgent</id>
            <severity>OK</severity>
            <summary>No problems were found with the management agent settings.</summary>
        </rule>
        <rule>
            <id>ManyRunningProcesses</id>
            <severity>OK</severity>
            <summary>137 processes were running while this Flight Recording was made.</summary>
            <explanation>At 4/4/14 8:54:38.623 AM, a total of 137 other processes were running on the host machine that this Flight Recording was made on.</explanation>
            <solution>If this is a server environment, it may be good to only run other critical processes on that machine.</solution>
        </rule>
        <rule>
            <id>MetaspaceOom</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>MethodProfiling</id>
            <severity>OK</severity>
            <summary>No methods where optimization would be particularly efficient could be detected.</summary>
        </rule>
        <rule>
            <id>Options</id>
            <severity>OK</severity>
            <summary>No undocumented, deprecated or non-recommended option flags were detected.</summary>
        </rule>
        <rule>
            <id>OverAggressiveRecordingSetting</id>
            <severity>OK</severity>
            <summary>No problems were found with the recording settings.</summary>
        </rule>
        <rule>
            <id>PasswordsInArguments</id>
            <severity>OK</severity>
            <summary>The recording does not seem to contain passwords in the application arguments.</summary>
        </rule>
        <rule>
            <id>PasswordsInEnvironment</id>
            <severity>OK</severity>
            <summary>The recording does not seem to contain passwords in the environment variables.</summary>
        </rule>
        <rule>
            <id>PasswordsInSystemProperties</id>
            <severity>OK</severity>
            <summary>The recording does not seem to contain passwords in the system properties.</summary>
        </rule>
        <rule>
            <id>PrimitiveToObjectConversion</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ProcessStarted</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketRead</id>
            <severity>OK</severity>
            <summary>SocketReadRuleFactory_TEXT_NO_EVENTS</summary>
            <explanation>Note that there are some socket read patterns with high duration reads that we consider to be normal and are therefore excluded. Such patterns include JMX RMI communication and MQ series.</explanation>
        </rule>
        <rule>
            <id>SocketWrite</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>StackdepthSetting</id>
            <severity>OK</severity>
            <summary>No stack traces were truncated in this recording.</summary>
        </rule>
        <rule>
            <id>StringDeduplication</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>TlabAllocationRatio</id>
            <severity>OK</severity>
            <summary>No object allocations outside of TLABs detected.</summary>
        </rule>
        <rule>
            <id>VMOperations</id>
            <severity>OK</severity>
            <summary>No excessively long VM operations were found in this recording (the longest was 0 s).</summary>
        </rule>
        <rule>
            <id>biasedLockingRevocation</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>biasedLockingRevocationPause</id>
            <severity>OK</severity>
            <summary>No revocation of biased locks found.</summary>
        </rule>
    </report>
    <report>
        <file>stringdedup_enabled_jdk9.jfr</file>
        <rule>
            <id>Allocations.class</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Allocations.thread</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ApplicationHalts</id>
            <severity>OK</severity>
            <summary>Application efficiency was not highly affected by halts.</summary>
            <explanation>The highest ratio of application halts to execution time was 0.0819 % during 4/24/2018 10:08:52.000 AM – 10:09:52 AM. 51.6 % of the halts were for reasons other than GC. The halts ratio for the entire recording was 1 %. 51.6 % of the total halts were for reasons other than GC.</explanation>
        </rule>
        <rule>
            <id>BufferLost</id>
            <severity>OK</severity>
            <summary>No Flight Recorder buffers were lost during the recording.</summary>
        </rule>
        <rule>
            <id>BytecodeVerification</id>
            <severity>OK</severity>
            <summary>The application ran with bytecode verification enabled.</summary>
        </rule>
        <rule>
            <id>ClassLeak</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ClassLoading</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CodeCache</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompareCpu</id>
            <severity>OK</severity>
            <summary>An average CPU load of 15 % was caused by other processes for during 4/24/2018 10:08:54.000 AM – 10:08:55 AM.</summary>
            <explanation>The application performance can be affected when the machine is under heavy load and there are other processes that use CPU or other resources on the same computer. To profile representatively or get higher throughput, shut down other resource intensive processes running on the machine.</explanation>
        </rule>
        <rule>
            <id>CompressedOops</id>
            <severity>OK</severity>
            <summary>The settings for Compressed Oops were OK.</summary>
        </rule>
        <rule>
            <id>ContextSwitch</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DMSIncident</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DebugNonSafepoints</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DiscouragedVmOptions</id>
            <severity>OK</severity>
            <summary>No problems were found with the VM options.</summary>
        </rule>
        <rule>
            <id>DumpReason</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DuplicateFlags</id>
            <severity>OK</severity>
            <summary>There were no duplicate JVM flags on the command line.</summary>
        </rule>
        <rule>
            <id>Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Exceptions</id>
            <severity>OK</severity>
            <summary>The program generated 0 exceptions per second during 4/24/2018 10:08:53.000 AM – 10:08:54 AM.</summary>
            <explanation>Throwing exceptions is more expensive than normal code execution, which means that they should only be used for exceptional situations. Investigate the thrown exceptions to see if any of them can be avoided with a non-exceptional control flow.</explanation>
        </rule>
        <rule>
            <id>Fatal Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FewSampledThreads</id>
            <severity>Information</severity>
            <summary>There are fewer sampled threads than the total number of hardware threads (cores).</summary>
            <explanation>1 threads with at least 4 method samples were found, but the machine has 32 hardware threads (cores). The application might benefit from a higher level of parallelism. This could also be caused by threads doing something else than running Java code, for example running native code or spending time in the JVM internals.</explanation>
        </rule>
        <rule>
            <id>FileRead</id>
            <severity>OK</severity>
            <summary>There are no file read events in this recording.</summary>
        </rule>
        <rule>
            <id>FileWrite</id>
            <severity>OK</severity>
            <summary>There are no file write events in this recording.</summary>
        </rule>
        <rule>
            <id>FlightRecordingSupport</id>
            <severity>OK</severity>
            <summary>The JVM version used for this recording has full Flight Recorder support.</summary>
        </rule>
        <rule>
            <id>JfrPeriodicEventsFix</id>
            <severity>OK</severity>
            <summary>The version of Java you are running is not affected by a performance issue related to periodic events.</summary>
        </rule>
        <rule>
            <id>FullGc</id>
            <severity>OK</severity>
            <summary>No Stop-the-World, Full GC events detected.</summary>
        </rule>
        <rule>
            <id>GarbageCollectionInfoRule</id>
            <severity>OK</severity>
        </rule>
        <rule>
            <id>GcFreedRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcLocker</id>
            <severity>OK</severity>
            <summary>No GCs were affected by the GC Locker.</summary>
        </rule>
        <rule>
            <id>GcOptions</id>
            <severity>OK</severity>
            <summary>No problems were found with the GC configuration.</summary>
        </rule>
        <rule>
            <id>GcPauseRatio</id>
            <severity>OK</severity>
            <summary>Application efficiency was not highly affected by GC pauses.</summary>
            <explanation>The highest ratio between garbage collection pauses and execution time was 0.0397 % during 4/24/2018 10:08:52.000 AM – 10:09:52 AM. The garbage collection pause ratio of the entire recording was 0.486 %.</explanation>
            <solution>Pause times may be reduced by increasing the heap size or by trying to reduce allocation.</solution>
        </rule>
        <rule>
            <id>GcStall</id>
            <severity>OK</severity>
            <summary>No indications that the garbage collector could not keep up with the workload were detected.</summary>
        </rule>
        <rule>
            <id>HeapContent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapDump</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapInspectionGc</id>
            <severity>OK</severity>
            <summary>The JVM did not perform any heap inspection GCs.</summary>
            <explanation>This is good since they usually take a lot of time.</explanation>
        </rule>
        <rule>
            <id>HighGc</id>
            <severity>OK</severity>
            <summary>The JVM was paused for 100 % during 4/24/2018 10:08:53.973.000 AM – .982</summary>
            <explanation>The time spent performing garbage collection may be reduced by increasing the heap size or by trying to reduce allocation.
To improve rule accuracy and/or get more details for further investigation, it is recommended to enable the following event types: 'Allocation in new TLAB', 'Allocation outside TLAB'.</explanation>
        </rule>
        <rule>
            <id>HighJvmCpu</id>
            <severity>OK</severity>
            <summary>The JVM does not seem to cause a lot of CPU load.</summary>
        </rule>
        <rule>
            <id>IncreasingLiveSet</id>
            <severity>Not Applicable</severity>
            <summary>Too few events to calculate the result.</summary>
        </rule>
        <rule>
            <id>IncreasingMetaSpaceLiveSet</id>
            <severity>OK</severity>
            <summary>The class data does not seem to increase during the recording.</summary>
        </rule>
        <rule>
            <id>JavaBlocking</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LongGcPause</id>
            <severity>OK</severity>
            <summary>The longest GC pause was 9.017 ms.</summary>
            <explanation/>
        </rule>
        <rule>
            <id>LowOnPhysicalMemory</id>
            <severity>Information</severity>
            <summary>The maximum amount of used memory was 91.8 % of the physical memory available.</summary>
            <explanation>The maximum amount of memory used was 29.3 GiB. This is 91.8 % of the 31.9 GiB of physical memory available. Having little free memory may lead to swapping, which is very expensive. To avoid this, either decrease the memory usage or increase the amount of available memory.</explanation>
        </rule>
        <rule>
            <id>ManagementAgent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ManyRunningProcesses</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>MetaspaceOom</id>
            <severity>OK</severity>
            <summary>The metaspace was not exhausted during this recording.</summary>
        </rule>
        <rule>
            <id>MethodProfiling</id>
            <severity>OK</severity>
            <summary>No methods where optimization would be particularly efficient could be detected.</summary>
        </rule>
        <rule>
            <id>Options</id>
            <severity>OK</severity>
            <summary>No undocumented, deprecated or non-recommended option flags were detected.</summary>
        </rule>
        <rule>
            <id>OverAggressiveRecordingSetting</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInArguments</id>
            <severity>OK</severity>
            <summary>The recording does not seem to contain passwords in the application arguments.</summary>
        </rule>
        <rule>
            <id>PasswordsInEnvironment</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInSystemProperties</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PrimitiveToObjectConversion</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ProcessStarted</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketRead</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketWrite</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>StackdepthSetting</id>
            <severity>OK</severity>
            <summary>No stack traces were truncated in this recording.</summary>
        </rule>
        <rule>
            <id>StringDeduplication</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SystemGc</id>
            <severity>OK</severity>
            <summary>No garbage collections were caused by System.gc().</summary>
        </rule>
        <rule>
            <id>TlabAllocationRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>VMOperations</id>
            <severity>OK</severity>
            <summary>No excessively long VM operations were found in this recording (the longest was 25.346 ms).</summary>
        </rule>
        <rule>
            <id>biasedLockingRevocation</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>biasedLockingRevocationPause</id>
            <severity>OK</severity>
            <summary>No revocation of biased locks found.</summary>
        </rule>
    </report>
    <report>
        <file>wldf.jfr</file>
        <rule>
            <id>Allocations.class</id>
            <severity>Information</severity>
            <summary>The most allocated type is likely ''char[]'', most commonly allocated by: &lt;ul&gt;&lt;li&gt;char[] java.util.Arrays.copyOfRange(char[], int, int)&lt;/li&gt;&lt;/ul&gt;</summary>
            <explanation>Frequently allocated types are good places to start when trying to reduce garbage collections. Look at where the most common types are being allocated to see if many instances are created along the same call path. Try to reduce the number of instances created by invoking the most commonly taken paths less.</explanation>
        </rule>
        <rule>
            <id>Allocations.thread</id>
            <severity>OK</severity>
            <summary>The most allocations were likely done by thread ''[ACTIVE] ExecuteThread: &amp;#39;5&amp;#39; for queue: &amp;#39;weblogic.kernel.Default (self-tuning)&amp;#39;'' at: &lt;ul&gt;&lt;li&gt;char[] java.util.Arrays.copyOfRange(char[], int, int)&lt;/li&gt;&lt;/ul&gt;</summary>
            <explanation>Many allocations performed by the same thread might indicate a problem in a multi-threaded program. Look at the stack traces for the thread with the highest allocation rate. See if the allocation rate can be brought down, or balanced among the active threads.</explanation>
        </rule>
        <rule>
            <id>ApplicationHalts</id>
            <severity>OK</severity>
            <summary>Application efficiency was not highly affected by halts.</summary>
            <explanation>The highest ratio of application halts to execution time was 2.22 % during 9/24/2015 10:08:56.000 AM – 10:09:56 AM. 0.0271 % of the halts were for reasons other than GC. The halts ratio for the entire recording was 1.88 %. 0.0212 % of the total halts were for reasons other than GC.
Enabling the following event types would improve the accuracy of this rule: jdk.SafepointBegin</explanation>
        </rule>
        <rule>
            <id>BufferLost</id>
            <severity>OK</severity>
            <summary>No Flight Recorder buffers were lost during the recording.</summary>
        </rule>
        <rule>
            <id>BytecodeVerification</id>
            <severity>OK</severity>
            <summary>The application ran WebLogic Server with bytecode verification disabled.</summary>
            <explanation>The application ran WebLogic Server with bytecode verification disabled. While not generally recommended, it is considered OK for WLS.</explanation>
        </rule>
        <rule>
            <id>ClassLeak</id>
            <severity>OK</severity>
            <summary>com.oracle.medrec.model.User was loaded -1 time(s) without being unloaded</summary>
            <explanation>Some classes have been loaded multiple times, and the difference between the number of times a class have been loaded and the number of times it has been unloaded has exceeded the user specified limit. This in itself need not be a problem, but check to see if you expect these classes to be loaded multiple times to make sure that you do not have a class loader leak. The following classes were detected as potential problems: &lt;ul&gt;&lt;li&gt;com.oracle.medrec.model.User (-1)&lt;/li&gt;&lt;li&gt;com.oracle.medrec.service.PatientService (-1)&lt;/li&gt;&lt;li&gt;com.oracle.medrec.service.PhysicianService (-1)&lt;/li&gt;&lt;li&gt;com.oracle.medrec.facade.PatientFacade (-1)&lt;/li&gt;&lt;li&gt;com.oracle.medrec.common.messaging.MessageClient (-1)&lt;/li&gt;&lt;/ul&gt;</explanation>
        </rule>
        <rule>
            <id>ClassLoading</id>
            <severity>OK</severity>
            <summary>No significant time was spent loading new classes during this recording.</summary>
        </rule>
        <rule>
            <id>CodeCache</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompareCpu</id>
            <severity>Warning</severity>
            <summary>An average CPU load of 54 % was caused by other processes for during 9/24/2015 10:08:17.000 AM – 10:08:22 AM.</summary>
            <explanation>The application performance can be affected when the machine is under heavy load and there are other processes that use CPU or other resources on the same computer. To profile representatively or get higher throughput, shut down other resource intensive processes running on the machine.</explanation>
        </rule>
        <rule>
            <id>CompressedOops</id>
            <severity>OK</severity>
            <summary>The settings for Compressed Oops were OK.</summary>
        </rule>
        <rule>
            <id>ContextSwitch</id>
            <severity>OK</severity>
            <summary>The program did not context switch excessively during the recording.</summary>
        </rule>
        <rule>
            <id>DMSIncident</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DebugNonSafepoints</id>
            <severity>Information</severity>
            <summary>DebugNonSafepoints was not enabled.</summary>
            <explanation>If DebugNonSafepoints is not enabled, the method profiling data will be less accurate as threads that are not at safepoints will not be correctly sampled. There is a slight performance overhead when enabling these flags. For more information see [HotSpot Runtime Overview/Thread Management](http://openjdk.java.net/groups/hotspot/docs/RuntimeOverview.html#Thread%20Management|outline]).</explanation>
            <solution>Use the following JVM flags to enable this: '-XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints'.</solution>
        </rule>
        <rule>
            <id>DiscouragedVmOptions</id>
            <severity>OK</severity>
            <summary>No problems were found with the VM options.</summary>
        </rule>
        <rule>
            <id>DumpReason</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DuplicateFlags</id>
            <severity>Information</severity>
            <summary>2 duplicated JVM flags found.</summary>
            <explanation>Duplicated JVM flags may be caused by multiple layers of scripts used when launching the application. Having duplicate flags is dangerous as changing one of the flags in one of the scripts may not have the intended effect. This can be especially dangerous for security related system properties. The following flags were duplicated: &lt;ul&gt;&lt;li&gt;-Djava.endorsed.dirs=c:\java\JDK18~1.0_6\jre\lib\endorsed;C:\tmp\WLS-JFR\oracle_common\modules\endorsed,-Djava.endorsed.dirs=c:\java\JDK18~1.0_6\jre\lib\endorsed;C:\tmp\WLS-JFR\oracle_common\modules\endorsed&lt;/li&gt;&lt;li&gt;-Xverify:none,-Xverify:none&lt;/li&gt;&lt;/ul&gt;</explanation>
            <solution>Try to find all the places where the flag is defined and keep only one.</solution>
        </rule>
        <rule>
            <id>Errors</id>
            <severity>OK</severity>
            <summary>The program generated an average of 17 errors per minute during 9/24/2015 10:08:14.000 AM – 10:09:14 AM.</summary>
            <explanation>17 errors were thrown in total. The most common error was ''java.lang.NoSuchMethodError'', which was thrown 13 times. Investigate the thrown errors to see if they can be avoided. Errors indicate that something went wrong with the code execution and should never be used for flow control. The following regular expression was used to exclude 381 errors from this rule: ''(com.sun.el.parser.ELParser\$LookaheadSuccess)''.</explanation>
        </rule>
        <rule>
            <id>Exceptions</id>
            <severity>OK</severity>
            <summary>The program generated 515 exceptions per second during 9/24/2015 10:08:58.000 AM – 10:09:27 AM.</summary>
            <explanation>Throwing exceptions is more expensive than normal code execution, which means that they should only be used for exceptional situations. Investigate the thrown exceptions to see if any of them can be avoided with a non-exceptional control flow.</explanation>
        </rule>
        <rule>
            <id>Fatal Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FewSampledThreads</id>
            <severity>OK</severity>
            <summary>There were no problems with the amount of sampled threads.</summary>
            <explanation>There are more sampled threads than the amount of hardware threads. This indicates that the application has enough parallelism for the available hardware.</explanation>
        </rule>
        <rule>
            <id>FileRead</id>
            <severity>OK</severity>
            <summary>No long file read pauses were found in this recording (the longest was 16.269 ms).</summary>
        </rule>
        <rule>
            <id>FileWrite</id>
            <severity>OK</severity>
            <summary>No long file write pauses were found in this recording (the longest was 172.408 ms).</summary>
        </rule>
        <rule>
            <id>FlightRecordingSupport</id>
            <severity>OK</severity>
            <summary>The JVM version used for this recording has full Flight Recorder support.</summary>
        </rule>
        <rule>
            <id>JfrPeriodicEventsFix</id>
            <severity>OK</severity>
            <summary>The version of Java you are running is not affected by a performance issue related to periodic events.</summary>
        </rule>
        <rule>
            <id>FullGc</id>
            <severity>Not Applicable</severity>
            <summary>This rule is only valid for CMS and G1 Garbage Collectors, neither of which were detected for this JVM.</summary>
        </rule>
        <rule>
            <id>GarbageCollectionInfoRule</id>
            <severity>OK</severity>
        </rule>
        <rule>
            <id>GcFreedRatio</id>
            <severity>OK</severity>
            <summary>The ratio between memory freed by garbage collections per second and liveset is 47.4 %. This is likely a reasonable amount.</summary>
            <explanation>61.4 MiB per second was freed by garbage collections during 9/24/2015 10:09:18.000 AM – 10:09:28 AM. The average liveset was 130 MiB. This is likely a reasonable amount.</explanation>
        </rule>
        <rule>
            <id>GcLocker</id>
            <severity>OK</severity>
            <summary>No GCs were affected by the GC Locker.</summary>
        </rule>
        <rule>
            <id>GcOptions</id>
            <severity>OK</severity>
            <summary>No problems were found with the GC configuration.</summary>
        </rule>
        <rule>
            <id>GcPauseRatio</id>
            <severity>OK</severity>
            <summary>Application efficiency was not highly affected by GC pauses.</summary>
            <explanation>The highest ratio between garbage collection pauses and execution time was 2.22 % during 9/24/2015 10:08:56.000 AM – 10:09:56 AM. The garbage collection pause ratio of the entire recording was 1.88 %.</explanation>
            <solution>Pause times may be reduced by increasing the heap size or by trying to reduce allocation.</solution>
        </rule>
        <rule>
            <id>GcStall</id>
            <severity>OK</severity>
            <summary>No indications that the garbage collector could not keep up with the workload were detected.</summary>
        </rule>
        <rule>
            <id>HeapContent</id>
            <severity>Warning</severity>
            <summary>Most of the heap was used by only a few classes.</summary>
            <explanation>If the heap usage needs to be reduced, then this would be a good place to start.</explanation>
        </rule>
        <rule>
            <id>HeapDump</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapInspectionGc</id>
            <severity>Information</severity>
            <summary>The JVM performed 4 heap inspection garbage collections.</summary>
            <explanation>Performing heap inspection garbage collections may be a problem since they usually take a lot of time.
Some of these inspections were caused by the 'Object Count' JFR event. It triggers a full garbage collection at the beginning and end of every recording where that event is enabled. If recordings are only made on demand or not too often, then these garbage collections are usually not a problem since the resulting pauses are not part of the normal application behavior. If recordings are collected often, for example by automatic scripts, or if the application is sensitive to pauses, then it might become an issue. In that case you can consider disabling the 'Object Count' event.</explanation>
        </rule>
        <rule>
            <id>HighGc</id>
            <severity>Information</severity>
            <summary>The JVM was paused for 100 % during 9/24/2015 10:07:58.865.000 AM – 10:07:59.432 AM</summary>
            <explanation>The time spent performing garbage collection may be reduced by increasing the heap size or by trying to reduce allocation.</explanation>
        </rule>
        <rule>
            <id>HighJvmCpu</id>
            <severity>OK</severity>
            <summary>The JVM does not seem to cause a lot of CPU load.</summary>
        </rule>
        <rule>
            <id>IncreasingLiveSet</id>
            <severity>Information</severity>
            <summary>The live set on the heap seems to increase with a speed of about 638 KiB per second during the recording.</summary>
            <explanation>This may be due to a memory leak in the application or it may be an artifact of a short recording if the JVM has recently been started. The recording began 3.249 s after the JVM was started. More information can be gathered by using the 'Old Object Sample' event, if available.</explanation>
        </rule>
        <rule>
            <id>IncreasingMetaSpaceLiveSet</id>
            <severity>Information</severity>
            <summary>The class data seems to increase constantly in the metaspace during the recording.</summary>
            <explanation>This behavior may indicate a memory leak in the metaspace, this could be due to the application not unloading classes as needed.</explanation>
        </rule>
        <rule>
            <id>JavaBlocking</id>
            <severity>Information</severity>
            <summary>Threads in the application were blocked on locks for a total of 1 min 26 s.</summary>
            <explanation>The most blocking monitor class was ''org.apache.log4j.Logger'', which was blocked 1,612 times for a total of 1 min 23 s.The following regular expression was used to exclude threads from this rule: ''(.*weblogic\.socket\.Muxer.*)''</explanation>
        </rule>
        <rule>
            <id>LongGcPause</id>
            <severity>OK</severity>
            <summary>The longest GC pause was 576.207 ms.</summary>
            <explanation/>
        </rule>
        <rule>
            <id>LowOnPhysicalMemory</id>
            <severity>OK</severity>
            <summary>The system did not run low on physical memory during this recording.</summary>
        </rule>
        <rule>
            <id>ManagementAgent</id>
            <severity>OK</severity>
            <summary>No problems were found with the management agent settings.</summary>
        </rule>
        <rule>
            <id>ManyRunningProcesses</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>MetaspaceOom</id>
            <severity>OK</severity>
            <summary>The metaspace was not exhausted during this recording.</summary>
        </rule>
        <rule>
            <id>MethodProfiling</id>
            <severity>OK</severity>
            <summary>No methods where optimization would be particularly efficient could be detected.</summary>
        </rule>
        <rule>
            <id>Options</id>
            <severity>Information</severity>
            <summary>Deprecated option flags were detected.</summary>
            <explanation>The following option flags are or will be deprecated. &lt;ul&gt;&lt;li&gt;-XX:PermSize=128m: Ignored in Java 8 and removed in Java 9. PermGen was removed in JDK 8, since Java users should not need to know up front how much memory to reserve for class metadata etc. Just like in the JRockit and J9 JVMs, native memory is now used for class metadata, and it will dynamically grow as needed. The equivalent of java.lang.OutOfMemoryError: PermGen will be much harder to provoke. To influence when to start attempting to reclaim metaspace memory, check out the [MaxMetaspaceSize flag](https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html).&lt;/li&gt;&lt;li&gt;-XX:MaxPermSize=256m: Ignored in Java 8 and removed in Java 9. PermGen was removed in JDK 8, since Java users should not need to know up front how much memory to reserve for class metadata etc. Just like in the JRockit and J9 JVMs, native memory is now used for class metadata, and it will dynamically grow as needed. The equivalent of java.lang.OutOfMemoryError: PermGen will be much harder to provoke. To influence when to start attempting to reclaim metaspace memory, check out the [MaxMetaspaceSize flag](https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html).&lt;/li&gt;&lt;/ul&gt; Deprecated option flags should be avoided. In some cases they enable legacy code and in other cases they are ignored completely. They will usually be removed in a later Java release.</explanation>
        </rule>
        <rule>
            <id>OverAggressiveRecordingSetting</id>
            <severity>OK</severity>
            <summary>No problems were found with the recording settings.</summary>
        </rule>
        <rule>
            <id>PasswordsInArguments</id>
            <severity>OK</severity>
            <summary>The recording does not seem to contain passwords in the application arguments.</summary>
        </rule>
        <rule>
            <id>PasswordsInEnvironment</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInSystemProperties</id>
            <severity>OK</severity>
            <summary>The recording does not seem to contain passwords in the system properties.</summary>
        </rule>
        <rule>
            <id>PrimitiveToObjectConversion</id>
            <severity>OK</severity>
            <summary>0.089 % of the total allocation (2.07 GiB) is caused by conversion from primitive types to object types. The most common object type that primitives are converted into is ''java.lang.Integer''.</summary>
            <explanation>
The most common object type that primitives are converted into is ''java.lang.Integer'', which causes 1.11 MiB to be allocated. The most common call site is ''weblogic.socket.NIOSocketMuxer$DirectBufferPool weblogic.socket.NIOSocketMuxer$NIOOutputStream.initPool():887''.
Conversion from primitives to the corresponding object types can either be done explicitly, or be caused by autoboxing. If a considerable amount of the total allocation is caused by such conversions, consider changing the application source code to avoid this behavior. Look at the allocation stack traces to see which parts of the code to change. This rule finds the calls to the valueOf method for any of the eight object types that have primitive counterparts.</explanation>
        </rule>
        <rule>
            <id>ProcessStarted</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketRead</id>
            <severity>OK</severity>
            <summary>No long socket read pauses were found in this recording (the longest was 105.982 ms).</summary>
            <explanation>Note that there are some socket read patterns with high duration reads that we consider to be normal and are therefore excluded. Such patterns include JMX RMI communication and MQ series.</explanation>
        </rule>
        <rule>
            <id>SocketWrite</id>
            <severity>Information</severity>
            <summary>There are long socket write pauses in this recording (the longest is 349.745 ms).</summary>
            <explanation>The longest recorded socket write took 349.745 ms to write 81 B to the host at 10.161.190.213. Average time of recorded IO: 37.121 ms. Total time of recorded IO: 1.077 s. Total time of recorded IO for the host 10.161.190.213: 398.835 ms. Note that there are some socket write patterns with high duration writes that we consider to be normal and are therefore excluded. Such patterns include JMX RMI communication.</explanation>
        </rule>
        <rule>
            <id>StackdepthSetting</id>
            <severity>Warning</severity>
            <summary>Some stack traces were truncated in this recording.</summary>
            <explanation>The Flight Recorder is configured with a maximum captured stack depth of 64. 35.7 % of all traces were larger than this option, and were therefore truncated. If more detailed traces are required, increase the ''-XX:FlightRecorderOptions=stackdepth=&lt;value&gt;'' value.
Events of the following types have truncated stack traces: &lt;ul&gt;&lt;li&gt;Allocation Requiring GC (31.6 % truncated traces)&lt;/li&gt;&lt;li&gt;Allocation in new TLAB (42.4 % truncated traces)&lt;/li&gt;&lt;li&gt;Allocation outside TLAB (60.7 % truncated traces)&lt;/li&gt;&lt;li&gt;Class Load (42.8 % truncated traces)&lt;/li&gt;&lt;li&gt;EJB Business Method Invoke (47.1 % truncated traces)&lt;/li&gt;&lt;li&gt;EJB Business Method Post Invoke (44.4 % truncated traces)&lt;/li&gt;&lt;li&gt;EJB Business Method Post Invoke Cleanup (47.1 % truncated traces)&lt;/li&gt;&lt;li&gt;EJB Business Method Pre Invoke (44.4 % truncated traces)&lt;/li&gt;&lt;li&gt;EJB Pool Manager Post Invoke (47.1 % truncated traces)&lt;/li&gt;&lt;li&gt;EJB Pool Manager Pre Invoke (47.1 % truncated traces)&lt;/li&gt;&lt;li&gt;EJB PoolManager Create (32.7 % truncated traces)&lt;/li&gt;&lt;li&gt;File Read (100 % truncated traces)&lt;/li&gt;&lt;li&gt;File Write (32.6 % truncated traces)&lt;/li&gt;&lt;li&gt;JDBC Connection Close (73 % truncated traces)&lt;/li&gt;&lt;li&gt;JDBC Connection Prepare (54.4 % truncated traces)&lt;/li&gt;&lt;li&gt;JDBC Connection Release (65 % truncated traces)&lt;/li&gt;&lt;li&gt;JDBC Statement Creation (54.4 % truncated traces)&lt;/li&gt;&lt;li&gt;JDBC Statement Execute (54.4 % truncated traces)&lt;/li&gt;&lt;li&gt;JDBC Statement Execute Begin (54.4 % truncated traces)&lt;/li&gt;&lt;li&gt;JDBC Transaction Commit (65 % truncated traces)&lt;/li&gt;&lt;li&gt;JDBC Transaction End (65.6 % truncated traces)&lt;/li&gt;&lt;li&gt;JDBC Transaction Is Same RM (6.59 % truncated traces)&lt;/li&gt;&lt;li&gt;JDBC Transaction Start (100 % truncated traces)&lt;/li&gt;&lt;li&gt;JTA Transaction Commit (51 % truncated traces)&lt;/li&gt;&lt;li&gt;JTA Transaction End (51.5 % truncated traces)&lt;/li&gt;&lt;li&gt;JTA Transaction Start (80 % truncated traces)&lt;/li&gt;&lt;li&gt;Java Error (29.1 % truncated traces)&lt;/li&gt;&lt;li&gt;Java Monitor Blocked (1.09 % truncated traces)&lt;/li&gt;&lt;li&gt;Java Monitor Wait (0.134 % truncated traces)&lt;/li&gt;&lt;li&gt;Java Thread Park (0.223 % truncated traces)&lt;/li&gt;&lt;li&gt;Java Thread Sleep (33.3 % truncated traces)&lt;/li&gt;&lt;li&gt;Method Profiling Sample (24.3 % truncated traces)&lt;/li&gt;&lt;li&gt;Servlet Execute (26.2 % truncated traces)&lt;/li&gt;&lt;li&gt;Servlet Request Dispatch (45 % truncated traces)&lt;/li&gt;&lt;li&gt;Servlet Response Write Headers (0.753 % truncated traces)&lt;/li&gt;&lt;li&gt;Socket Read (41.6 % truncated traces)&lt;/li&gt;&lt;li&gt;Socket Write (20.6 % truncated traces)&lt;/li&gt;&lt;li&gt;Webservices JAXRPC Client Request (45.4 % truncated traces)&lt;/li&gt;&lt;li&gt;Webservices JAXRPC Client Response (100 % truncated traces)&lt;/li&gt;&lt;/ul&gt;</explanation>
        </rule>
        <rule>
            <id>StringDeduplication</id>
            <severity>OK</severity>
            <summary>Approximately 1,746 % of the live set consists of the internal array type of strings (''char[]'' for this JDK version).
The heap is around 22.3 % full. There is likely no big benefit from enabling string deduplication.</summary>
            <explanation>String deduplication is enabled using the JVM flag '-XX:+UseStringDeduplication'. This flag can be used together with the G1 garbage collector in JDK 8u20 or later, or with the Shenandoah garbage collector.
To validate if this gives a performance improvement for your application, create flight recordings both with and without string deduplication. For the run with string deduplication enabled, also enable statistics with '-XX:+PrintStringDeduplicationStatistics' for JDK 8 or '-Xlog:stringdedup*=debug' for JDK 9. Check if the heap live set decrease in the recording with string deduplication enabled is larger than the size of the string deduplication metadata table. The size of the metadata table is printed in the statistics output as 'Table/Memory Usage: XX MB'
You can read more about string deduplication in the java options documentation or in [JEP 192](https://openjdk.java.net/jeps/192).&lt;p&gt;String deduplication is only supported when using the G1 (JDK 8u20+) or Shenandoah garbage collectors. If you want to use this feature you can enable G1 by using '-XX:+UseG1GC', or enable Shenandoah by using '-XX:+UseShenandoahGC'.</explanation>
        </rule>
        <rule>
            <id>SystemGc</id>
            <severity>OK</severity>
            <summary>No garbage collections were caused by System.gc().</summary>
        </rule>
        <rule>
            <id>TlabAllocationRatio</id>
            <severity>OK</severity>
            <summary>The program allocated 2.39 % of the memory outside of TLABs.</summary>
            <solution>Allocating objects outside of Thread Local Allocation Buffers (TLABs) is more expensive than allocating inside TLABs. This may be acceptable if the individual allocations are intended to be larger than a reasonable TLAB. It may be possible to avoid this by decreasing the size of the individual allocations. There are some TLAB related JVM flags that you can experiment with, but it is usually better to let the JVM manage TLAB sizes automatically.</solution>
        </rule>
        <rule>
            <id>VMOperations</id>
            <severity>OK</severity>
            <summary>No excessively long VM operations were found in this recording (the longest was 592.965 ms).</summary>
        </rule>
        <rule>
            <id>biasedLockingRevocation</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>biasedLockingRevocationPause</id>
            <severity>OK</severity>
            <summary>No revocation of biased locks found.</summary>
        </rule>
    </report>
    <report>
        <file>wls-medrec-jdk9.jfr</file>
        <rule>
            <id>Allocations.class</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Allocations.thread</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ApplicationHalts</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>BufferLost</id>
            <severity>OK</severity>
            <summary>No Flight Recorder buffers were lost during the recording.</summary>
        </rule>
        <rule>
            <id>BytecodeVerification</id>
            <severity>OK</severity>
            <summary>The application ran with bytecode verification enabled.</summary>
        </rule>
        <rule>
            <id>ClassLeak</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ClassLoading</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CodeCache</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompareCpu</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompressedOops</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ContextSwitch</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DMSIncident</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DebugNonSafepoints</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DiscouragedVmOptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DumpReason</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DuplicateFlags</id>
            <severity>Information</severity>
            <summary>5 duplicated JVM flags found.</summary>
            <explanation>Duplicated JVM flags may be caused by multiple layers of scripts used when launching the application. Having duplicate flags is dangerous as changing one of the flags in one of the scripts may not have the intended effect. This can be especially dangerous for security related system properties. The following flags were duplicated: &lt;ul&gt;&lt;li&gt;-XX:NewSize=65m,-XX:NewSize=65m&lt;/li&gt;&lt;li&gt;-Dweblogic.home=C:\weblogic\src122130_build\Oracle_Home\wlserver/server,-Dweblogic.home=C:\weblogic\SRC122~1\ORACLE~1\wlserver\server&lt;/li&gt;&lt;li&gt;-Xmx500m,-Xmx500m&lt;/li&gt;&lt;li&gt;-Xms160m,-Xms160m&lt;/li&gt;&lt;li&gt;-XX:MaxNewSize=65m,-XX:MaxNewSize=65m&lt;/li&gt;&lt;/ul&gt;</explanation>
            <solution>Try to find all the places where the flag is defined and keep only one.</solution>
        </rule>
        <rule>
            <id>Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Exceptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Fatal Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FewSampledThreads</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FileRead</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FileWrite</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FlightRecordingSupport</id>
            <severity>Warning</severity>
            <summary>The recording is from an early access build.</summary>
            <explanation>This recording is from an early access build of the JRE (Java HotSpot(TM) 64-Bit Server VM (9-ea+148) for windows-amd64 JRE (9-ea+148), built on Dec  7 2016 18:47:38 by &amp;#34;javare&amp;#34; with MS VC++ 12.0 (VS2013)). The automated analysis is not supported, and you may see errors when attempting to analyze the recording.</explanation>
        </rule>
        <rule>
            <id>JfrPeriodicEventsFix</id>
            <severity>OK</severity>
            <summary>The version of Java you are running is not affected by a performance issue related to periodic events.</summary>
        </rule>
        <rule>
            <id>FullGc</id>
            <severity>Not Applicable</severity>
            <summary>This rule is only valid for CMS and G1 Garbage Collectors, neither of which were detected for this JVM.</summary>
        </rule>
        <rule>
            <id>GarbageCollectionInfoRule</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcFreedRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcOptions</id>
            <severity>Not Applicable</severity>
            <summary>Too few events to calculate the result.</summary>
        </rule>
        <rule>
            <id>GcPauseRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapContent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapDump</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HighGc</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HighJvmCpu</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>IncreasingLiveSet</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>IncreasingMetaSpaceLiveSet</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>JavaBlocking</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LongGcPause</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LowOnPhysicalMemory</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ManagementAgent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ManyRunningProcesses</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>MetaspaceOom</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>MethodProfiling</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Options</id>
            <severity>OK</severity>
            <summary>No undocumented, deprecated or non-recommended option flags were detected.</summary>
        </rule>
        <rule>
            <id>OverAggressiveRecordingSetting</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInArguments</id>
            <severity>OK</severity>
            <summary>The recording does not seem to contain passwords in the application arguments.</summary>
        </rule>
        <rule>
            <id>PasswordsInEnvironment</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInSystemProperties</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PrimitiveToObjectConversion</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ProcessStarted</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketRead</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketWrite</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>StackdepthSetting</id>
            <severity>Warning</severity>
            <summary>Some stack traces were truncated in this recording.</summary>
            <explanation>The Flight Recorder is configured with a maximum captured stack depth of 64. 17.5 % of all traces were larger than this option, and were therefore truncated. If more detailed traces are required, increase the ''-XX:FlightRecorderOptions=stackdepth=&lt;value&gt;'' value.
Events of the following types have truncated stack traces: &lt;ul&gt;&lt;li&gt;Debug (1.59 % truncated traces)&lt;/li&gt;&lt;li&gt;EJB Business Method Invoke (71.3 % truncated traces)&lt;/li&gt;&lt;li&gt;EJB Business Method Post Invoke (71.3 % truncated traces)&lt;/li&gt;&lt;li&gt;EJB Business Method Post Invoke Cleanup (71.3 % truncated traces)&lt;/li&gt;&lt;li&gt;EJB Business Method Pre Invoke (71.3 % truncated traces)&lt;/li&gt;&lt;li&gt;EJB Pool Manager Create (75 % truncated traces)&lt;/li&gt;&lt;li&gt;EJB Pool Manager Post Invoke (71.3 % truncated traces)&lt;/li&gt;&lt;li&gt;EJB Pool Manager Pre Invoke (71.3 % truncated traces)&lt;/li&gt;&lt;li&gt;JDBC Connection Close (96.8 % truncated traces)&lt;/li&gt;&lt;li&gt;JDBC Connection Prepare (100 % truncated traces)&lt;/li&gt;&lt;li&gt;JDBC Connection Release (85.7 % truncated traces)&lt;/li&gt;&lt;li&gt;JDBC Statement Creation (100 % truncated traces)&lt;/li&gt;&lt;li&gt;JDBC Statement Execute (96.7 % truncated traces)&lt;/li&gt;&lt;li&gt;JDBC Statement Execute Begin (96.7 % truncated traces)&lt;/li&gt;&lt;li&gt;JDBC Transaction Commit (45 % truncated traces)&lt;/li&gt;&lt;li&gt;JDBC Transaction End (45 % truncated traces)&lt;/li&gt;&lt;li&gt;JDBC Transaction Is Same RM (1.79 % truncated traces)&lt;/li&gt;&lt;li&gt;JDBC Transaction Start (100 % truncated traces)&lt;/li&gt;&lt;li&gt;JTA Transaction Commit (36.4 % truncated traces)&lt;/li&gt;&lt;li&gt;JTA Transaction End (6.06 % truncated traces)&lt;/li&gt;&lt;li&gt;JTA Transaction Start (16.7 % truncated traces)&lt;/li&gt;&lt;li&gt;Servlet Response Write Headers (1.87 % truncated traces)&lt;/li&gt;&lt;li&gt;Webservices JAXRPC Client Request (50 % truncated traces)&lt;/li&gt;&lt;li&gt;Webservices JAXRPC Client Response (100 % truncated traces)&lt;/li&gt;&lt;li&gt;Webservices JAXWS Endpoint (100 % truncated traces)&lt;/li&gt;&lt;li&gt;Webservices JAXWS Resource (50 % truncated traces)&lt;/li&gt;&lt;/ul&gt;</explanation>
        </rule>
        <rule>
            <id>StringDeduplication</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>TlabAllocationRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>VMOperations</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>biasedLockingRevocation</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>biasedLockingRevocationPause</id>
            <severity>Not Applicable</severity>
        </rule>
    </report>
    <report>
        <file>openjdk8u302ea.jfr</file>
        <rule>
            <id>biasedLockingRevocationPause</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>VMOperations</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>TlabAllocationRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>StackdepthSetting</id>
            <severity>Not Applicable</severity>
            <summary>No events with stack traces were recorded.</summary>
        </rule>
        <rule>
            <id>PasswordsInSystemProperties</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInEnvironment</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>OverAggressiveRecordingSetting</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ManyRunningProcesses</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ManagementAgent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LowOnPhysicalMemory</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>IncreasingMetaSpaceLiveSet</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>IncreasingLiveSet</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HighJvmCpu</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HighGc</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcPauseRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcOptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcFreedRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GarbageCollectionInfoRule</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FullGc</id>
            <severity>Not Applicable</severity>
            <summary>This rule is only valid for CMS and G1 Garbage Collectors, neither of which were detected for this JVM.</summary>
        </rule>
        <rule>
            <id>FlightRecordingSupport</id>
            <severity>Warning</severity>
            <summary>The recording is from an early access build.</summary>
            <explanation>This recording is from an early access build of the JRE (OpenJDK 64-Bit Server VM (25.302-b04) for linux-amd64 JRE (1.8.0_302-ea-b04), built on May 27 2021 15:04:41 by &amp;#34;openjdk&amp;#34; with gcc 4.4.7 20120313 (Red Hat 4.4.7-23)). The automated analysis is not supported, and you may see errors when attempting to analyze the recording.</explanation>
        </rule>
        <rule>
            <id>FileWrite</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FileRead</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FewSampledThreads</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Exceptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DiscouragedVmOptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompressedOops</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompareCpu</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ApplicationHalts</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Allocations.thread</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Allocations.class</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>biasedLockingRevocation</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>StringDeduplication</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketWrite</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketRead</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ProcessStarted</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PrimitiveToObjectConversion</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInArguments</id>
            <severity>OK</severity>
            <summary>The recording does not seem to contain passwords in the application arguments.</summary>
        </rule>
        <rule>
            <id>Options</id>
            <severity>Not Applicable</severity>
            <summary>No events with JVM arguments were recorded.</summary>
        </rule>
        <rule>
            <id>MethodProfiling</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>MetaspaceOom</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LongGcPause</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>JfrPeriodicEventsFix</id>
            <severity>OK</severity>
            <summary>The version of Java you are running is not affected by a performance issue related to periodic events.</summary>
        </rule>
        <rule>
            <id>JavaBlocking</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapDump</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapContent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Fatal Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DuplicateFlags</id>
            <severity>OK</severity>
            <summary>There were no duplicate JVM flags on the command line.</summary>
        </rule>
        <rule>
            <id>DumpReason</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DebugNonSafepoints</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DMSIncident</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ContextSwitch</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CodeCache</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ClassLoading</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ClassLeak</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>BytecodeVerification</id>
            <severity>OK</severity>
            <summary>The application ran with bytecode verification enabled.</summary>
        </rule>
        <rule>
            <id>BufferLost</id>
            <severity>OK</severity>
            <summary>No Flight Recorder buffers were lost during the recording.</summary>
        </rule>
    </report>
    <report>
        <file>openjdk8u292.jfr</file>
        <rule>
            <id>biasedLockingRevocationPause</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>VMOperations</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>TlabAllocationRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>StackdepthSetting</id>
            <severity>Not Applicable</severity>
            <summary>No events with stack traces were recorded.</summary>
        </rule>
        <rule>
            <id>PasswordsInSystemProperties</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInEnvironment</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>OverAggressiveRecordingSetting</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ManyRunningProcesses</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ManagementAgent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LowOnPhysicalMemory</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>IncreasingMetaSpaceLiveSet</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>IncreasingLiveSet</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HighJvmCpu</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HighGc</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcPauseRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcOptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcFreedRatio</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GarbageCollectionInfoRule</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FullGc</id>
            <severity>Not Applicable</severity>
            <summary>This rule is only valid for CMS and G1 Garbage Collectors, neither of which were detected for this JVM.</summary>
        </rule>
        <rule>
            <id>FlightRecordingSupport</id>
            <severity>OK</severity>
            <summary>The JVM version used for this recording has full Flight Recorder support.</summary>
        </rule>
        <rule>
            <id>FileWrite</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FileRead</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FewSampledThreads</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Exceptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DiscouragedVmOptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompressedOops</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompareCpu</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ApplicationHalts</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Allocations.thread</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Allocations.class</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>biasedLockingRevocation</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>StringDeduplication</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketWrite</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketRead</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ProcessStarted</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PrimitiveToObjectConversion</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInArguments</id>
            <severity>OK</severity>
            <summary>The recording does not seem to contain passwords in the application arguments.</summary>
        </rule>
        <rule>
            <id>Options</id>
            <severity>Not Applicable</severity>
            <summary>No events with JVM arguments were recorded.</summary>
        </rule>
        <rule>
            <id>MethodProfiling</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>MetaspaceOom</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LongGcPause</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>JfrPeriodicEventsFix</id>
            <severity>Warning</severity>
            <summary>The version of OpenJDK 8 you are running is lacking an important performance fix.</summary>
            <explanation>The version of OpenJDK (OpenJDK 64-Bit Server VM (25.292-b10) for linux-amd64 JRE (1.8.0_292-b10), built on Apr  9 2021 02:15:01 by &amp;#34;openjdk&amp;#34; with gcc 4.4.7 20120313 (Red Hat 4.4.7-23)) you are running is lacking an important performance fix. Upgrading to version 8u302 or later can, in some cases, improve your performance quite radically. See JDK-8266723 for more information. An alternative can be to disable any periodic events not needed, such as the NativeExecutionSample event.</explanation>
        </rule>
        <rule>
            <id>JavaBlocking</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapDump</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HeapContent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Fatal Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DuplicateFlags</id>
            <severity>OK</severity>
            <summary>There were no duplicate JVM flags on the command line.</summary>
        </rule>
        <rule>
            <id>DumpReason</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DebugNonSafepoints</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DMSIncident</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ContextSwitch</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CodeCache</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ClassLoading</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ClassLeak</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>BytecodeVerification</id>
            <severity>OK</severity>
            <summary>The application ran with bytecode verification enabled.</summary>
        </rule>
        <rule>
            <id>BufferLost</id>
            <severity>OK</severity>
            <summary>No Flight Recorder buffers were lost during the recording.</summary>
        </rule>
    </report>
    <report>
        <file>flight_recording_17eaMonitoredVM10440_3.jfr</file>
         <rule>
            <id>biasedLockingRevocationPause</id>
            <severity>OK</severity>
            <summary>No revocation of biased locks found.</summary>
        </rule>
        <rule>
            <id>SystemGc</id>
            <severity>OK</severity>
            <summary>No garbage collections were caused by System.gc().</summary>
        </rule>
        <rule>
            <id>VMOperations</id>
            <severity>OK</severity>
            <summary>No excessively long VM operations were found in this recording (the longest was 54.343 ms).</summary>
        </rule>
        <rule>
            <id>TlabAllocationRatio</id>
            <severity>OK</severity>
            <summary>The program allocated 3.08 % of the memory outside of TLABs.</summary>
            <solution>Allocating objects outside of Thread Local Allocation Buffers (TLABs) is more expensive than allocating inside TLABs. This may be acceptable if the individual allocations are intended to be larger than a reasonable TLAB. It may be possible to avoid this by decreasing the size of the individual allocations. There are some TLAB related JVM flags that you can experiment with, but it is usually better to let the JVM manage TLAB sizes automatically.</solution>
        </rule>
        <rule>
            <id>StackdepthSetting</id>
            <severity>Warning</severity>
            <summary>Some stack traces were truncated in this recording.</summary>
            <explanation>The Flight Recorder is configured with a maximum captured stack depth of 64. 10.5&#xA0;% of all traces were larger than this option, and were therefore truncated. If more detailed traces are required, increase the &#x27;&#x27;-XX:FlightRecorderOptions=stackdepth=&#x3C;value&#x3E;&#x27;&#x27; value.
Events of the following types have truncated stack traces: &#x3C;ul&#x3E;&#x3C;li&#x3E;Allocation in new TLAB (2.41&#xA0;% truncated traces)&#x3C;/li&#x3E;&#x3C;li&#x3E;Allocation outside TLAB (1.45&#xA0;% truncated traces)&#x3C;/li&#x3E;&#x3C;li&#x3E;Object Allocation Sample (3.06&#xA0;% truncated traces)&#x3C;/li&#x3E;&#x3C;li&#x3E;Old Object Sample (44.4&#xA0;% truncated traces)&#x3C;/li&#x3E;&#x3C;li&#x3E;Socket Write (48.1&#xA0;% truncated traces)&#x3C;/li&#x3E;&#x3C;/ul&#x3E;</explanation>
        </rule>
        <rule>
            <id>PasswordsInSystemProperties</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PasswordsInEnvironment</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>OverAggressiveRecordingSetting</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ManyRunningProcesses</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ManagementAgent</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>LowOnPhysicalMemory</id>
            <severity>OK</severity>
            <summary>The system did not run low on physical memory during this recording.</summary>
        </rule>
        <rule>
            <id>IncreasingMetaSpaceLiveSet</id>
            <severity>OK</severity>
            <summary>The class data does not seem to increase during the recording.</summary>
        </rule>
        <rule>
            <id>IncreasingLiveSet</id>
            <severity>Not Applicable</severity>
            <summary>Too few events to calculate the result.</summary>
        </rule>
        <rule>
            <id>HighJvmCpu</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>HighGc</id>
            <severity>OK</severity>
            <summary>The JVM was paused for 100 % during 7/13/2021 6:23:56.617.000 AM – .630</summary>
            <explanation>The time spent performing garbage collection may be reduced by increasing the heap size or by trying to reduce allocation.</explanation>
        </rule>
        <rule>
            <id>GcPauseRatio</id>
            <severity>OK</severity>
            <summary>Application efficiency was not highly affected by GC pauses.</summary>
            <explanation>The highest ratio between garbage collection pauses and execution time was 0.0311 % during 7/13/2021 6:23:54.000 AM – 6:24:54 AM. The garbage collection pause ratio of the entire recording was 0.00178 %.</explanation>
            <solution>Pause times may be reduced by increasing the heap size or by trying to reduce allocation.</solution>
        </rule>
        <rule>
            <id>GcOptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>GcFreedRatio</id>
            <severity>OK</severity>
            <summary>Only 6 heap summary events were found, this rule requires at least 10 events to be able to calculate a relevant result. This likely means that only a few garbage collections occurred during the recording. Having few garbage collections is generally a good sign.</summary>
        </rule>
        <rule>
            <id>GarbageCollectionInfoRule</id>
            <severity>OK</severity>
        </rule>
        <rule>
            <id>FullGc</id>
            <severity>Not Applicable</severity>
            <summary>This rule is only valid for CMS and G1 Garbage Collectors, neither of which were detected for this JVM.</summary>
        </rule>
        <rule>
            <id>FlightRecordingSupport</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FileWrite</id>
            <severity>OK</severity>
            <summary>No long file write pauses were found in this recording (the longest was 22.875 μs).</summary>
        </rule>
        <rule>
            <id>FileRead</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>FewSampledThreads</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Exceptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DiscouragedVmOptions</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompressedOops</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CompareCpu</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ApplicationHalts</id>
            <severity>OK</severity>
            <summary>Application efficiency was not highly affected by halts.</summary>
            <explanation>The highest ratio of application halts to execution time was 0.123 % during 7/13/2021 6:23:54.000 AM – 6:24:54 AM. 74.7 % of the halts were for reasons other than GC. The halts ratio for the entire recording was 0.00705 %. 74.7 % of the total halts were for reasons other than GC.</explanation>
        </rule>
        <rule>
            <id>Allocations.thread</id>
            <severity>OK</severity>
            <summary>The most allocations were likely done by thread &#x27;&#x27;RMI TCP Connection(19)-192.168.29.191&#x27;&#x27; at: &#x3C;ul&#x3E;&#x3C;li&#x3E;void java.io.ObjectOutputStream$HandleTable.growEntries()&#x3C;/li&#x3E;&#x3C;li&#x3E;int java.io.ObjectOutputStream$HandleTable.assign(Object)&#x3C;/li&#x3E;&#x3C;/ul&#x3E;</summary>
            <explanation>Many allocations performed by the same thread might indicate a problem in a multi-threaded program. Look at the stack traces for the thread with the highest allocation rate. See if the allocation rate can be brought down, or balanced among the active threads.</explanation>
        </rule>
        <rule>
            <id>Allocations.class</id>
            <severity>OK</severity>
            <summary>The most allocated type is likely &#x27;&#x27;java.lang.Object[]&#x27;&#x27;, most commonly allocated by: &#x3C;ul&#x3E;&#x3C;li&#x3E;void java.io.ObjectOutputStream$HandleTable.growEntries()&#x3C;/li&#x3E;&#x3C;li&#x3E;int java.io.ObjectOutputStream$HandleTable.assign(Object)&#x3C;/li&#x3E;&#x3C;/ul&#x3E;</summary>
            <explanation>Frequently allocated types are good places to start when trying to reduce garbage collections. Look at where the most common types are being allocated to see if many instances are created along the same call path. Try to reduce the number of instances created by invoking the most commonly taken paths less.</explanation>
        </rule>
        <rule>
            <id>StringDeduplication</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>SocketWrite</id>
            <severity>OK</severity>
            <summary>There are no socket write events in this recording.</summary>
            <explanation>Note that there are some socket write patterns with high duration writes that we consider to be normal and are therefore excluded. Such patterns include JMX RMI communication.</explanation>
        </rule>
        <rule>
            <id>SocketRead</id>
            <severity>OK</severity>
            <summary>SocketReadRuleFactory_TEXT_NO_EVENTS</summary>
            <explanation>Note that there are some socket read patterns with high duration reads that we consider to be normal and are therefore excluded. Such patterns include JMX RMI communication and MQ series.</explanation>
        </rule>
        <rule>
            <id>ProcessStarted</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>PrimitiveToObjectConversion</id>
            <severity>OK</severity>
            <summary>No allocation was caused by conversion from primitive types to the corresponding object types.</summary>
        </rule>
        <rule>
            <id>PasswordsInArguments</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Options</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>MethodProfiling</id>
            <severity>OK</severity>
            <summary>No methods where optimization would be particularly efficient could be detected.</summary>
        </rule>
        <rule>
            <id>MetaspaceOom</id>
            <severity>OK</severity>
            <summary>The metaspace was not exhausted during this recording.</summary>
        </rule>
        <rule>
            <id>LongGcPause</id>
            <severity>OK</severity>
            <summary>The longest GC pause was 13.480 ms.</summary>
            <explanation/>
        </rule>
        <rule>
            <id>JfrPeriodicEventsFix</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>JavaBlocking</id>
            <severity>OK</severity>
            <summary>No excessive problems with lock contention found.</summary>
            <explanation>The following regular expression was used to exclude threads from this rule: ''(.*weblogic\.socket\.Muxer.*)''</explanation>
        </rule>
        <rule>
            <id>HeapDump</id>
            <severity>OK</severity>
            <summary>No heap dump performed.</summary>
        </rule>
        <rule>
            <id>HeapContent</id>
            <severity>Warning</severity>
            <summary>Most of the heap was used by only a few classes.</summary>
            <explanation>If the heap usage needs to be reduced, then this would be a good place to start.</explanation>
        </rule>
        <rule>
            <id>Fatal Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>Errors</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DuplicateFlags</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DumpReason</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DebugNonSafepoints</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>DMSIncident</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ContextSwitch</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>CodeCache</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>ClassLoading</id>
            <severity>OK</severity>
            <summary>No significant time was spent loading new classes during this recording.</summary>
        </rule>
        <rule>
            <id>ClassLeak</id>
            <severity>OK</severity>
            <summary>No classes with identical names have been loaded more times than the limit.</summary>
        </rule>
        <rule>
            <id>BytecodeVerification</id>
            <severity>Not Applicable</severity>
        </rule>
        <rule>
            <id>BufferLost</id>
            <severity>OK</severity>
            <summary>No Flight Recorder buffers were lost during the recording.</summary>
        </rule>
        <rule>
            <id>HeapInspectionGc</id>
            <severity>OK</severity>
            <summary>The JVM did not perform any heap inspection GCs.</summary>
            <explanation>This is good since they usually take a lot of time.</explanation>
        </rule>
        <rule>
            <id>GcStall</id>
            <severity>OK</severity>
            <summary>No indications that the garbage collector could not keep up with the workload were detected.</summary>
        </rule>
        <rule>
            <id>GcLocker</id>
            <severity>OK</severity>
            <summary>No GCs were affected by the GC Locker.</summary>
        </rule>
        <rule>
            <id>biasedLockingRevocation</id>
            <severity>OK</severity>
            <summary>No revocation of biased locks found.</summary>
        </rule>
    </report>
</reportcollection>
