Dynamic Analysis and Profiling of Multithreaded Systems - Advanced Operating Systems and Kernel Applications - page 181

Figure 10. Applications running on virtual machine

Sampling-Based VM Profiling These problems can be avoided by using

techniques described in Subramaniam and
Thazhuthaveetil (1994). To obtain a consistent pic-
ture of application behavior, however, a significant
number of runs must be performed. This number
will vary from application to application, so the
sampling period may also require configuration
for each application.

One approach to profiling applications that execute
in a VM environment is to sample the execu-
tion state (i.e., program counter value and call
stack) at periodic timer-driven intervals. Whaley
(2000) demonstrates the use of such timer-driven
sampling via a “samping profiler” that examines
threads within the JVM process corresponding to
the Java application being profiled. The profiler
then periodic traverses the operating system's
thread queues, and for each active Java thread,
retrieves the register state (program counter and
stack pointer) as well as the current time. In effect,
this is a combination of operating system level
profiling with the restriction on VM processes
(i.e., crossing the OS-VM boundary).
Although sampling-based profiling meth-
ods are relatively lightweight, they are sus-
ceptible to certain problems (Subramaniam &
Thazhuthaveetil, 1994), including:

Bytecode Counting

Another instance of VM sampling-based profiling
is Komorium (Binder, 2005). Komorium does not
check the program counter at regular intervals.
Instead, a snapshot of the call stack is recorded by
each thread after a certain number of bytecodes
are executed. The motivation for this approach is
that bytecode counting is a platform-independent
metric that does not depend upon VM-specific
profiling services. Bytecode counting can also be
done without on the need for low-level platform-
dependent utilities to acquire resource usage
data, thus making it more portable and easier to
maintain.
Komorium relies on the periodic activation of
a user-defined profiling agent to process samples
of the call stack. Bytecode rewriting is used to
pass the current call stack of the caller into the
profiling function. To schedule regular activation
of the custom profiling function, each thread
maintains an activation counter (ac) that represents
the upper bound of the number of executed byte-
codes since the last invocation. The active count
is decremented at given points in the code. The

• Straddling effect of counters: the initial

analysis to segregate the bytecode for dif-
ferent methods will be approximate, causing
inconsistent results;

• Short submethods: short-lived calls that

take less time than the sampling frequency
may not be recorded at all; and

• Resonance effects: the time to complete a

single iteration of a loop can coincide with
the sampling period, which may sample the
same point each time, while other sections
are never measured.