D Query protocol and monitoring support mechanism

Transcription

1 SBO-program CoDAMoS: Context-Driven Adaptation of Mobile Services D Query protocol and monitoring support mechanism Peter Rigole, Davy Preuveneers Yolande Berbers K.U.Leuven Celestijnenlaan 200A, B-3001, Leuven October 7, 2004

2 CONTENTS 1 Introduction 2 2 Query Protocol State of the art Context Discovery Monitoring Support State of the art Contracting and monitoring framework Resource Contracts A Resource-Aware Slideshow System support First Results Bandwidth monitoring Memory monitoring Monitor implementation Monitoring Overhead Conclusion 20 1

3 1 Introduction With the advent of modern mobile computing, a new paradigm called ambient intelligence (AmI) arose that introduces computing capabilities far beyond what is nowadays the standard: proactive user support, context-sensitive behavior, intelligent ubiquitous computing that minimizes user distraction, etc.. Acquiring the knowledge that feeds the intelligent behavior of ubiquitous mobile services is the first goal of CoDAMoS task 4.3. This knowledge, represented as context information, is either discovered by actively searching it, passively being notified of changes in context or actively monitoring it. It are the services themselves that need to specify which context information they need, which may be dependent of other context information (e.g. user preferences or the available services). The need for gathering context information is not only expressed by services but also by middleware, the underlying infrastructure that supports the services. The middleware may need to take important decisions (such as hosting decisions) that are paramount for the availability and continuity of the services the user is using based on context information (e.g. resource availability). This leads us to the second goal in task 4.3, context-driven adaptation. Adaptation is the keyword that introduces the flexibility that is required to enable continuity in ubiquitous computing. Indeed, guaranteeing continuity in the availability of services hosted on a multitude of mobile embedded devices hidden in the fabric of our everyday life is a harsh job that needs careful deployment considerations. In our solution, these considerations are enforced by resource contracts that are negotiated between software components and the middleware. Although, at this stage in the CoDAMoS project, the adaptation mechanisms themselves are not yet developed, the framework that manages resource contracts (called CRUMB) is already in a far evolved stage. Since CRUMB depends on the resource monitor (called the resource abstraction layer or RAL) which provides the required resource information, we will briefly discuss it in section

4 2 Query Protocol Context discovery is about finding all necessary context information from the environment using a powerful and selective query protocol. In task 1.2 we set up an ontology for the CODAMOS context specification, which specifies which content should be available as context and how this content relates to each other. Runtime instances of this model are scattered in a distributed computing environment where they can be discovered by interested parties. These parties, however, may be interested in very specific information and thus need very specific methods for determining their needs. There are two common approaches to obtain information from a data source. We can use either push mechanisms or pull mechanisms. Push mechanisms usually boil down to using a publish-subscriber pattern, which means a push on request. An observer entity subscribes for certain events at a data source which in turn notifies its subscribers when the requested event occurs. The pull mechanism requests for data only when the data is needed. Pull means that the observer builds up a query specifying which data it needs and then releases this query at the data source(s). The query is executed at the data source, which then returns the requested data if available. 2.1 State of the art SQL 1, likely the most well known query language, might be a good candidate for our purposes. Because SQL is mostly used in relational database systems for querying on keys and tables, adjustments need to be made to apply the language onto ontologies (such as our context ontology). SQL is wide-spread and has a proven applicability on huge and complex data sets. An innovative query mechanism is presented in the XML Query project [19] (XQuery). This project aims at providing flexible query facilities to extract data from real and virtual documents on the World Wide Web. This way, the interaction between the web world and the database world would become complete. The XQuery working group is developing a standard for querying web documents, serializing XML documents and providing a set of functions for manipulating web data. As context information could be stored as XML documents, XQuery might be a good candidate query protocol. Another initiative around XML, only a couple of years older than XQuery, is XQL [17]. XQL is a query language for XML documents that is closely related to XPath [16], a language for addressing parts of an XML document. XQL can handle queries that can make use of information in multiple documents, which allow the information contained in those documents to be reused in ways not foreseen by the designers the original documents. This is useful when many documents or data sources may each contain part of the context information needed. 1 Structured Query Language 3

