Automated Analysis Result Overview

Java Application

Threads Allocating

The most allocations were likely done by thread ''RMI TCP Connection(4)-10.0.2.100'' at:

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.

Application Halts

Application efficiency was affected by halts

The highest ratio of application halts to execution time was 6.24 % during 12/9/2021, 2:32:56.000 PM – 2:33:56 PM. 98.7 % of the halts were for reasons other than GC. The halts ratio for the entire recording was 1.86 %. 98.3 % of the total halts were for reasons other than GC. Application halts are often caused by garbage collections, but can also be caused by excessive thread dumps or heap dumps. Investigate the VM Operation information and possibly the safepoint specific information.

N/A

Parallel Threads

Ignored

High JVM CPU Load

This recording has a high sampling period for 'CPU Load' events.

The sampling period for the 'CPU Load' events was set to Every Chunk, which is too high for CPU load related rules to work.

N/A

Method Profiling

Could not extract enough execution samples to calculate a score. Try generating more samples, either by increasing the load on your application, lowering the sample period, or extending the recording time.

Memory

Allocated Classes

The most allocated type is likely ''byte[]'', most commonly allocated by:

Object jdk.internal.misc.Unsafe.allocateUninitializedArray0(Class, int)
Object jdk.internal.misc.Unsafe.allocateUninitializedArray(Class, int)
byte[] java.lang.invoke.StringConcatFactory$MethodHandleInlineCopyStrategy.newArray(int, byte)
Object java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(Object, int, int)

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.

GC Freed Ratio

Only 4 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.

Heap Content

Most of the heap was used by only a few classes.

If the heap usage needs to be reduced, then this would be a good place to start.

N/A

Heap Dump

Ignored

GC Pressure

The JVM was paused for 100 % during 12/9/2021, 2:32:57.683.000 PM – .732

The time spent performing garbage collection may be reduced by increasing the heap size or by trying to reduce allocation.

Free Physical Memory

The maximum amount of used memory was 91.8 % of the physical memory available.

The maximum amount of memory used was 28.7 GiB. This is 91.8 % of the 31.3 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.

Primitive To Object Conversion

0.815 % of the total allocation (7.02 MiB) is caused by conversion from primitive types to object types. The most common object type that primitives are converted into is ''java.lang.Long''.

The most common object type that primitives are converted into is ''java.lang.Long'', which causes 58.5 KiB to be allocated. The most common call site is ''javax.management.openmbean.CompositeData sun.management.MemoryUsageCompositeData.getCompositeData():62''. 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.

String Deduplication

Approximately 2,153 % of the live set consists of the internal array type of strings (''byte[]'' for this JDK version). The heap is around 0.0944 % full. There is likely no big benefit from enabling string deduplication.

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.

Live Objects

Heap Live Set Trend

The live set on the heap seems to increase with a speed of about 0 B per second during the recording.There is no particular class that seems to be leaking more than any other.

Perform a dump with the 'Trace Paths to GC Roots' option enabled to enable a more detailed analysis of the potential memory leak.

Lock Instances

Context Switches

The program did not context switch excessively during the recording.

Java Blocking

No excessive problems with lock contention found.

The following regular expression was used to exclude threads from this rule: ''(.*weblogic\.socket\.Muxer.*)''

File I/O

File Read Peak Duration

No long file read pauses were found in this recording (the longest was 21.890 μs).

N/A

File Write Peak Duration

Ignored

Socket I/O

Socket Read Peak Duration

There are long socket read pauses in this recording (the longest is 20.676 s).

The longest recorded socket read took 20.676 s to read 0 B from the host at 10.0.2.100. Average time of recorded IO: 352.765 ms. Total time of recorded IO: 55.384 s. Total time of recorded IO for the host 10.0.2.100: 55.384 s. 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.

Socket Write Peak Duration

