ActorFoundry

Slide 1:ActorFoundry – actors in an OO world Rajesh Karmani* Amin Shali Gul Agha 12/03/08

Slide 2:Actor model of programming Autonomous, concurrent actors => Inherently concurrent No shared state => No data races Asynchronous message-passing => High-level synchronization Light-weight, high-level abstractions allow cheap creation and context-switching, and efficient implementation Motivation beyond getting an AMotivation beyond getting an A

Slide 3:n blind men, the elephant Distributed programming EJBs, services in SOA Dataflow programming Pipeline stages in stream processing (StreamIt) Nodes in visual computing (Labview) Reactive, event-driven programming Embedded computing (Ptolemy) Sensor networks (ActorNet) Operating Systems Singularity, Unix process + pipes Criticised for being too general and presumedly inefficient due to message passing overhead… No incentive for client-side computing since there was no parallelism Criticised for being too general and presumedly inefficient due to message passing overhead… No incentive for client-side computing since there was no parallelism

Slide 4:Multi-core, many-core programming Erlang Scala Actors E SALSA (Java) Kilim (Java) Stackless Python Theron (C++) RevActor (Ruby) Jsasb (Java) … still growing Brought us lot of funding, revived the Actor model for client-side computingBrought us lot of funding, revived the Actor model for client-side computing

Slide 5:Actor anatomy Actors = encapsulated state + behavior + thread of control + mailbox Great thing about library: leverage existing libraries, code and expertise, easier to build Uniquely addressable mailbox One elephant, n blind men EJBs, SOA, stages in stream computing, visual computing Great thing about library: leverage existing libraries, code and expertise, easier to build Uniquely addressable mailbox One elephant, n blind men EJBs, SOA, stages in stream computing, visual computing

Slide 6:Explicit control & mailbox Kilim syntaxKilim syntax

Slide 7:Explicit control Scala syntax inspired by Erlang’sScala syntax inspired by Erlang’s

Slide 8:Actor anatomy Actors = encapsulated state + behavior + thread of control + mailbox

Slide 9:Motivation Off-the-web library for Actor programming Syntax similar to that of objects ..because the structure is! Focus on the programming model instead of syntax Avoid mixing multiple programming models Major goals: Usability and Extensibility Other goals: Reasonable performance Motivation beyond getting an A Treasure hunting ? Encourage programming fine-grained actors objects look-alikeMotivation beyond getting an A Treasure hunting ? Encourage programming fine-grained actors objects look-alike

Slide 10:Actor Foundry Actor library for Java, developed at OSL1 (around ‘98-00) Goal: Modularity, extensibility instead of efficiency Great thing about library: leverage existing libraries, code and expertiseGreat thing about library: leverage existing libraries, code and expertise

Slide 11:Implicit Control – ActorFoundry

Slide 12:Actor Foundry – an Actor microcosm

Slide 13:Actor Anatomy (Safety)

Slide 14:Actor Foundry – Programming Model Object like actors Implicit ‘receive’ Run-time provides fetch-decode loop One-to-one correspondence between message and Java method Primitives for asynchronous (send) as well as synchronous (call) messages Wraps standard IO objects as actors (stdout, stdin, stderr actors) ‘return’ is implicitly a message back to the sender for RPC-like messages‘return’ is implicitly a message back to the sender for RPC-like messages

Slide 15:Actor Foundry - Implementation Maps each actor onto a Java thread Actor = Java Object + Java Thread + ActorName Message contents are deep copied Java Reflection for method dispatch Fairness: Reliable delivery (but unordered messages) and fair scheduling

Slide 16:Actor Foundry - basic API Create(node, class, params) Locally or at remote nodes Send(actor, method, params) Call(actor, method, params) Synchronous/RPC-like messages Destroy(reason) Explicit memory management Ideally we need Garbage Collection

Slide 17:Actor Foundry – Other features Support for concurrent as well as distributed programming ActorName provides location transparency NameService, TransportLayer (TCP, UDP) Support for actor migration

Slide 18:Actor Foundry - Architecture

Slide 19:Motivation Revisited – Why ActorFoundry? Extensibility Modular and hence extensible Usability Actors as objects + small set of library calls Leverage Java libraries and expertise Performance Let’s check… ? Encourage programming fine-grained actors So very programmable, modular and hence extendible. So let’s try Threadring…. Model – checking, Test, Debugging, GC, Compiler optimizations, Run-time optimizations Encourage programming fine-grained actors So very programmable, modular and hence extendible. So let’s try Threadring…. Model – checking, Test, Debugging, GC, Compiler optimizations, Run-time optimizations

Slide 20:Great Language Shootout Ported ActorFoundry to Java6 The Computer Language Benchmarks Game [2] Implemented a concurrent benchmark in ActorFoundry: Thread-ring Thread-ring: Pass a token around 503 concurrent entities 107 times Generics, variable number of arguments, autoboxing, annotationsGenerics, variable number of arguments, autoboxing, annotations