5 QUERY PROTOCOL 2.2 Context Discovery DAML QL [4] (DQL in short) stands for the DAML 2 [10] Query Language and is a formal language and protocol for a querying agent and an answering agent to use in conducting a query-answering dialogue. The knowledge used is represented in the DAML+OIL [9] markup language. A DQL query consists of a query pattern that is a collection of DAML+OIL sentences in which some literals and URIrefs have been replaced by variables. An answer is composed of a set of DAML sentences and is referred to as the answer knowledge base. Considering that our context specification is described in an ontology language (OWL[18]), DQL proves to be an excellent candidate query language in the arsenal of our context discovery protocols. Service discovery is a well-studied topic that has been described thoroughly in literature. The CODAMOS deliverable elaborates on service discovery and as service information should be part of the context, these discovery techniques could be considered in the development of our own discovery protocol. Since the implementation of our distributed context framework is still going on, we are still working on the most expressive and efficient way to perform queries in context, taking into account the state of the art and the above candidate query protocols. 2 DARPA Agent Markup Language 4

6 3 Monitoring Support Often, accurate context-aware behavior can not be realized by a discovery mechanism due to frequent changes in certain context data. A device s resource use for example changes continuously, which can only be perceived smoothly by active context monitoring. Developing several resource monitoring techniques is a core activity in this part of task 4.3. A general resource contracting framework called CRuMB was designed that is extensible towards different resource types. CRUMB has a resource abstraction layer (RAL) that does the actual resource monitoring. The extensions we focus on are bandwidth and memory monitoring of components in a component-based middleware infrastructure. In this chapter we discuss the current state of the art in resource monitoring followed by the design of our resource monitoring framework. We elaborate on the bandwidth and memory monitor we designed for CRUMB in the consecutive sections and we end with a conclusion. 3.1 State of the art Resource adaptation and resource monitoring is a relatively new research topic. Most resource-constrained devices have a well defined and fixed functionality for which resource analysis can be performed at design-time 1. In fact, real-time constraints and stability issues make industry very reluctant to embrace any form of dynamic adaptation. The advent of multi-functional mobile computing devices and modern computing paradigms resulted in the incorporation of resource awareness in a number of existing middleware solutions. Although resource-aware middleware such as the KaffeOS VM [1] offers basic timing and/or memory accounting support, it generally lacks a general negotiation mechanism that can enforce dynamic adaptation. Our proposed framework offers a higher level of abstraction to programmers of resource-aware software. In this way, our component-based approach is a form of architectural resource adaptation (as described in [3]) with the added advantage of a powerful negotiation mechanism. A different approach is taken by the Quality Objects framework [5]. QuO explicitly and rightfully separates program functionality from QoS aspects. Adaptability of an application is modeled by the definition of a number of fixed regions for which the programmer defines a number of transitions. Rather than finding an optimal general resource distribution, application specific logic (QoS delegates) tries to come to a suitable QoS level. Finally, the JAMUS/RAJE framework [12] also offers resource contracts that can be (re)negotiated. JAMUS considers any component a potential threat, but it is unclear how each component obliged to request a contract before using a resource. JAMUS does not focus so much on a certain software architecture: it expects general object-oriented applications to use their framework. This makes it difficult to demand software entities to adhere to the contract rules. CRUMB is bound to a component architecture and knows exactly where to expect contracts and how it can postpone or stop a component s execution if necessary. These aspects are part of the architecture and required by design. In addition, CRUMB ameliorates contract expressiveness by allowing multiple quality attributes and multi-party contracts. JAMUS relies on RAJE for monitoring the resources used by Java application programs at runtime the same way as CRUMB relies on its RAL. RAJE, however, does not operate on a fine-grained level. RAJE does not focus on a specific architecture and as a consequence its measurements are global for the application rather than concentrated 1 as opposed to run-time 5

