| OCR Text |
Show The execution stream provides an alternative approach to the problem mentioned by Snodgrass [78]: "It might be desirable to have the monitor play a greater part in sensor specification (e.g., allow it to substitute sampling for tracing to lower the data-collection overhead) and sensor installation (e.g., allow it to install the sensors at execution time by using conventional breakpointing mechanisms). How this may be done is an open question." Traditionally, events are obtained by installing sensors in the executor. These sensors report various aspects of the executor's behavior. Sensors are installed by modifying executor's source program or its machine program. Since the approach with sensors requires modifications of the executor, there are limitations on the sensor specification and on the sensor installation. The approach with the execution stream presents a different view. There is no need to modify the executor, since the execution stream captures the complete behavior of the executor. An analysis of the execution stream is thus able to provide the implementation of any possible sensor. Since the execution stream collects the executor's behavior in one place, it is much easier to define complex sensors and to dynamically change their range than by modifying executor's code. For example, if we use a traditional approach to monitor all conditional statements in the executor, we need to incorporate sensors at all occurrences of these statements in the executor's code. This causes a significant time overhead when sensors are installed, switched on or switched off. Using the approach with the execution stream, only one sensor which analyzes the execution stream is needed. This sensor can be turned on and off quickly. The approach with the execution stream can easily scale to multiple complex sensors. The execution stream thus provides a good description of the executor's behavior together with the capacity for a complex analysis of events. To help the director in 26 |
