Information Technology Reference
In-Depth Information
are differences. For example, the JVMTI provides
application-specific details, such as the method
name, object name, class name, and parameters,
from the calls, whereas the CLR interface pro-
vides them in a metadata format and details can
only be extracted using the metadata API, which
is tedious. The JVMTI also provides additional
features compared to the CLR, including monitor
wait and monitor waited, which provide informa-
tion related to thread blocking on critical sections
of code.
Research (Reiss, 2003, 2005) has shown that
the JVMTI interface incurs significant runtime
overhead because the profiling agent is written in
a native language, so JNI calls (Sun Microsystems
Corporation, 2002) are needed to call this agent.
JNI calls can incur significant overhead because
they perform actions such as saving registers,
marshaling arguments, and wrapping objects
in JNI handles (Dmitriev, 2002). This overhead
may not be acceptable for some applications, so
the explicit bytecode instrumentation approach
described in the next section may be a less costly
solution because it does not use JNI.
tions triggered by specific events. This approach
en ables the use of application-specific events for
profiling, such as transac tion completion or data
regarding critical sections of the application.
Bytecode instrumentation has in most instances
less overhead and greater flexibility than using
VM-provided profiling interfaces. Nevertheless,
the responsibility of implementing measurement
functionality lies with the profiler user.
There are several approaches to bytecode
instrumentation, including:
•
Static instrumentation, which involves
changing the compiled code off-line be-
fore execution that is, creating a copy of
the instrumented intermediate code. Many
commercial profilers, such as OptimizeIt
(Borland Software Corporation, 2006),
work this way. Static instrumentation has
also been implemented by Reiss (2003) and
later extended in Reiss (2005).
•
Load-time instrumentation, which calls the
agent before loading each class, and passes it
the bytecode for the class that can be changed
by the agent and returned. The JVMTI/CLR
profiler interfaces are examples of load-time
instrumentation.
application code instrumentation
A l t h o u g h s a m p l i n g - a n d h o o k- b a s e d i n s t r u m e n t a -
tion can be performed with relatively little over-
head, the breadth of the information collected is
limited and often insufficient to build application-
level detail. An alternative is to instrument the
application's bytecode directly. Bytecode instru-
mentation inserts functionality (in the form of
additional bytecodes) that performs application
profiling within compiled code. The Komorium
work discussed previously is a form of byte code
instrumentation. However, we differentiate the
discussion in this section by instrumentation that
is driven directly by the application logic.
As a general approach, bytecode instrumen-
tation involves redefining classes that are going
to be profiled by re placing the original bytecode
with instrumented code that contains logging ac-
•
Dynamic instrumentation, which works
when the application is already running
and also uses a profiler interface (Dmitriev,
2002). The agent makes a call to the VM
passing it the new definitions of the classes
that are installed by the VM at runtime.
Like other forms of code modification, dynam-
ic instrumentation supports “fix and continue”
debugging, which avoids lengthy exit, recompile,
and restart cycles. It also helps reduce application
overhead by enabling developers to (1) pinpoint
specific regions of code that are experiencing per-
formance problems at runtime and (2) instrument
the classes' involved, rather than instrumenting
the entire application. Instrumented classes can
be replaced with the original ones after sufficient
data is collected.
Search WWH ::
Custom Search