7 Figure 3.1: Resource Aware Tasks negotiating resource contracts on application components. As we describe below, CRUMB s RAL operates on the level of an application s subcomponents, which enables the use of a fine-grained componentlevel contracting framework. This fact is extremely important for our application adaptation mechanisms since it makes it possible to execute fine-grained application-adaptations as well, suiting the needs for an AmI computing environment. 3.2 Contracting and monitoring framework Resource Contracts Software envisioned by Ambient Intelligence (AmI software) supports a user and his tasks while avoiding user-device interaction as much as possible. It is intelligent in the sense that proactive behavior tries to avoid superfluous distraction of the user. Therefore, it needs detailed knowledge about the user s task. Furthermore, AmI software very often relies on harvested resources to provide a more powerful computing space. To ensure its survival on mobile devices, such software must be extremely robust and flexible in supporting these user tasks because of the frequent occurrence of location changes. As a consequence, two major responsibilities of AmI software are: task management: continuously supporting the computing functionality expected by the user according to the current task, avoiding user distraction as much as possible task availability: continuously supporting the user s computing space, hiding variations in the availability of external resources as much as possible It would be an unbearable burden for software designers if software should be given these responsibilities without appropriate middleware support. An approach to solve task management in pervasive environments has been described in [20]. This paper focuses on guaranteeing task availability and proposes a contract-driven solution involving a design methodology supported by middleware that allows for adaptable task behavior at runtime. Dealing with sudden changes in the availability of resources and ensuring that applications survive these fluctuations implicates that certain knowledge must be at hand: resource requirements of different parts of the application current resource use of different parts of the application 6

8 resource availability on the host system resource availability on other hosts in the environment Task management will use this information to continuously deal with changes in the availability of resources, through negotiation, renegotiation and application adaptation strategies. The remainder of this section will introduce supporting concepts and processes to support these mechanisms. Contractual Component Based Programming The nature of AmI software suggests the use of software building blocks that are more course-grained than software objects and more easily inter-connectible than web services. Component Based Development (CBD) [13] offers architectural and runtime support for programming in the large. To integrate a software component in an already existing setup of component based applications, the component specification is transferred, analyzed and checked by the middleware. We use the contract paradigm to map and adapt component specifications to the underlying middleware in order to connect their interfaces. Contractual programming is widely used in object-oriented programming, where it complements syntactic method specifications with pre- and postconditions regarding the semantic message behavior. It proved even more useful in CBD, and was extended to cover more levels of interoperation. Beugnard et al. introduced a specific CBD contract notion containing the following levels [2]: syntactic specification: signatures of messages and parameters semantic specification: description of component invariants, states, pre- and postconditions synchronization specification: description of the synchronization protocol by means of a state chart or a sequence chart QoS specification: non-functional properties related to the interaction, such as message timing, resource usage, result accuracy and reliability. Seamless component interoperation requires at least a partial matching of all contract levels. To match on a functional part of a component requires an extensive specification of its behavior. The problem of matching incompatible specifications either has to be solved by using well accepted standardized component specifications instead, or by adding (semi- )automatic glue code or other adaptation mechanisms. This is an important challenge in the heterogeneous domain of Ambient Intelligence in the years to come. This paper focuses on a concrete solution to match the QoS level of a component specification. Typical AmI scenario s [14] require software components to migrate and adapt to changing environments. In order to maintain a minimum QoS and take use of available resource where appropriate, components and their enabling middleware must be aware of their resource usage. To facilitate the reuse of a component in a new or changed environment, we adapt its QoS by introducing parameterized contracts. These resource contracts become first class entities that are effectively and continuously subject to negotiation. Contract Negotiation This section explains the notion of multi-party contracts and how they are agreed upon. 7

9 Definition 1 (Resource Declaration) A resource declaration is a parameterized description of a certain type of resource a software entity requires when it deploys its functionalities. An example set of resource declarations can be found in table 3.1. Developing software using the contract paradigm means that designers have to think carefully about several functional and non-functional properties during the development process. It is an essential part of it. The properties of the resources required by some software entities are outlined in a resource declaration. Each resource contract type has a resource declaration form that has to be filled in by the designer. This form may be filled in using static numbers (when the property is known precisely in advance) or using a parameterized formula. These parameters are filled in at runtime and are based on initial configuration data of the software entity involved. It may be obvious that defining a resource declaration involves a thorough knowledge of the internals of the software entity and often, testing, measuring and statistical analysis can be required to acquire the data needed in the declaration. Definition 2 (Resource Contract Proposal) A resource contract proposal contains an agreement on intended resource use by one or several parties. At runtime, resource declarations are the basis for creating a resource contract proposal, only the missing parameters are to be filled in. If more than one party is involved in creating a contract proposal based on their resource declarations, a negotiation process may be started to reach an agreement. As soon as the proposal is agreed upon, it may be submitted to the middleware where a validation procedure is initiated. Usually, a set of related contracts is submitted at once. Indeed, a task typically involves more than one component and/or type of resource. Rejected contract proposals are returned to the task manager of the application and a cause (e.g. the clause that caused the rejection) for the rejection is given. This cause can then be used to compile a new resource contract proposal and start a renegotiation. Definition 3 (Signed Resource Contract) A resource contract proposal can become a signed resource contract when the middleware system accepts the contract and signs it. A signed resource contract means that the parties involved must adhere to the agreements in the contract and that the middleware system must provide the resources as described in the contract. On acceptance, all contracts of a resource contract set become a signed entity in the runtime system. From that moment on, both the parties involved as the middleware system have a responsibility in respecting the contract. The middleware system may use monitoring mechanisms to validate whether all parties involved in signed contracts are behaving accordingly. Parties violating contracts can be disciplined in several ways. Depending on the middleware configuration, a small violation may be ignored, whereas recurring or more serious violations may cause the rejection of a signed contract. The middleware may allow the managing task to start a contract renegotiation. As long as no contract is signed for the allocation of a certain resource, the software entities involved have no more rights to allocate that type of resource. Resource contracts alleviate the programmer of many aspects involving the implementation of adaptive resource-aware components. Moreover, a supporting run-time framework can handle important decision making tasks, such as: automatic selection of an appropriate QoS level (based on user expectancy) decisions involving global resource usage and allocation (aggressive or not) 8

