Optionally typed languages enable direct performance comparisons between untyped and type annotated source code. We present a comprehensive performance evaluation of two different JIT compilers in the context of ActionScript, a production-quality optionally typed language. One JIT compiler is optimized for quick compilation rather than JIT compiled code performance. The second JIT compiler is a more aggressively optimizing compiler, performing both high-level and low-level optimizations.

Since their inception, the usage pattern of web browsers has changed substantially. Rather than sequentially navigating static web sites, modern web browsers often manage a large number of simultaneous tabs displaying dynamic web content, each of which might be running a substantial amount of client-side JavaScript code. This environment introduced a new degree of parallelism that was not fully embraced by the underlying JavaScript virtual machine architecture. We propose a novel abstraction for multiple disjoint JavaScript heaps, which we call compartments. We use the notion of document origin to cluster objects into separate compartments.Objects within a compartment can reference each other directly. Objects across compartments can only reference each other through wrappers. Our approach reduces garbage collection pause times by permitting collection of sub-heaps (compartments), and we can use cross-compartment wrappers to enforce cross origin object access policy.

JavaScript is a highly dynamic language for web-based applications. Innovative implementation techniques for improving its speed and responsiveness have been developed in recent years. Industry benchmarks such as WebKit SunSpider are often cited as a measure of the efficacy of these techniques. However, recent studies have shown that these benchmarks fail to accurately represent the dynamic nature of modern JavaScript applications, and so may be poor predictors of real-world performance. Worse, they may guide the development of optimizations which are unhelpful for real applications. Our goal is to develop a tool and techniques to automate the creation of realistic and representative benchmarks from existing web applications. We propose a record-and-replay approach to capture JavaScript sessions which has sufficient fidelity to accurately recreate key characteristics of the original application, and at the same time is sufficiently flexible that a recording produced on one platform can be replayed on a different one. We describe JSBench, a flexible tool for workload capture and benchmark generation, and demonstrate its use in creating eight benchmarks based on popular sites. Using a variety of runtime metrics collected with instrumented versions of Firefox, Internet Explorer, and Safari, we show that workloads created by JSBench match the behavior of the original web applications.

In a Multi-Variant Execution Environment (MVEE), several slightly different versions of the same program are executed in lockstep. While this is done, a monitor compares the behavior of the versions at certain synchronization points with the aim of detecting discrepancies which may indicate attacks.As we show, the monitor can be implemented entirely in user space, eliminating the need for kernel modifications. As a result, the monitor is not a part of the trusted code base.We have built a fully functioning MVEE, named Orchestra, and evaluated its effectiveness. We obtained benchmark results on a quad-core system, using two variants which grow the stack in opposite directions. The results show that the overall penalty of simultaneous execution and monitoring of two variants on a multi-core system averages about 15% relative to unprotected conventional execution

Dynamic languages such as JavaScript are more difficult to compile than statically typed ones. Since no concrete type information is available, traditional compilers need to emit generic code that can handle all possible type combinations at runtime. We present an alternative compilation technique for dynamically-typed languages that identifies frequently executed loop traces at run-time and then generates machine code on the fly that is specialized for the actual dynamic types occurring on each path through the loop. Our method provides cheap inter-procedural type specialization, and an elegant and efficient way of incrementally compiling lazily discovered alternative paths through nested loops. We have implemented a dynamic compiler for JavaScript based on our technique and we have measured speedups of 10x and more for certain benchmark programs.

Today's web applications are pushing the limits of modern web browsers. The emergence of the browser as the platform of choice for rich client-side applications has shifted the use of in-browser JavaScript from small scripting programs to large computationally intensive application logic. For many web applications, JavaScript performance has become one of the bottlenecks preventing the development of even more interactive client side applications. While traditional just-in-time compilation is successful for statically typed virtual machine based languages like Java, compiling JavaScript turns out to be a challenging task. Many JavaScript programs and scripts are short-lived, and users expect a responsive browser during page loading. This leaves little time for compilation of JavaScript to generate machine code.We present a trace-based just-in-time compiler for JavaScript that uses run-time profiling to identify frequently executed code paths, which are compiled to executable machine code. Our approach increases execution performance by up to 116% by decomposing complex JavaScript instructions into a simple Forth-based representation, and then recording the actually executed code path through this low-level IR. Giving developers more computational horsepower enables a new generation of innovative web applications.

