The Fluid Project Analytic assurance for dependable Java concurrency

1. The Fluid ProjectAnalytic assurance for dependable Java concurrency Bill Scherlis NASA HDCP WorkshopFebruary 2003 Carnegie Mellon West

2. Provide assurance for “mechanical” dependability attributes • Race conditions • Shared data access • Lock management • Affiliations of threads, code segments, shared state • API and pattern compliance • Sharing • Realtime threads, no-heap, etc. • Code quality and structure • Appropriate typing • Structured design fragments • Ignored exceptions • Others • Unique references, owned, and borrowed • Deadlocks • Effect expectations

3. Create and maintain safe code • Provide assurance • Consistency of code with low-level design intent • Code safety = “mechanical” dependability attributes • Express dependability models • Document dependability-related low-level design intent • Code embodies insufficient information about itself • Maintain explicit consistency as code and intent evolve • Annotations • Composable analyses • Improve quality measurement • Reduce surrogacy • Assist in bug finding

4. Ensure usability by programmers • Principle of early gratification • Increments of effort yield increments of benefit • Effort • Model: Expressing low-level models • Annotate: Affiliating the models with code • Benefit • Static check of safe concurrency, etc • Enforcement of API contracts • Approach • Tool use • Models easy to express, in programmer terms • Succinct annotations • (Cf. type information)

5. Approach • Study existing production code • Concurrency case studies • 2MLOC quality analysis corpus + HDCP testbeds (MERBoard) • Numerous concurrency-related anomalies • Races: failure to acquire locks or to identify critical data • Policy: “bad” and “good” concurrency – definition and enforcement • Many quality issues • Poor abstraction and type selection: API usage”time bombs” • Createtool capability adhering to early-gratification principle • Low barrier to entry • Eclipse – deliver as plug-in for familiar IDE • Avoid language extensions and difficult formalisms • Ease of use • Some value for no work – bug finding • More value for some work – few assertions • Provide both positive and negative results to programmer • Positive strong assurances – e.g., lock policy compliance • Negative results point to remedies

6. The Tool Prototype • Code-checking with annotations • Locks for shared data • Use parameterized regions of state • Method callee/caller lock responsibility • Thread-safe constructors • Assure no escape of object reference • Overly specialized types • Over specialization impairs flexibility • Uncaught exceptions (easy analysis) • Use intent annotations to reduce false positives • Analyses used • Parameterized regions of state • Effect upper bounds • Uniqueness and aliasing • Lock usage • Color analysis • Binding, typing, control flow, etc.

7. Examples • Eclipse demo • Locks  Shared data (Greenhouse) • Type appropriateness and exceptions (Halloran) • Case studies • AWT thread rules and color (Sutherland) • Queries on code (Newman)

8. The Eclipse plugin Concurrency Assurance Initial state • Annotation to document affiliation of lock with shared state • Some annotations for locking responsibility Errors detected • Unprotected access to shared state (with field references identified) • Potential access to a shared object through a protected field • Ignored exceptions Actions to take • Add a small number of annotations – document design intent enable analysis to assure code is consistent with intent

9. The Eclipse plugin Concurrency Assurance Actions taken • Add annotations to identify policy – design intent relating to management of access to shared state • Add annotations to identify intent for unique references, enabling analysis to produce a positive assurance Assurance obtained • All lock preconditions are satisfied for method calls that require callers to hold locks • All accesses to shared fields are protected • Constructor does not allow references to escape (i.e., avoiding leakage)

10. The Eclipse plugin Quality Indicators Overspecialized types • Identify potentially over-specialized types declared for program variables. Note • This indicates potential inappropriate use of an API, which can lead to downstream evolution problems • This is a code style issue – these usages are (strictly speaking) not incorrect.

11. The Eclipse plugin Quality Indicators Uncaught exceptions • Identify potentially dangerous cases of caught-and-ignored exceptions. Note • Typically benign cases include InterruptedException and IOException. • Typically dangerous cases include Throwable and Exception. • This is a code style issue – these usages are (strictly speaking) not incorrect.

12. Regions of state Lock assignments Condition variables Conditions checked Lock responsibility Thread and state model jini.WakeupManager

13. Example: AWT Thread Policy API threading model • Exactly one draw/event thread (per app) • Hence no locking required for GUI update • Don’t steal the event thread • Otherwise GUI could pause or freeze • Don’t redraw in other threads • Otherwise GUI state could be corrupted (see 1) Example results • Validation of AWT thread policy compliance • Data race in a Java demo app

14. Graph AWT Callbacks GraphPanel AWT Callbacks run relax GraphLayout Thread LifeCycle AWT Thread Compute Thread start() * * * * X stop()

15. Graph AWT Callbacks GraphPanel AWT Callbacks run relax GraphLayout Thread LifeCycle AWT Thread Compute Thread start() * * * * X stop()

16. Tooling Delivery Eclipse plug-in (100kloc) Standalone operation Server-side build element Ultra-fine-grained versioning Multiple Java analyses Analysis infrastructure Model/code visualization Models and analysis Locks (ICSE’02) Models (UML’01) Effects (ECOOP’99) Coloring (PASTE’02) RTSJ coloring Uniqueness and alias Capabilities Practices Concurrency design Query-based code analysis API design for compliance Fragment architecture Empirical analyses Quality practice (ICSE’02 OpSrc) Bugs and issues Quality evaluation (to appear) HDCP testbed engagement MERBoard [M3] Code quality analysis MDS tbd [M1] Concurrent/RT Java assurance Broadly applicable [M2] Java quality analysis Status