Compositional Development of Performance Models

Jim Browne

Department of Computer Science

University of Texas

Austin, Texas 78712

browne@cs.utexas.edu

http://www.cs.utexas .edu/users/browne

Abstract

Performance models are software systems where the components implement abstractions of the behavior of a total system.. Compositional development of simulation models is a domain specific instance of the general problem of software component reuse or design reuse. Performance models span software, middleware and hardware semantic domains and multiple levels of abstraction. Evaluation of components requires multiple modes of execution. Execution may require translation across levels of abstraction and modes of evaluation. The conceptual innovations which enables compositional development are integration of associative interfaces with standard objects and use of hierarchical dynamic data flow graphs as an application structuring model. Associative interfaces extend the concept of interface from specification of services provided to include specification of the behaviors of component instances and specification of the services a component instance invokes. The associative model of communication from which associative object interfaces are derived is formally described in the dissertation of Bayerdoffer [BAY93] and an application to communication can be found in [BAY95].

1. Problem Specification - Performance Models as Software Systems

End-to-end performance models of computer systems are semantically complex software systems.

a) The models span three (or more) semantic domains:

(i) The application domain which is the driver for the execution of the system,

(ii) the operating system and the runtime systems used by the application and

(iii) hardware architecture.

Each has quite different semantics. Parallel semantics is required for the operating system and hardware domains.

b) Components are frequently defined at multiple levels of resolution in a system model. And a given component may be represented at different levels of resolution in different instantiations of a system model. This implies that component models must be able to translate input/output parameters across different representations of the state of the system in different contexts.

c) Multiple methods of evaluation (different simulators and/or a mixture of procedural and analytic evaluation methods) may be applied to components of a given system model.

d) Dynamic composition (runtime modification) of performance models is desired for adaptive control of total system behavior.

.

The result of these complexities is that end-to-end performance models of computer systems are software systems which are very challenging to develop.

But the individual components performance-oriented simulation models of computer systems have relatively simple and precise semantics which can readily be defined in terms of object models [SHL92, RUM91]. This factor enables definition of associative objects which in turns enables compositional development of programs representing simulation models.

2. Position

Existing technologies for component reuse do not address the requirements for compositional development of performance models of computer/communication systems. A more powerful model of interfaces is required. Specifically a specification language which has an executable semantics and supports compositional development is required.

3. Approach to Definition of Composable Models of Components.

The four conceptual elements of the process for developing composable components are:

a) Abstraction hierarchies which are a familiar method for decomposition of complex systems.

b) Standard object models

c) Associative interfaces which are used to encapsulate standard objects to create associative objects.

d) Hierarchical dynamic data flow graphs.

Abstraction hierarchies, object models and data flow graphs are all familiar concepts. Therefore we discuss only associative interfaces and their integration with object models.

3.1 Definitions

Component - A component is a logical or physical element  of a system. An example of a component is a cache in a model of the system level architecture of a processor/memory system.

Model - A model is a representation of a component which resolves or all of the behavior of the component. A  component may be represented by many different  models.

Transaction - A transaction is a unit of work to be executed. A transaction has an identify and a state which may persist across execution sites. It is instances of transactions which cross interfaces to generate interactions among model instances.

Interaction - A singular interaction is a flow of information across component interfaces. An interaction may be singular or compound. A compound interaction is a sequence of singular interactions governed by a protocol.

Interface - Interfaces are associated with components. An interface specifies the set of interactions in which a component can participate both as invoker and invokee. The nature of the interactions in which a component can participate is determined by an associative characterization of its behavior. A given instantiation of an interface will cause selection of a matching invokee component by the invoker component. 

3.2 Associative Interfaces

Associative interfaces encapsulate standard objects with an interface which specifies all of the interactions in which a component can participate and which specifies the behaviors it implements in terms of the attributes which define the behavior and the states of the standard objects. An associative interface has two elements: an "accepts" interface and a "requests" interface.

The "accepts" interface for a component is a set of three tuples (profile, transaction, protocol). One member of the set is associated with each instance of an object.

A profile is a set of attribute/value pairs.

A transaction specifies the functionality and the parameters of the units of work which are executed on a given interaction by this instance of the component.

A protocol defines the sequence of singular interactions necessary to complete the interaction specified by the profile.

The "request" interface is a set of three-tuples (selector, transaction, protocol). One member of the set is associated with each instance of an object.

A selector is a conditional expression over the attributes of the objects in its domain and the other domains with which it has interactions. (See the example in Figure 3.) The conditional expression of a selector is a template with slots for attribute name/value pairs specified in the profiles of other object instances. A selector is said to match a profile whenever the conditional expression of the selector evaluates to true when the attribute values from the profile are inserted into or compared with the slots in the template of the conditional expression. The parameters in a profile and selector which match should either conform or the match should include a mechanism (type coercion) which is invoked to translate the transaction in the request interface instance to the transaction in the matched accepts interface and visa versa. Associative interfaces, together with a runtime system which carry the information necessary to enable matching of component models and to invoke runtime system procedures to implement parameter translation and interaction sequencing to implement protocols required by the matchings between component models.

3. Status

A specification language for performance models based on associative objects has been defined. A prototype compiler which maps programs written in this specification language to the CODE [NEW92] parallel programming system has been written [Dube98].

The conceptual framework is being implemented in a common modeling framework for design of Intel-based servers.

There is a great volume of conceptually related work. Associative interfaces are generalization of typed ports which have a very long history. The many object brokers all have some type of mediation interface. Additionally the data mediation community uses similar concepts for data fusion.

This work was supported by DARPA/ITO under Contract N66001-97-C-8533, "End-to-End Performance Modeling of Large Heterogenous Adaptive Parallel/Distributed Computer/Communication Systems,"

[BAY93] B. Bayerdorffer, Associative Broadcast and the Communication

Semantics of Naming in Concurrent Systems, Ph.D. Dissertation, Dept. of

Computer Sciences, Univ. of Texas at Austin. Dec. 1993.

[BAY95] B. Bayerdorffer, "Distributed programming with associative broadcast",

Proceedings of the Twenty-eighth Hawaii International Conference on System

Sciences, January 1995.

[RUM91] J. Rumbaugh, et.al. Object-Oriented Modeling and Design"

(Prentice-Hall, Englewood Cliffs, NJ, 1991)

[SHL92] S. Shlaer and S. Mellor "Object Lifecycles: Modeling the World

in States" (Yourdon Press, New York, 1992)