Presentation is loading. Please wait.

Presentation is loading. Please wait.

Observations on the Assured Evolution of Concurrent Java Programs Aaron Greenhouse, CMU SEI T. J. Halloran, CMU SCS William L. Scherlis, CMU SCS.

Similar presentations


Presentation on theme: "Observations on the Assured Evolution of Concurrent Java Programs Aaron Greenhouse, CMU SEI T. J. Halloran, CMU SCS William L. Scherlis, CMU SCS."— Presentation transcript:

1 Observations on the Assured Evolution of Concurrent Java Programs Aaron Greenhouse, CMU SEI T. J. Halloran, CMU SCS William L. Scherlis, CMU SCS

2 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI2 public class Logger {... private Filter filter; /**... * @param newFilter a filter object (may be null) */ public void setFilter(Filter newFilter)... { if (!anonymous) manager.checkAccess(); filter = newFilter; } public void log(LogRecord record) {... synchronized (this) { if (filter != null && !filter.isLoggable(record)) return; }... } Example: java.util.logging.Logger

3 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI3 public class Logger {... private Filter filter; /**... * @param newFilter a filter object (may be null) */ public void setFilter(Filter newFilter)... { if (!anonymous) manager.checkAccess(); filter = newFilter; } public void log(LogRecord record) {... synchronized (this) { if (filter != null && !filter.isLoggable(record)) return; }... } Example: java.util.logging.Logger

4 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI4 public class Logger {... private Filter filter; /**... * @param newFilter a filter object (may be null) */ public void setFilter(Filter newFilter)... { if (!anonymous) manager.checkAccess(); filter = newFilter; } public void log(LogRecord record) {... synchronized (this) { if (filter != null && !filter.isLoggable(record)) return; }... } Example: java.util.logging.Logger

5 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI5 /** @lock LogLock is this protects filter */ public class Logger {... private Filter filter; /**... * @param newFilter a filter object (may be null) */ public synchronized void setFilter(Filter newFilter)…{ if (!anonymous) manager.checkAccess(); filter = newFilter; } public void log(LogRecord record) {... synchronized (this) { if (filter != null && !filter.isLoggable(record)) return; }... } Example: java.util.logging.Logger

6 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI6 Concurrent Programming is Hard Reasoning about concurrent programs –What is the design intent? –Is code consistent with the design intent? Need answers to –Assure safety of program –Evolve program

7 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI7 What is the Design Intent? Programmers ask What data is shared by multiple threads? What locks are used to protect it? Whose responsibility is it to acquire the lock? Is this delegate object owned by its referring object?

8 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI8 What is the Design Intent? Programmers often use conventions –E.g., Objects protects themselves But intent can be more complex: –Lock also protects a delegate object E.g., queue protects its underlying array –Certain methods expect caller to acquire lock E.g., “transactional” call patterns –Call isEmpty() before getHead() –Not all fields require protection E.g., single-threaded usage à la AWT

9 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI9 Where is the Design Intent? Recovering design intent is hard: Intent has non-local manifestations: –Distributed across method implementations –Distributed across class and its clients No way to explicitly denote intent –Not part of language

10 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI10 Is Code Consistent with Intent? Infeasible to test: Non-determinism Difficult to inspect: Non-locality Traditional verification tools too painful –High “expression cost” –Uncertain scalability Whole-program analysis –Where’s the whole program? Composable static analysis + Models…

11 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI11 Composable Analysis + Models Models and attributes “Mechanical” properties (non-functional) –“this lock protects these fields” –“single-threaded constructor” –“unaliased field” Models provide cut points –Locking responsibility –Effects –Aliasing Consequences Steps towards scalability –Composability via cut points Incrementality –Models –Analysis –Program components Reduced expressiveness –No representation invariants Tension: Power–Scalability Some analyses almost global

12 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI12 What’s Next… Annotations and the Fluid Analysis Tool Case study results Refactorings for concurrency

13 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI13 The Fluid Eclipse Plug-in Eclipse IDE Fluid Tool View

14 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI14 The Fluid Eclipse Plug-in

15 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI15 Reporting Code–Model Consistency Tool assures annotated models No annotations  no assurance Three classes of results –Code–model consistency –Code–model inconsistency –Informative — Request for annotation

16 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI16 Code–Model Inconsistency Code is wrong — bug in the program –E.g., missing lock acquisition Model is incomplete — bug in model –E.g., need to add more annotations Model is incorrect — bug in model –E.g., wrong lock associated with shared state Analysis is conservative — limitation of tool –E.g., analysis looses track of lock –E.g., memory model trickery

17 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI17 Fluid Tool: Prior Work Annotation, analysis, and tool publications ICSE ’98 ECOOP ’99 Software—Practice and Experience ’01 ICSE ’02 PASTE ’02 Greenhouse Dissertation ‘03 OOPSLA ’03 eclipse Tech eXchange http://www.fluid.cs.cmu.edu/

18 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI18 Example: BoundedFIFO Circular queue used for inter-thread communication in Log4j. /** @lock BufLock is this protects Instance */ public class BoundedFIFO { … LoggingEvent[] buf; int numElts = 0, first = 0, next = 0, size; public BoundedFIFO(int size) { … } /** @requiresLock BufLock */ public LoggingEvent get() { … } /** @requiresLock BufLock */ public void put(LoggingEvent o) { … } // etc. }

19 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI19 Example: BoundedFIFO Circular queue used for inter-thread communication in Log4j. /** @lock BufLock is this protects Instance */ public class BoundedFIFO { … LoggingEvent[] buf; int numElts = 0, first = 0, next = 0, size; public BoundedFIFO(int size) { … } /** @requiresLock BufLock */ public LoggingEvent get() { … } /** @requiresLock BufLock */ public void put(LoggingEvent o) { … } // etc. } Instances use themselves as the lock

20 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI20 Example: BoundedFIFO Circular queue used for inter-thread communication in Log4j. /** @lock BufLock is this protects Instance */ public class BoundedFIFO { … LoggingEvent[] buf; int numElts = 0, first = 0, next = 0, size; public BoundedFIFO(int size) { … } /** @requiresLock BufLock */ public LoggingEvent get() { … } /** @requiresLock BufLock */ public void put(LoggingEvent o) { … } // etc. } Clients must acquire lock before calling method

21 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI21 BoundedFIFO: Bad Callsite

22 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI22 BoundedFIFO: Owned Array (1)

23 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI23 BoundedFIFO: Owned Array (2) /** @lock BufLock is this protects Instance */ public class BoundedFIFO { … /** @unshared * @aggregate [] into Instance */ LoggingEvent[] buf; // etc. }

24 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI24 BoundedFIFO: Constructor (1)

25 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI25 BoundedFIFO: Constructor (2) /** @lock BufLock is this protects Instance */ public class BoundedFIFO { … /** @singleThreaded * @borrowed this */ public BoundedFIFO(int maxSize) { … } // etc. }

26 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI26 BoundedFIFO: Assured

27 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI27 Case Study: Util.Concurrent

28 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI28 Case Studies SystemkSLOC# of Annotations jEdit 4.172.336 Log4j 1.2.819.843 Util.concurrent 1.3.2 10.3158 java.util.logging 1.4.1_01 2.345 Sponsor program 17.412 Sponsor program 2323549

29 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI29 Refactoring Preconditions ensure transformation safety –[ How we got into analysis ] Safe refactoring needs –Explicit models –Analysis of consistency –Refactorings that transform both code and model

30 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI30 Split Lock: Before /** @lock RectLock is this protects Instance */ public class Rectangle { private int x, y; private int w, h; public synchronized void move(int newX, int newY) { x = newX; y = newY; } public synchronized void resize(int newW, int newH) { w = newW; h = newH; } public synchronized void reconfigure( int newX, int newY, int newW, int newH) { x = newX; y = newY; w = newW; h = newH; } // etc. } {x,y} {w,h} {x,y, w,h} If move() and resize() are invoked more frequently than reconfigure(), splitting the lock will allow more aggressive concurrency within the program. Start with an assured locking model

31 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI31 Split Lock: After /** @region public Location * @lock LocationLock is this protects Location * @region public Dimension * @lock DimLock is dimLock protects Dimension */ public class Rectangle { private final Object dimLock = new Object(); /** @mapInto Location */ private int x, y; /** @mapInto Dimension */ private int w, h; public void move(int newX, int newY) { synchronized (this) { x = newX; y = newY; } } public void resize(int newW, int newH) { synchronized (dimLock) { w = newW; h = newH; } } public void reconfigure( int newX, int newY, int newW, int newH) { synchronized (this) { synchronized (dimLock) { x = newX; y = newY; w = newW; h = newH; } // etc. }

32 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI32 Split Lock Caveats Subclasses Lock order to prevent deadlock Updating @requiresLock annotations Allowable interleavings

33 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI33 Refactoring: Related Work [Lea 2000] describes lock splitting as a design concept Compiler optimizations that modify the scope of critical sections –Via escape analysis [Blanchet ’99], [Bogda & Hoelzle ’99], [Choi, et al. ’99], [Whaley & Rinard ’99] –[Plevyak, Zhang & Chien ’95] –In automatically parallelized programs [Diniz & Rinard ’96], [Diniz & Rinard ’97]

34 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI34 Conclusion Concurrency is difficult Defies testing and inspection –Non-locality –non-determinism Complex code patterns –Driven by performance Reverse engineering is painful –Capture results as models/annotations How can we be principled? Avoid concurrency Capture models Use refactoring –Introduce complexity in a systematic manner Consistency of code and model Bad news –Finds bugs Good news –Assures absence of useful categories of bugs Enables safe refactoring Achieving success in practice Scalability Incrementality Late adoption Low barrier to entry http://www.fluid.cs.cmu.edu

35 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI35 Extra Slides Here

36 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI36 Split Lock (1) Decreases lock granularity by moving “down” the region hierarchy. Inputs –Lock annotation @lock L is M protects R –Lock names { L i } and references { M i } to use as the locks for subregions { R j } of R

37 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI37 Split Lock (2) For each synchronized block that acquires L –Determine the regions { R j } used within –Replace with nested synchronized blocks that acquire { L j } Remove original @lock annotation Insert new annotations @lock L i is M i protects R i

38 CSJP — 25 July 2004Aaron Greenhouse, CMU SEI38 Split Lock: Before /** @lock RectLock is this protects Instance * @region public Location * @region public Dimension */ public class Rectangle { /** @mapInto Location */ private int x, y; /** @mapInto Dimension */ private int w, h; public synchronized void move(int newX, int newY) { x = newX; y = newY; } public synchronized void resize(int newW, int newH) { w = newW; h = newH; } public synchronized void reconfigure( int newX, int newY, int newW, int newH) { x = newX; y = newY; w = newW; h = newH; } // etc. }


Download ppt "Observations on the Assured Evolution of Concurrent Java Programs Aaron Greenhouse, CMU SEI T. J. Halloran, CMU SCS William L. Scherlis, CMU SCS."

Similar presentations


Ads by Google