10 Figure 3.2: Basic component diagram for the presentation task. stroked lines depict data flow. Solid lines depict control flow, trade-offs between robustness and speed Removing most of the decision making process from the application software to supporting software improves resource sharing and stability of the overall system. Of course, this functionality comes with a penalty: as the granularity of resource monitoring becomes finer, the resource use of the run-time system itself will increase. The use of trusted software components may remove the need for extensive resource monitoring. The primary goal of CRUMB is to control user tasks as they have been defined in the field of Ambient Intelligence and context awareness. It does this by striving for the greatest application fidelity while maintaining a strong control on each individual component A Resource-Aware Slideshow To illustrate our approach, we present an example resource-aware application. The task involved is the display of a slide presentation. Figure 3.2 shows the basic component instance diagram of the task. It consists of the following component instances: The Presentation Domain Controller manages the actual presentation, and can send out individual slides. The Presentation Renderer processes slide models and produces an annotated graphical representation of the slide. These annotations include transition and animation information. The Transition Renderer is able to distill animation sequences out of a number of graphical slide representations. Each component has an associated resource description that is used by the task to form its contract. A subset of these descriptions involving memory are shown in table 3.1. The presentation task will first submit a set of contracts that reflects all desired functionality e.g. displaying high-resolution fluidly animated slides. Depending on the used policy and underlying device configuration, this contract may be accepted or not. Table 3.2 lists a number of possible contract sets. Note that a change from contract set 1 to set 2 will cause a reconfiguration of the Animation Renderer, whereas contract set 4 does not require the Animation Renderer at all. 9

11 Component Instance Average Maximum Max 95th Min 5th Memory Memory percentile percentile Domain Controller 274KB 1057KB 459KB 139KB Presentation Renderer 474KB 3247KB 1634KB 639KB Transition Renderer 5240KB 15021KB 9459KB 7139KB Table 3.1: Memory Profiles of the example component instances Contract Set Object Transition High Animation Animation Resolution set 1 yes yes yes set 2 yes no yes set 3 yes no no set 4 no no yes Table 3.2: Example contract sets Configuration Total Used Contractually Free Possible Memory Reserved Memory Contract Sets Laptop 256MB 68MB 78MB 178MB 1,2,3,4 PDA 32MB 25MB 28MB 4MB 4 Cellphone 2MB 512KB 768KB 1280KB Table 3.3: Example device configurations System support The CRUMB Architecture The CRUMB resource contract management architecture is available as an extension module for the DRACO [15] middleware system. As a module, it has access to the core of the system and can add listeners for getting notified of core events. CRUMB s functionality is encapsulated in several interacting submodules, as depicted in figure 3.3. Resource Monitor: The resource monitor performs the essential task of monitoring resource availability and resource consumption. By reifying the monitored information, it is made available to and understandable by the other subcomponents. Contract Manager: The contract manager has the following responsibilities: 1. keeping account of all signed contracts and managing contract removals. This also means that the contract manager should hand over contract information of newly signed contracts to the contract monitor if the latter is present. 2. checking the feasibility of resource contract proposals and signing them when their feasibility gets positively evaluated. 3. negotiating about contract proposals by interacting with the contract broker. 4. dealing with contract violations reported by the contract monitor. Upon a violation, contracts may get rejected which requires a renegotiation procedure through the contract broker to reestablish the contract. Contract Broker: As the CRUMB access point, the contract broker contains the negotiation logic for settling mutual agreements between tasks and CRUMB regarding certain contracts. 10

