Virtual machines face significant performance challenges beyond those confronted by traditional static optimizers. First, portable program representations and dynamic language features, such as dynamic class loading, force the deferral of most optimizations until runtime, inducing runtime optimization overhead. Second, modular

Execution profiles have become increasingly important for guiding code optimization. However, little has been done to develop ways to check automatically that a profile does, in fact, reflect the actual execution behavior of a program. This paper describes a framework that uses program monitoring techniques in a way that allows the automatic checking of a wide variety of profile data. We also describe our experiences with using an instance of this framework to check edge profiles. The profile checker uncovered profiling anomalies that were previously unknown and that would have been very difficult to identify using existing techniques.

The instruction cache is a popular target for optimizations of microprocessor-based systems because of the cache's high impact on system performance and power, and because of the cache's predictable temporal and spatial locality. Optimization techniques can be designed based on this predictability. We explore for the first time the interplay of two popular instruction cache optimization techniques: the long-known technique of code reordering and the relatively-new technique of cache configuration. We address the question of whether those two optimizations complement each other or if one optimization dominates the other. Through experiments using embedded system benchmarks, we show that cache configuration dominates a particular category of code reordering techniques with respect to optimizing performance and energy, obviating the need for reordering. We also examine the modern scenario of synthesized custom caches, and show that combining cache configuration with code reordering results in cache size reductions of 13% on average, and up to 89% in some benchmarks, beyond just cache configuration alone.

In modern superscalar microarchitectures that speculatively execute a great quantity of code, without performing branch prediction, it won’t be possible to aggressively exploit program’s instruction level parallelism. Both the architectural and technological complexity of current processors emphasizes the negative impact on performance due to every branch missprediction. Due to this importance, branch prediction becomes a core topic in Computer Architecture curricula. The fast development of computer science and information technology domains, and of computer architecture especially, have determined that many software tools used not far ago in research, to be enhanced with an interactive graphical interface and to be taught in Introductory Computer Organization respectively Computer Architecture courses. The lack of simulators dedicated to branch prediction used in didactical purposes despite of plenty used in research goals, represents the starting point of this paper. The main aim of this work consists in identifying the difficult-to-predict branches, quantifying them at benchmarks level and finding the relevant information to reduce their numbers. Finally, we evaluate the impact of these branches on three commonly used

Understanding the performance impact of compiler optimizations on superscalar processors is complicated because compiler optimizations interact with the microarchitecture in complex ways. This paper analyzes this interaction using interval analysis, an analytical processor model that allows for breaking total execution time into cycle components. By studying the impact of compiler optimizations on the various cycle components, one can gain insight into how compiler optimizations affect out-of-order processor performance. The analysis provided in this paper reveals various interesting insights and suggestions for future work on compiler optimizations for out-of-order processors. In addition, we contrast the effect compiler optimizations have on out-of-order versus in-order processors. 1