Parameterized models for distributed objects Eric Madelaine, Rabéa Boulifa, Tomás Barros OASIS INRIA Sophia-Antipolis, I3S, UNSA

OASIS Modocop, Grenoble, Aims Models for analysis of distributed applications: –specification : compositional, graphical, intuitive –automatic derivation from code Checking behavioral properties: –branching time, action-based logics –bisimulation-based models (compositional reduction) In the context of the Vercors, our verification platform for distributed communicating components.

OASIS Modocop, Grenoble, Contents Parameterized model Graphical syntax Application to ProActive Ongoing work

OASIS Modocop, Grenoble, Behavioral Models Starting point = Finite models : Networks of communicating Labelled Transition Systems Process Algebras (under syntactic conditions for finiteness) Format for automatic tools (FC2 format, Concur tools) Parametric models : Compact representation for (families of) finite models Closer to code structure Automatic construction Automatic instantiations Other approaches : IF, NTIF, Promela, BIR, Estelle,...

OASIS Modocop, Grenoble, Finite Model Rabea Boulifa : “Model generation for Distributed Java Programs”, FIDJI’03 Networks of LTSs as finite abstractions of distributed systems: Actions are communication events (e.g. remote method calls) Data abstraction : Finite set of process parameters (static analysis, or user provided, or deployment descriptor) Finite set of messages (e.g. method names only, or finite sets of values) Method : Static analysis : class analysis, MCG construction, pointer analysis (for keeping track of active objects) SOS rules crossing the MCG, building the corresponding LTS. Interleaving of the remote responses.

OASIS Modocop, Grenoble, Finite Model Results : Given a finite data abstraction, the construction procedure terminates, and produces a finite LTS. (even with recursive local or remote method calls) Optimisation of the request queue model. Difficulties : Precision, and cost, of static analysis (cannot be modular). Size of the network (one process per active object) => crucial importance of compositional reduction techniques.

OASIS Modocop, Grenoble, Parameterized Model Finite representation of data þ parameterized states with variables þ message arguments l Instances of dynamic / generic networks þ parameterized processes þ evolving communication links l More compact, closer to the code structure þ easier for model generation þ one model => many (instantiated) proofs.

OASIS Modocop, Grenoble, Graphical Syntax ¶ Networks !M (args) P1 (params) vars Tree structure of boxes with ports, links, labels… Encodes structure, scopes, renamings. P2 (…) !… ?… M (abst)

OASIS Modocop, Grenoble, Graphical Syntax · p-LTSs States, with variables Visible transitions (communication events) Local transitions (sequential programs) Compromise macro-transitions / interleaving x, y y=2*x If y=0 then {z=0; goto s1} else... x, z ! O[y].Mess (x+1) s1 s2 s3

OASIS Modocop, Grenoble, Graphical Syntax ¸ Data l Local variables Scope = boxes, states, transitions. l Expressions Variables, operators, structured objects l Types booleans, integers, intervals finite enumerations structured objects ¹ Communication l Rendez-vous (a la value-passing CCS) but the model allows for group / multicast communication...

OASIS Modocop, Grenoble, Application : Building models of Distributed Active Objects ProActive code Abstracted ProActive code Parameterized Network eXtended MCG Static Analysis P-LTS: behavior, queue Behavioral rules Instantiations, Checking tools

OASIS Modocop, Grenoble, ProActive 100% java, Parallel, Distributed, Concurrent, Mobile programming Sequential Distributed Transparent distribution, remote object creation, migration of active objects Remote method call -> asynchronous communication Futures & wait-by-necessity

OASIS Modocop, Grenoble, !Serv_m request served (executed and removed) response received !Serv_m Remote Method Calls : informal diagram method call Local objectRemote object request arriving in the queue !Req_m ?Req_m !Rep_m ?Rep_m !Req_m ?Req_m ?Rep_m response sent back !Rep_m

OASIS Modocop, Grenoble, Application : Building models of Distributed Active Objects ProActive code Abstracted ProActive code Parameterized Network eXtended MCG Static Analysis P-LTS: behavior, queue Behavioral rules Instantiations, Checking tools

