Ecoop June 15-18 Oslo, Norway 1 Increasing Concurrency in Databases using Program Analysis Roman Vitenberg, Kristian Kvilekval and Ambuj Singh University

Ecoop June 15-18 Oslo, Norway

1

Increasing Concurrency in Databases using Program

Analysis

Roman Vitenberg, Kristian Kvilekval and Ambuj SinghUniversity of California, Santa Barbara

Ecoop June 15-18 Oslo, Norway 2

Outline

Motivation Shape graphs and prediction Predictive scheduler optimizations Results Conclusions


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)


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


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


Outline



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


Example shape

class Connector{ 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;}

part connector

part

right

material


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


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


Predicting with Shape Graphs

a1

a2

a5

a4

a3

G:5 K:10

F:10 J:10

N:5

o1:0 o4:5N

o6:10N

o2:10 o5:15

o3:20

F

K

JJ

(o1,a1) » (o4,a1) » (o2,a2) » (o6,a1) » (o5,a4) » (o3,a5)

Shape Graph

Object Graph


Outline



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)


Deadlock handling: our approach

Shape analysis helps us prune parts of WFG and other graphs in all graph-based algorithms


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


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)


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.


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)


Lock preclaiming: background

Standard 2PL acquires locks gradually Conservative 2PL preclaims all the locks

Fewer aborts upon high contention & long transactions

Shorter wait-for chainsT1.A(O2)

T2.A(O1)T2.A(O2) T3.A(O1)

Requires apriori knowledge of locks


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


Outline



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


Evaluation: OO7

Comp

Parts

•Short Read

•2ms

•600/min

•Short Update

•2ms

•10/min

•Long Reorg

•2000ms

•3/min


OO7 Results

0

50

100

S2PL Early Release Preclaim Both

ms

update

query

reorg

Relative delay by scheduler


Delays in short query

Strict 2-Phase Predictive


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


End

Questions?


Evaluation: Car Reservation

1 2 3

User Rate 300/s 30/s 30/s

User dur 30ms 30ms 30ms

Trav Rate 1/min 1/min 1/min

Trav dur 560ms 560ms 1200ms

Maint rate 6min 2min 2min

Maint dur 6s 6s 6s


Evaluation: car reservation

0

5000

Conf 1 Conf 2 Conf 3

S2PL

Pr

Op

Exec0102030405060

Conf 1 Conf 2 Conf 3

3423Starved Starved

Query Traversal


Construction of Shape Graphs

x



F

x.f = s;



F

G

x.f = s;t = x.f.g;



F

G

x.f = s;x.f.g = t; x = x.n;

N

?



F

G

N

x.f = s;x.f.g = t;if (x != null) x = x.n;


Combining Shape Graphs

F

G

N

F

K

J

x = y;


Combining Shape Graphs

F

G

N

F

K

J

Unify graphs recursively


Unification of Shape Graphs

F

G

N

F

K

J

G K

F J

N

Unify graphs recursively


Shape Analysis Algorithm

methods Interpret basic blocks Create shapes for basic blocks Run until fixed-point is reached

Propagate in static callgraph


Static Call Graphs

mainm2m3

m4

m3{a.f = s;o.m4(a)}Class C { m4(F f) { … }

Static representation of calls

f

Unify(a,f)


Call Graphs

Propagate bottom up Merge polymorphic calls

Recursive Calls Fixed point Merge SCC[Ruf00]

m1m2m3

m4B.m4

D1.m4

D2.m4

m1

m2

m1


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

Documents

Ecoop June 15-18 Oslo, Norway 1 Increasing Concurrency in Databases using Program Analysis Roman Vitenberg, Kristian Kvilekval and Ambuj Singh University