Presentation is loading. Please wait.

Presentation is loading. Please wait.

Laboratory for Computer Science Massachusetts Institute of Technology Ownership Types for Safe Region-Based Memory Management in Real-Time Java Chandrasekhar.

Similar presentations


Presentation on theme: "Laboratory for Computer Science Massachusetts Institute of Technology Ownership Types for Safe Region-Based Memory Management in Real-Time Java Chandrasekhar."— Presentation transcript:

1 Laboratory for Computer Science Massachusetts Institute of Technology Ownership Types for Safe Region-Based Memory Management in Real-Time Java Chandrasekhar Boyapati Alexandru Salcianu William Beebee Martin Rinard

2 Ownership types Ownership types  Clarke et al. ( OOPSLA ’98 ) ( OOPSLA ’02 )  Boyapati et al. ( OOPSLA ’01 ) ( OOPSLA ’02 )  Boyapati et al. ( POPL ’03 ) ( OOPSLA ’03 )  Aldrich et al. ( OOPSLA ’02 ) Region types Region types  Tofte, Talpin ( POPL ’94 )  Christiansen et al. ( DIKU ’98 )  Crary et al. ( POPL ’99 )  Grossman et al. ( PLDI ’02 ) Unified type system for OO languages Unified type system for OO languages  Object encapsulation AND Memory safety  Foundation for enforcing other safety properties  Data race and deadlock freedom  Safe software upgrades  Safe real-time programming (Real-Time Java) Contribution (Object encapsulation) (Memory safety)

3 Talk Overview Type system for OO programs Type system for OO programs  Ownership types  Region types  Similarities  Unified type system Extensions for Real-Time Java Extensions for Real-Time Java Experience Experience

4 Ownership Types

5 data next head data next data next … … … Stack Node Data data next … Say Stack s is implemented with linked list Say Stack s is implemented with linked list

6 Ownership Types s Say Stack s is implemented with linked list Say Stack s is implemented with linked list

7 Ownership Types s o ~ ~ Say Stack s is implemented with linked list Say Stack s is implemented with linked list Outside objects must not access list nodes Outside objects must not access list nodes

8 Ownership Types Program can declare s owns list nodes Program can declare s owns list nodes System ensures list is encapsulated in s System ensures list is encapsulated in s s o ~ ~ Say Stack s is implemented with linked list Say Stack s is implemented with linked list Outside objects must not access list nodes Outside objects must not access list nodes

9 Region-Based Memory Management Region-Based Memory Management

10 Provides control over memory Provides control over memory  For efficiency  For predictability While ensuring memory safety While ensuring memory safety Region-Based Memory Management Region-Based Memory Management

11 Programs can create a region Programs can create a region Allocate objects in a region Allocate objects in a region Delete a region & free all objects in it Delete a region & free all objects in it Region-Based Memory Management Region-Based Memory Management

12 Programs can create a region Programs can create a region Allocate objects in a region Allocate objects in a region Delete a region & free all objects in it Delete a region & free all objects in it Region lifetimes are nested Region lifetimes are nested Region-Based Memory Management Region-Based Memory Management

13 Ensure memory safety Ensure memory safety Disallow pointers from outside to inside Disallow pointers from outside to inside Region Types Region Types ~ ~

14 Ownership types ensure object encapsulation Ownership types ensure object encapsulation Disallow pointers from outside to inside Disallow pointers from outside to inside Region types ensure memory safety Region types ensure memory safety Disallow pointers from outside to inside Disallow pointers from outside to inside Similarities

15 Unified Type System

16 Disallows pointers from outside to inside Disallows pointers from outside to inside Ensures object encapsulation Ensures object encapsulation Ensures memory safety Ensures memory safety Unified Type System

17

18 Every object has an owner Every object has an owner Owner can be another object or a region Owner can be another object or a region Ownership relation forms a forest of trees Ownership relation forms a forest of trees Unified Type System

19 An object owned by another object An object owned by another object  Is an encapsulated subobject of its owner Unified Type System

20 An object owned by another object An object owned by another object  Is an encapsulated subobject of its owner An object owned by a region An object owned by a region  Is allocated in that region Unified Type System

21 An object owned by another object An object owned by another object  Is an encapsulated subobject of its owner  Is allocated in the same region as its owner An object owned by a region An object owned by a region  Is allocated in that region Unified Type System

22 Programmers specify Programmers specify  Owner of every object  In types of variables pointing to objects Type checker statically verifies Type checker statically verifies  No pointers from outside to inside

23 class Stack { Node head; Node head; void push(Data data) {…} void push(Data data) {…} Data pop() {…} Data pop() {…}} class Node { Node next; Node next; Data data; Data data; …} Unified Type System data next head data next data next … … … Stack Node Data