12 Figure 3.3: CRUMB General Architecture Contract Monitor: The contract monitor is not a required CRUMB submodule, but it is recommended when the robustness of the system has to be ensured. Its task consists of validating the use of resources (monitored by the Resource Monitor) against the established contracts. Whenever the use of resources exceeds the usage profile that was agreed upon, a violation is reported to the contract manager. The report contains information about the constraints that caused the violation. Rules for Resources Figure 3.3 shows the internals of the Contract Manager and the Contract Monitor. Both use a rule engine of an expert system to perform their vital functions. This provides easy validation and monitoring of all resource constraints. The Contract Manager receives Contract Proposals from the Contract Broker and delegates them to the appropriate rule generator. Rule generators are defined for each type of resource contract. Generated rules use previously submitted contract facts and policy rules to decide whether to sign a set of contract proposals. If a contract is signed, the necessary contract facts are generated for use in subsequent validation procedures. The Contract Monitor is notified of successfully signed contracts so it can produce its own monitoring rules, again according to the ruling policy. Relevant resource facts are updated periodically and trigger the appropriate monitoring rules. As an example, listing 3.1 triggers a violation if the associated memory bean reports a memory usage that is higher than 512KB. ( defrule memorycontractcompa (MemoryBean (name beancompa) (currentmemory?curr&:(>?curr 512KB)) ) => ( call ( fetch contractmonitor) violationalert memorycontractcompa) ) Listing 3.1: Example of a memory monitoring rule To deal with renegotiation (requiring changes in existing contracts), contract rules and facts can either be reinserted, or made to reference dynamic contract details objects. 11

13 avg IT stdv IT med IT perc 5 IT perc 95 IT avg MS stdv MS med MS perc 5 MS perc 95 MS Table 3.4: Bandwidth statistics Figure 3.4: Measuring bandwidth use First Results We implemented a proof-of-concept prototype of CRUMB in Java. Though Java has thus far seldom been considered as an option for embedded software development, we believe it can play a critical role in the development of computing systems for Ambient Intelligence. We chose Jess [11] (which is based on Clips [8]) as expert system, because of its integration with Java. CRUMB was implemented as a module of our in-house open-source DRACO component middleware platform [15]. DRACO offers many advanced CBD concepts such as ports and connectors, while remaining lightweight and easy to extend. A non-invasive memory monitoring technique using Java s resource API approximately slowed down the system with 10%. Moreover, the garbage collection mechanism makes profiling data very unreliable if it is not sampled after a garbage collection. That is why we feel memory monitoring would certainly benefit from VM support. 3.3 Bandwidth monitoring One of the monitors CRUMB s resource abstraction layer (RAL) has been extended with is a port-based bandwidth monitor. Whenever a component emits a message, the size of the message is measured and a high-resolution timer is started to measure the interval time between consecutive messages. This way, size and timing information is gathered from which the bandwidth use of a certain component port can be deducted. Graphically, the relationship between this collected information and the bandwidth use can be represented as in figure 3.4. Through the RAL, this information is presented to the middleware layer as context information that can be further processed in CRUMB s contracting submodules. The bandwidth monitor operates by injecting probes into the connectors between component ports. This injection is easily done using DRACO s message handling chains that are present in each connector. The injected probes perform the necessary measurements and calculations to produce statistical information regarding the parameters that influence bandwidth consumption. Table 3.4 summarizes the information that is calculated for each port. These are the average (avg), standard deviation (stdv), median (med), 5th percentile (perc 5 ) and the 95th percentile (perc 95 ) for both the interval time (IT ) and the message size (MS). 12

