Adaptive OS Design Using Reflection: Apertos System

Adaptive operating system design using reflection
Rodger Lea
Yasuhiko Yokote
Jun-ichiro Itoh
Sony Computer Science Lab.
Sony Corp.
Tokyo, Japan
[email protected]
Sony Computer Science Lab.
Sony Corp.
Tokyo, Japan
[email protected]
Dept. of Computer Science.
Keio University
Tokyo, Japan
[email protected]
Abstract
encapsulates components and makes them easier to
change or evolve. Micro-kernel architectures have popularised such modularity and have demonstrated benefits in their overall flexibility[2][1]. Object oriented
operating systems have extended this modularity with
a finer degree of granularity and used techniques such
as abstract interfaces and inheritance hierarchies t o
support a high degree of flexibility[lO]. Systems such
as Choices[5] have exploited this software engineering
model to support an extremely sophisticated mix and
match approach to the initial build phase, in some
cases exploiting it to specialise systems not only for
hardware but for the intended application.
Flexibility t o a d a p t t o different applications is a k e y
requirement of m o d e r n operating s y s t e m s . W e h a v e
explored t h e u s e of m e t a - o b j e c t s a n d reflection a s a
m e a n s t o w r i t e adaptable s y s t e m s o f t w a r e . This p a p e r discusses t h e A p e r t o s operating s y s t e m t h a t u s e s
these techniques. It outlines h o w m e t a - o b j e c t s help t o
support flexibility a n d h o w w e h a v e i m p l e m e n t e d t h e
concepts, a n d g i v e s s o m e p e r f o r m a n c e figures.
1
Flexibility in operating systems
Recent trends in networking, multi-media and mobile computing have placed new requirements on the
flexibility and adaptability of existing operating systems. It is increasingly recognised that existing OS
architectures are not sufficiently flexible to meet these
demands. As such there is significant interest in building more flexible, or adaptive operating systems. It is
our belief that this trend represents one of the most
important hot topics in the OS research community.
We can categorise flexibility in work t o date as follows: flexibility in the way we combine the components of the system a t build time, flexibility in the
way the systems adapts to application needs and flexibility in the way the system and its interfaces evolve
over time.
There has been much work in the OS community
that aims to support these flexibility requirements.
However we argue that much of this work lacks a consistent framework, ie. the mechanisms adopted have
been applied to selected areas, and different mechanisms have been used in different parts of the system. The Apertos system is an operating system design that uses the language community ideas of metaobject programming and reflection to support an open
OS architecture in which all aspects of the system are
flexible. This paper briefly outlines recent work on extending system flexibility and then discusses the Apertos system and its use of a meta-object protocol.
2
Flexibility through run-time adaptation:
Most operating systems have supported some degree
of run time adaptation; for example scheduling policies are often adapted to deal with changing application loads. Recently there has been much interest in
the use of more sophisticated techniques to not only
choose between existing policy modules, but also to
dynamically generate code that is optimised t o a set
of run-time constraints [12] [3].
Flexibility of interface evolution: Flexibility to
support the evolution of system interfaces is more difficult t o achieve. Some of the work on object oriented
systems has attempted to exploit type conformance 141
or similar means [6] to achieve it.
It is clear that the operating system community is
aware of and is actively addressing the issues of flexibility. We argue however, that although this work is
moving in the right direction, it is ad hoc in that is
opens up pieces of a system without an overall architectural model for making that flexibility intrinsic and
so available t o all OS components.
3
The Apertos system (formally Muse)[13][14] has
been investigating a flexible open OS architecture
since 1988 and has concentrated its efforts on the
meta-level programming model.
Simply put, a meta-level architecture is one in
which all system components have a meta-level component that holds information about that component
and how it is used; in essence the meta-level defines
Current work
Rather than identify all ongoing work on flexibility
in the OS community we have chosen work that is representative of the three categories mentioned above.
Flexibility though modularity: Modularity is
a key technique in building flexible software since it
95
0-8186-7081-9/95
$04.000 1995 IEEE
Reflective OS architecture based on
meta-object s
referred to as a meta-space which is also represented
by an object (which we call a reflector). The metaspace constitutes the execution environnient for an
object. At any point in time there will be niany metaspaces co-existing in the system.
control and policy. This meta-level component can
be viewed as an environment for the component and
provides an interface to manipulate aspects of the
component’s environment. This is traditionally called
the meta-interface or meta-object protocol (MOP)[9].
However it could equally be called its management interface.
For example, a thread in an object oriented operating system is represented by a simple object that has
a ’standard’ interface such as start and yield. In addition, somewhere in the kernel is the scheduling code
which decides which thread to execute next. This algorithm is often refered to as the policy associated
with the simple object. In our terms this algorithm is
part of its meta-object. In a traditional OS the implementation of the policy and its application to the
thread was a closed a-priori decision made by the OS
designers. In a more flexible system we would like t o
be able to open up that algorithm, make it accessible
to other parts of the system and perhaps even change
it. By providing an interface to the scheduler metaobject, a MOP, we are able to expose that algorithm
and allow system designers and even applications t o
use it.
Reflection can be viewed as a use of this basic foundation. Reflection is the process in which we step back
from computation that is on behalf of, or part of the
application and carry out computation on behalf of
the system itself. To achieve this it is necessary to be
able to access a description of the system. When we
have finished this computation we will have changed
the description of the system. These changes are then
’reflected’ back to the actual system. Hence reflection gives us a way to cleanly make changes to the
system. Using the example above, when we use the
MOP interface to make a scheduling decision, e.g. reorder the scheduler queue, we are making a reflective
computation at the meta-level.
It is clear that this ability to access and manipulate
the basic features of an OS is useful; some of the work
cited above is using a variety of different techniques
to do just that. What is different about the Apertos
system is that the entire operating system is built using this meta-object architecture and so all aspects of
the system are open and can be easily changed. It
is our belief that only by doing this in a completely
consistent manner will we be able to fully realise the
benefits of the flexibility it provides.
In the following section we sketch out some of the
actual features of the Apertos meta-object architecture and give several examples to support our claim
to consistent flexibility.
4
Reflectors are ‘real‘ objects and have classs
which are arranged in a class hierarchy (shown
left). Each instance,e.g. reflector 1 has
a class within this hierarchy
mta-space for
muspace
Figure 1: The object/meta-object relationship and the
reflector hierarchy
Interaction between objects is achieved through
MetaCore, a minimal system component that allows
an object t o call into its meta-space. MetaCore can
be likened t o a micro kernel, however rather than implementing a simple set of base abstractions, it implements only the means t o move from a simple object
into its meta-space.
An object that wishes to access another object does
so by calling into its meta-space; the target object is
located and the invocation dispatched. In the cases
where an object wishes to compute not at the base
level, but at the meta-level, the same invocation model
is used. However the target for the invocation is a
meta-object and not a base object. This common invocation path implies that all aspects of the invocation
are also open t o change including look-up, dispatch
and invocation semantics.
The last extension that Apertos supports is a means
of allowing objects to change their behaviour not by
using the MOP to modify some feature of their existing environment, but by migrating themselves t o a
completely new environment which supports a different set of policies. Apertos supports a simple form of
type conformance to allow this.
As an example of these mechanisms we look at three
cases of management of a simple thread abstraction.
In the first case we show the simple use of the MOP
for a thread object which has an associated priority
used by a priority based scheduling algorithm. The
commands to start a thread running, and to explicitly
The Apertos operating system
As mentioned above, Apertos is an investigation
into how we can apply this meta-object model t o all
aspects of the operating system and what are the costs
and drawbacks. The Apertos system generalises some
of the ideas mentioned above.
Each simple object in Apertos is managed by a set
of meta-objects. The meta-objects are associated with
the simple object via a descriptor object that holds a
reference to all the required meta-objects. This set is
96
yield control are standard thread interface methods.
However, the command t o change the priority of a
thread is one that is called not by the thread itself,
but usually by the environment managing the thread.
This operation is part of the thread MOP and implemented via a separate object in the meta-space for
this thread. While this example is simple it serves to
illustrate the difference between base operations and
meta operations. Further it also shows the separation
of concerns between the interface that the programmer must use and the interface that the environment
uses. It is possible t o take this basic thread object
and reuse it in a different environment without any
modification to the application code. All changes are
made t o the environment or meta-objects.
A more sophisticated use of the meta-object model
is to evolve the MOP to implement extra functionality.
Consider for example the case where we wish to define
a new scheduler object that supports not only the priority based scheme discussed above, but uses priority
inheritance. The thread MOP is implemented through
a set of meta-objects which are collectively described
by a reflector object. The reflector objects are organised into a class hierarchy. To add priority inheritance
to the MOP we derive a new reflector class object and
add a method that re-orders the waiting thread based
on an inherited value.
Our last example illustrates the use of migration between meta-spaces. Consider the case where we wish
to move our existing thread object into a schedulin
regime that supports a simple quality of service (QofSf
guarantee. Rather than using a pre-emptive scheme,
the Qofs scheduler uses fixed slots based on event arrival or pre-computation. Apertos makes this possible
by allowing the thread to migrate from one meta-space
to another. In the new meta-space the meta-objects
that support the execution of this thread object will
include a meta-object implementing this new scheduler policy. The thread would continue to use its
original interface, i.e. call yield when it has finished
computation and would see no difference in its execution environment. However, the scheduler code implemented on yield is far different from the previous
environment.
It is important to note that this model is consistent
throughout the entire Apertos architecture and all objects have meta-objects. Thus every aspect of the system, apart from the basic operation t o move from a
simple object into its meta-space, is open and flexible.
Not only does this approach help us solve the traditional issue of thread scheduling, but it is used in the
virtual memory system t o allow us to support multiple
page replacement policies, each tailored to the application they support and each dynamically changeable
a t run time. This method is also used in the communications system where we use these techniques to allow
us to support standard send-receive, send-receive with
user supplied continuations and send-receive with implicit continuations.
5
object/meta-object model, and discussed how the
Apertos system conforms to this conceptual framework. In this section we discuss in more detail how
the actual implementation of these concepts is carried
out. We begin with the key meta-spaces in the system,
then describe the actual implementation of an object
and finally detail how objects are created and interact
using the Apertos OS facilities.
In Figure 2 the abstract meta-architecture shown
in fig.1 is visible as the seperate meta-spaces mCOOP,
mzero and "re.
n
w
ii-\
mcore
MetaCore
'rovldesthe baslc
undmnalty Io
j u w d the meta
:omputing model
911obpts accw
hlsfundmnality
provides basic system sewices
eg. virtual memory, activity etc
provides support for the computational
model, eg. object send and reply, object
migrate etc.
,
Specialisations of the basic
meta-space 10 suppol device
drivers,system objects or
\ application environments
base level, or 'simple' objects
Figure 2: Implementation hierarchy of meta-spaces
5.1
MetaCore
MetaCore acts in a manner similiar to that of
a micro-kernel in more traditional systems. However, rather than providing a minimal set of resource
abstractions, its role is restricted to supporting the
object/meta-object model, the base notion of activity
and interrupt dispatching. This allows a very small
core object (currently around 3K) which aids both
understanding and porting. MetaCore supports the
following operations:
Implementation and performance
In the previous sections we outlined the conceptual framework that Apertos supports, i.e. the
97
0
M(meta): Make a request for meta-computing.
This causes the execution of an object to be suspended and control to pass from the object to its
meta-ob j ect .
0
R(reflect): Resume object execution, i.e. pass
control from the meta-object back to a base object.
0
CBind: Specify a recipient for an interrupt.
0
CUnbind: Break the association between a recipient and an interrupt.
MetaCore is shown in figure 2 as the vertical box
running alongside the meta hierarchy. Since MetaCore supports the basic facilities for meta-computing,
i.e. the reify(M) and deify(R) operations, it is accessible and used by all meta-spaces. In table 1 we give
performance figures for these basic operations'. Note
that operations without trap occur when we do not
cross a protection boundry.
The exec meta-object
places the a~tivv
associated with Obi2
at the head of the run
queue and returns to
Zero
MetaCore
Table 1: Execution cost of MetaCore primitives (in
F C )
primitive
M (w/ o trap)
R(w/ o trap)
CBind
CUnbind
5.2
Metacore uses the Context
sttucture to actually support
theexecution of the activny
4.1
3.5
Figure 3: Activity and the execution path
are written in the same way as any other concurrent
object application, i.e. we are able to hide the restrictions normally visible to device driver programmers.
d r i v e supports device drivers that have direct physical access t o hardware and msystem supports device
drivers t h a t have no acces to hardware.
Interupt handling requires that an interrupt is
bound t o a particular receiving object. The CBind
operation in MetaCore does this. It sets up a dispatch entry in MetaCore which is used when the interrupt occours. Interrupts are initially directed to
MetaCore which uses the dispatch table t o decide
on the receiving object. A standard R operation then
passes control, as if it was a normal method invocation, to the context asociated with the object bound
t o this interrupt. Thus, once an interrupt has been
dispatched by MetaCore its execution path does not
differ from the normal message invocation and return
path.
Table 2 gives some brief details of execution costs
for interrupt handling and using concurrent objects in
the driver meta-spaces. Details can be found in [7].
Activity in Apertos
The underlying CPU is abstracted in a structure
known as a context. Contexts2 are created by the
meta-object exec which resides in mcore. Contexts
are actually abstracted by a notion of Activity which
is the unit of manipulation a t the meta-level (see fig.3).
T h e context structure is seen by MetaCore as it uses
this to set up the hardware to support the actual execution of an activity. The context structure contains
the pointer to the meta-space for that context. This
enables MetaCore t o move from the currently executing context to its meta-space when the M operation is
called.
mBaSe is the first level meta-space for a base level
object, it implements the scheduling policy.
,Zero is one of the terminal meta-spaces for all
other nieta-spaces and is thus accessed by all other
meta-spaces. This allows some operations, eg. context
location. to be optimised.
,Core is the reflector for mzero and contains
meta-objects to handle activity, physical memory and
virtual memory. Although, as mentioned above,
mZerO is the shared reflectors for all others, it too
needs a reflector, hence the use of mcore. To halt to
potentially infinite hierarchy of meta-spaces we make
the meta-space for mCole be mzero. Although this
introduces a circular dependency between the two it
allows us to 'bottom out' when moving down through
the meta hierarchy.
m D r i v e and m s y s t e m are meta-spaces for device
driver programming (see fig.2). They implement a
concurrent object environment where device drivers
5.3
Activity Aows in the system
Below we discuss the creation of a new application
object; invocation of an application object; and interrupt handling.
5.3.1
Object creation
An object in the Apertos system consists of a set
of memory segments and two meta-data structures;
Activity and Descriptor. The memory segments are
typed as data, code and stack.
T h e Descriptor is created and managed by t h e reflector for the object, thus the format of each descriptor is dependant on the reflector. However, certain
'All performance figures from a 486DX2-66MHz, 16MByte
PCAT compatible.
'Contexts in Apertos should not be confused which the general OS concept of a context a.~an address space. They are
simply the state of the machine registers
31n t h e MIPS implementation all interrupts are dispatched
through a single vector.
98
Apertos
25.0
44.2
108.6
207.8
metaoperation
Interrupt message delivery
Null interrupt handler execution
Send metacall overhead on d r i v e
Call-Reply roundtrip on d r i v e
11.5
16.2
-
calling context for the execution of the recipient. Table 3 shows the benefit of this technique within the
framework of the driver meta-space.
In table 4 we show the macroscopic result of these
performance optimisations for the implementation of
an IP protocol. The protocol consists of 5 seperate
concurrent objects that, reside within mSYstem, i.e.
they all have the same meta-space.
items are common, including the memory segment information, a pointer to the context for this object, a
pointer t o its class and some information regarding its
scheduling status.
Object creation begins by a call from an application
object into its meta-space asking for the creation of an
instance of a particular class of object. The first stage
in creating an object is to access the class t o determine the object structure. The object is then named
by requesting a name from the namer meta-object.
Memory space is allocated by sending a request message to the VM meta-object that manages memory for
this meta-space. The reflector then creates a context
structure for the object so that it can be scheduled.
Finally an activity is created by the meta-object exec.
5.3.2
BSD/986
6
Current and future work
We are currently working on the use of Apertos in
a distributed multi-media environment. In our initial
set u p we have ported Apertos to a number of Sony
News 5000 workstations with MIPS R4000 processors
and a video server using the R3000 processor. These
machines are interconnected with a small experimental ATM network. We are experimenting with Apertos
in two areas; the first uses the meta-object model t o
support QofS constraints and exploits our flexible architecture t o adapt the resource scheduling policies to
varying simulated system loads and failures. The second area of work uses Apertos in a proprietary graphics engine attached to the above network where we are
experimenting with protocols for distributed shared
virtual environments. In particular we are looking at
the issues of distributed consistency where we are exploring the use of migration between meta-spaces to
dynamically change the consistency associated with
shared objects.
Efficiency is always a concern. We have chooseii
t o explore the meta-object model t o its fullest and we
have paid a price for this. We argue however, that
it is necessary to get the model right first, then exploit the model t o optimise. Some initial performance
improvement is shown in tables 3 and 4. We are interested in exploring the use of dynamic code generation
as in [12, 31 to improve further our performance.
One of the advantages of a clean base/meta seperation is that for the majority of application programmers the meta-level is hidden. However, those that
wish to exploit flexibility must code at the meta-level.
We have instigated some work to use compile time
tools t o abstract the details of the system [ll],but
are concerned that system users will need sophisticated tools to allow them to easily exploit the power
of the meta-level model. We hope to report further
as we begin t o use Apertos within a number of Sony
internal development projects.
Object interaction
A particular meta-space for an object will provide
the base implementation of send and reply. When
an object makes a send request, control is transferred
from the sending objects’ context to its meta-space
(mBase). mBase locates the receiving object’s context by calling up into its meta-space (again through
M) to mzero. Since mZerO is shared, the location
of the context, if on this machine4, is found and the
meta-space can call into the recipient object.
Referring back to fig.3, when object O b j l attempts
to call Obj2, it actually makes an M call into mBase,
i.e. it uses the M operation to switch t o the context ofmBase. mBase then calls into mzero as the
send/receive functionality exists there. Here, the context associated with Obj2 is located. Using the e x e c
meta-object, which manages the queue of activities,
we place the activity associated with Obj2 a t the head
of the queue. mzero then exits, which is translated
into an R operation, causing the scheduler to find Obj2
on the run queue and schedule it.
5.4 Optimisation
It is clear that in a pure implementation of our system, the continual rescheduling of objects as we move
up and down the object hierachy is expensive. To
alleviate this cost we implement a dynamic context
hand-off mechanism [8] that allows us to reuse the
4 F ~ remote
r
objects the namer meta-object is used to locate
the host for the object. The message is then sent t o the d e r 0
running on that host.
99
metaoperation
Send metacall overhead on msystem
Call-Reply roundtrip on ,System
Call-Reply roun dt rip on msys t em(cont ext h and-off )
Apertos
88.2
772.8
7.8
Table 4: Costs of network protocol handlers on mSYstem (in psec)
metaoperation
ICMP echo-echoreply roundtrip
ICMP echo-echoreply roundtrip(optimized)
References
Apertos
3466.0
362.3
[8] Jun ichiro Itoh, Yasuhiko Yokote, and Mario Tokoro.
Using Metaobjects to support optimization in Apertos Operating System. Technical Report SCSLTM-95-006, Sony Computer Science Laboratory Inc.,
1995.
[l]Tevanian Avadis Jr. and Richard F. Rashid. MACH:
A Basis for Future UNIX Development. Technical
report, Department of Computer Science, Carnegie
Mellon University, June 1987.
[9] Gregor Kiczales, Jim des Rivikres, and Daniel G. Bobrow. T h e A r t of t h e Metaobject Protocol. The MIT
Press, 1991.
[2] Nariman Batlivala, Gleeson Barry, Hamrick Jim,
Lurndal Scott, Price Darren, Soddy James, and
Abrossimov Vadim. Experience with SVR4 over
CHORUS. In Micro-kernel and other kernel architectures, pp. 223-241. USENIX, April 1992.
[lo] Rodger Lea, Christian Jacquemot, and Eric Pillevesse. COOL: System support for distributed programming. Communacataons of the A C M , Vol. 36,
No. 9,, September 1993.
[3] Brian Bershad. SPIN - an extensible micro-kernel for
application specific operating system services. In Proceedings of t h e 6th A C M - S I G O P S European W o r t shop: Matching Operating S y s t e m s t o Application
Needs, September 1994.
[ll] Kenichi Murata, Nigel Horspool,
and Yasuhiko
Yokote. Design and specification of cognac. Technical Report SCSL-TM-94-006, Sony Computer Science
Laboratory Inc., 1994.
[4] C Bryce, V Issarny, G Muller, and I Puaut. Towards
[12] Carlton Pu and Jon Walpole. A study of dynamic optimisation techniques: Lessons and directions in kernel design. Technical Report CS/E 93-007, Oregon
Graduate Institute (OGI), April 1993. Technical Report CS/E 93-007.
safe and efficient customization in distributed systems. In Proceedings of t h e 6th A C M - S I G O P S European Workshop: Matching Operating S y s t e m s t o A p plication Needs, September 1994.
[5] Roy H. Campbell, Nayeem Islam, Ralph Johnson,
Panos Kougiouris, and Peter Madany.
Choices,
Frameworks and Refinement. In Proceedings of the
i99i International Workshop o n Object Orientation
in Operating Systems, pp. 9-15. IEEE Computer S e
ciety Press, October 1991.
[13] Yasuhiko Yokote. The Apertos Reflective Operating System: The Concept and Its Implementation.
In Proceedzngs of Object- Oraented Programmang Syst e m s , Languages and Applacations an 1992. ACM
Press, October 1992. Also appeared in SCSL-TR-92014 of Sony Computer Science Laboratory Inc.
[6] Graham Hamilton and Panos Kougiouris. The Spring
nucleus: A microkernel for objects. In U S E N I X 1993
S u m m e r Technical Conference Proceedings. USENIX
Association, June 1993.
[14] Yasuhiko Yokote, Gregor Kiczales, and John Lamping. Separation of Concerns and Operating Systems
for Highly Heterogeneous Distributed Computing. In
Proceedzngs of the 6 t h A C M - S I G O P S European W o r k shop: Matchang Operatang S y s t e m s t o Applacataon
Needs, September 1994.
[7] Jun ichiro Itoh, Yasuhiko Yokote, and Mario Tokoro.
SCONE: A New Execution Model for Low-Level
System Programming based on Concurrent Objects.
Technical Report SCSL-TM-95-005, Sony Computer
Science Laboratory Inc., 1995. submitted to OOPSLA95.
I
100