24 class Stack  stackOwner, dataOwner  { Node  this, dataOwner  head; Node  this, dataOwner  head;} class Node  nodeOwner, dataOwner  { Node  nodeOwner, dataOwner  next; Node  nodeOwner, dataOwner  next; Data  dataOwner  data; Data  dataOwner  data;}

25 Unified Type System Classes are parameterized with owners First owner owns the corresponding object class Stack  stackOwner, dataOwner  { Node  this, dataOwner  head; Node  this, dataOwner  head;} class Node  nodeOwner, dataOwner  { Node  nodeOwner, dataOwner  next; Node  nodeOwner, dataOwner  next; Data  dataOwner  data; Data  dataOwner  data;}

26 class Stack  stackOwner, dataOwner  { Node , dataOwner  head; Node  this, dataOwner  head;} class Node  nodeOwner, dataOwner  { Node  nodeOwner, dataOwner  next; Node  nodeOwner, dataOwner  next; Data  dataOwner  data; Data  dataOwner  data;} Unified Type System Stack owns the head Node

27 class Stack  stackOwner, dataOwner  { Node  this, dataOwner  head; Node  this, dataOwner  head;} class Node  nodeOwner, dataOwner  { Node , dataOwner  next; Node  nodeOwner, dataOwner  next; Data  dataOwner  data; Data  dataOwner  data;} Unified Type System All Nodes have the same owner

28 Ownership Types for Safe Regions s is an encapsulated stack with encapsulated elements class Stack  stackOwner, dataOwner  { Node  this, dataOwner  head; Node  this, dataOwner  head;} class Node  nodeOwner, dataOwner  { Node  nodeOwner, dataOwner  next; Node  nodeOwner, dataOwner  next; Data  dataOwner  data; Data  dataOwner  data;} class Client { Stack  this, this  s; Stack  this, this  s;}

29 Unified Type System class Stack  stackOwner, dataOwner  { Node  this, dataOwner  head; Node  this, dataOwner  head;} class Node  nodeOwner, dataOwner  { Node  nodeOwner, dataOwner  next; Node  nodeOwner, dataOwner  next; Data  dataOwner  data; Data  dataOwner  data;}

30 Unified Type System class Stack  stackOwner, dataOwner  { Node  this, dataOwner  head; Node  this, dataOwner  head;} class Node  nodeOwner, dataOwner  { Node  nodeOwner, dataOwner  next; Node  nodeOwner, dataOwner  next; Data  dataOwner  data; Data  dataOwner  data;} (RegionHandle  r  h) { …} r is the region name. It is a compile time entity. h is the region handle. It is a runtime value.

