1. 1 The Alchemy Project Jay Lepreau Matthew Flatt Eric Eide Alastair Reid John Regehr University of Utah Contract F33615-00-C-1696 April 4, 2002

2. 2 Problem Description  Embedded RT software development too difficult, prone to error, expensive  System-level programming using components is especially hard  Embedded sys, VM, middleware, OS  Non-local constraints  Need build-time assurance  Existing code  Performance  Static component architecture versus dynamic execution behavior

3. 3 Project Objectives & Technical Approach  Robust, flexible component composition  A mostly static architecture  Design rules checked at system build time  Aspects implemented using components  “Weaving” by composition  … provides:  “Product line” flexibility, increased reuse  AOP  Architectural clarity

4. 4 Objectives & Approach (2)  Policy-driven, reservation-based scheduling in UAV  Formalizing execution environments to provide restricted execution models to get software engineering benefits in middleware and embedded systems; could be applied in UAV  Schedulability-driven priority scheduling with mixed preemption and non-preemption  Application support for monitoring and debugging scheduling behavior -- not directly applicable but is a good part of our toolkit

5. 5 Jiazzi: Components for Java  Support for component programming on a large scale  Jiazzi components…  import and export signatures  are parameterized by imports.  are defined and composed using an external language.  Flexible class extensions (mixins)  Groups of related mixin functionality (aspects)  Transition to Purdue OVM

6. 6 Maya: Compile-time Metaprogramming for Java  “Macros on crack” [PLDI 2002]  Maya “macros” are methods on generic functions in the parser  Handi-Wrap runtime aspect weaving [AOSD 2002]  Jason Baker to Purdue PhD program

7. 7 “Task Isolation” in Java  For real-time in particular  For QoS in general  For robustness  JSR-121… more later  JSR-xxx: resource management

8. 8 UAV Resource Reservations  Expose resource kernel CPU isolation to ACE, TAO, QuO, UAV  Based on TimeSys Linux/RT  CPU Broker: policy-directed reservation scheduling [WMMM ’01]  Policies based on:  Static: critical vs. non-critical flows  Dynamic: feedback mechanism for reservation assignments

9. 9 Composable Execution Environments  Different subsystems want different architectures  Traditional embedded software  Threads and semaphores  Click, TinyOS  Non-preemptible events  Audio, video, other signal processing  Dataflow

10. 10 Definitions  Execution Model – collection of rules for:  Structuring code  Sequencing events  Mediating access to resources  Controlling namespaces  Analysis and reasoning  Execution Environment – instantiation of a model

11. 11 Why Compose?  Matching code to the right model gives powerful software engineering benefits  Easier to:  Understand  Debug  Analyze  Extend  Maintain

12. 12 Why Compose? #2  To support diverse trust relationships – e.g.  A and B mutually trusting  A trusts B, but B doesn’t trust A  A and B mutually untrusting  Lack of trust motivates isolation  Time – CPU reservation  Space, crashing – process model (type-safety or MMU)  Data – dependency analysis

13. 13 Why Compose? #3  We want to reuse code that assumes a particular environment  Porting code to new environment:  Time consuming, error prone  May lose benefits of original model  Rather, we support multiple concurrent environments and late binding

14. 14 Example  Non-preemptive environment is not schedulable  E runs too long  Solution 1: Preemptive scheduler  Problem: Makes life harder for everyone – races, deadlocks, fine- grained locking A D C B E non-preemptive

15. 15 Example Cont’d  Solution 2: Move E to a different environment  Benefits: less locking; more efficient system; developers unconcerned with E need not be aware of preemption E A D C B non-preemptive preemptive

16. 16 Principle 1: Restricted Environments  Components do not encapsulate control flows  Written in call/return style  Real-time properties and requirements explicitly declared  Explicit access to shared resources  Rationale: threads, implicit timing requirements, implicit sharing all compose poorly

17. 17 Principle 2: Hierarchical Composition  Permits:  Modular design  Coexisting diverse environments  “Confinement” of resources  Rationale:  Environments closely match needs of components  Environments seem to want to be nested

18. 18 Principle 3: Late Binding  Wait for entire system to be available for analysis before binding:  Components to threads  Threads to schedulers  Critical sections to lock implementations  Rationale:  Maximize component flexibility  Create efficient systems

19. 19 Composable Execution Environments: Summary  Mismatch between code and execution model can be a major problem for embedded systems  Makes it hard to understand, analyze, debug, reuse  Prevent mismatch with  Late binding  Hierarchical composition

20. 20 Other Tools: SPAK  SPAK: static priority analysis and thread mapping  Support task model with mixed preemption and non-preemption  Uses preemption threshold analysis to show when tasks can be run non- preemptively without affecting schedulability  Chooses schedules to maximize robustness in face of timing overruns

21. 21 Other Tools: Hourglass  Synthetic, instrumented real-time app.  Requires no kernel modifications  Measures:  Direct and indirect costs of context switches  Dispatch latency  Quality of timers  Interference from kernel activity (e.g., receive processing)  Deadline hits/misses  Supports:  Priorities and CPU reservations (TimeSys)  Linux, FreeBSD, Windows 2000