While memory-safe and type-safe languages have been available for many years, the vast majority of software is still implemented in type-unsafe languages such as C/C++. Despite massive concerted efforts by software vendors such as Microsoft to eliminate buffer overflow vulnerabilities through automated and manual code review, they continue to be found and exploited. We present a novel approach that accepts the existence of overflow vulnerabilities and uses parallelism available through current and future multi-core architectures to detect vulnerabilities by monitoring the parallel execution of several slightly varying instances of the same application. During regular execution each instance performs equivalent computations. When an attacker attempts to inject an attack vector through a buffer overflow vulnerability, however, each instance reacts differently due to the variances we introduced into each instance. We describe our prototype implementation of such a parallelism-based buffer overflow detection system and demonstrate that it is capable of stopping buffer overflow vulnerabilities using actual exploit codes for the popular Apache Web server. The experimental results show that the runtime overhead of our parallel execution framework is less than 10% on average.

Java Virtual Machines (JVMs) traditionally perform bytecode verification by way of an iterative dataflow analysis. Bytecode verification is necessary to ensure type safety because temporary variables in the JVM are not statically typed. We present an alternative verification mechanism that transforms JVM bytecode into Static Single Assignment Form (SSA) and thereby propagates definitions directly to uses. Type checking at control flow merge points can then be performed in a single pass. Our prototype implementation of the new algorithm is faster than the standard JVM bytecode verifier. It has the additional benefit of generating SSA as a side effect, which may be immediately useful for a subsequent dynamic compilation stage.

This report gives an overview over the Workshop on Programming Languages and Operating Systems (PLOS 2006), which was colocated with ASPLOS XII. It introduces the motivation for the work-shop and gives a summary of the workshop contributions.

Modern cars contain a multitude of micro controllers for a wide area of tasks. The diversity of the heterogeneous hardware and software leads to a complicated and expensive integration process.Integrating multiple tasks on fewer micro controllers reduces diversity and costs of production, but poses new problems with the growing complexity of software on a single micro controller. Therefore a more robust software development process and a safe execution environment is needed in the automotive area and other areas with similar constraints. With the KESO system we have implemented a very small and adapted Java execution environment for an OSEK/VDX operating system to address these issues.In this paper we present our approach for a low overhead OSEK/VDX system interface, which is an integral component of the KESO system. We show how access to the system services can be restricted at low cost to ensure the isolation of tasks by the use of type-safety and modern compiler techniques, while maintaining a familiar programming interface for developers that are used to OSEK application development using the C programming language.

We present a just-in-time compiler for a Java VM that is small enough to fit on resource-constrained devices, yet is surprisingly effective. Our system dynamically identifies traces of frequently executed bytecode instructions (which may span several basic blocks across several methods) and compiles them via Static Single Assignment (SSA) construction. Our novel use of SSA form in this context allows to hoist instructions across trace side-exits without necessitating expensive compensation code in off-trace paths. The overall memory consumption (code and data) of our system is only 150 kBytes, yet benchmarks show a speedup that in some cases rivals heavy-weight just-in-time compilers.

We predict that we will soon witness attacks on all kinds of systems that will be based on the attacked systems' worst-case behavior. For example, the worst-case performance of Java Bytecode Verification rises quadratically with program length. By sending a legal, but difficult-to-verify program to a server virtual machine, we can keep that server occupied for an inordinate amount of time, effectively making it unavailable for useful work. The problem, however, is not restricted to mobile-code verification: for example, an attacker could exploit knowledge about a just-in-time compiler's register allocator by sending it a particularly difficult to solve graph-coloring puzzle. The same vulnerability can be exploited if the attacker has intimate knowledge of the data structures used in the attacked system. Similar problems occur in hardware, e.g. with respect to power variability or the heat dissipation of processors. Malicious programs can exploit which parts of computer chips dissipate power, thereby overheating regions of the chip that are known to contain no temperature sensors. This attack could be used to affect battery life or cause early chip aging. Unfortunately, worst case-based attacks are hard to counter without also limiting the system's behavior in the average case.