14 3.4 Memory monitoring Middleware controlling software hosted on mobile embedded devices needs a way to keep track of the memory its software components are using in order to prevent quality of service problems caused by inappropriate memory use. It is an asset to share information about memory use as context information so that it can support the well-functioning of middleware systems. Also, incorporating resource sharing capabilities into distributed middleware requires resource information to be present in context. The general idea behind the design of the component-level memory monitor is the following: The memory allocated by a component is the sum of all object memory allocated by the threads working for that component. Based on this simple principle, we can design a mechanism for monitoring a component s memory use without changing or interfering with the component s runtime behavior. Using the Java Virtual Machine Profiling Interface [7], we are able to monitor each object a thread allocates. It provides additional information such as the size of the allocated object, its object identification number and memory arena number. Mapping the thread back to the component it is operating for completes the component-object relationship. Some information (such as component ID, object size, object ID and arena ID) has to be stored until later on when the garbage collector frees the object and thus decreases the amount of memory allocated by the owner component Monitor implementation The Java Virtual Machine Profiling Interface (JVMPI) A high-level overview of a JVMPI-profiler is shown on figure 3.5 in which the profiler agent represents native C or C ++ code that implements the profiling interface. The virtual machine and the profiler agent interact through synchronous function calls. An important function call from the JVM to the profiler is the void (*NotifyEvent)(JVMPI_Event *event); call. Through this function the JVM publishes certain events that occurred inside the virtual machine. A brief overview of all events is given in table 3.5. The events that are primarily relevant for memory monitoring purposes are object allocation, object move and object free, GC start and GC finish. The JVMPI Event data structure that is passed as the argument contains additional information about the event that occurred. For example, the object allocation event is accompanied with the following structure: struct { jint arena_id; jobjectid class_id; jint is_array; jint size; jobjectid obj_id; } obj_alloc; The meaning of this structure is as follows: the arena identification (arena id) is a number specifying the section of the heap the object is allocated in, the obj id is a number that uniquely identifies the object, while the class id refers to the class the object is an instance of and size is the amount of memory in bytes the object allocated on the heap. 13

15 method enter and exit heap arena create and delete JNI global reference alloc and free compiled method load and unload JVM initialization and shutdown monitor dump object dump object alloc, move, and free GC start and finish JNI weak reference alloc and free thread start and end class load and unload heap dump request to reset profiling data Table 3.5: JVMPI events Figure 3.5: JVM Profiling Interface The Java Native Interface (JNI) The Java Native Interface [6] enables Java programmers to call native libraries from within their Java code and vice versa. Data can be exchanged between them simply by passing parameters in both directions during function and method calls. Java methods that are declared native are usually bound to their implementation by calling System.loadLibrary("libraryname"); from within Java code. There is, however, also a less frequently used way by doing it the other way around. Native methods can be registered with natively declared Java methods from inside the native library. The way to do this is to call the RegisterNatives function onto the JNI-environment structure. In C ++ this looks like: env->registernatives(classid, &nativemethod, 1); Where ClassID is an identification for the class the natively declared method belongs to and &nativemethod is a reference to the native method. This second way for binding native methods is handy when methods have to be bound to already instantiated native code (such as a profiler agent). Profiling implementation The native implementation 2 of the profiling agent basically subscribes to several JVM events and collects the event data regarding memory use. In order to understand how this data is processed, it is important to know which data structures are maintained in this profiler. There are two dynamic data structures that account for the object-thread-component relationships. vector<threadenvironment>* schedulerthreads; The first data structure is a vector (schedulerthreads) containing ThreadEnvironment objects. These objects store a JNI env, which can be seen as a unique thread identifier, and a 2 Using C ++ and the C ++ standard template library. 14

16 Components Draco component system Java Virtual Machine RAL JNI JVM Profiling Interface Native Profiling Agent C++ JVMPI Figure 3.6: Several layers in the monitoring framework. hashmap containing object ID to ObjectData mappings. The hashmap maintains a collection of all objects that were allocated by the given thread. The ObjectData objects contain the object ID, arena ID, the object s size and the ID of the component that allocated them. map<jint,componentdata*>* allocatedcomponents; The second data structure (allocatedcomponents) consists of a hashmap relating component IDs with ComponentData objects and it contains entries for every component allocated by the middleware platform. Each ComponentData object keeps track of the total amount of memory allocated by the given component. According to the working of our profiler, we can divide the JVM events into three groups. One group of events is only relevant during initialization of the middleware platform. The second group is related to object allocations, and the last group takes care of garbage collection events. The two events that are relevant during initialization are the class loading event and the thread start event. Class loading is monitored only to catch the ID of the MemoryResource- Manager class. This class is part of DRACO s resource abstraction layer and is responsible for communicating with the profiling agent. As soon as the profiler finds this class, it registers its native functions with the corresponding natively declared Java methods. Examples of these native functions are getcomponentsize, through which the RAL can get the current size of a certain component, newcomponentid, which is issued by the RAL to update the profiler with the ID of a newly created component, and passcomponentid, which is used to store the component a certain thread is working for. The thread start event monitors the startup of new threads and verifies whether or not the new thread is a member of the SchedulerThreads thread group. Members of this thread group are threads from the scheduler s thread pool, which either work for various components or work privately for a single component. These are the only threads that are empowered to perform the work of components and they are stored in the schedulerthreads data structure (see above). Figure 3.6 pictures a global overview of the interactions of the profiling agent with the virtual machine and the RAL. 15

