From Modeling to Deployment of Active Objects A

From Modeling to Deployment of Active Objects - A Pro. Active backend for ABS Ludovic Henrio, Justine Rochas With the contribution of: Fabrice Huet, Zsolt Istvàn Lamha, Jan 2015 1

About the SCALE team • Distributed applications are: - Difficult to program safely (correctness) - Difficult to program and run efficiently (efficient deployment running and synchronisation) • In the scale team we propose: - Languages: active object, asynchronous processes - Design support: Vercors – specification and verification of distributed components - Runtime support: a Java middleware, and VM placement algorithms Application domains: cloud computing, service oriented computing …

Agenda I. Active Object Programming models II. Multi-active Objects: Principles III. Scheduling in Multi-active Objects IV. A Pro. Active backend for ABS V. Conclusion and Future Works 3

Active objects: generalities • Asynchronous method calls / requests • No race condition: each object manipulated by a single thread b a f Result foo. Access = beta. bar(p) … foo 4

ASP/Pro. Active Principles • Active and Passive objects • Asynchronous method calls ; request queue • With implicit transparent futures a Request invocation b result=beta. foo(b) Caromel, D. , Henrio, L. : A Theory of Distributed Object. Springer-Verlag (2005) foo 5

ASP/Pro. Active Principles • Active and Passive objects • Asynchronous method calls ; request queue • With implicit transparent futures a Request invocation b f beta. foo(b) result foo result=beta. foo(b)6

ASP/Pro. Active Principles • Active and Passive objects • Asynchronous method calls ; request queue • With implicit transparent futures a Wait-bynecessity b f …. . Result. getval() foo WBN!! Result. getval() 7

ASP/Pro. Active Principles • Active and Passive objects • Asynchronous method calls ; request queue • With implicit transparent futures … a b f beta. foo(b) Result. getval() foo Result. getval() 8

ASP/Pro. Active Principles • Active and Passive objects • Asynchronous method calls ; request queue A transparent beta = new. Active • With implicit futures (“A”, …); V result = beta. foo(b); …. . result. getval( ); a Future sending b f beta. foo(b) Result. getval() foo Result. getval() 9

First Class Futures a b f delta. snd(result) d 10

First Class Futures a b delta. snd(result) Active objects are the unit of distribution and concurrency (one thread per AO / no data shared) d Pro. Active is a Java library ASP is a “calculus” 11

ASP: Summary and Results An Asynchronous Object Calculus: - Structured asynchronous activities - Structured communications with futures - Data-driven synchronization ASP Confluence and Determinacy Future updates can occur at any time Execution characterized by the order of request senders Determinacy of programs communicating over trees, … 2 - Confluence and Determinacy 12

Active Objects – Limitations AO 1 AO 2 • No data sharing – inefficient local parallelism - Parameters of method calls/returned values are passed by value (copied) - No data race-condition simpler programming + easy distribution • Risks of deadlocks, e. g. no re-entrant calls - Active object are single threaded - Re-entrance: Active object deadlocks by waiting on itself (except if first-class futures) - Solution: Modify the application logic, difficult to program 13

Another model: Cooperative multithreading Creol, ABS, and Jcobox: • Active objects & futures • Cooperative multithreading l All requests served at the same time l But only one thread active at a time l Explicit release points in the code can solve the re-entrance problem More difficult to program: less transparency Possible interleaving still has to be studied 14

ABS in more details COGs (set of objects) - Each object is active (can be invoked remotely) - Cooperative scheduling - Explicit syntax for asynchronous call and future access COG - A a = new cog A(); B b = new cog B(); b!foo(a); foo(A a) { Fut<V> v. Fut = a!bar(p); await v. Fut? ; V v = v. Fut. get; } obj COG call() obj foo(A a) { Fut<V> v. Fut = a!bar(p); await v. Fut? ; V v = v. Fut. get; } obj obj 15

Active Object Models Uniform Model • • • Active objects only Creol [4] A lot of threads All objects are accessible Non Uniform Model • • • Active & passive objects ASP/Pro. Active Complex semantic but scales Object Group Model JCo. Box [5], ABS One thread for many objects A lot of global references to manage if not in shared-memory 16

Explicit vs Transparent Explicit asynchronous method invocation & future access e. g. : Creol, ABS, JCobox Transparent remote invocation and future access e. g. : ASP/Pro. Active • • Explicit asynchronous calls object. method() // synchronous or asynchronous object. method() // synchronous object!method() // asynchronous • Explicit futures Fut<T> future = object!method(); T t = future. get; // blocks Transparent asynchonous calls • Transparent first class futures T future = object. method(); 17

Threading Models in Active Objects Local Concurrency Cooperative Single-threaded • ASP and Pro. Active • • • Creol JCo. Box ABS Multi-threaded • Multi. Active Objects (extended Pro. Active) Neither ASP nor cooperative multithreading solve all the active object issues (multicore efficiency) We propose an alternative AO model: more transparent but more parallel than ABS 18

