a type system for preventing data races and deadlocks in the java virtual machine language pratibha...

A Type System for Preventing A Type System for Preventing Data Races and Deadlocks in the Data Races and Deadlocks in the Java Virtual Machine LanguageJava Virtual Machine Language

Pratibha Permandla

Michael Roberson

Chandrasekhar Boyapati

University of Michigan

OutlineOutline

Motivation• Data Races

• Deadlocks

• Object EncapsulationType SystemRelated Work

Motivation• Data Races

• Deadlocks

• Object EncapsulationType SystemRelated Work

Data Races in Multithreaded Data Races in Multithreaded ProgramsPrograms

Two threads access the same dataAt least one access is a writeNo synchronization to separate accesses

Thread 1:Thread 1:

x = x + 1; x = x + 1;

Thread 2:Thread 2:

x = x + 2; x = x + 2;

Why Data Races are a ProblemWhy Data Races are a ProblemSome correct programs contain data races

But most races are programming errors

• Code intended to execute atomically

• Synchronization omitted by mistake

Consequences can be severe

• Nondeterministic timing-dependent bugs

• Difficult to detect, reproduce, eliminate

Avoiding Data RacesAvoiding Data Races

Thread 1:Thread 1:

x = x + 1; x = x + 1;

Thread 2:Thread 2:

x = x + 2; x = x + 2;

Associate locks with shared mutable dataAcquire lock before data accessRelease lock after data access

Thread 1:Thread 1:

lock(l);lock(l);

x = x + 1; x = x + 1;

unlock(l);unlock(l);

Thread 2:Thread 2:

lock(l); lock(l);

x = x + 2; x = x + 2;

Problem: Locking is not enforced!Inadvertent programming errors…Problem: Locking is not enforced!Inadvertent programming errors…

Thread 1:Thread 1:

lock(l);lock(l);

x = x + 1; x = x + 1;

Thread 2:Thread 2:

lock(l); lock(l);

x = x + 2; x = x + 2;

Avoiding DeadlocksAvoiding Deadlocks

Thread 1Thread 1

Thread 2Thread 2

Thread nThread n

……

Lock 1Lock 1 Lock nLock n

Lock 2Lock 2 Lock 3Lock 3

Thread 1Thread 1

Thread 2Thread 2

Thread nThread n

……

Associate a partial order among locksAcquire locks in order

Thread 1Thread 1

Thread 2Thread 2

Thread nThread n

……

~~~~Problem: Lock ordering is not enforced!Problem: Lock ordering is not enforced!

Inadvertent programming errors…Inadvertent programming errors…

Problem: Lock ordering is not enforced!Problem: Lock ordering is not enforced!

Object EncapsulationObject Encapsulation

Enables local reasoning

Stack s is implemented with a linked listOutside objects must not access list nodes

ssoo ~~~~

Object EncapsulationObject EncapsulationStack s is implemented with a linked listOutside objects must not access list nodes

Problem: Encapsulation is not enforced!Problem: Encapsulation is not enforced!

ssoo ~~~~

SolutionSolution

Type system for object-oriented languagesStatically prevents errors

• data races, deadlocks, representation exposureProgrammers write simple annotations

• how objects are synchronized

• partial ordering on locks to prevent deadlocks

• encapsulation hierarchyType checker statically verifies program

• Objects are used only as specified

Ownership TypesOwnership Types

Every object is owned by• Another object, or

• A thread, or

• A special global owner called world

Ownership forms a tree rooted at world

Thread1Thread1Thread1Thread1 Thread2Thread2Thread2Thread2

Thread2 objectsThread2 objectsThread1 objectsThread1 objects Potentially shared objectsPotentially shared objects

worldworldworldworld

Ownership TypesOwnership Types

Prevent representation exposure• No references from outside object o to objects owned by o

• No references from outside thread t to objects owned by t

Ownership TypesOwnership Types Prevent races

• For race free access to an object not owned by a thread The lock on its outermost containing object must be held

• For race free access to an object owned by a thread No lock needs to be held

Acquire LocksAcquire Locks

Ownership TypesOwnership Types Prevent Deadlocks

• Locks must be ordered according to a partial order

• Locks must be acquired in descending order

Acquire LocksAcquire Locks

