1 / 41

Increasing Concurrency in Databases using Program Analysis

Increasing Concurrency in Databases using Program Analysis. Roman Vitenberg, Kristian Kvilekval and Ambuj Singh University of California, Santa Barbara. Outline. Motivation Shape graphs and prediction Predictive scheduler optimizations Results Conclusions. Transactional Schedulers.

jaclyn
Download Presentation

Increasing Concurrency in Databases using Program Analysis

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. Increasing Concurrency in Databases using Program Analysis Roman Vitenberg, Kristian Kvilekval and Ambuj Singh University of California, Santa Barbara Ecoop June 15-18 Oslo, Norway

  2. Outline • Motivation • Shape graphs and prediction • Predictive scheduler optimizations • Results • Conclusions Ecoop June 15-18 Oslo, Norway

  3. Transactional Schedulers • Most fundamental problem of concurrency control [Pap86][BHG87]… • Little has been done on predictive schedulers • Difficult to extract future usage • Difficult to use it (Optimal Scheduling NP-complete) Ecoop June 15-18 Oslo, Norway

  4. Program analysis for better concurrency • OODB’s increasingly integrated (JDO) • Shape analysis makes predicting data accesses more feasible • Transactional code is known in advance • Rich type structure available to analysis • Enhance schedulers with specific optimizations based on the extracted info • Deadlock handling, early lock release, adaptive preclaiming Ecoop June 15-18 Oslo, Norway

  5. Previous and Related Work • Scheduling in object bases • [Graham&Barker95] • Shape analysis (pointer analysis) • Escape analysis[Bogda99][Ruf00] • Parallelization[Corbera99] • Type Safety[Ghiya96] [Nurit98] [Wilhem00] • Others... Ecoop June 15-18 Oslo, Norway

  6. Outline • Motivation • Shape graphs and prediction • Predictive scheduler optimizations • Results • Conclusions Ecoop June 15-18 Oslo, Norway

  7. Overview of Prediction • Predict locking based on program code • Extract program summary in shape graph • Provide runtime system with future accesses • Advantages • Facilitates integration OODB • Supports complex pointer-based structures • Automatically derived from source code Ecoop June 15-18 Oslo, Norway

  8. part part connector right material Example shape classConnector{ Part a,b; } class Part { Connector left,right,up,down; Material m Supplier s; … int volume(); } weight=0; while (part) { weight+=(part.material.density *part.volume()); part=part.right.b; } Ecoop June 15-18 Oslo, Norway

  9. Basic Shape Analysis • Graph • Abstract locations (heap cells) • Edges labeled with with field names • Abstract interpretation • Extend graph through field references • Combine graphs when heap location is shared • Merge shapes bottom up through static call graph Ecoop June 15-18 Oslo, Norway

  10. Predicting with shape graphs • Compile Time • Generate shapes for method references • Self, arguments, and global variables • Label shape edges with earliest access • Annotate programs to pass visible references and shapes to transaction scheduler • Runtime • Interpret shape graph on the actual object graph generating expected object set Ecoop June 15-18 Oslo, Norway

  11. Predicting with Shape Graphs Object Graph N:5 a1 N N o1:0 o4:5 o6:10 J:10 F:10 F J J o2:10 o5:15 a2 a4 K G:5 K:10 o3:20 a3 a5 Shape Graph (o1,a1) » (o4,a1) » (o2,a2) » (o6,a1) » (o5,a4) » (o3,a5) Ecoop June 15-18 Oslo, Norway

  12. Outline • Motivation • Shape graphs and prediction • Predictive scheduler optimizations • Results • Conclusions Ecoop June 15-18 Oslo, Norway

  13. Deadlock Handling: Background • Deadlock detection • Wait-for-graph (WFG) • Nodes are active transactions • Edge (ti,tj) indicates that ti waits for tj to release a lock • Maintaining throughout execution is expensive • Deadlock prevention • Heuristic-based techniques (wound-wait) • Cheaper but causing unnecessary transaction aborts • Resource allocation graph (infeasible w/o future knowledge) Ecoop June 15-18 Oslo, Norway

  14. Deadlock handling: our approach • Shape analysis helps us prune parts of WFG and other graphs in all graph-based algorithms Ecoop June 15-18 Oslo, Norway

  15. Early lock release: background • Strict 2PL: all locks are held till the end of transaction • Non-strict 2PL: read locks are released after the last access to the object • Non-strict allows greater concurrency but • Difficult to determine the last access • Allows non-serializable execution Ecoop June 15-18 Oslo, Norway

  16. Early lock release: non-searializable execution T1 : Acq(o1) T2: read(o1) Rel (o1) Acq(o1) write(o1) Acq(o2) write(o2) Rel(o1,o2) Acq(o2) read(o2) Rel(o2) Ecoop June 15-18 Oslo, Norway

  17. Early lock release: our approach • Estimate the last access to an object in order to release early • Causality-aware scheduler • T1 causally precedes T2 (T1c T2) if either • T2 is initiated after T1 by the same client, or • T2 acquires a lock that T1 has released, or • There is T3 such that T1c T3 and T3c T2 • If T1c T2 the scheduler blocks T2.A(O) if T1 may access O in the future. Ecoop June 15-18 Oslo, Norway

  18. Early lock release: Causality-aware scheduling T1 : Acq(o1) T2: read(o1) Rel (o1) Acq(o1) write(o1) Acq(o2) <- Blocks write(o2) Rel(o1,o2) Acq(o2) read(o2) Rel(o2) Ecoop June 15-18 Oslo, Norway

  19. Lock preclaiming: background • Standard 2PL acquires locks gradually • Conservative 2PL preclaims all the locks • Fewer aborts upon high contention & long transactions • Shorter wait-for chains T1.A(O2) T2.A(O1)T2.A(O2) T3.A(O1) • Requires apriori knowledge of locks Ecoop June 15-18 Oslo, Norway

  20. Lock preclaiming: our approach • Predict the set of objects to be preclaimed automatically • Adaptive hybrid schemes • Preclaim when expected contention level is high across executing transactions • Preclaim locks only for short transaction Ecoop June 15-18 Oslo, Norway

  21. Outline • Motivation • Shape graphs and prediction • Predictive scheduler optimizations • Results • Conclusions Ecoop June 15-18 Oslo, Norway

  22. Overview of performance measurements • Two applications: OO7 & Prototype reservation system • Mix of transaction types (lock sequence, short/long transactions) • Transaction rates, and transaction parameters • Compare Standard 2PL with our enhanced 2PL based on scheduling delay time Ecoop June 15-18 Oslo, Norway

  23. Evaluation: OO7 • Short Read • 2ms • 600/min • Short Update • 2ms • 10/min • Long Reorg • 2000ms • 3/min Comp Parts Ecoop June 15-18 Oslo, Norway

  24. OO7 Results Relative delay by scheduler Ecoop June 15-18 Oslo, Norway

  25. Delays in short query Predictive Strict 2-Phase Ecoop June 15-18 Oslo, Norway

  26. Conclusions & future directions • Runtime use of shape graph can generate object use prediction (even without prior statistics) • Transaction scheduler improved by • Better deadlock handling (smaller WFG) • Early read lock release • Lock preclaiming • Future: lease prediction Ecoop June 15-18 Oslo, Norway

  27. End Questions? Ecoop June 15-18 Oslo, Norway

  28. Evaluation: Car Reservation Ecoop June 15-18 Oslo, Norway

  29. 3423 Evaluation: car reservation Query Traversal Starved Starved Ecoop June 15-18 Oslo, Norway

  30. Construction of Shape Graphs x Ecoop June 15-18 Oslo, Norway

  31. Construction of Shape Graphs x.f = s; F Ecoop June 15-18 Oslo, Norway

  32. Construction of Shape Graphs x.f = s; t = x.f.g; F G Ecoop June 15-18 Oslo, Norway

  33. Construction of Shape Graphs x.f = s; x.f.g = t; x = x.n; N F ? G Ecoop June 15-18 Oslo, Norway

  34. N F G Construction of Shape Graphs x.f = s; x.f.g = t; if (x != null) x = x.n; Ecoop June 15-18 Oslo, Norway

  35. N F J F G K Combining Shape Graphs x = y; Ecoop June 15-18 Oslo, Norway

  36. N F J F G K Combining Shape Graphs • Unify graphs recursively Ecoop June 15-18 Oslo, Norway

  37. N F J F G K Unification of Shape Graphs • Unify graphs recursively N F J G K Ecoop June 15-18 Oslo, Norway

  38. Shape Analysis Algorithm •  methods Interpret basic blocks • Create shapes for basic blocks • Run until fixed-point is reached • Propagate in static callgraph Ecoop June 15-18 Oslo, Norway

  39. Static Call Graphs main Static representation of calls m2 m3 m4 m3{ a.f = s; o.m4(a) } Class C { m4(F f) { … } Unify(a,f) f Ecoop June 15-18 Oslo, Norway

  40. Call Graphs m1 • Propagate bottom up • Merge polymorphic calls • Recursive Calls • Fixed point • Merge SCC[Ruf00] m2 B.m4 m3 m4 D1.m4 D2.m4 m1 m2 m1 Ecoop June 15-18 Oslo, Norway

  41. Overview of scheduler enhancements • Better Deadlock handling • Smaller WFG based on type information • Conservative Resource Allocation Graph • Early Lock Release • Read locks released after last use • Lock Preclaiming • Better throughput in high contention Ecoop June 15-18 Oslo, Norway

More Related