17 During the life-time of the middleware system, events relating to newly created objects are constantly pouring into the profiler. The first thing the profiler does is checking whether the object was created by one of the scheduler threads or not. If not, the event is ignored, otherwise, the component the given scheduler thread is working for is looked up and stored in a new ObjectData object together with the object s data (size, ID,... ). In the next step, the memory size of the component is increased with the new object s size. And finally, the object is added to the ThreadEnvironment object s hashmap. This way, we know the total size of each component and we stored the data that is necessary to update the new state of each component after a garbage collection. Often at runtime, when memory is filling up, the garbage collector kicks in, removes all unused objects and moves objects to a new memory arena when necessary. At the level of the profiling agent, the beginning and the end of the garbage collection process is notified with appropriate events. However, the events our profiler is interested in occur inbetween these two notifications. The object free event, the object move event and the arena delete event all contribute to the updating process of the profiler s internal data structures. During the garbage collection process itself we simply keep track of all events by pushing their data into temporary lists. There is a list storing IDs of freed objects, update information for moved objects and IDs of deleted arenas. When garbage collection finally has finished, during the processing of the garbage collect finish event, these three lists are processed and the two main data structures are updated. IDs of freed objects are looked up, removed from the data structures and their corresponding component s memory use decreased with their sizes. All moved objects are updated with a new object ID and a new arena ID. And finally, all objects left in a deleted area are also removed Monitoring Overhead Using a high-resolution timer 3, we were able to measure the timing overhead caused by our profiling agent. We did four sets of measurements: the overhead during object allocations, the overhead during class loading, the total overhead of garbage collections and the part of the garbage collection overhead spent to updating the profiling agent s internal data structures Each of these measurements are discussed in the following sections. Object allocation overhead During the 15-hour test run, we processed object allocations. During this processing we examined wether or not each object was allocated by a software component and if so, an identifier for this component was retrieved and accounted for into the profiling agent s data structures together with the object data. The results of our measurements show that 99,98% of the timing overhead of this processing falls within the range from 1 to 50 microseconds. The histogram of this overhead measurement is illustrated in figure 3.7. Roughly 80% of these values vary around 7 and 8 microseconds, which means there is only a considerable small overhead during the execution of an application caused by object allocations. 3 with a 1 microsecond resolution 16

18 Figure 3.7: Histogram of the object allocation overhead (time in microseconds) However, there are outliers among the measurements. 0,02% of our measurements are situated over the 50 microseconds border, with one exceptionally large outlier of almost 24 milliseconds. The histogram of these outliers is pictured in figure 3.8. We expect that these outliers might have been caused by accidental process-switching issues on the host operating system. Luckily, their number is very small and almost all of them take less than 3 milliseconds. Class loading overhead Each first time an object of a certain class is allocated by the Java virtual machine, the object s class is loaded into the virtual machine. We monitor class loading to find the reference to the MemoryResourceManager class so that we can register our native methods with this class. As a consequence, the only time we need to do any processing during class loading is when we receive the event that publishes the MemoryResourceManager class. That is why processing class load only takes 1 or 2 microseconds, with an exceptional outlier of about 25 microseconds. Because this single occurrence only takes place when the resource manager is loaded, we may conclude that monitoring class loading causes virtually no overhead for the system at runtime. Garbage collection overhead During the test period, we registered a total of 59 barbage collections with an average collection time of 427,5 milliseconds. In its histogram shown on figure 3.9 we see that most garbage collections take between 350 and 400 milliseconds. One exceptional outlier of milliseconds was removed from the histogram. These results are rather high. Other test runs with the same application but without memory profiling resulted in garbage collection times that were almost 5 times shorter. Apparently, the additional processing of memory data during garbage collection with profiling takes quite some time. The next section elaborates on this issue. 17

19 Figure 3.8: Histogram of the object allocation overhead outliers (time in microseconds) Figure 3.9: Histogram of the garbage collection overhead (time in milliseconds) 18