OASIS Modocop, Grenoble, It encodes both the usual control flow usual in MCG (resolution of class analysis and of method calls), and the data flow relative to interesting parameters. MCG= - Node types : ent(id,args), seq, ret(val), call(id,args), resp(id,val), serve(id,args) - Loc (M) and Loc(V) sets of variables local to a method or to a node. -  : V  V, function mapping a future use-point to its definition. Extended Method Call Graph M(args)prog Call edges Transfer edges

OASIS Modocop, Grenoble, JIMPLE Our construction of the extended MCG starts with JIMPLE code, that allows for a simpler data flow representation of the significant parameters. The subset of JIMPLE that is interesting here is: -Control points: Label, Goto, If, *Switch=> SEQ -Assignements=> Code -Calls: VirtualCall, SpecialCall=> CALL -Returns=> RET Expressions: CallExpr OpExpr FieldValue Arrays, Exception and Monitors are not considered in this short version Also ProActive specifics: newActive (“A”, args) serveOldest (“foo,bar”) ro.foo (args)

OASIS Modocop, Grenoble, Application : Building models of Distributed Active Objects ProActive code Abstracted ProActive code Parameterized Network eXtended MCG Static Analysis P-LTS: behavior, queue Behavioral rules Instantiations, Checking tools

OASIS Modocop, Grenoble, Application level: Network Topology Enumeration: O ={O i } a set of active object classes. Dom (O i ) a set of instantiations of each class. (use the abstraction of creation parameters) Incoming ports (available services) = set of public methods (with abstracted parameters) Outgoing links = remote requests (use the abstraction of message name and parameters) Philo(p) Fork(f) !ReqTake(p,f) ?RepTake(p,f) ?ReqDrop(p,f) Eat(p) Think(p)

OASIS Modocop, Grenoble, Application : Building models of Distributed Active Objects ProActive code Abstracted ProActive code Parameterized Network eXtended MCG Static Analysis P-LTS: behavior, queue Behavioral rules Instantiations, Checking tools

OASIS Modocop, Grenoble, Active Object Model ProActive structure : - One activity = one request queue + one behavior + one local store. - Queues = at any time, accept a set of values (mess+args) Specialised generation procedure, factorisation possible. Synchronised with the behavior through “Serve” messages. - Behavior = parameterized LTS, or network. One process (box) for each SCC of the method call graph (or even one box for each method)

OASIS Modocop, Grenoble, Example : recursive method int Fact (int y) { if y=0 {return 1;} else return y*Fact(y-1); }

OASIS Modocop, Grenoble, public int m1() { int $val, y; y = 2; this.[TStore.x:int] = 1; virtualinvoke this.[TStore.m2(int):void](y); $val = this.[TStore.x:int]; return $val; } Example (store) Each object allocation has a parameterized representation in the active object store.

OASIS Modocop, Grenoble, Example (store) A, thisalloc(i)

OASIS Modocop, Grenoble, Rules: SOS-style v = pattern, the current MCG node analyzed, n, the last LTS node created, A, the LTS under construction, M, the mapping between MCG nodes and LTS nodes, Sc, the continuations stack, Sm, the method calls stack. {Premisses} For each SCC of the call graph : 

OASIS Modocop, Grenoble, Method Entry v1  M v1  T v2 Push the new method m on the calls stack, and starts its processing. The process produced encodes calls of m for any values of the parameters. This is carried by the guards/assignments of its transitions... 

OASIS Modocop, Grenoble, Sequence If b0 then x0=v0; if b1 then x1=v2; goto C1 else x1=v3; goto C2 else x0=v1; goto C3 Call 3 Call 1 Call 0 Macro-transitions are simple sequential programs: - no intermediate nodes - no code duplication - no mixing with communication events.

OASIS Modocop, Grenoble, Return v  D(m) v1  M Ret1 Ret2 By construction, v is a node within the current method (we have not finished its treatment). We go and process the next available branch; n’ is the corresponding node in the LTS Processing of the current method is finish, remove it from the stack. Not yet changed  