31 Unified Type System Region r2 is nested inside region r1 class Stack  stackOwner, dataOwner  { Node  this, dataOwner  head; Node  this, dataOwner  head;} class Node  nodeOwner, dataOwner  { Node  nodeOwner, dataOwner  next; Node  nodeOwner, dataOwner  next; Data  dataOwner  data; Data  dataOwner  data;} (RegionHandle  r1  h1) { (RegionHandle  r2  h2) { (RegionHandle  r2  h2) { Stack  r1, r1  s1; Stack  r1, r1  s1; Stack  r2, r1  s2; Stack  r2, r1  s2;}}

32 Unified Type System class Stack  stackOwner, dataOwner  { Node  this, dataOwner  head; Node  this, dataOwner  head;} class Node  nodeOwner, dataOwner  { Node  nodeOwner, dataOwner  next; Node  nodeOwner, dataOwner  next; Data  dataOwner  data; Data  dataOwner  data;} (RegionHandle  r1  h1) { (RegionHandle  r2  h2) { (RegionHandle  r2  h2) { Stack  r1, r1  s1; Stack  r1, r1  s1; Stack  r2, r1  s2; Stack  r2, r1  s2;}} Stack and its elements are in the same region

33 Unified Type System class Stack  stackOwner, dataOwner  { Node  this, dataOwner  head; Node  this, dataOwner  head;} class Node  nodeOwner, dataOwner  { Node  nodeOwner, dataOwner  next; Node  nodeOwner, dataOwner  next; Data  dataOwner  data; Data  dataOwner  data;} (RegionHandle  r1  h1) { (RegionHandle  r2  h2) { (RegionHandle  r2  h2) { Stack  r1, r1  s1; Stack  r1, r1  s1; Stack  r2, r1  s2; Stack  r2, r1  s2;}} Stack and its elements are in different regions

34 Unified Type System class Stack  stackOwner, dataOwner  { Node  this, dataOwner  head; Node  this, dataOwner  head;} class Node  nodeOwner, dataOwner  { Node  nodeOwner, dataOwner  next; Node  nodeOwner, dataOwner  next; Data  dataOwner  data; Data  dataOwner  data;} (RegionHandle  r1  h1) { (RegionHandle  r2  h2) { (RegionHandle  r2  h2) { Stack  r1, r1  s1; Stack  r1, r1  s1; Stack  r2, r1  s2; Stack  r2, r1  s2; Stack  r1, r2  s3; // illegal Stack  r1, r2  s3; // illegal}} Scoping alone does not ensure safety in presence of subtyping First owner must be same as or nested in other owners

35 Other details Other details  Special regions  Garbage collected heap  Immortal region  Runtime provides  Region handle of most nested region  Region handle of an object  Type checker statically infers  If a region handle is in scope Unified Type System

36 Enforces object encapsulation Enforces object encapsulation  Boyapati, Liskov, Shrira ( POPL ’03 ) Enable safe region-based memory management Enable safe region-based memory management  Boyapati, Salcianu, Beebee, Rinard ( PLDI ’03 ) Prevents data races and deadlocks Prevents data races and deadlocks  Boyapati, Rinard ( OOPSLA ’01 )  Boyapati, Lee, Rinard ( OOPSLA ’02 ) Enables upgrades in persistent object stores Enables upgrades in persistent object stores  Boyapati, Liskov, Shrira, Moh, Richman ( OOPSLA ’03 ) Unified Type System

37 Talk Overview Unified type system for OO programs Unified type system for OO programs Extensions for Real-time Java Extensions for Real-time Java  Multithreaded programs  Real-time programs  Real-time Java programs Experience Experience

38 Regions for Multithreaded Programs Shared regions with reference counting Shared regions with reference counting  Grossman ( TLDI ’01 )

39 Regions for Multithreaded Programs Shared regions with reference counting Shared regions with reference counting  Grossman ( TLDI ’01 ) Sub regions within shared regions Sub regions within shared regions To avoid memory leaks in shared regions To avoid memory leaks in shared regions

40 Regions for Multithreaded Programs Shared regions with reference counting Shared regions with reference counting  Grossman ( TLDI ’01 ) Sub regions within shared regions Sub regions within shared regions To avoid memory leaks in shared regions To avoid memory leaks in shared regions ~ ~

41 Regions for Multithreaded Programs Shared regions with reference counting Shared regions with reference counting  Grossman ( TLDI ’01 ) Sub regions within shared regions Sub regions within shared regions To avoid memory leaks in shared regions To avoid memory leaks in shared regions Typed portal fields in sub regions Typed portal fields in sub regions To start inter-thread communication To start inter-thread communication

42 Regions for Multithreaded Programs Shared regions with reference counting Shared regions with reference counting  Grossman ( TLDI ’01 ) Sub regions within shared regions Sub regions within shared regions To avoid memory leaks in shared regions To avoid memory leaks in shared regions Typed portal fields in sub regions Typed portal fields in sub regions To start inter-thread communication To start inter-thread communication Region kinds to make it all work Region kinds to make it all work

43 Talk Overview Unified type system for OO programs Unified type system for OO programs Extensions for Real-time Java Extensions for Real-time Java  Multithreaded programs  Real-time programs  Real-time Java programs Experience Experience

44 Regions for Real-Time Programs Real-time (RT) threads with real-time constraints Real-time (RT) threads with real-time constraints RT threads cannot use garbage collected heap RT threads cannot use garbage collected heap RT threads can use immortal memory RT threads can use immortal memory RT threads can use regions RT threads can use regions

45 Regions for Real-Time Programs Real-time (RT) threads with real-time constraints Real-time (RT) threads with real-time constraints RT threads cannot use garbage collected heap RT threads cannot use garbage collected heap RT threads can use immortal memory RT threads can use immortal memory RT threads can use regions RT threads can use regions RT threads cannot read heap references RT threads cannot read heap references RT threads cannot overwrite heap references RT threads cannot overwrite heap references

46 Regions for Real-Time Programs Real-time (RT) threads with real-time constraints Real-time (RT) threads with real-time constraints RT threads cannot use garbage collected heap RT threads cannot use garbage collected heap RT threads can use immortal memory RT threads can use immortal memory RT threads can use regions RT threads can use regions RT threads cannot read heap references RT threads cannot read heap references RT threads cannot overwrite heap references RT threads cannot overwrite heap references Ownership types augmented with effects clauses Ownership types augmented with effects clauses To statically verify above properties To statically verify above properties

47 Real-Time Java (RTJ) Extension to Java for real-time programs Extension to Java for real-time programs Java Specification Request (JSR) 1 Java Specification Request (JSR) 1 http://www.rtj.org http://www.rtj.org

48 Real-Time Java (RTJ) Extension to Java for real-time programs Extension to Java for real-time programs Java Specification Request (JSR) 1 Java Specification Request (JSR) 1 http://www.rtj.org http://www.rtj.org Real-time (RT) threads Real-time (RT) threads Region-based memory management Region-based memory management Threads cant violate memory safety Threads cant violate memory safety RT threads cant interact with garbage collector RT threads cant interact with garbage collector

49 Real-Time Java (RTJ) Uses dynamic checks to ensure Uses dynamic checks to ensure  No pointers from outer to inner regions  Nesting of regions forms a hierarchy  RT threads do not read heap refs  RT threads do not overwrite heap refs Introduces new failure modes Introduces new failure modes Programming model is difficult to use Programming model is difficult to use

50 Region Types as Front-End for RTJ Typechecker Translator (Removes extra types) (Generates real-time Java) Compiler JVM Real-time Java bytecodes + Extra types types Java

51 Benefits of Using Region Types Safety Safety Checks errors at compile time Checks errors at compile time Efficiency Efficiency Avoids runtime checking overhead Avoids runtime checking overhead Typechecker Translator (Removes extra types) (Generates real-time Java) Real-time Java + Extra types types Java

52 Experience

53 Reducing Programming Overhead Type inference for method local variables Type inference for method local variables Default types for method signatures & fields Default types for method signatures & fields User defined defaults as well User defined defaults as well Significantly reduces programming overhead Significantly reduces programming overhead Approach supports separate compilation Approach supports separate compilation

54 Programming Overhead Program # Lines of code # Lines annotated HTTP Server 603 60320 Game Server 97 9710 Database Server 244 24424 Image Recognition 567 567 8 java.util.Vector 992 99235java.util.Hashtable 1011 101153 Water185031Barnes185016

55 RTJ Dynamic Checking Overhead Program Execution Time (sec) Speed Up Dynamic Checks Static Checks Water2.552.0624%Barnes 21.6 21.6 19.1 19.113% Image Recognition 8.106.7021% load load 0.813 0.813 0.667 0.66725% cross cross 0.014 0.014 thinning thinning 0.026 0.026 0.023 0.023 10% 10% save save 0.731 0.731 0.617 0.61718%

56 Related Work

57 Our work unifies these areas Ownership types Ownership types  Clarke, Potter, Noble ( OOPSLA ’98 ), ( ECOOP ’01 )  Clarke, Drossopoulou ( OOPSLA ’02 )  Boyapati, Lee, Rinard ( OOPSLA ’01 ) ( OOPSLA ’02 )  Boyapati, Liskov, Shrira, Moh, Richman ( POPL ’03 ) ( OOPSLA ’03 )  Aldrich, Kostadinov, Chambers ( OOPSLA ’02 ) Region types Region types  Tofte, Talpin ( POPL ’94 )  Christiansen, Henglein, Niss, Velschow ( DIKU ’98 )  Crary, Walker, Morrisett ( POPL ’99 )  Grossman, Morrisett, Jim, Hicks, Wang, Cheney ( PLDI ’02 )  Grossman ( TLDI ’03 )

58 Related Work Systems that allow regions to be freed early Systems that allow regions to be freed early  Aiken, Fahndrich, Levien ( PLDI ’95 )  Gay, Aiken ( PLDI ’98 ) ( PLDI ’01 )  Crary, Walker, Morrisett ( POPL ’99 ) Dynamic analysis to infer RTJ regions Dynamic analysis to infer RTJ regions  Deters, Cytron ( ISMM ’02 ) Static analysis to remove RTJ dynamic checks Static analysis to remove RTJ dynamic checks  Salcianu, Rinard ( PPoPP ’01 ) Static analysis to help infer size of RTJ regions Static analysis to help infer size of RTJ regions  Gheorghioiu, Salcianu, Rinard ( POPL ’03 ) Real-time garbage collection Real-time garbage collection  Baker ( CACM ’78 )  Bacon, Cheng, Rajan ( POPL ’03 )

59 Conclusions Unified type system for OO languages Statically enforces several properties Statically enforces several properties  Object encapsulation  Memory safety  Data race and deadlock freedom  Safe software upgrades  Safe real-time programming Type checking is fast and scalable Type checking is fast and scalable Requires little programming overhead Requires little programming overhead Promising way to make programs reliable Promising way to make programs reliable

60 Laboratory for Computer Science Massachusetts Institute of Technology Ownership Types for Safe Region-Based Memory Management in Real-Time Java Chandrasekhar Boyapati Alexandru Salcianu William Beebee Martin Rinard


Download ppt "Laboratory for Computer Science Massachusetts Institute of Technology Ownership Types for Safe Region-Based Memory Management in Real-Time Java Chandrasekhar."

Similar presentations


Ads by Google