1 / 43

The Alchemy Project

The Alchemy Project. Jay Lepreau Matthew Flatt Eric Eide Alastair Reid John Regehr University of Utah Contract F33615-00-C-1696 April 4, 2002. Problem Description. Embedded RT software development too difficult, prone to error, expensive

vincent
Download Presentation

The Alchemy Project

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. 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. 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. 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. 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. 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. “Task Isolation” in Java • For real-time in particular • For QoS in general • For robustness • JSR-121… more later • JSR-xxx: resource management

  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. ComposableExecution Environments • Different subsystems want different architectures • Traditional embedded software • Threads and semaphores • Click, TinyOS • Non-preemptible events • Audio, video, other signal processing • Dataflow

  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. Why Compose? • Matching code to the right model gives powerful software engineering benefits • Easier to: • Understand • Debug • Analyze • Extend • Maintain

  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. 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. B D E A C non-preemptive 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

  15. B D A C E 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 non-preemptive preemptive

  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. 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. 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. 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. 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. 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. 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. 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. 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 Contributions to Military Apps } } }

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

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

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

  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. 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. 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. Collaborations • OVM team (Purdue, UMD, SUNY) • BBN: • CPU Broker for UAV • Alchemy-configured feature selection in OVM • Deliver RT-JVM components (w/ Purdue)

  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. Program Issues • none

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

  36. Artist’s Conception

  37. 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

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

  39. 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

  40. 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

  41. 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

  42. 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

More Related