VMC profiling provides options for analyzing memory consumption, runtime, Java methods and exceptions, and synchronization.
You can activate the following statistics and traces for analyzing memory consumption:
● Object allocations
The number and memory size of all object instantiations provide information about objects that are especially large or frequently created.
● Class statistics
The number and memory size of all "live" (still referenced) objects within a VM following interim GCs provide information about how long an application object lives. Objects that live unexpectedly long can indicate a memory leak.
● Reference chains
The reference chains of all objects still alive after a GC can indicate which objects are being kept alive by other objects, possibly indirectly across several other references. This analysis can also be useful if a leak is discovered.
● Object assignments
The value and reference assignments of individual objects provide information about which instance holds a reference to the object and in which method the assignment is made. The list is created on the thread activities screen, and not in a separate view.
● Local VM garbage collection
The total memory size of all the object types before and after garbage collections within individual VMs provides information about whether the memory areas for the GC object generations (young, old) are configured adequately.
More information: How the Local Garbage Collector Works
● Shared garbage collection
The number and memory size of the object types of shared VM objects before and after a shared GC provide information about the memory dynamics within the shared memory area of the VM Container.
More information: How the Shared Garbage Collector Works
● Shared closure operations
The returned data provides information about the size and frequency of individual shared closure versions that have been created, copied, mapped, and deleted.
More information: Shared Closures
You can activate the following statistics for analyzing runtime (performance):
Method sampling: The values of the individual methods in the total runtime of the application provide information about methods that are called particularly frequently or run for a particularly long time. This information helps to identify possible places where performance could be optimized.
The frequency values are measured, and not the runtime values, since the methods found directly on the Java stack are determined only at regular intervals (based on an internal timer). The statistical error, should, however be negligible.
The difference between a method being found at the top of the stack or just somewhere in the stack indicates whether the method itself has been running for a long time or whether it has been called particularly frequently.
The following traces can be activated to analyze the process flow of an application:
● Java exceptions
Frequency and code locations where Java exceptions that are:
○ Thrown with the THROW command
○ Caught with the CATCH command
○ Processed with the FINALLY command
○ Deleted with the CLEAR JNI command
provide information about whether and how error situations within the application can be processed, and this can be useful for debugging an application.
● Method Trace
The list of entry and exit locations of the individual methods provides information about the control flow of the application, which can useful for debugging an application. Note: The list is not created in a separate view, but as part of the thread activities display.
The following statistics and traces can be activated for analyzing synchronizations.
● Monitor Trace
The list of operations on Java monitoring objects from individual VMs provides information about thread synchronization problems within the VM. For example, "wait leaks" could cause "hanging" threads. This means a thread goes into "wait" status, after the expected "notify" operation of another thread is already completed. Note: The list is not created in a separate view, but as part of the thread activities display.
● Shared Lock Trace
Lists the frequency, wait times, and hold times set for different types of shared VM locks. This provides information about synchronization problems between the VMs and about possible escalation problems (contention) when accessing VMC or system resources at the same time.