OASIS Modocop, Grenoble, Local calls will be inlined if possible, that is if the called method is not recursive (part of a SCC of the call graph). M M is an abstract event “!Lcall m(co, o, args)”, generated only if visible. In the next step, we go and inline the callee code Local Call 1 v1  M v1  C v2 v1  T v3 Local (O) fresh(n ’) M

OASIS Modocop, Grenoble, Local Call 2 v1  M v1  C v2 v1  T v3 Local (O) fresh(n1, n2, n3) If the called method is recursive, its model is a boxed process, we generated a (parameterized) local call to this process, immediately followed by the corresponding return transition. n n1 !Lcall m(args) n2 n3 prog ?Ret m(val) 

OASIS Modocop, Grenoble, Remote Request O is a remote active object. We simply generate a send message ! Req_m (Oc, O, args) encoding the method name and its (abstracted) parameters. v1  T v2 Remote(O) fresh(n ’) !Req_M 

OASIS Modocop, Grenoble, Mixed Call Difficulty: distinguish the local object amongst the other instances of the same class (Philo[n] = Philo[n+1]). i i i Local O[i] => !Lcall m(args) Remote O[i] => !Req O[i].m(args) i ?Ret m(val) 

OASIS Modocop, Grenoble, Futures V v = O.m1(x); xxx; yyy; v.f(); A ’  (v1)=v2 n1=M(v1) n2=M(v2) A ’ = (A  ) ? Rep_M(val) Where M is the phantom of M, i.e. the union of all Ms during the construction procedure n1 n2 

OASIS Modocop, Grenoble, Server Side : models for the queues General case : – Infinite structure (unbounded queue) – In practice the implementation uses bounded data structures – Approximation : (small) bounded queues – Operations : Add, Remove, Choose (filter on method name and args) Generic Queue model Optimisation : – Most programs filter on method names : partition the queue. – Use specific (temporal) properties to minimise the queue model.

OASIS Modocop, Grenoble, Example : Optimised Fork model Two small queues + One behaviour LTS Philo(p) Fork(f) !ReqTake(p,f) ?RepTake(p,f) ?ReqDrop(p,f) Eat(p) Think(p)

OASIS Modocop, Grenoble, Application : Building models of Distributed Active Objects ProActive code Abstracted ProActive code Parameterized Network eXtended MCG Static Analysis P-LTS: behavior, queue Behavioral rules Instantiations, Checking tools

OASIS Modocop, Grenoble, Verification : Tools 1) Formats : Graphical: we are building the tool… experience from a large realistic case study. Textual: conservative extension of the FC2 format, but we need more experience, and will certainly redesign it. 2) Instantiation : Work already done, tools by Toufik and Tomas. Direct (on-the-fly) interface to be worked on with CADP.

OASIS Modocop, Grenoble, Imprecision Abstract Interpretation (data domains). Static Analysis (class analysis, pointer analysis); production of the extended MCG. Instantiation = abstraction of finite or integer domains to abstract “range” domains: typically Nat -> {0, 1, …, k, more}

OASIS Modocop, Grenoble, Other Formats Promela (SPIN) : –State-based versus action-based –No hierarchical models –Bounded generation (user control) NTIF : –Lotos communication (agreement) –No parallelism –No guarantee of finiteness Estelle, IF2.0, IC,  CRL,...

OASIS Modocop, Grenoble, System specification

OASIS Modocop, Grenoble, System specification (2)

OASIS Modocop, Grenoble, Conclusion Graphical and textual Intermediate Format for parameterized and compositional transition systems, capturing value-passing communication within distributed applications. Compact representation for families of finite instantiations. Close to the source code structure. Automatic generation from static analysis of source code, starting with a simple abstraction of parameter domains.

OASIS Modocop, Grenoble, Ongoing work Parameterized properties and their instantiations. Implementation of the generation tool. Bridges with verification tools: on the fly interface (evaluator), LTS operation at parameterized level (minimisation, product…). Specialised tools for infinite systems (Trex, Bebop, …)