A real system evaluation of hardware atomicity for software speculation

Abstract

In this paper we evaluate the atomic region compiler abstraction by incorporating it into a commercial system. We find that atomic regions are simple and intuitive to integrate into an x86 binary-translation system. Furthermore, doing so trivially enables additional optimization opportunities beyond that achievable by a high-performance dynamic optimizer, which already implements superblocks. We show that atomic regions can suffer from severe performance penalties if misspeculations are left uncontrolled, but that a simple software control mechanism is sufficient to reign in all detrimental side-effects. We evaluate using full reference runs of the SPEC CPU2000 integer benchmarks and find that atomic regions enable up to a 9% (3% on average) improvement beyond the performance of a tuned product. These performance improvements are achieved without any negative side effects. Performance side effects such as code bloat are absent with atomic regions; in fact, static code size is reduced. The hardware necessary is synergistic with other needs and was already available on the commercial product used in our evaluation. Finally, the software complexity is minimal as a single developer was able to incorporate atomic regions into a sophisticated 300,000 line code base in three months, despite never having seen the translator source code beforehand.

Acceldroid: Co-designed acceleration of Android bytecode

“…The existing DBT on Efficeon cannot achieve that because after the DVM translates bytecode into X86 code, all the nullpointer and array-bound checks become the normal conditional branches, and the high level information that they are extremely biased branches is lost and therefore the DBT won't be able to leverage it for converting the checks into asserts. Naveen et al [11] experimented a dynamic feedback based technique to identify biased branches and convert them into asserts, but their reported benefit is much smaller than ours because our approach leverages high level bytecode information.…”

“…First, we leverage the internal LINKPIPE feature [21] in Efficeon to reduce indirect branch mis-predictions during the interpretation of cold bytecode. Second, we leverage the internal SPECULATION feature [4] [11] in Efficeon for efficient bytecode null-pointer and arraybound checks. Third, we leverage the internal FLOOK [21] feature in Efficeon for the efficient translation of bytecode function calls and returns.…”

Allocating rotating registers by scheduling

“…The target architecture is a VLIW processor similar to Transmeta Efficeon [12], but besides the 14 static alias registers, it also has a variable-sized rotating alias register file. The rotating alias register file has not been implemented in any commercial processor yet, and thus a product-quality functional simulator is used in the experiments here.…”

“…In this paper, we focus only on modulo scheduling, and use the two terms, modulo scheduling and software pipelining, interchangeably. We assume a loop body is a hyperblock [11], where branches, if any, have been converted either to predicated code [3], or to asserts [12].…”

DeAliaser

“…Speculative code optimizations in atomic regions have been applied to control speculation over a hot trace of code [15,29,30,32]. When these traces of code are generated to enable on-the-fly optimization of uops translated from machine instructions [7,8,15,29], the atomic regions are also used to support precise exceptions at the machine level.…”