Agenda I. Active Object Programming models II. Multi-active Objects: Principles III. Scheduling in Multi-active Objects IV. A Pro. Active backend for ABS V. Conclusion and Future Works 20

Multi-active objects joi n() • A programming model that mixes local parallelism and distribution with high-level programming constructs • Execute several requests in parallel but in a controlled manner Provided add, add and monitor are compatible add() { monitor() add() { … {… … …} …} } Note: monitor is compatible with join 21

Scheduling Requests • An « optimal » request policy that « maximizes parallelism » : ➜ Schedule a new request as soon as possible (when it is compatible with all the served ones) ➜ Serve it in parallel with the others ➜ Serves l Either the first request l Or the second if it is compatible with the first one (and the served ones) Compatibility = l Or the third one … requests can execute at the same time compatible and can be re-ordered 22

Declarative concurrency by annotating request methods Groups (Collection of related methods Rules (Compatibility relationships between groups) Memberships (To which group each method belongs) 23

Dynamic compatibility joi n() • Compatibility may depend on object’s state or method parameters e. g. provided the parameters of add are different add(int n) { … } add(int n) { … …} Returns true if requests compatible 24

Hypotheses and programming methodology • We trust the programmer: annotations supposed correct static analysis or dynamic checks should be applied in the future • Without annotations, a multi-active object runs like an active object Easy to program • If more parallelism is required: 1. Add annotations for non-conflicting methods 2. Declare dynamic compatibility 3. Protect some memory access (e. g. by locks) and add new annotations More parallelism More complex code / performance Difficult to program better 25

Experiment: CAN P 2 P network • Parallel and distributed • Parallel routing Each peer is implemented by a (multi) active object and placed on a machine Significant speedup due to parallelisation of communications, while controlling which communications are performed in parallel With only a few annotations ! 26

Agenda I. Active Object Programming models II. Multi-active Objects: Principles III. Scheduling in Multi-active Objects IV. A Pro. Active backend for ABS V. Conclusion and Future Works 27

Thread Limitation • Too many threads can be harmful: - memory consumption, - too much concurrency wrt number of cores @Define. Thread. Config(thread. Pool. Size=4, hard. Limit=false) 4 active threads V v = o. bar(); v. foo(); start! Still 4 active threads ! 28

Muti-active Objects Scheduling - Overview Receive requests Apply Compatibilities Filter Apply Priorities Reorder Apply Threading policies Filter Execute requests 29

Priority Specification Mechanism @Define. Priorities ({ @Priority. Order({ dependency@Set(group. Names = {"G 1"}), @Set(group. Names = {"G 2"}), dependency @Set(group. Names = {"G 5", "G 4"}) }), @Priority. Order({ @Set(group. Names = {"G 3"}), @Set(group. Names = {"G 2"}) }) }) Priorities are automatically taken into account in the scheduling policy High priority G 1 G 3 G 2 G 5 G 4 Low priority incoming request R 2 R 4 R 3 R 1 30

Thread Limitation per Group routing", min. Threads=2, max. Threads=5) @Group(name=" routing Threads never used by the routing group max min Threads never used by other groups Thread pool 31

Summary of the programming model • Everything is based on groups of methods (requests) • Compatibility between groups and inside a group Possibly decided dynamically • Global thread limitation (soft or hard) • Upper and lower bound per group • Priorities among compatible requests 32

Agenda I. Active Object Programming models II. Multi-active Objects: Principles III. Scheduling in Multi-active Objects IV. A Pro. Active backend for ABS V. Conclusion and Future Works 33

Motivation Pro. Active – Multiactive Objects Development and deployment of distributed applications ✔ ABS – Abstract Behavioral Spec. Language Modeling of distributed applications ✔ Java Translator ✔ No support for distribution ✗ OBJECTIVE Provide distributed deployment to ABS using Pro. Active

Challenge ABS ASP/Pro. Active • Object Group Active Object model • Non Uniform Active Object Model • Explicit asynchronous calls and futures • Transparent asynchronous calls and futures • Cooperative threading model • Multi-threaded model 35

Active Object Creation in Pro. Active on node 1, active object o does: T a = new. Active(T. class, params…, node 2) // a: local reference to a proxy node 1 node 2 active object o object a (proxy to ra) active object ra local reference object remote reference active object 36

Method calls in Pro. Active on node 1, active object a does: P param 1, param 2 = … ; T a = new. Active(T. class, params…, node 2) V res = a. bar(param 1, param 2); // Same syntax as a local call node 1 node 2 param 1 copy of param 1 o bar a copy of param 2 ra bar 37

Translation Issues 1. Active Object Models ABS Object Group Model Pro. Active Non Uniform Model 1. Asynchronous Method Calls 1. Threading Models 38

Towards translation of ABS in Pro. Active • Select active objects - a COG = a Pro. Active active object - Entry point to the local memory space • Hierarchical indexing of objects ① COG registry (RMI) Global index via the network Object URL Object ② Object registry (in a COG) Local index via shared memory @COG 1 @COG 2 … cog 1 cog 2 … … Object ID ID 1 ID 2 … … Object ref o 1 o 2 … … … 39

Translation of a new cog statement ABS code: Server server = new cog Server() Translated during compilation into: Server server = new Server() COG cog = new. Active(COG. class, {}, node 2) cog. register. Object(server) (3) node 2 node 1 main cog (3) remote (1) server (2) cog (proxy) (1) (2) server (2) cog 40

Translation Issues 1. Active Object Models 1. Asynchronous Method Calls ABS Pro. Active Explicit Transparent 3. Threading Models 41

Translation of an Asynchronous Method Call ABS code: server!start() Translated during compilation into: server. get. Cog(). execute("start", {}, server. get. ID()) node 1 main cog COG node 2 server remote server get. Cog cog (proxy) execute cog start Objects registry Object ID Object ref execute = 1 -retrieve object with id 2 -run by reflection 42

Asynchronous Method Call with Parameters ABS code: server!start(param 1, param 2) Translated during compilation into: server. get. Cog(). execute("start", {param 1, param 2}, server 1. get. ID()) node 1 main cog node 2 server get. Cog cog (proxy) execute param 1 param 2 remote server start execute cog copy of param 2 copy of param 1 main cog proxies 43

Translation Issues 1. Active Object Models 1. Asynchronous Method Calls 3. Threading Models ABS Cooperative scheduling Pro. Active Multi-threading 44

Translation of an await statement ABS code: Fut<Bool> ready. Fut = server!start() await ready. Fut? (1) (2) (1) Translated during compilation into: PAFuture. get. Future. Value(ready. Fut) Blocks! @Define. Groups({ @Group(name="scheduling", self. Compatible=true) }) @Define. Thread. Config(thread. Pool. Size=1, hard. Limit=false) public class COG { @Member. Of("scheduling") public ABSType execute(…) { } } (2) # of active threads = 0 start! # of active threads = 1 45

Translation of a get statement ABS code: Fut<Bool> ready. Fut = server!run() Bool ready = ready. Fut. get (1) (2) Limit = 1 thread in total Translated during compilation into: this. get. COG(). switch. Hard. Limit(true); Boolean ready = PAFuture. get. Future. Value(ready. Fut); this. get. COG(). switch. Hard. Limit(false); (2) Blocks all executions! Limit = 1 active thread 46

Direct Modifications for Distribution • Serialization - Most classes implement now "Serializable" - Some fields have been made "transient" • Deployment - Node specification added in the ABS language Server server = new cog "slaves" Server(); <GCMDeployment> <hosts id="slaves" host. Capacity="1"/> <ssh. Group host. List="machine 1 machine 2" /> </GCMDeployment> <GCMApplication> <virtual. Node id="slaves"> <node. Provider capacity="4"/> </virtual. Node> </GCMApplication> XML files required to configure the application deployment 47

Experimental Evaluation Constant speedup 48

Correctness of translation • Formalised an operational semantics for class-based multi-active objects • Formalised the translation ABS MAO • Proved that MAO simulates any ABS semantics and that MAO reductions correspond to a possible ABS execution (on most meaningful cases) • Restrictions: - Causally ordered communications; in ASP, request sending = rendez-vous - Requests served in FIFO order in ASP (also in Java backend) 49

Conclusion – A Fully Working Tool • Translation of await on conditions await a == True && b == False? ; @Group(name="waiting", self. Compatible=true, min. Threads=50, max. Threads=50) • Automated compilation & deployment of ABS programs • Significant speedup from local programs • Partial proof of correctness 50

Agenda I. Active Object Programming models II. Multi-active Objects: Principles III. Scheduling in Multi-active Objects IV. A Pro. Active backend for ABS V. Conclusion and Future Works 51

Conclusion (1/2): a new programming model • Active object model - Easy to program - Support for distribution • Local concurrency and efficiency on multi-cores - Transparent multi-threading - Simple annotations A programming model for locally concurrent and globally distributed objects 52

Conclusion (2/2): Results and Status • Implemented multi-active objects above Pro. Active • Case studies, benchmarks: NAS, CAN, GCM components, ABS backend • Specified SOS semantics and proved - « maximal parallelism » - Correctness of ABS translation • Next steps: - Prove stronger properties, mechanised formalisation - Find deadlocks using behavioural types (ongoing Ph. D) - Design a recovery protocol for MAO - Provide a debugger for MAO (forthcoming internship) 53

Questions? Related publications: 1. Multi-threaded Active Objects. Ludovic Henrio, Fabrice Huet, and Zsolt István - In COORDINATION 2013. 2. Declarative Scheduling for Active Objects paper. Ludovic Henrio and Justine Rochas - SAC 2014. 54