1 / 38

Parameterized models for distributed objects

Parameterized models for distributed objects. Eric Madelaine, Rabéa Boulifa, Tomás Barros OASIS INRIA Sophia-Antipolis, I3S, UNSA. Eric.Madelaine@sophia.inria.fr http://www-sop.inria.fr/oasis/Vercors. Aims. Models for analysis of distributed applications:

kirkan
Download Presentation

Parameterized models for distributed objects

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Parameterized models for distributed objects Eric Madelaine, Rabéa Boulifa, Tomás Barros OASIS INRIA Sophia-Antipolis, I3S, UNSA Eric.Madelaine@sophia.inria.fr http://www-sop.inria.fr/oasis/Vercors

  2. 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.

  3. Contents • Parameterized model • Graphical syntax • Application to ProActive • Ongoing work

  4. 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, ...

  5. 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.

  6. 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.

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

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

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

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

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

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

  13. Remote Method Calls : informal diagram Local object Remote object !Req_m !Req_m • method call ?Req_m • request arriving in • the queue ?Req_m !Serv_m • request served • (executed and removed) !Serv_m !Rep_m • response sent back !Rep_m • response received ?Rep_m ?Rep_m

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

  15. prog Extended Method Call Graph • 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=<V, C, T , > • 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. M(args) Call edges Transfer edges

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

  17. Eat(p) !ReqTake(p,f) Philo(p) ?RepTake(p,f) Think(p) Fork(f) ?ReqDrop(p,f) Application level:Network Topology • Enumeration: • O ={Oi} a set of active object classes. • Dom (Oi) 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)

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

  19. 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)

  20. Example : recursive method int Fact (int y) { if y=0 {return 1;} else return y*Fact(y-1); }

  21. Example (store) Each object allocation has a parameterized representation in the active object store. 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; }

  22. Example (store) A, thisalloc(i)

  23. {Premisses} <v=pattern, n, A, M, Sc, Sm> <v ’,n ’, A ’, M ’, Sc ’,Sm ’> Rules: SOS-style For each SCC of the call graph : • 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.

  24. Method Entry v1  Mv1 T v2 <v1=ent(m,args), _, _, M, Sc, Sm> <v2, _, _, M  {v1  n}, Sc,(m,args):Sm> 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...

  25. Call 0 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 Sequence Macro-transitions are simple sequential programs: - no intermediate nodes - no code duplication - no mixing with communication events.

  26. Local Call 1 v1  M v1C v2 v1 Tv3  Local (O) fresh(n ’) <v1=call(O.m, args), n, A, M, Sc, Sm> <v2, n ’, A‹(n n ’), M  {v1  n}, (v3, ):Sc, Sm> M 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 is an abstract event “!Lcall m(co, o, args)”, generated only if visible. In the next step, we go and inline the callee code

  27. n n1 n2 n3 Local Call 2 prog v1  M v1C v2 v1 Tv3 Local (O) fresh(n1, n2, n3) <v1=call(O.m, args), n, A, M, Sc, Sm> !Lcall m(args) ?Ret m(val) prog 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.

  28. v1T v2 Remote(O) fresh(n ’) <v1=call(O.m,args), n, A, M, _, _> <v2, n ’, A‹(n   n ’), M  {v1  n ’}, _, _> !Req_M 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.

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

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

  31. 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.

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

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

  34. 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.

  35. 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}

  36. 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, ...

  37. 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.

  38. 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, …) http://www-sop.inria.fr/oasis/Vercors http://www-sop.inria.fr/oasis/ProActive

More Related