Profiler - Instrumentation

Full Instrumentation vs. Sampled Instrumentation

During CPU profiling, a "method entry" call is injected at the beginning of each profiled method, and a "method exit" call before each return. These "method entry"/"method exit" calls generate a timestamp. The difference between full and sampled instrumentation is when the timestamp on the instrumented methods is taken:

  • Full instrumentation mode

    Each "method entry" and "method exit" call generates a timestamp, and the time spent in the method is calculated as a difference between these timestamps.

  • Sampled instrumentation mode

    Timestamps are taken only on those "method entry"/"method exit" call that fall approximately at the end of each specified sampling period.

Full Instrumentation

When the default full instrumentation is used, both the "method entry" and "method exit" injected calls record the timestamp every time each of them is invoked. The execution time for a target application method is calculated as the difference between the two timestamps. In this way, you get locally precise timings.

The drawback to this is that the overhead of the OS call that returns a high-resolution timestamp is pretty high – on the order of a few hundred nanoseconds on machines running the Solaris and Linux operating systems, and over 1 microsecond on machines running Windows. Thus, if your application contains a lot of small methods (a few lines of code) executed frequently, you may discover that the overhead when using full instrumentation is very high - between a few tens and a few thousand percent, depending on the application.

Sampled instrumentation

Sampled instrumentation is a hybrid method that provides the advantages of both the traditional instrumentation (counting the exact number of method invocations) and traditional sampling technique (small overhead). When this method is used, the "method entry" and "method exit" calls count the number of invocations, but don't take a timestamp every time they are called. Instead, they check a per-thread flag that a separate thread of execution, managed by Profiler, sets at a specified period.

When the flag for a thread is true, the next call to "method entry"/"method exit", whichever comes first, takes a timestamp. It then charges the difference between this timestamp and the previous one recorded in the same way, to the method that is currently on top of the thread's stack. In this way, the number of calls to the OS high-precision timer is reduced dramatically.

For highly call-intensive applications that make around 10,000 – 1,000,000 calls per second, this translates into a very significant overhead reduction (10 times or more). Furthermore, it appears that for such applications this profiling method may actually give more precise results. This is because it tends to create less disruption to optimizations that the dynamic compiler in the JVM and the CPU may apply in the course of the program execution.

The only drawback of this scheme is that it will not give you precise results for methods that are executed infrequently and for a short time. However, unlike traditional sampling, it will at least record the exact number of invocations for these methods.

Which should you choose?

Our advice for choosing a profiling method is to start with full instrumentation. If you observe that the overhead is 100 per cent or greater, and the call intensity is more than 10,000/second (usually both things come together), consider switching to sampled instrumentation. For highly call-intensive applications, results produced by full and sampled instrumentation may be slightly different. In this case, sampled instrumentation typically produces more accurate results for the top 10-20 methods, whereas full instrumentation is more accurate for the rest of the application code.

See also


Project Features

About this Project

Profiler was started in November 2009, is owned by Tomas Hurka, and has 62 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
Please Confirm