Slide 21:Thread-ring performance

Slide 22:The quest for Continuations.. (contd.) Kilim - Actor library2 for Java Consists of a run-time and a “Weaver” (bytecode post-processor) for CPS transform With a custom continuations based scheduler M:N architecture Credit to the extensible architecture Threadring performance: ~ 4.5 minutes ? One major problem: Java ReflectionOne major problem: Java Reflection

Slide 23:Kilim’s CPS Transform Notice @pausable annotations. We require @message annotations in Actors. Every Actor encapsulates a Fiber. Fiber is a user-space stack which is wound when calling a @pausable method and unwound as Actor finishes executing a pausable method. Live variable analysis to figure out what to put on the stack.Notice @pausable annotations. We require @message annotations in Actors. Every Actor encapsulates a Fiber. Fiber is a user-space stack which is wound when calling a @pausable method and unwound as Actor finishes executing a pausable method. Live variable analysis to figure out what to put on the stack.

Slide 24:Runtime Architecture M:N

Slide 25:Runtime Architecture M:N

Slide 26:Runtime Architecture M:N

Slide 27:Runtime Architecture M:N

Slide 28:Runtime Architecture M:N

Slide 29:To copy or not to copy? Another major bottleneck: deep copying of message contents By serializing/de-serializing object

Slide 30:To copy or not to copy? Exclude immutable types Introduced new run-time functions: SendByRef (actor, method, params) CallByRef (actor, method, params) Threadring performance: ~ 20s ?? Scala, Kilim provide zero-copy messages Onus on programmers to copy contents, if needed Breaks encapsulation, infeasible in general Not many convincing examples for copying? Audience please. Linear types + copy-on-write Expose structure, infeasible Not many convincing examples for copying? Audience please. Linear types + copy-on-write Expose structure, infeasible

Slide 31:Fairness – even the playing field Non-cooperating actors can occupy a native thread indefinitely IO, System calls, Infinite loop Fairness specially critical in libraries for existing languages Interaction with existing code-base Kilim and Scala do not guarantee fairness

Slide 32:Fairness – ActorFoundry approach Scheduler thread periodically monitors “progress” of worker threads Progress means executing an actor from schedule queue If no progress has been made by any worker thread => possible starvation Launch a new worker thread Conservative but not incorrect

Slide 33:Local Synchronization Constraints Behavioral life-cycle Modularity, independent specification, Prevents piles of switch case stmts Hard to understand programs Inheritance Prevents duplication of information Prevents violation of encapsulation Behavioral life-cycle Modularity, independent specification, Prevents piles of switch case stmts Hard to understand programs Inheritance Prevents duplication of information Prevents violation of encapsulation

Slide 34:Actor with Local Constraints

Slide 35:Actor with Local Constraints

Slide 36:Actor with Local Constraints

Slide 37:Disable Conditions in ActorFoundry

Slide 38:Disable Conditions in ActorFoundry

Slide 39:Performance – crude comparison

Slide 40:Performance – More numbers Time to create Kilim: 0ms up to 300k actors Scala: 0ms up to 300k actors ActorFoundry: 0.17ms up to 300k actors Maximum # of actors Kilim: 3m actors Scala: 1m actors ActorFoundry: 350k actors

Slide 41:Performance - Can we do better? Yes, but at the cost of Distribution (Transport layer) Migration (Book-keeping for in-transit messages) Location transparency (Name service) We believe all are useful… …but at a significant cost …which remains to be quantified

Slide 42:Actor Foundry - Discussion Elegant, object-like syntax and implicit control Leverage existing Java code and libraries Declarative high-level local constraints Zero-copy as well as by-copy message passing Reasonably efficient run-time With fair scheduling Support for distributed actors, migration Modular and extensible

Slide 43:Promise for scalable performance? Over-decompose application into fine-grained actors As the number of cores increase, spread out the actors Of course, speed-up is constrained by parallelism in application Parallelism is bounded by # of actors What it means for design patternsWhat it means for design patterns

Slide 44:Using Actor Foundry Download binary distribution3 Win32, Solaris, Linux, MacOS Bundled with a bunch of example programs Ant build.xml file included Launch foundry node manager Specify the first actor and first message Launch ashell for command-line interaction with foundry node (optional)

Slide 45:Future Directions Representative client-side/GUI applications Performance benchmarks Understand further performance and programmability requirements (join expressions, soft real-time sync, atomicity) Can’t do it all within run-time Need cooperation between compiler and run-time

Slide 46:Future Directions Garbage collection Debugging Automated testing Model checking Type-checking messages Support for ad-hoc actor definitions Locality-aware scheduler