-
Executors
The call site is the last profiled method before a task is handed off to an
executor service from the java.util.concurrent
package. The execution site is in the thread
that executes the task.
For example, if you call
Executors.newSingleThreadExecutor().submit(new Runnable() {
public void run() {
// your code
}
});
the enclosing method that calls submit
is the call site, and the code below // your code
is the execution site.
Executors are used by many higher-level libraries for managing asynchronous executions, those libraries
are implicitly supported by this request tracking type.
-
AWT
The call site is last profiled method before a deferred action is posted to the AWT event queue with
EventQueue.invokeLater(...)
or similar. The execution site is always in the event dispatch thread.
For example, if you call
EventQueue.invokeLater(new Runnable() {
public void run() {
// your code
}
});
the enclosing method that calls invokeLater
is the call site, and the code below // your code
is the execution site.
Together with the default entry in the exceptional method configuration,
this feature provides a way to comprehensively analyze long-running AWT events.
-
SWT
The call site is the last profiled method before a deferred action is posted on the UI thread with
Display.getDefault().asyncExec(...)
or similar. The execution site is always in the UI thread.
For example, if you call
Display.getDefault().asyncExec(new Runnable() {
public void run() {
// your code
}
});
the enclosing method that calls asyncExec
is the call site, and the code below // your code
is the execution site.
-
Thread start
The call site is the last profiled method before Thread.start()
is called.
The execution site is a a top-level node in the started thread. If multiple threads
are merged, each recorded execution site is still displayed separately.
For example, if you call
new Thread() {
public void run() {
// your code
}
}.start();
the enclosing method that calls start
is the call site, and the code below // your code
is the execution site.
Request tracking for threads can add a lot of nodes into your call trees that may be hard to interpret, because threads
are started by the JRE in ways that are not immediately obvious. It is recommended to use thread start request tracking
only in the case of a related problem.