tang-IT ARM: ARM 4.0 agent for C/C++

The ARM 4.0 standard by The Open Group specifies language bindings for C/C++ and Java programming languages. We support both bindings and in this document the C/C++ part is described in more detail.

C versus C++

The ARM 4.0 standard only defines a C API which can be used in C++ as well. The reason why there is no real C++ API is due to the fact how ARM is deployed within a system.

One major goal of ARM is that any application which is instrumented with a certain version of ARM should be able to run with any installed ARM agent of that version. But currently there exists no real application binary interface (ABI) standard for C++ language. A compiler vendor can choose its own way how the compiler layouts objects or mangles class/method names to linker symbols. So different ARM implementations could have different object layouts and different linker symbol names.

This problem does not arise within plain ANSI-C programs.

C Agent shared library architecture

The main part of the ARM agent is the shared library (object) which implements the ARM 4.0 C API. Each ARM instrumented application is linked against this library. The library base name is arm4 and for example libarm4.so is used under Linux and Solaris platforms, whereas libarm4.dll is used on Windows platforms.

Agent shared library overview
Figure 1: Agent shared library overview

Figure 1 also shows that the libarm4.so library in turn uses different backend shared libraries which are loaded at runtime according to the current backend configuration. Here the MySQL backend library libmysqlsink.so is shown which stores any ARM data which is passed from the libarm4.so library into a MySQL database. For a complete list of supported backends please have a look at our backend page.

Multi-threading versus Single-threading

The ARM 4.0 standard says that any ARM implementation has to be thread-safe. This is sensible, but providing one library for both single- and multi-threaded applications, is not perfect regarding overhead in a single-threaded application. Therefore tang-IT ARM provides two libraries:

  1. the default libarm4.so for multi-threaded environments.
  2. libarm4_st.so for single-threaded environments.

Linking against this single-threaded version is not really standard compliant, but makes more sense to us, so we provide this feature in tang-IT ARM.

Granularity of response times

The ARM 4.0 standard defines the granularity of response times in nano seconds. Considering today's modern hardware this is a wise decision. However defining is one thing, implementation is the other. tang-IT ARM provides this nano second granularity on platforms which support high resolution timers. The following table shows the granularity for each platform:

Platform Response time Stop time Comments
Linux (x86, TSC) nano seconds milli seconds Processor timestamp counter (TSC) (if available, not used on multi-processor machines and laptops)
Linux (x86) micro seconds milli seconds Using gettimeofday() system call
Linux (ppc) micro seconds milli seconds Using gettimeofday() system call
Solaris (sparc) nano seconds milli seconds Using gethrtime() system call
Tru64 UNIX (alpha) micro seconds milli seconds Using gettimeofday() system call

Performance impact

Measuring any business or technical transactions need to execute by itself. Therefore getting measurement information is not just for free. In order to decide if the instrumentation does not significantly interfere the real application tasks, it is probably good to know the performance impact of the instrumentation. As of its nature it is highly hardware and platform dependent; with higher performing processors the performance impact of the measurement decreases expressed in real time.

From our internal measurements we can say that the impact of tang-IT ARM is less than a few micro seconds per transaction on modern hardware. However it depends on various factors. If you need a more detailed answer please have a look on our internal measurement summary page which will be available soon.