A programmer's view of performance monitoring in the PowerPC microprocessor

Levine, F. E.; Roth, C.

doi:10.1147/rd.413.0345

“…An HPM counter can be configured to generate an interrupt when the counter value overflows. To provide detailed information on the HPM event that caused the interrupt, POWER6 has two special purpose registers called SIAR (sampled instruction address register) and SDAR (sampled data address register) [9]. The SIAR contains the instruction address of the sampled instruction and the SDAR contains the data address if the sampled event is a memory-related event † .…”

Section: Hpm Of the Power6 Processormentioning

confidence: 99%

How a Java VM can get more from a hardware performance monitor

Inoue

¹

,

Nakatani

²

2009

View full text Add to dashboard Cite

This paper describes our sampling-based profiler that exploits a processor's HPM (Hardware Performance Monitor) to collect information on running Java applications for use by the Java VM. Our profiler provides two novel features: Java-level event profiling and lightweight context-sensitive event profiling. For Java events, we propose new techniques to leverage the sampling facility of the HPM to generate object creation profiles and lock activity profiles. The HPM sampling is the key to achieve a smaller overhead compared to profilers that do not rely on a hardware help. To sample the object creations with the HPM, which can only sample hardware events such as executed instructions or cache misses, we correlate the object creations with the store instructions for Java object headers. For the lock activity profile, we introduce an instrumentation-based technique, called ProbeNOP, which uses a special NOP instruction whose executions are counted by the HPM. For the contextsensitive event profiling, we propose a new technique called CallerChaining, which detects the calling context of HPM events based on the call stack depth (the value of the stack frame pointer). We show that it can detect the calling contexts in many programs including a large commercial application. Our proposed techniques enable both programmers and runtime systems to get more valuable information from the HPM to understand and optimize the programs without adding significant runtime overhead.

show abstract

“…To provide detailed information on the HPM event that caused the interrupt, POWER6 has two special purpose registers called SIAR (sampled instruction address register) and SDAR (sampled data address register) [9]. The SIAR contains the instruction address of the sampled instruction and the SDAR contains the data address if the sampled event is a memory-related event † .…”

Section: Hpm Of the Power6 Processormentioning

confidence: 99%

How a Java VM can get more from a hardware performance monitor

Inoue

¹

,

Nakatani

²

2009

Proceedings of the 24th ACM SIGPLAN Conference on Object Oriented Programming Systems Languages and Applications

View full text Add to dashboard Cite

This paper describes our sampling-based profiler that exploits a processor's HPM (Hardware Performance Monitor) to collect information on running Java applications for use by the Java VM. Our profiler provides two novel features: Java-level event profiling and lightweight context-sensitive event profiling. For Java events, we propose new techniques to leverage the sampling facility of the HPM to generate object creation profiles and lock activity profiles. The HPM sampling is the key to achieve a smaller overhead compared to profilers that do not rely on a hardware help. To sample the object creations with the HPM, which can only sample hardware events such as executed instructions or cache misses, we correlate the object creations with the store instructions for Java object headers. For the lock activity profile, we introduce an instrumentation-based technique, called ProbeNOP, which uses a special NOP instruction whose executions are counted by the HPM. For the contextsensitive event profiling, we propose a new technique called CallerChaining, which detects the calling context of HPM events based on the call stack depth (the value of the stack frame pointer). We show that it can detect the calling contexts in many programs including a large commercial application. Our proposed techniques enable both programmers and runtime systems to get more valuable information from the HPM to understand and optimize the programs without adding significant runtime overhead.

show abstract

“…The Motorola PowerPC 604e microprocessor provides hardware assists to monitor and count predefined events such as cache misses, mispredicted branches, and issued instructions [12,18]. Because the scheduler switches a processor's execution among multiple processes, and because statistics about a particular process may be of interest, a process can be marked for runtime profiling.…”

Section: Runtime Performance Monitormentioning

confidence: 99%

Approximation of Worst-Case Execution Time for Preemptive Multitasking Systems

Corti

¹

,

Brega

²

,

Groß

³

2001

Lecture Notes in Computer Science

View full text Add to dashboard Cite

The control system of many complex mechatronic products requires for each task the Worst Case Execution Time (WCET), which is needed for the scheduler's admission tests and subsequently limits a task's execution time during operation. If a task exceeds the WCET, this situation is detected and either a handler is invoked or control is transferred to a human operator. Such control systems usually support preemptive multitasking, and if an object-oriented programming language (e.g., Java, C++, Oberon) is used, then the system may also provide dynamic loading and unloading of software components (modules). Only modern, state-of-the art microprocessors can provide the necessary compute cycles, but this combination of features (preemption, dynamic un/loading of modules, advanced processors) creates unique challenges when estimating the WCET. Preemption makes it difficult to take the state of the caches and pipelines into account when determining the WCET, yet for modern processors, a WCET based on worst-case assumptions about caches and pipelines is too large to be useful, especially for big and complex real-time products. Since modules can be loaded and unloaded, each task must be analyzed in isolation, without explicit reference to other tasks that may execute concurrently. To obtain a realistic estimate of a task's execution time, we use static analysis of the source code combined with information about the task's runtime behavior. Runtime information is gathered by the performance monitor that is included in the processor's hardware implementation. Our predictor is able to compute a good estimation of the WCET even for complex tasks that contain a lot of dynamic cache usage, and its requirements are met by today's performance monitoring hardware. The paper includes data to evaluate the effectiveness of the proposed technique for a number of robotics control kernels that are written in an objectoriented programming language and execute on a PowerPC 604e-based system.

show abstract

A programmer's view of performance monitoring in the PowerPC microprocessor

Cited by 14 publications

References 5 publications

How a Java VM can get more from a hardware performance monitor

How a Java VM can get more from a hardware performance monitor

How a Java VM can get more from a hardware performance monitor

Approximation of Worst-Case Execution Time for Preemptive Multitasking Systems

Contact Info

Product

Resources

About