Actor Frameworks for the JVM Platform: A Comparative Analysis Rajesh K. Karmani, Amin Shali, Gul Agha Open Systems Laboratory Department of Computer Science University of Illinois at Urbana-Champaign frkumar8; shali1; aghag@illinois:edu ABSTRACT tiple threads working with a shared memory. The shared The problem of programming scalable multicore processors memory model is unnatural for developers, leading to pro- has renewed interest in message-passing languages and frame- grams that are error-prone and unscalable [2]. Not surpris- works. Such languages and frameworks are typically actor- ingly, researchers and practitioners have shown an increas- oriented, implementing some variant of the standard Actor ing interest in using actor-oriented programming. Some lan- semantics. This paper analyzes some of the more signi¯cant guages based on the Actor model include Erlang [3], E lan- e®orts to build actor-oriented frameworks for the JVM plat- guage [4], SALSA [5], Ptolemy [6] and Axum [7]. form. It compares the frameworks in terms of their execution Ed Lee [2] has argued that in adopting a new language semantics, the communication and synchronization abstrac- or library, programmers are motivated as much by its syn- tions provided, and the representations used in the imple- tax as by its semantics. Perhaps for this reason, despite the mentations. It analyzes the performance of actor-oriented development of a number of novel Actor languages, there frameworks to determine the costs of supporting di®erent continue to be e®orts to develop Actor frameworks based actor properties on JVM. The analysis suggests that with on familiar languages such as C/C++ (Act++ [8], Broad- suitable optimizations, standard Actor semantics and some way [9], Thal [10]), Smalltalk (Actalk [11]), Python (Stack- useful communication and synchronization abstractions may less Python [12], Parley [13]), Ruby (Stage [14]), .NET (Mi- be supported with reasonable e±ciency on the JVM plat- crosoft's Asynchronous Agents Library [15], Retlang [16]) form. and Java (Scala Actors library [17], Kilim [18], Jetlang [19], ActorFoundry [20], Actor Architecture [21], Actors Guild [22], JavAct [23], AJ [24], and Jsasb [25]). Categories and Subject Descriptors In this paper, we analyze actor-oriented frameworks that D.1.3 [Software]: PROGRAMMING TECHNIQUES|Con- execute on the JVM platform. Supporting actors through current Programming; D.3.3 [Software]: PROGRAMMING frameworks in a language with a di®erent programming LANGUAGES|Language Constructs and Features, Con- model can be complicated. Moreover, because the actor code current programming structures runs on compilers and runtime systems for other languages, the resulting execution can be ine±cient. Either to sim- General Terms plify the implementation, or to improve performance, many actor-oriented frameworks compromise one or more seman- Languages, Performance tic property of the standard Actor model. For example, execution e±ciency may be improved by unfair scheduling, Keywords or by implementing message-passing by passing references Actors, Libraries, Frameworks, Java, JVM, Comparison, Se- rather than copying messages. Our goal in this paper is to mantics, Abstractions, Performance understand the semantic properties of Actor-oriented frame- works, what abstractions they support, and how they are implemented. 1. INTRODUCTION A programming frameworks can be analyzed along two di- The growth of multicore computers has made it impera- mensions: the linguistic support the framework provides for tive for application programmers to write concurrent pro- programmers, and the e±ciency of executing code written grams [1]. The dominant model for concurrent program- using the framework. In case of the actor frameworks, lin- ming, popularized by Java, is a shared memory model: mul- guistic support comes in two forms. First, by supporting the properties of the Actor model, a framework can enable scal- able concurrency which facilitates compositional program- ming. Second, by providing programming abstractions that Permission to make digital or hard copies of all or part of this work for simplify expression of communication and synchronization personal or classroom use is granted without fee provided that copies are between actors, a framework can allow programming idioms not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to to be expressed in succinct notation. republish, to post on servers or to redistribute to lists, requires prior specific As mentioned earlier, many actor-oriented frameworks permission and/or a fee. compromise one or more of the semantic properties of actors. PPPJ ’09, August 27–28, 2009, Calgary, Alberta, Canada. We discuss the signi¯cance of each of these properties in or- Copyright 2009 ACM 978-1-60558-598-7 ...$10.00. der to understand the impact of compromising the property performance. from the \ease of programming" point of view (x3). We then Asynchronous messaging is a key source of nondetermin- describe some common communication and synchronization ism in Actor programs: the order in which messages are abstractions in actor frameworks (x4). Finally, we analyze processed a®ects the behavior of an actor. In many applica- the implementation mechanisms in Actor frameworks and tions, application programmers want to prune some of the study how the cost of providing actor properties may be nondeterminism by restricting the possible orders in which mitigated (x5). Our analysis suggests that while a naijve im- messages are processed. Two commonly used abstractions plementation of actor properties may be highly ine±cient, that constrain the message order are request-reply messaging a sophisticated implementation of actor framework on JVM and local synchronization constraints (we will discuss these may provide e±cient execution without compromising es- abstractions in x4). sential actor properties. The main contribution of this paper is to provide a basis for understanding how various actor frameworks di®er, both 3. ACTOR PROPERTIES from a programmability point of view, and from a perfor- We discuss four important semantic properties of actor mance point of view. We hope that the results will guide systems: encapsulation, fairness, location transparency and developers in selecting a suitable framework and facilitate mobility. Using examples, we argue for the advantages of in the development of other actor-oriented frameworks. preserving these semantics in Actor implementations. 2. OVERVIEW OF THE ACTOR MODEL 3.1 Encapsulation Encapsulation is one of the core principles of object ori- The Actor model is an inherently concurrent model of ented programming. Preserving encapsulation boundaries programming [26]. In the Actor model, systems comprise between objects facilitates reasoning about safety proper- of concurrent, autonomous entities, called actors, and mes- ties such as memory safety, data race freedom, safe mod- sages. Each actor has a unique, immutable name which is i¯cation of object state. For example, Java is considered required to send a message to that actor. An actor name a memory-safe language because it hides memory pointers cannot be guessed but may be communicated to other ac- behind object references that provide safe access to objects tors. Each actor has its own mutable local state; actors do (e.g. pointer arithmetic is not allowed). Memory-safety is not share this local state with other actors{each actor is important for preserving object semantics: it permits access responsible for updating its own local state. to an object's state only using well-de¯ned interfaces. In the Actors communicate by sending asynchronous messages context of the Actor model of programming, there are two to other actors (see Figure 1). The receiving actor processes important requirements for encapsulation: state encapsula- the messages one at a time in a single atomic step. Each step tion and safe messaging. consists of all actions taken in response to a given message, enabling a macro-step semantics [27]. State Encapsulation. An actor cannot directly (i.e., in its own stack) access the State Thread internal state of another actor. An actor may a®ect the state of another actor only by sending the second actor a message. Methods The code in Figure 2 shows an implementation of a count- ing semaphore in the Scala Actors. The main actor, in addi- [create] tion to sending an enter() message, executes enter() in its State Thread Mailbox State Thread own stack. Because of a lack of enforcement of Actor encap- Methods Methods sulation in the library, the code violates the Actor property that an actor may not directly access the internal state of an- [msg_a] other actor. As a consequence, in a multi-threaded, shared Mailbox memory implementation of the Actor model, two actors can Mailbox concurrently enter the critical section and thus violate the semantics of a counting semaphore. In Kilim, actors have memory references to other actors' Figure 1: Actors are concurrent entities that ex- mailboxes. Again, this violates the desired encapsulation change messages asynchronously. property. Actor implementations that enforce state encap- sulation do so using indirection. Because such indirection The standard Actor semantics provides encapsulation, fair also provides location transparency, we discuss this sepa- scheduling, location transparency (location independent nam- rately later in this section. ing), locality of reference, and