20 Figure 3.10: Histogram of the garbage collection processing overhead (time in milliseconds) Garbage collection processing overhead Our calculations show that the fraction of the garbage collection time that is spent on the processing of memory data is substantial: 343 milliseconds on average. The appearance of the histogram (see figure 3.10) is similar to the histogram of the total garbage collection overhead, shifted only 75 milliseconds to the left. There is an outlier marking 2713,9 milliseconds removed from the figure. Of course, it corresponds with the outlier from the total garbage collection time. Clearly, once the garbage collection process itself is completed, it takes the profiling agent a considerable amount of time to update the accounting information that keeps track of the relationship between software components and the objects they allocated. Each object that was garbage collected has to be removed from the agent s data structures and the data for each object that was moved to another memory arena has to be updated to reflect the object s new identification 4. Unfortunately, there seems very little to do about this excessive timing overhead during garbage collection. The best option is to update the memory accounting data structures completely immediately after the garbage collection process ends. Only then we are in a virtual machine state in which all application threads are suspended and thus no changes occur on the heap. As soon as we return from that state, activity restarts and it becomes difficult (though not impossible) to update the data structures consistently. A complex alternative would be to spread this updating between two consecutive garbage collections and update the changes in a fine-grained way. It should then be guaranteed, however, that the update is completed before the next garbage collection begins. 4 which consists of a new object ID and a new memory arena ID 19

21 4 Conclusion In this deliverable, we first described the tracks we can follow in developing our context query mechanism by elaborating on the current state of the art. Our query protocol will evolve as the context framework implementation gets shape. The CRuMB contracting framework deals with resource contracts between software components and the middleware system. This way, a complete resource management environment ensures that software gets guarantees about required resources and that the device hosting the software will not get overloaded, which could cause device malfunctions. Two resource monitoring techniques are already worked out: bandwidth monitoring and memory monitoring. This deliverable mostly elaborates on the memory monitor and its performance on an existing component middleware system. 20

22 BIBLIOGRAPHY [1] Godmar Back, Wilson C Hsieh, and Jay Lepreau. Processes in KaffeOS: Isolation, resource management, and sharing in Java. In Proceedings of the 4th Symposium on Operating Systems Design and Implementation, [2] A. Beugnard, J.M. Jezequel, N. Plouzeau, and D. Watkins. Making components contract aware. Computer IEEE, 32(7):38 45, [3] Shang-Wen Cheng, David Garlan, Bradley Schmerl, Joäo Pedro Sousa, Bridget Spitznagel, Peter Steenkiste, and Ningning Hu. Software architecture-based adaptation for pervasive systems. In International Conference on Architecture of Computing Systems (ARCS 02): Trends in Network and Pervasive Computing. LNCS, April [4] DAML Joint Committee. Daml query language. Internet, August [5] JP Loyall, RE Schantz, JA Zinky, and DE Bakken. Specifying and measuring quality of service in distributed object systems. In Proceedings of the First International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC 98), Kyoto, Japan, April [6] Sun Microsystems. Java native interface (jni). Internet. [7] Sun Microsystems. Java virtual machine profiling interface (jvmip). Internet. [8] NASA. Clips: C language integrated production system, [9] DAML project. Daml+oil. Internet. [10] DAML project. The darpa agent markup language. Internet, August [11] Sandia National Laboratories. Jess: the rule engine for the Java platform, [12] Nicolas Le Sommer. A contract-based approach of resource management in informations systems. In Proceedings of 9th International Conference on Object-Oriented Information Systems (OOIS 2003), Genève. LNCS, September [13] C. Szyperski. Component Software: Beyond Objectoriented Programming. Addison- Wesley, New York, [14] the IST Advisory Group. Istag scenario s for ambient intelligence in 2010, [15] Yves Vandewoude, Peter Rigole, and David Urting. Draco: an adaptive runtime environment for components. Appendix of the EMPRESS deliverable for Run-time Evolution and Dynamic (Re)configuration of Components, [16] w3c. Xml path language. Internet, November

23 BIBLIOGRAPHY [17] w3c. Xql (xml query language). Internet, August [18] w3c. Web ontology language. Internet, February [19] w3c. The xml query project: Xquery. Internet, July and [20] Zhenyu Wang and David Garlan. Task-driven computing. Technical Report CMU- CS , School of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15217, USA, May