22. 22 Metrics  UAV & Linux/RK & CPU Broker:  “Perfect” timing resilience: much quicker response to timing faults in other apps  100% CPU utilization w/o important streams missing any deadlines  Reduced module coupling within and between OVM subsystems with zero performance penalty  OVM product family: footprint  More specific numbers soon

23. 23 Contribution to PCES Goals  Unified model for components and aspects  Functional and non-functional aspects  Design rule checking (constraints)  Support product families & evolution in Java  Java: aspects via components and language  Task/process isolation: robust architectures  Isolates in future COTS JVMs via JSR-121  RK-based CPU Broker for UAV  Future Java-based RT policies via OVM  Usable today: Jiazzi, Maya, Hourglass: open source

24. 24 Contributions to Military Apps Family of JVMs: the OVM product line  Composable RT schedulers  Task isolation  Resource controls  VM services, footprint  Object representation  Design / configure time assurances  Component reuse  Principled use of COTS software  Predictable, resilient run-time behavior  Fit constrained execution envs.  Cheaper, faster, better development } } }

25. 25 Military Apps (cont’d)  CPU reservations for UAV OEP, other ACE/TAO-based applications  Benefits:  Increased predictability  Isolation of timing faults  for C++ soon, Java later  Challenges:  Param calibration for multithreaded apps  Adjustable safety margin

26. 26 Project Tasks/Schedule Knit release Alchemy-configured feature selection in OVM Initial OVM as Alchemy components Alchemy-configured data layout in OVM OVM mobile processes as Alchemy components Jiazzi + constraint checker Alchemy-configured memory management in OVM Jiazzi + weaver release Jiazzi release 2001 Resource management in OVM w/Alchemy checking Blue: tools Black: tool use Maya release CPU resv in UAV

27. 27 Technical Progress & Accomplishments  Jiazzi: components for Java  New release (Jan ’02)  Ongoing collaboration with Purdue

28. 28 Accomplishments (cont’d)  Maya: Metaprogramming for Java  Updated release  Maya paper at PLDI ’02 (Jun)  Handi-Wrap paper at AOSD ’02 (Apr)

29. 29 Accomplishments (cont’d)  Composable EEs  Initial ADL designed  Assimilated TinyOS components  EE for TinyOS (non-premptive events) and Click routers (dataflow)  Acquired motes for experimental platform  Analysis and compiler in progress

30. 30 Accomplishments (cont’d)  CPU Broker for UAV  Initial prototyping with free Linux/RK  Finally acquired TimeSys Linux/RT!  ACE Wrapper Facades for RK resource APIs, integrated with ACE Thread Manager  Initial experiments toward deploying RK-enhanced UAV on the Utah Network Testbed (Emulab)

31. 31 Next Milestones  CPU reservations in UAV OEP (2Q02)  Jiazzi  Construct OVM from Jiazzi components (2Q02)  RT-Java components (4Q02)  Java “Task” isolation  JSR-121 release (2Q02)  CEE  Initial development (2Q02)  Determine application to OEPs (2Q02)

32. 32 Collaborations  OVM team (Purdue, UMD, SUNY)  BBN:  CPU Broker for UAV  Alchemy-configured feature selection in OVM  Deliver RT-JVM components (w/ Purdue)

33. 33 Technology Transition/Transfer  Software releases & users described earlier: OVM, BBN OEP, Boeing OEP?  Sun JSR-121: “pseudo-task” isolation  Highly relevant to real-time & robustness  Potential alternate base for RT-Java  A natural resource boundary  OS abstractions, GC mechanisms  Long line of OS/lang. research at Utah  Utah has leading role in Expert Group  Will be in JDK 1.5 (3Q02)  Just first stage: control; next: sharing, resource management

34. 34 Program Issues  none

35. 35 Utah Alchemy Project DARPA PCES Program www.cs.utah.edu/flux/alchemy

36. 36

37. 37 Artist’s Conception

38. 38 Knit: Components for C  External component definition and linking language  Discussed at previous PI meetings  Released Feb’01, open source  Gaining experience and refining it  Version 2 in progress

39. 39 Maya and AspectJ Maya: compile-time metaprogramming AspectJ: language support for cross-cutting concerns JSE

40. 40 How to Do It  Binding components to threads:  Constraint: must be schedulable  Constraint: use as few threads as possible (zero, ideally)  Static priority analysis will cover most cases  Binding threads to schedulers:  Only a few reasons for genuine scheduler diversity: temporal isolation or conflicting scheduling requirements

41. 41 How to Do It #2  Binding critical sections to synchronization primitives:  Analysis based on properties of environments that can access a particular resource; e.g.  No lock for resource shared by non- preemptible events  Blocking lock for resource shared by threads  Raise IRQL for resource shared by threads and interrupts

42. 42 Metrics  SW Engineering metrics  Reduced module “coupling” in Jiazzi’ed systems  Constraints: fewer incorrect systems composed by students, in a controlled study  Mining: quicker to componentize, in a controlled study

43. 43 Military Apps (cont’d)  Jiazzi’ed event service in Boeing OEP Java-based ORB (w/ Wash U)  Aspect weaving in UAV Java code  At compile time using Maya  At runtime using Handi-Wrap