Modules, Thread Colors, & Data Colors:

1. Modules, Thread Colors, & Data Colors: How bad is the Annotation Burden? Dean F. Sutherland Fluid Meeting 2/7/06

2. Using Electric v8.01 as Examplar • Electric contains • ~120K SLOC • 44 Java Packages • 443 Java Classes • It divides along package boundaries into 4 modules • UI • Tool • DB • Other

3. Module Annos: @module • Placing classes in modules • Apply @module name to each class in each package, using scoped promises in package-info.java file, e.g.@promise “module Tool” for com.sun.electric.tool:*: • Requires 44 promises, one for each package • Could reduce this to 4 promises if we could wild-card package names too!

4. Module Annos: @vis • Identify Classes, Methods, and Fields that are referenced across module boundaries • (Done automatically by the tool) • Mark each as being @vis • Makes it legally visible outside it’s own package • Minimum of one scoped promise per package-info.java file • Actually use ~6 scoped promises per file for readability • Could be automatic with a “make-it-so” button • Either 44 or (44*6)=264 annos • Or 0 (user-written) with “make-it-so”

5. Module Annos: @vis (2) • Example scoped promises:@promise “vis DB” for kill*(**) | modify*(**)| erase*(**) | write*(**)@promise “vis DB” for get*(**) | new(**) | examine*(**)

6. Thread Coloring: Declaring and Importing • Four intereseting Colors: • DBExaminer, DBChanger, Main, GUI • GUI is an abbreviation imported from java.awt. It really means:(AWT | (Compute & !AWT)) • Define DBExaminer, DBChanger, Main in one of the Electric package-info.java files. • @colorImport it into the rest of the classes • One anno/package:@promise “colorImport com.sun.electric;” for com.sun.electric.database.change.* • Also need to colorImport java.awt • 88 annos total • Could be 2 if scoped promises could wildcard packages

7. Thread Coloring: Abbreviations • Want concise way to say(DBChanger | DBExaminer) • Use @colorRenames, e.g.@colorRenames DBExCh for (DBChanger | DBExaminer); • Place this in package-info.java • It gets imported along with the color definitions

8. Thread Coloring: Coloring Code • Write a @colorConstraint anno for each @vis method, e.g.@promise “colorConstraint DBChanger;” for kill*(**) | modify*(**)| erase*(**) | write*(**) • One of these for each @promise to do the @vis -- 264 total.

9. Annotation burden so far • Modules • Names • Best case: 4, Worst case 44 • Visibility • Best case: 0, Worst case 264 • Thread Coloring • Color names, abbreviations, & imports • Best case: 6, Worst case 92 • colorConstraints on methods • Currently 264 • Grand Total so far (for ~120K SLOC) • Best case: 274 (2.3/KSLOC) • Worst Case: 664 (~5.5/KSLOC)

10. Adding Data Coloring • Just like thread coloring, except… • Need effects analysis to find which regions are touched • (More on this later) • Need annos to identify regions of interest • For Electric: • Declare two regions (DB and UI) • Map all instance regions of “DB”-ish classes into DB • Map all instance regions of “UI”-ish classes into UI • Requires 1 annotation per class (~440)

11. Data Coloring (2) • First try • Mark region DB as being of interest to Data Coloring@colorizedRegion DB • Discover that I must annotate effects for every method in the world • This is too much work

12. Data Coloring (3) • Implement module-at-a-time inference of Effects • Now need only annotate effects for @vis methods • That’s still a lot! • Now attempting to annotate in terms of DB and UI, rather than individual regions • Seems more feasible • Effort is similar to Thread Coloring • Another 264 annos (or so)? • Results not yet complete