class TStack {class TStack {

TNode head;TNode head;

void push(T value) {…}void push(T value) {…}

T pop() {…}T pop() {…}

class TNode {class TNode {

TNode next; TNode next;

T value;T value;

… …

class T {…}class T {…}

TStack ExampleTStack Example

valuevalue

nextnext

headhead

valuevalue

nextnext

valuevalue

nextnext

…… …………

TStackTStack

TNodeTNode

class TStackclass TStackstackOwner, TOwnerstackOwner, TOwner { { TNodeTNodethis, TOwnerthis, TOwner head; head;

… …

class TNodeclass TNodenodeOwner, TOwnernodeOwner, TOwner { { TNodeTNodenodeOwner, TOwnernodeOwner, TOwner next; next;

TTTOwnerTOwner value; value;

… …

TStackTStack

TNodeTNode

class TStackclass TStackstackOwner, TOwnerstackOwner, TOwner { { TNodeTNodethis, TOwnerthis, TOwner head; head;

… …

class TNodeclass TNodenodeOwner, TOwnernodeOwner, TOwner { { TNodeTNodenodeOwner, TOwnernodeOwner, TOwner next; next;

TTTOwnerTOwner value; value;

… …

TStackTStack

TTTStackTStackthisThread, thisThreadthisThread, thisThread s1; s1;

TStackTStackthisThread, worldthisThread, world s2; s2;

TStackTStackworld, worldworld, world s3; s3;

worldworld

Thread1Thread1

Checking ProgramsChecking Programs

Type Type checkerchecker CompilerCompiler

BytecodesBytecodes

+ Extra + Extra typestypes

JavaJava

VirtualVirtualMachineMachine

Previous work was on SafeJava

Our ApproachOur Approach

Type Type checkerchecker CompilerCompiler

BytecodesBytecodes

+ Extra + Extra typestypes

JavaJava

+ Extra+ Extratypes ontypes on

interfacesinterfaces

IntraproceduralIntraproceduralTypeType

InferenceInference

BytecodeBytecodeVerifierVerifier

VirtualVirtualMachineMachine

Previous work was on SafeJava We extend to SafeJVML

• Verifies Java bytecodes

ExampleExample

1234567891011121314151617181920212223242526272829

load 0store 3load 3monitorenterload 1store 4load 4monitorenterload 0getfieldpush 0ifeq 25load 1load 1getfieldload 2addputfieldload 0load 0getfieldload 2subputfieldload 4monitorexitload 3monitorexitreturn

static void transfer(Account, Account, int); class Account { private int balance; static void transfer(Account from, Account to, int x) { synchronized (to) { synchronized (from) { if (from.balance != 0) { to.balance += x; from.balance -= x; } } } }}

No block structure No types on stack or local variables Requires alias analysis

ExampleExamplei Instruction Fi[0] Fi[1] Fi[2] Fi[3] Fi[4] Si LSi

1234567891011121314151617181920212223242526272829

Fi[n] : Type of local variable nat instruction i

Si : Types of elements of the stackat instruction iLSi : Types of locks held

at instruction i

Problem: Can’t tell which object islocked based on the type

Indexed TypesIndexed Types

Solution: Use indexed types• Laneve and Bigliardi (TIC ’00)

• Example : Object3

• Objects with identical indexed types are equal

• Otherwise, unknown

ExampleExamplei Instruction Fi[0] Fi[1] Fi[2] Fi[3] Fi[4] Si LSi

1234567891011121314151617181920212223242526272829

AccountAccount1

Account1

AccountAccountAccountAccountAccountAccount5

Account5

intintintintintintintintintintintintintintintintintintintintintintintintintintintintint

----Account1

Account1

------------Account5

Account5

Account1

Account5

Account1

intint.int

Account5

Account5.Account5

int.Account5

int.int.Account5

int.Account5

Account1

Account1.Account1

int.Account1

int.int.Account1

int.Account1

Account5

Account1

Account1, Account5

Account1

Static SemanticsStatic Semantics

i Instruction Fi[0] Fi[1] Fi[2] Fi[3] Fi[4] Si LSi

1234567891011121314151617181920212223242526272829

AccountAccount1

Account1

Account5

----Account1

Account1

------------Account5

Account5

Account1

Account5

Account1

intint.int

Account5

Account5.Account5

int.Account5

int.int.Account5

int.Account5

Account1

Account1.Account1

int.Account1

int.int.Account1

int.Account1

Account5

Account1

Account1, Account5

Account1

M[i] = add

i+1 Dom(M)

Fi <: Fi+1

Si = int.int.β

int.β <: Si+1

LSi = LSi+1

Static SemanticsStatic Semanticsi Instruction Fi[0] Fi[1] Fi[2] Fi[3] Fi[4] Si LSi

1234567891011121314151617181920212223242526272829

AccountAccount1

Account1

Account5

----Account1

Account1

------------Account5

Account5

Account1

Account5

Account1

intint.int

Account5

Account5.Account5

int.Account5

int.int.Account5

int.Account5

Account1

Account1.Account1

int.Account1

int.int.Account1

int.Account1

Account5

Account1

Account1, Account5

Account1

M[i] = ifeq L

i+1, L Dom(M)

Fi <: Fi+1

Si <: t.t.Si+1

LSi = LSi+1

Fi <: FL

Si <: t.t.SL

LSi = LSL

1234567891011121314151617181920212223242526272829

AccountAccount1

Account1

Account5

----Account1

Account1

------------Account5

Account5

Account1

Account5

Account1

intint.int

Account5

Account5.Account5

int.Account5

int.int.Account5

int.Account5

Account1

Account1.Account1

int.Account1

int.int.Account1

int.Account1

Account5

Account1

Account1, Account5

Account1

M[i] = monitorenter

i+1 Dom(M)

Fi <: Fi+1

Si <: cnworld,...Si+1

LSi+1 = cnworld,...LSi

1234567891011121314151617181920212223242526272829

AccountAccount1

Account1

Account5

----Account1

Account1

------------Account5

Account5

Account1

Account5

Account1

intint.int

Account5

Account5.Account5

int.Account5

int.int.Account5

int.Account5

Account1

Account1.Account1

int.Account1

int.int.Account1

int.Account1

Account5

Account1

Account1, Account5

Account1

M[i] = getfield ||cnf1..n,fd,t||Fi+1 Dom(M)

Fi <: Fi+1

Si <: cno1..n.β

t[o1/f1]..[on/fn][cno1..n/this].β <: Si+1

Lock(cno1..n) LSi

LSi = LSi+1

1234567891011121314151617181920212223242526272829

AccountAccount1

Account1

Account5

----Account1

Account1

------------Account5

Account5

Account1

Account5

Account1

intint.int

Account5

Account5.Account5

int.Account5

int.int.Account5

int.Account5

Account1

Account1.Account1

int.Account1

int.int.Account1

int.Account1

Account5

Account1

Account1, Account5

Account1

M[i] = getfield ||cnf1..n,fd,t||Fi+1 Dom(M)

Fi <: Fi+1

Si <: cno1..n.β

t[o1/f1]..[on/fn][cno1..n/this].β <: Si+1

Lock(cno1..n) LSi

LSi = LSi+1

M[i] = monitorenter

i+1 Dom(M)

Fi <: Fi+1

Si <: cnworld,...Si+1

LSi+1 = cnworld,...LSi

M[i] = ifeq L

i+1, L Dom(M)

Fi <: Fi+1

Si <: t.t.Si+1

LSi = LSi+1

Fi <: FL

Si <: t.t.SL

LSi = LSL

M[i] = add

i+1 Dom(M)

Fi <: Fi+1

Si = int.int.β

int.β <: Si+1

LSi = LSi+1

Properties of SafeJVMLProperties of SafeJVML SafeJVML programs are free of data races

SafeJVML programs are free of deadlocks

SafeJVML programs are free of encapsulation errors

Need a proof of these properties Need a formalization of dynamic semantics

SafeJVML programs are free of data races

SafeJVML programs are free of deadlocks

SafeJVML programs are free of encapsulation errors

Need a proof of these properties Need a formalization of dynamic semantics

Dynamic SemanticsDynamic Semantics

o1f : o3v : 2

o2a : o5

o4n : 1

o3a : o3

Thread1Thread2Thread3Thread4

First Activation Record

Second Activation Record

Current Activation Record

M : foo pc : 6

o3 7 o1o1

Local Variables: Stack:

o4 o1Locks:

Dynamic SemanticsDynamic SemanticsThread1Thread2Thread3Thread4

M : foo pc : 6

o3 7 o1o1

Locks:

o1f : o3v : 2

o2a : o5

o4n : 1

o3a : o3

M[pc] = getfield v

(M,pc,f,o.s,ls.A); h →

(M,pc+1,f,(h[o].v).s,ls.A); h

pc : 7

M : foo

o3 7 o12

Locks:

o1f : o3v : 2

o2a : o5

o4n : 1

o3a : o3

M[pc] = add

(M,pc,f,v1.v2.s,ls.A); h →

(M,pc+1,f,(v1+v2).s,ls.A); h

pc : 7pc : 8

M : foo

o3 7 o16

Locks:

o1f : o3v : 2

o2a : o5

o4n : 1

o3a : o3

M[pc] = store 0

(M,pc,f,v.s,ls.A); h →

(M,pc+1,f[0 →v],s,ls.A); h

pc : 8pc : 9

M : foo

6 7 o1

Locks:

o1f : o3v : 2

o2a : o5

o4n : 1

o3a : o3

M[pc] = monitorexit

(M,pc,f,o.s,ls {o}.A); h →

(M,pc+1,f,s,ls.A); h

pc : 9pc : 10

Dynamic SemanticsDynamic Semantics

M[pc] = getfield v

(M,pc,f,o.s,ls.A); h →

(M,pc+1,f,(h[o].v).s,ls.A); h

M[pc] = add

(M,pc,f,v1.v2.s,ls.A); h →

(M,pc+1,f,(v1+v2).s,ls.A); h

M[pc] = store 0

(M,pc,f,v.s,ls.A); h →

(M,pc+1,f[0 →v],s,ls.A); h

M[pc] = monitorexit

(M,pc,f,o.s,ls {o}.A); h →

(M,pc+1,f,s,ls.A); h

Proof SketchProof Sketch

Identify runtime invariants• Relating static and dynamic semantics

• States satisfying invariants are well-typedProve that invariants always hold

Preservation Theorem• A well-typed state only transitions to

other well-typed statesProgress Theorem

• A well-typed program state: transitions to another state, or terminates normally, or has a null dereference

Identify runtime invariants• Relating static and dynamic semantics

• States satisfying invariants are well-typedProve that invariants always holdUse invariants to prove properties

• There are no data races

• There are no deadlocks

• Encapsulation is never violated

Related WorkRelated Work

Preventing Data Races and Deadlocks in Java• Flanagan and Freund (PLDI ’00)• Bacon, Strom, and Tarafdar (OOPSLA ’00)• Boyapati and Rinard (OOPSLA ’01)• Boyapati, Lee, Rinard (OOPSLA ’02)• Grossman (TLDI ’03)

Enforcing Encapsulation in Java• Clarke, Potter, and Noble (OOPSLA ’98)• Clarke and Drossopoulou (OOPSLA ’02)• Aldrich, Kostadinov, and Chambers (OOPSLA ’02)• Boyapati, Liskov, Shiria (POPL ’03)• Krishnaswamy and Aldrich (PLDI ’05)

Related WorkRelated Work

Formalizing JVML• Freund and Mitchell (OOPSLA ’98)• Bertelsen (WPAM ’98)• Qian (FSSJ ’99)

Formalizing subroutines in JVML• Stata and Abadi (POPL ’98)• Callahan (POPL ’99)• Klein and Wildmoser (JAR ’03)

Tracking aliases in JVML• Laneve and Bigliardi (TIC ’00)• Iwama and Kobayashi (ASIA-PEPM ’02)

A Type System for Preventing A Type System for Preventing Data Races and Deadlocks in the Data Races and Deadlocks in the Java Virtual Machine LanguageJava Virtual Machine Language

Pratibha Permandla

Michael Roberson

Chandrasekhar Boyapati

University of Michigan

a type system for preventing data races and deadlocks in the java virtual machine language pratibha...

data races thread

thread n lock

deadlocks thread

data access thread

lock n lock

unlockl thread

errors data races

data races problem

Documents

korat: automated testing based on java predicates authors :...

chandrasekhar azad (34)

subramanyan chandrasekhar prize of plasma...

chandrasekhar boyapati laboratory for computer science...

pratibha report

korat automated testing based on java predicates...

ct chest and abdomen for beginners arcot chandrasekhar, m.d....

pratibha sinha. au msgg

cin company name l85195tg1984plc004507 dr.reddy's ... ·...

rajeev chandrasekhar

chandrasekhar s

pratibha syntex

chandrasekhar radiativetransfer

subrahmanyan chandrasekhar - national academy of...

s ep - pratibha singhi

pratibha group

subramanyan chandrasekhar prize of plasma...

prof. pratibha singhi

systematic software testing: the korat aproach (acm sigsoft...

chandrasekhar karatheodory