Abstract. The primary goal of exception mechanisms is to help ensure that when an operation fails, code that depends on the operation’s successful completion is not executed (a property we call dependency safety). However, the exception mechanisms of current mainstream programming languages make it hard to achieve dependency safety, in particular when objects manipulated inside a try block outlive the try block. Many programming languages, mechanisms and paradigms have been proposed that address this issue. However, they all depart significantly from current practice. In this paper, we propose a language mechanism called failboxes. When applied correctly, failboxes have no significant impact on the structure, the semantics, or the performance of the program, other than to eliminate the executions that violate dependency safety. Specifically, programmers may create failboxes dynamically and execute blocks of code in them. Once any such block fails, all subsequent attempts to execute code in the failbox will fail. To achieve dependency safety, programmers simply need to ensure that if an operation B depends on an operation A, then A and B are executed in the same failbox. Furthermore, failboxes help fix the unsafe interaction between locks and exceptions and they enable safe cancellation and robust resource cleanup. Finally, the Fail Fast mechanism prevents liveness issues when a thread is waiting on a failed thread. We give a formal syntax and semantics of the new constructs, and prove dependency safety. Furthermore, to show that the new constructs are easy to reason about, we propose proof rules in separation logic. The theory has been machine-checked. 1

Operating systems account for memory consumption and allow for termination at the level of individual processes. As a result, if one process consumes too much memory, it can be terminated without damaging the rest of the system. This same capability can be useful within a single application that encompasses subtasks. An individual task may go wrong either because the task’s code is untrusted or because the task’s input is untrusted. Conventional accounting mechanisms, however, needlessly complicate communication among tasks by partitioning their object spaces. In this paper, we show how to provide applications with per-task memory accounting without per-task object partitions.

Building reusable libraries and reliable, maintainable programs requires modular design, yet JavaScript currently provides little support for modularity. In this paper, we present the design of a module system for JavaScript. Our design is currently the basis for the module system in the next version of the JavaScript standard. The design provides a simple model for programmers and supports developing both client-side applications in the browser as well as standalone, server-side applications. Modules in our system are lexically scoped, may be nested and recursive, and can be statically loaded from external sources, allowing existing programs to be refactored naturally. In addition to static modules, our design provides a flexible mechanism for dynamically loading code that maintains isolation from untrusted modules. Finally, the system supports programmatic transformation and validation of code, supporting emerging practices in the JavaScript community. 1.