Evaluating Application Analyses
Use
The application analysis contains the method trace of the application as well as tasks for Java exceptions that occurred while the application was running.
Prerequisites
You have closed a profiling session in which you had activated recording of the application data. You are now in the evaluation overview for this session.
More information: Evaluating Profiling Data
Procedure
Depending on which analyses you had activated for your profiling session, you can now evaluate them.
Evaluating Java Exceptions
...
In the navigation structure, choose the node Application Analysis→ Exception Trace.
On the right-hand side a table appears containing the Java exceptions recorded during the profiling session in all the VMs of the VM Container. The table contains the:
● Name of the exception class
● The number of times the exception occurred
This information indicates whether errors are dealt with appropriately and what their causes may be.
All table rows have a triangle at the front to indicate that the rows can be expanded by double-clicking on them, and then detailed information is displayed in the expanded rows. In this case this information is the results of the four exception operations (throw, catch, finally, and clear JNI).
● THROW: This number specifies the number of different method locations where the exception was thrown. If you expand the row by double-clicking on the triangle symbol at the front, these different locations are displayed in as many rows in the form of stack traces. A stack trace contains the following information:
○ The uppermost method on the stack with class names, method names, and line numbers, which enables you to quickly identify the position in the code where the exception was thrown.
○ The number of times the exception was thrown in this location.
○ If you double-click on the stack trace line, the display expands to show the depth to which the stack was recorded in the profiling session.
● CATCH: This number specifies the number of different method locations where the exception was caught. If you expand the line by double-clicking on the triangle symbol at the front, these different locations are displayed in as many different lines:
○ Class names, method names, and line numbers, enabling you to quickly identify the position in the code where the exception was caught.
○ The number of times the exception was caught at this position.
● FINALLY: The number of different "finally" blocks of the Java program where the exception was handled. Since processing of the "finally" block is only registered if an exception is present, and not if the program is running normally, only those exceptions that were not previously caught by a catch command are included in this number. Like the CATCH lines, FINALLY lines contain method locations that can be expanded.
● CLEAR JNI: The number specifies the number of different method locations where an exception was explicitly deleted by a Java Native Interface (JNI) command. Since this type of error handling should only be used in low-level programs, these table entries should not normally occur in standard Java application programs. Like the CATCH lines, CLEAR JNI lines contain method locations that can be expanded.
The table rows allow for only a limited number of characters for the names of method locations. If a text line is truncated, you can display it in full in a popup using the context menu (by clicking on the right mouse button).
By default the table is sorted in descending order by the number of thrown exceptions, which means that you can quickly identify the most frequently occurring error situations.
Together with the table containing exception operations, entries are always made in the thread trace too. These can be displayed in the evaluation of thread activities (see below).
Evaluating Method Traces (Thread Activities)
In the navigation structure, choose the node Application Analysis→ Thread Activities.
On the right-hand side you will get a table containing the method calls that were running during the profiling session in the individual threads of a VM (in chronological order).
In the header line select the number of the VM and the thread whose activities you want to view.
The threads can be selected from a dropdown list. Possible entries are:
● RFC Server (in process): The thread has processed a Java application program, which was in the same work process as the calling ABAP program was running in. The call was made through remote function call (RFC).
● RFC Server (out of process): The thread has processed a Java application program, though the calling ABAP program was running in a different work process, or on a different application server, or even in a different system. The call was made through remote function call (RFC).
● VMC Event Container, VM Control Handler and VM Message Handler: These three threads belong to the VM Container framework, and process events, shared VM variables, or messages exchanged between VMs.
● Reference Handler and Finalizer: These two internal VM threads process reference objects or Java objects declared as "final" in the context of garbage collections.
Threads that were started by the application itself also appear in the list.
The entries in the thread selection box are sorted in descending order by the number of activities in the traces. Since by default the results of the top entry are displayed in the table, you immediately see the results of the most important thread.
The table in the upper section of the screen contains the results for the thread in question. Since one thread may have a large number of activities, if necessary, the results are divided into groups. You can expand the group by double-clicking on the triangle symbol at the front of the row. The activities are listed separately in the expanded lines.
Thread Activities
Activities that affect the thread contain "thread" in the results line.
Examples are lines with "set thread" value assignments for thread name, client, user, session name, component name, application name, or request.
Depending on which traces had been selected for the profiling session, the table may contain other entries too:
● Object assignments (for memory analysis),
● Method traces (for application analyses)
● Java exceptions (for application analysis)
● Monitor traces (for synchronization)
● Shared lock traces (for synchronization)
More information: Creating and Starting New Sessions.
Object Assignments
Activities recorded for the object assignments, have the format "assign to", and indicate assignments, for example, to:
● Class variables
● Known and unknown instance variables
● Slots of array variables
A click on a result line displays a screen with details of source and target objects of an assignment, and details of the thread and method location where the objects were assigned.
Method Trace
Activities recorded in the method trace have the format:
"call" <method location> "from" <method location> or
"return from" <method location> "to" <method location>.
<method location> refers to the class and method name, and the code line number of the calling or called method. A triangle symbol at the front of a result line indicates a nested method call. By double-clicking on the triangle symbol you can expand the call hierarchy.
If you click on a result line, a screen appears with details of the calling method, the called method, and the thread itself. If you expand the lines containing caller" or "callee", the following information about the calling or called method is displayed:
● Class name including packet name
● Class and instance variables
● Class loader of the class
● The same information about all superclasses, if there are any.
● Method location with name, signature, and line number in the source code
The following information about the thread is displayed:
● Internal thread ID
● Thread name
● User data (client, user name)
● Application name and component name (of deployed "applications"; see Displaying Applications
● Session name
● Request name
Java Exceptions
Exception operations recorded for the analysis of Java exceptions also appear in the thread activities and have the format:
● "throw <exception class> in <method location>"
● "catch <exception class> in <method location>"
● "finally <exception class> in <method location>"
● "clear (JNI) <exception class> in <method location>"
If you click on a results line a screen appears in with details of the exception class, thread, and method location.
Monitor Trace
Activities recorded in the monitor trace have the format "wait on monitor of <object ID>" or "notify all threads waiting on monitor of <object ID>".
If you click on a result line, a screen appears with details of the monitor, the waiting threads, if applicable, the notified threads, and the method location where the monitor operation took place.
Shared Lock Trace
Activities recorded in the shared lock trace have the format:
"shared lock <lock name> <lock type> enter" or "shared lock <lock name> <lock type> leave"
and indicate the receipt or release of a shared VM lock.
If you click on a results line, a screen appears with details of the lock operation, thread, and method location where the operation took place.
More Information