No long socket write pauses were found in this recording (the longest was 3.057 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.

Method Profiling

N/A

Method Profiling

Exceptions

N/A

Thrown Errors

Ignored

Thrown Exceptions

The program generated 0.238 exceptions per second during 12/9/2021, 2:32:57.000 PM – 2:37:55 PM.

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.

JVM Internals

Bytecode Verification

The application ran with bytecode verification enabled.

DebugNonSafepoints

DebugNonSafepoints was implicitly enabled in the JVM version used to create this recording.

Discouraged VM Options

No problems were found with the VM options.

Duplicated Flags

There were no duplicate JVM flags on the command line.

N/A

Fatal Errors

Ignored

Flight Recording Support

The JVM version used for this recording has full Flight Recorder support.

GC Setup

No problems were found with the GC configuration.

JFR Periodic Events Fix

The version of Java you are running is not affected by a performance issue related to periodic events.

Discouraged Management Agent Settings

No problems were found with the management agent settings.

Command Line Options Check

No undocumented, deprecated or non-recommended option flags were detected.

Passwords in Java Arguments

The recording does not seem to contain passwords in the application arguments.

Stackdepth Setting

Some stack traces were truncated in this recording.

The Flight Recorder is configured with a maximum captured stack depth of 64. 0.00651 % of all traces were larger than this option, and were therefore truncated. If more detailed traces are required, increase the ''-XX:FlightRecorderOptions=stackdepth=<value>'' value. Events of the following types have truncated stack traces:

Allocation in new TLAB (2.04 % truncated traces)

Garbage Collections

G1/CMS Full Collection

Full GC detected.

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.

Garbage Collection Info

GCs Caused by GC Locker

No GCs were affected by the GC Locker.

GC Pauses

Application efficiency was not highly affected by GC pauses.

The highest ratio between garbage collection pauses and execution time was 0.0817 % during 12/9/2021, 2:32:56.000 PM – 2:33:56 PM. The garbage collection pause ratio of the entire recording was 0.0315 %.

Pause times may be reduced by increasing the heap size or by trying to reduce allocation.

GC Stall

No indications that the garbage collector could not keep up with the workload were detected.

GCs Caused by Heap Inspection

The JVM performed 2 heap inspection garbage collections.

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.

Metaspace Live Set Trend

The class data does not seem to increase during the recording.

GC Pause Peak Duration

The longest GC pause was 48.994 ms.

Metaspace Out of Memory

The metaspace was not exhausted during this recording.

GCs Caused by System.gc()

No garbage collections were caused by System.gc().

GC Configuration

Compressed Oops

The settings for Compressed Oops were OK.

Compilations

Code Cache

N/A

Code Cache

Ignored

Class Loading

Class Leak

java.util.Vector$Itr was loaded 1 time(s) without being unloaded

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:

java.util.Vector$Itr (1)
java.util.Vector$1 (1)
com.sun.management.internal.GcInfoCompositeData$1 (1)
com.sun.management.internal.GcInfoCompositeData$2 (1)
java.rmi.server.UnicastRemoteObject (1)

Class Loading Pressure

No significant time was spent loading new classes during this recording.

VM Operations

VMOperation Peak Duration

No excessively long VM operations were found in this recording (the longest was 49.049 ms).

Biased Locking Revocation Pauses

The application was halted for a total time of 109.823 μs revoking biased locks.

TLAB Allocations

TLAB Allocation Ratio

The program allocated 0.651 % of the memory outside of TLABs.

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.

Environment

Processes

Competing CPU Ratio Usage

An average CPU load of 12 % was caused by other processes for during 12/9/2021, 2:32:57.000 PM – 2:37:57 PM.

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.

N/A

Competing Processes

Ignored

N/A

Process Started

Ignored

Environment Variables

Passwords in Environment Variables

The environment variables in the recording may contain passwords.

The following suspicious environment variables were found in this recording:

AB_JOLOKIA_PASSWORD_RANDOM

. The following regular expression was used to exclude strings from this rule: ''(passworld|passwise)''.

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.

System Properties

Passwords in System Properties

The recording does not seem to contain passwords in the system properties.

Recording

Lost Flight Recorder Buffers

No Flight Recorder buffers were lost during the recording.

N/A

Exceptional Dump Reason

Ignored

Discouraged Recording Settings

These following event types had no threshold:

'Java Monitor Blocked'
'Java Thread Park'

Event types without threshold can lead to quite a lot of events being generated, possibly translating to higher overhead. If this was not intended, please check the settings in the template for future recordings.

Event Browser

N/A

DMS Incidents

Ignored

Biased Locking Revocation

Instances of classes were revoked more times than the user configured limit.

The following instances of classes were revoked more than the configured limit for this rule (not including disabled classes):

java.rmi.NoSuchObjectException (1)

Biased locking is a technique used by the JVM to decrease the cost of uncontended locking to near lock free performance. A thread can bias a lock object to itself, making subsequent locking by the same thread very inexpensive. If the lock starts being used by other threads, the bias can either be revoked, rebiased towards the other thread, or revoked from being biased again for the rest of the runtime of the JVM. Having a lot of revoked classes need not be a problem, but can provide opportunities for optimizations, tuning and design improvements. For example, if you have a lot of contention during the startup of your application, the revocation costs may be significant, and you may want to delay the enablement of biased locking using the ''-XX:BiasedLockingStartupDelay=<time in ms>'' flag. For applications that heavily depend on contended locking, and cannot be redesigned, it may be beneficial to turn off biased locking altogether (''-XX:-UseBiasedLocking''). For benchmarking, you may want to set ''-XX:BiasedLockingStartupDelay'' to zero. The following classes were filtered out:

java.lang.ref.ReferenceQueue$Lock