Home

SCS - Callstack Sampling


Overview

Callstack sampling uses timer ticks or other events in the same way as time profiling (TPROF). However, instead of merely recording the address being executed, it calls the JVM to record the entire callstack for that thread. By treating this callstack as if it were a series of method entries and exits, the information can be stored in the same way that callflow information is stored. This allows callflow analysis of an application with far less overhead than would be encountered by handling all of the method entry and exit events.

Performance Inspector uses callstack sampling in two different modes: either driven by platform independent JVM events, such as memory allocations or monitor events, or driven by events generated by a platform specific device driver.

The platform independent mode is very useful for identifying the context in which events occur. Although the overhead of getting the callstack information varies by the depth of the callstack, the impact on the execution of the application is usually minimal because the events do not occur often and only occur on one thread at a time.

However, when callstack sampling is used to replace TPROF, using events generated by the device driver, complications arise when running on multi-processor systems. Unlike TPROF, which only needs to get the current execution address on each processor, a series of spin loops is required to prevent one processor from making forward progress while the JVM gets the callstack information on another processor. So far, the code to handle this has only been implemented on Windows, but Linux support should be available soon.


Examples

The best way to explain anything is through examples. We have a page of examples of common tasks which is worth reading. The following are examples specific to callstack sampling:
Home