The Alchemy Project
Jay Lepreau
Matthew Flatt
Eric Eide Alastair Reid John Regehr
University of Utah
Contract F33615-00-C-1696
April 4, 2002
1
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
2
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

3
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
4
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
5
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
6
“Task Isolation” in Java





For real-time in particular
For QoS in general
For robustness
JSR-121… more later
JSR-xxx: resource management
7
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

8
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
9
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
10
Why Compose?


Matching code to the right model
gives powerful software
engineering benefits
Easier to:
Understand
 Debug
 Analyze
 Extend
 Maintain

11
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

12
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
13
Example
B
A
C
D
non-preemptive

Non-preemptive environment is
not schedulable


E
E runs too long
Solution 1: Preemptive scheduler

Problem: Makes life harder for
everyone – races, deadlocks, finegrained locking
14
Example Cont’d
B
A
C
D
E
non-preemptive
preemptive

Solution 2: Move E to a different
environment

Benefits: less locking; more efficient
system; developers unconcerned with E
need not be aware of preemption
15
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
16
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

17
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

18
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

19
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 nonpreemptively without affecting
schedulability
 Chooses schedules to maximize
robustness in face of timing overruns

20
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
21
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
22
Contribution to PCES Goals

Unified model for components and aspects




Task/process isolation: robust architectures




Functional and non-functional aspects
 Design rule checking (constraints)
Support product families & evolution in Java
Java: aspects via components and language
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
23
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
24
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

25
Project Tasks/Schedule
OVM mobile processes
as Alchemy components
Resource management in OVM
w/Alchemy checking
Alchemy-configured memory
management in OVM
Jiazzi + weaver release
CPU resv in UAV
Maya release
Alchemy-configured
data layout in OVM
Alchemy-configured
feature selection in OVM
Jiazzi release
2001
Jiazzi + constraint checker
Initial OVM as Alchemy components
Knit release
Blue: tools
Black: tool use
26
Technical Progress &
Accomplishments
1.
Jiazzi: components for Java


New release (Jan ’02)
Ongoing collaboration with Purdue
27
Accomplishments (cont’d)
2.
Maya: Metaprogramming for Java



Updated release
Maya paper at PLDI ’02 (Jun)
Handi-Wrap paper at AOSD ’02 (Apr)
28
Accomplishments (cont’d)
3.
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
29
Accomplishments (cont’d)
4.
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)
30
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)

31
Collaborations


OVM team (Purdue, UMD, SUNY)
BBN:
CPU Broker for UAV
 Alchemy-configured feature selection in
OVM
 Deliver RT-JVM components (w/ Purdue)

32
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

33
Program Issues

none
34
Utah Alchemy Project
DARPA PCES Program
www.cs.utah.edu/flux/alchemy
35
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 and AspectJ
AspectJ:
language support
for cross-cutting
concerns
Maya:
compile-time
metaprogramming
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 nonpreemptible 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

43