Upload
griffin-reynolds
View
220
Download
1
Tags:
Embed Size (px)
Citation preview
Parameterized models for distributed objects
Eric Madelaine, Rabéa Boulifa, Tomás Barros
OASISINRIA Sophia-Antipolis, I3S, UNSA
[email protected]://www-sop.inria.fr/oasis/Vercors
OASIS Modocop, Grenoble, 4-12-2003 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.
OASIS Modocop, Grenoble, 4-12-2003 3
Contents
• Parameterized model
• Graphical syntax
• Application to ProActive
• Ongoing work
OASIS Modocop, Grenoble, 4-12-2003 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, ...
OASIS Modocop, Grenoble, 4-12-2003 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.
OASIS Modocop, Grenoble, 4-12-2003 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.
OASIS Modocop, Grenoble, 4-12-2003 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.
OASIS Modocop, Grenoble, 4-12-2003 8
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, 4-12-2003 9
Graphical Syntax
p-LTSs
• States, with variables• Visible transitions (communication events)• Local transitions (sequential programs)• Compromise macro-transitions / interleaving
x, y
x, y
y=2*x
If y=0 then
{z=0; goto s1}
else ...
x, zx, z x, z
! O[y].Mess (x+1)
s1s2 s3
OASIS Modocop, Grenoble, 4-12-2003 10
Graphical Syntax Data
Local variablesScope = boxes, states, transitions.
ExpressionsVariables, operators, structured objects
Typesbooleans, integers, intervals
finite enumerations
structured objects
Communication Rendez-vous (a la value-passing CCS)
but the model allows for group / multicast communication...
OASIS Modocop, Grenoble, 4-12-2003 11
Application :Building models of Distributed Active Objects
ProActive code Abstracted
ProActive code
ParameterizedNetwork
eXtendedMCG
Static Analysis
P-LTS:behavior, queue
Behavioral rules
Instantiations,
Checking tools
OASIS Modocop, Grenoble, 4-12-2003 12
ProActive 100% java,Parallel, Distributed, Concurrent, Mobileprogramming
Sequential Distributed
• Transparent distribution, remote object creation, migration of active objects• Remote method call -> asynchronous communication• Futures & wait-by-necessity
OASIS Modocop, Grenoble, 4-12-2003 13
!Serv_m• request served (executed and removed)
• response received
!Serv_m
Remote Method Calls : informal diagram
• method call
Local object Remote 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, 4-12-2003 14
Application :Building models of Distributed Active Objects
ProActive code Abstracted
ProActive code
ParameterizedNetwork
eXtendedMCG
Static Analysis
P-LTS:behavior, queue
Behavioral rules
Instantiations,
Checking tools
OASIS Modocop, Grenoble, 4-12-2003 15
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.
Extended Method Call Graph
M(args) prog
Call edgesTransfer edges
OASIS Modocop, Grenoble, 4-12-2003 17
Application :Building models of Distributed Active Objects
ProActive code Abstracted
ProActive code
ParameterizedNetwork
eXtendedMCG
Static Analysis
P-LTS:behavior, queue
Behavioral rules
Instantiations,
Checking tools
OASIS Modocop, Grenoble, 4-12-2003 18
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)
Philo(p)
Fork(f)
!ReqTake(p,f)
?RepTake(p,f)
?ReqDrop(p,f)
Eat(p)
Think(p)
OASIS Modocop, Grenoble, 4-12-2003 19
Application :Building models of Distributed Active Objects
ProActive code Abstracted
ProActive code
ParameterizedNetwork
eXtendedMCG
Static Analysis
P-LTS:behavior, queue
Behavioral rules
Instantiations,
Checking tools
OASIS Modocop, Grenoble, 4-12-2003 20
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, 4-12-2003 21
Example : recursive method
int Fact (int y) { if y=0 {return
1;} else return y*Fact(y-
1);}
OASIS Modocop, Grenoble, 4-12-2003 22
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, 4-12-2003 23
Example (store)
A, thisalloc(i)
OASIS Modocop, Grenoble, 4-12-2003 24
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}
<v=pattern, n, A, M, Sc, Sm> <v ’,n ’, A ’, M ’, Sc ’,Sm ’>
For each SCC of the call graph :
OASIS Modocop, Grenoble, 4-12-2003 25
Method Entry
v1 M v1 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...
OASIS Modocop, Grenoble, 4-12-2003 26
Sequence
If b0 then x0=v0; if b1 then x1=v2; goto C1 else x1=v3; goto C2elsex0=v1; goto C3
Call 3Call 1
Call 0
Macro-transitions are simple sequential programs:
- no intermediate nodes
- no code duplication
- no mixing with communication events.
OASIS Modocop, Grenoble, 4-12-2003 28
Local calls will be inlined if possible, that is if the called method is not recursive (part of a SCC of the call graph).
MM 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 ’)
<v1=call(O.m, args), n, A, M, Sc, Sm> <v2, n ’, A‹(n n ’), M {v1 n}, (v3, ):Sc, Sm>
MM
OASIS Modocop, Grenoble, 4-12-2003 29
Local Call 2
v1 M v1 C v2 v1 T v3 Local (O) fresh(n1, n2, n3)
<v1=call(O.m, args), n, A, M, Sc, Sm>
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
prog?Ret m(val)
OASIS Modocop, Grenoble, 4-12-2003 30
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 ’)
<v1=call(O.m,args), n, A, M, _, _> <v2, n ’, A‹(n n ’), M {v1 n ’}, _, _>
!Req_M
OASIS Modocop, Grenoble, 4-12-2003 31
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]).
i i
i
Local O[i] => !Lcall m(args)
Remote O[i] => !Req O[i].m(args)
i
?Ret m(val)
OASIS Modocop, Grenoble, 4-12-2003 32
Futures
V v = O.m1(x);xxx;yyy;v.f();
<v1, A> 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
n1n2
OASIS Modocop, Grenoble, 4-12-2003 33
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, 4-12-2003 34
Example : Optimised Fork model
Two small queues +
One behaviour LTSPhilo(p)
Fork(f)
!ReqTake(p,f)
?RepTake(p,f)
?ReqDrop(p,f)
Eat(p)
Think(p)
OASIS Modocop, Grenoble, 4-12-2003 35
Application :Building models of Distributed Active Objects
ProActive code Abstracted
ProActive code
ParameterizedNetwork
eXtendedMCG
Static Analysis
P-LTS:behavior, queue
Behavioral rules
Instantiations,
Checking tools
OASIS Modocop, Grenoble, 4-12-2003 36
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, 4-12-2003 37
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, 4-12-2003 38
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, 4-12-2003 41
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, 4-12-2003 42
Ongoing work
http://www-sop.inria.fr/oasis/Vercors
http://www-sop.inria.fr/oasis/ProActive
• 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, …)