The type of component connections and the behavior of component interactions are equally important to the overall performance of an application as the performance of individual components. This is true both to understand the frequency and granularity of component interactions, but also the degree and type of data exchange that occurs. Thus, we must have support to observe component connections and how they are used. Our approach to this problem is to integrate performance instrumentation in the process of interface definition and generation. This instrumentation will target measurement mechanisms built with TAU to capture performance information specific to interface type, operation, and invocation.
The main problem we need to address is how component interfaces are instrumented. We assume that the component interface is CCA-compliant and, therefore, follows the methodology of defining provides and uses ports. If the component interface is implemented directly in C++ (i.e., using the CCAFFEINE framework), we can use the mechanisms for component instrumentation discussed above, both manual and automatic. It is also reasonable to consider whether the CCA classic::gov::cca::Port class should be extended to facilitate instrumentation in this case.
However, if the component interface is specified in SIDL and generated with a SIDL compiler (i.e., Babel [7]), we have two choices to consider. One option is to wait until the interface code is generated and instrument it similar to how we use TAU to instrument the C++ component interface. The difficulty here is that Babel is able to generate interface code in the component's native language (e.g., C, C++, F77, F90/95). Thus, we must be able to apply TAU's cross-language instrumentation appropriately to the different native languages Babel supports. Knowing how the code that Babel generates is constructed will be important to producing efficient TAU instrumentation. We can also attempt to automatically generate the instrumentation at the time of SIDL compilation. This approach will possibly allow more efficient and optimized TAU instrumentation.
Our goal is to use the performance instrumentation to observe component interactions. These interactions occur through the services one component provides and others use. CCA defines the port abstraction as a means to specify what services a component will provide and use. We speak of component composition as the act of connecting components; effectively the binding of provides and uses ports. The instrumentation idea we will develop is to construct ``port wrappers'' (or, more appropriately, ``service wrappers'') to observe service ``entry'' and ``exit'' events. However, a question arises concerning whether the observation of component interactions is from the point of view of the service provider or the service user. Not only is this a question of where instrumentation gets placed, but it also relates to the meaning of the performance data measured at these points. If we consider component interface instrumentation in the service provider, we will be able to measure, for example, how often a service provided by this component is invoked, how long the service takes, and other information characterizing service type. Alternatively, if we put the instrumentation in the service user component, we will be able to determine, for instance, the execution profile across all services this component invokes, as measured in that component.
In programs with subroutine libraries, the contrast above reduces to the problem of observing ``callee'' / ``caller'' performance. However, with CCA components and frameworks, the situation is more complex, both from the instrumentation point of view and with respect to performance observation. Ideally, we want to observe performance from both provider and user points of view, and we intend to develop support for both. In addition, we will want to associate performance to specific component (port) bindings. The CCA framework interconnects components by binding compatible provides and uses ports, but the binding information is not available to the instrumentation in the component interfaces at the time the instrumentation is created. Thus, we must develop additional mechanisms to pass this knowledge to the interface instrumentation.