Context: States as graphs heap stack Objects & method frames - PDF document

Context: States as graphs heap stack • Objects & method frames as nodes Graph-Based State Spaces • Relations & variables as (labelled) edges Cell Object val next Arend Rensink next first last University of Twente Cell Buffer Cell Object val next next no method frames in Cell this presentation 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 1 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 2 Graphs as states Graph formalism val Cell Object • Graphs in this presentation: next next first, last Cell Buffer Cell – flat (i.e., not hierarchical), untyped Cell <put> Cell Object next next <get> next next – directed, edge-labelled, no parallel edges first Cell val next last <put> next <get> Cell Buffer Cell – self-edges depicted as node labels first next next last Cell • Formally: G = (L,N,E) with Cell Buffer Cell Object val – L set of labels val Cell Object – N finite set of nodes next next next next first – E ⊆ N × L × N finite set of labelled edges last Cell Buffer Cell Object Cell <get> <put> val val Cell Object val next next • Partial morphisms next next <get> first Object Cell Object val Cell Buffer Cell Object – structure-preserving node mappings val <put> last next next Cell Object val 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 3 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 4 1

Graph Productions Example production rule Production rule Alternative single-graph black = reader: public void put(Object val) { LHS and RHS; if (last.next.val == null ) { representation: <put> rule morphism to be matched and preserved LHS RHS last = last.next; NAC (partial) NAC last.val = val; NACs blue = eraser: } LHS, not RHS; red = embargo: } Cell NAC, not LHS; to be matched and deleted forbidden matching forbidden last next Buffer morph(t) source target Object last src(t) tgt(t) val graph graph Cell green = creator: val Graph transition pushout Object RHS, not LHS; (SPO = Single Pushout Approach) to be added 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 5 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 6 Graphs as states Example rule application transitions carry partial morphisms val Cell Object next next Cell first, last last Cell Buffer Cell Cell next <put> Buffer next next <get> Object next next last val first Cell last <put> <get> Cell Buffer Cell Cell val Object next next Cell Object Cell next val next first matching last Cell Buffer Cell Object val not val Object val Object val Cell Object next inverse! next Cell Cell Cell next next first last Object Cell Buffer Cell Object <get> <put> next transition val next val Cell Object first next val next next next next first | last <get> first next Object Cell Object Buffer val val last Cell Buffer Cell Object Buffer val <put> last next next next next Cell Cell Cell Cell Cell Object val 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 7 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 8 2

Aim: software model checking Envisaged tool chain • Construct graph procuction system from – UML diagrams / other specifications – Programs to be checked • Generate state space – States=graphs, transitions=transformations • Formulate properties – invariants/reachability (safety) – liveness = implemented – full temporal logic = planned • Check properties on the model 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 9 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 10 Issues to be addressed Example cases [GraBaTs 2004] • Time consumption (complexity) � – graph matching – isomorphism • Space consumption (memory usage) – state and transition storage – symbolic techniques (BDDs) not applicable • Problem size – state size not a priori fixed (generally unbounded) – state spaces generally infinite • List append: highly dynamic, hardly symmetric • Propositional logic not suitable • Philosophers: not at all dynamic, highly symmetric • Model checking algorithms not suitable • Ring mutex: somewhat dynamic, rather symmetric • Verification not generic (problem size 4, 5, …) 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 11 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 12 3

Time consumption (1) Time consumption (2) • Graph matching • Graph isomorphism – Needed to find production rule matchings – Used to collapse states – Complexity: NP-complete – Complexity: between P and NP (!) • Alleviating circumstances: • Approximation techniques – Graphs to be matched are LHSs – Over-approximation: graph certificates • typically small • Excellent precision (> 99%) – Host graphs are software models • Still requires isomorphism check afterwards – Under-approximation: equality • mostly deterministic • transformations only at “locus of control” • Mediocre precision (10-50%) • Very fast; useful as initial filter 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 13 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 14 Issues to be addressed Time consumption • Time consumption (complexity) � – graph matching – isomorphism • Space consumption (memory usage) – state and transition storage – symbolic techniques (BDDs)? • Problem size – state size not a priori fixed (generally unbounded) • List append: Relatively large graphs – state spaces generally infinite • Propositional logic not suitable • Philosophers: Many symmetries • Model checking algorithms not suitable • Mutex: Many states & transitions • Verification not generic (problem size 4, 5, …) 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 15 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 16 4

Issues to be addressed Space consumption • Time consumption (complexity) • Symbolic methods (BDDs) not suitable – graph matching – No fixed state vector – isomorphism – Idea: Store “deltas” between graphs • Space consumption (memory usage) � – Average delta: 2-7 elements – state and transition storage – symbolic techniques (BDDs) not applicable • Transition storage also expensive • Problem size – Idea: Store “boundaries” of LHS matching – state size not a priori fixed (generally unbounded) – Average boundary: 2-3 elements – state spaces generally infinite • Current implementation: • Propositional logic not suitable – Overhead per state/transition > 75% • Model checking algorithms not suitable – Java quite memory generous • Verification not generic (problem size 4, 5, …) 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 17 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 18 State space reduction (1) State space reduction (2) • Existing techniques: • Partial order reduction – Symmetry recognition – Linearization of confluent rule applications – Partial order reduction – Theory: – Abstraction, e.g. slicing (property-driven) • Exponential “best case” improvement • Restricted applicability, especially with NACs • Symmetry recognition: here automatic – Practice: ??? – Implied by isomorphism check • Abstraction – Dining philosophers: linear reduction – Approximative results ( false negatives ) – Expectation: little symmetry in real life – Very promising, not just for this purpose 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 19 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 20 5

Experimentation (1) Comparison [ICGT 2004] • CheckVML (Varró) Dining philosophers reduction = – Encode graphs in SPIN – get hungry degree of symmetry – Choose fixed node identities – get left fork, get right fork (in sequence) – Predict rule applications – drop both forks (atomically) and think #phils #phils #states #states #trans #trans space(MB) space(MB) exec(s) prep(s) exec(s) prep(s) #phils #states #trans space (MB) time (s) 8 8 3,261 3,261 21,536 21,536 2.9 2.9 19 19 5 117 481 0.1 1 25,961 171,058 8.8 1 7 8 3,261 21,536 2.9 19 10 10 32,903 32,903 271,634 271,634 24.8 24.8 199 199 10 32,903 271,634 24,8 199 328,503 2,711,200 90.0 12 9 12 347,337 3,440,980 267.0 3,712 12 12 347,337 347,337 3,440,980 3,440,980 267.0 267.0 3,712 3,712 4,165,710 41,267,300 419.8 545 10 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 21 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 22 Issues to be addressed Property specification • Time consumption (complexity) • State-based properties – graph matching – isomorphism – Invariants, liveness properties • Space consumption (memory usage) – Expressible by graph predicates – state and transition storage – Mechanism: graph embedding (+ NACs) – symbolic techniques (BDDs) not applicable • Temporal logic properties • Problem size � – state size not a priori fixed (generally unbounded) – Existing MC logics are propositional (L/CTL) – state spaces generally infinite – Graph properties are FOL formulae • Propositional logic not suitable – Dynamic allocation/deallocation • Model checking algorithms not suitable • Verification not generic (problem size 4, 5, …) 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 23 4 March 2005, NVTI day, Utrecht Graph-Based State Spaces 24 6