Semantics and Algorithms for Parametric Monitoring

Analysis of execution traces plays a fundamental role in many program analysis approaches, such as runtime verification, testing, monitoring, and specification mining. Execution traces are frequently parametric, i.e., they contain events with parameter bindings. Each parametric trace usually consists of many meaningful trace slices merged together, each slice corresponding to one parameter binding. This gives a semantics-based solution to parametric trace analysis. A general-purpose parametric trace slicing technique is introduced, which takes each event in the parametric trace and dispatches it to its corresponding trace slices. This parametric trace slicing technique can be used in combination with any conventional, non-parametric trace analysis technique, by applying the later on each trace slice. As an instance, a parametric property monitoring technique is then presented. The presented parametric trace slicing and monitoring techniques have been implemented and extensively evaluated. Measurements of runtime overhead confirm that the generality of the discussed techniques does not come at a performance expense when compared with existing parametric trace monitoring systems.


Introduction and Motivation
Parametric traces, i.e., traces containing events with parameter bindings, abound in program executions, because they naturally appear whenever abstract parameters (e.g., variable names) are bound to concrete data (e.g., heap objects) at runtime.In this section we first discuss some motivating examples and describe the problem addressed in this paper, then we recall related work and put the work in this paper in context, and then we explain our contributions and finally the structure of the paper.

1.1.
Motivating examples and highlights.We here describe three examples of parametric properties, in increasing difficulty order, and use them to highlight and motivate the semantic results and the algorithms presented in the rest of the paper.
Typestates [34] refine the notion of type by stating not only what operations are allowed by a particular object, but also what operations are allowed in what contexts.Typestates are particular parametric properties with only one parameter.Figure 1 shows the typestate description for a property saying that it is invalid to call the next() method on an iterator object when there are no more elements in the underlying collection, i.e., when hasnext() returns false, or when it is unknown if there are more elements in the collection, i.e., hasnext() is not called.From the unknown state, it is always an error to call the next() method because such an operation could be unsafe.If hasnext() is called and returns true, it is safe to call next(), so the typestate enters the more state.If, however, the hasnext() method returns false, there are no more elements, and the typestate enters the none state.In the more and none states, calling the hasnext() method provides no new information.It is safe to call next() from the more state, but it becomes unknown if more elements exist, so the typestate reenters the initial unknown state.Finally, calling next() from the none state results in an error.For simplicity, we here assume that next() is the only means to modify the state of an iterator; concurrent modifications are discussed in other examples shortly.
It is straightforward to represent the typestate property in Figure 1, and all typestate properties, as particular (one-parameter) parametric properties.Indeed, the behaviors described by the typestate in Figure 1 are intended to be obeyed by all iterator object instances; that is, we have a property parametric in the iterator.To make this more precise, let us look at the problem from the perspective of observable program execution traces.A trace can be regarded as a sequence of events relevant to the property of interest, in our case calls to next() or to hasnext(); the latter can be further split into two categories, one when hasnext() returns true and the other when it returns false.Since the individuality of each iterator matters, we must regard each event as being parametric in the iterator yielding it.Formally, traces relevant to our typestate property are formed with three parametric events, namely next i , hasnexttrue i , and hasnextfalse i .A possible trace can be hasnexttrue i1 hasnextfalse i2 next i1 next i2 ..., which violates the typestate property for iterator instance i 2 .How to obtain execution traces is not our concern here (several runtime monitoring systems use AspectJ instrumentation).Our results in this paper are concerned with how to specify properties over parametric traces, what is their meaning, and how to monitor them.
Let us first briefly discuss our approach to specifying properties over parametric execution traces, that is, parametric properties.To keep it as easy as possible for the user and to leverage our knowledge on specifying ordinary, non-parametric properties, we build our specification approach on top of any formalism for specifying non-parametric properties.
More precisely, all one has to do is to first specify the property using any conventional formalism as if there were only one possible instance of its parameters, and then use a special Λ quantifier to make it parametric.For our typestate example, suppose that typestate is the finite state machine in Figure 1, modified by replacing the method calls on edges with actual events as described above.Then the desired parametric property is Λi .typestate.The meaning of this parametric property is that whatever was intended for its non-parametric counterpart, typestate, must hold for each parameter instance; that is, the error state must not be reached for any iterator instance, which is precisely the desired meaning of this typestate.Another way to specify the same property is using a regular expression matching all the good behaviors, each bad prefix for any instance thus signaling a violation: Λi .(hasnexttrue i + next i | hasnextfalse i * ) * Yet another way to specify its non-parametric part is with a linear-temporal logic formula: The above LTL formula says "it is always ( ) the case that each next i event is preceded (• • ) by a hasnexttrue i .The LTL formula must hold for any iterator instance.In general, if ΛX .P is a parametric property, where X is a set of one or more parameters, we may call P its corresponding base or root or non-parametric property.In this paper we develop a mathematical foundation for specifying such parametric properties independently of the formalism used for specifying their non-parametric part, define their precise semantics, provide algorithms for online monitoring of parametric properties, and finally bring empirical evidence showing that monitoring parametric properties is in fact feasible.
Parametric properties properly generalize typestates in two different directions.First, parametric properties allow more than one parameter, allowing us to specify not only properties about a given object such as the typestate example above, but also properties that capture relationships between objects.Second, they allow us to specify infinite-state root properties using formalisms like context-free grammars (see Sections 2.4, 2.5 and 2.6).
Let us now consider a two-parameter property.Suppose that one is interested in analyzing collections and iterators in Java.Then execution traces of interest may contain events createIter c i (iterator i is created for collections c), updateColl c (c is modified), and next i (i is accessed using its next element method), instantiated for particular collection and iterator instances.Most properties of parametric traces are also parametric; for our example, a property may be "collections are not allowed to change while accessed through iterators", which is parametric in a collection and an iterator.The parametric property above expressed as a regular expression (here matches mean violations) can be Λc, i .createIter c i next i * updateColl c + next i From here on, when we know the number and types of parameters of each event, we omit writing them in parametric properties, because they are redundant; for example, we write Λc, i .createIter next * updateColl + next Parametric properties, unfortunately, are very hard to formally verify and validate against real systems, mainly because of their dynamic nature and potentially huge or even unlimited number of parameter bindings.Let us extend the above example: in Java, one may create a collection from a map and use the collection's iterator to operate on the map's elements.A similar safety property is: "maps are not allowed to change while accessed indirectly through iterators".Its violation pattern is: with two new parametric events createColl m c (collection c is created from map m) and updateMap m (m is updated).All the events used in this property provide only partial parameter bindings (createColl binds only m and c, etc.), and parameter bindings carried by different events may be combined into larger bindings; e.g., createColl m 1 c 1 can be combined with createIter c 1 i 1 into a full binding m 1 c 1 i 1 , and also with createIter c 1 i 2 into m 1 c 1 i 2 .It is highly challenging for a trace analysis technique to correctly and efficiently maintain, locate and combine trace slices for different parameter bindings, especially when the trace is long and the number of parameter bindings is large.
This paper addresses the problem of parametric trace analysis from a foundational, semantic perspective: Given a parametric trace τ and a parametric property ΛX .P , what does it mean for τ to be a good or a bad trace for ΛX .P ?How can we show it?How can we leverage, to the parametric case, our knowledge and techniques to analyze conventional, non-parametric traces against conventional, nonparametric properties?In this paper we first formulate and then rigorously answer and empirically validate our answer to these questions, in the context of runtime verification.In doing so, a technique for trace slicing is also presented and shown correct, which we regard as one of the central results in parametric trace analysis.In short, our overall approach to monitor a parametric property ΛX .P is to observe the parametric trace as it is being generated by the running system, slice it online with respect to the used parameter instances, and then send each slice piece-wise to a non-parametric monitor corresponding to the base property P ; this way, multiple monitor instances for P can and typically do coexist, one for each trace slice.
The main conceptual limitation of our approach is that the parametrization of properties is only allowed at the top-level, that is, the base property P in the parametric property ΛX .P cannot have any Λ binders.In other words, we do not consider nested parameters.
To allow nested parameters one needs a syntax for properties, so that one can incorporate the syntax for parameters within the syntax for properties.However, one of our major goals is to be formalism-independent, which means that, by the nature of the problem that we are attempting to solve, we can only parameterize properties at the top.Many runtime verification approaches deliberately accept the same limitation, as discussed below, because arbitrarily nested parameters are harder to understand and turn out to generate higher runtime overhead in the systems supporting them.
Our concrete contributions are explained after the related work.
1.2.Related Work.We here discuss several major approaches that have been proposed so far to specify and monitor parametric properties, and relate them to our subsequent results in this paper.It is worth mentioning upfront that, except for the MOP approach [28] which motivated and inspired the work in this paper, the existing approaches do not follow the general methodology proposed by our approach in this paper.More precisely, they employ a monolithic monitoring approach, where one monitor is associated to each parametric property; the monitor receives and handles each parametric event in a formalism-specific way.In contrast, our approach is to generate multiple local monitors, each keeping track of one parameter instance.Our approach leads not only to a lower runtime overhead as empirically shown in Section 9, but it also allows us to separate concerns (i.e., the parameter handling from the specification formalism and monitor synthesis for the basic property) and thus potentially enabling a broader spectrum of optimizations that work for various different property specification formalisms and corresponding monitors.
Tracematches [1,4] is an extension of AspectJ [2] supporting parametric regular patterns; when patterns are matched during the execution, user-defined advice can be triggered.J-LO [9] is a variation of Tracematches that supports a first-order extension variant of linear temporal logic (LTL) that supports data parametrization by means of quantifiers [33]; the user-provided actions are executed when the LTL properties are violated.Also based on AspectJ, [24] proposes Live Sequence Charts (LSC) [17] as an inter-object scenario-based specification formalism; LSC is implicitly parametric, requiring parameter bindings at runtime.Tracematches, J-LO and LSC [24] support a limited number of parameters, and each has its own approach to handle parameters, specific to its particular specification formalism.Our semantics-based approach in this paper is generic in the specification formalism and admits, in theory, a potentially unlimited number of parameters.In spite of the generality of our theoretical results, we chose in our current implementations (see Section 9) to also support only a bounded number of parameters, like in the aforementioned approaches.
JavaMOP [28,14] (http://javamop.org) is a parametric specification and monitoring system that is generic in the specification formalism for base properties, each formalism being included as a logic plugin.Monitoring code is generated from parametric specifications and woven within the original Java program, also using AspectJ, but using a different approach that allows it to encapsulate monitors for non-parametric properties as blackboxes.Until recently, JavaMOP's genericity came at a price: it could only monitor execution traces in which the first event in each slice instantiated all the property parameters.This limitation prevented the JavaMOP system presented in [14] from monitoring some basic parametric properties, including ones discussed in this paper.Our novel approach to parametric trace slicing and monitoring discussed in this paper does not have that limitation anymore.The parametric slicing and monitoring technique discussed in this paper has been incorporated both in JavaMOP [28] and in its commercial-grade successor RV [27], together with several optimizations that we do not discuss here; Section 9 discusses experiments done with both these systems, as well as with Tracematches, for comparison, because Tracematches has proven to be the most efficient runtime verification system besides JavaMOP.
Program Query Language (PQL) [25] allows the specification and monitoring of parametric context-free grammar (CFG) patterns.Unlike the approaches above that only allow a bounded number of property parameters, PQL can associate parameters with sub-patterns that can be recursively matched at runtime, yielding a potentially unbounded number of parameters.PQL's approach to parametric monitoring is specific to its particular CFGbased specification formalism.Also, PQL's design does not support arbitrary execution traces.For example, field updates and method begins are not observable; to circumvent the latter, PQL allows for observing traces local to method calls.Like PQL, our technique also allows an unlimited number of parameters (but as mentioned above, our current implementation supports only a bounded number of parameters).Unlike PQL, our semantics and techniques are not limited to particular events, and are generic in the property specification formalism; CFGs are just one such possible formalism.
Eagle [5], RuleR [6], and Program Trace Query Language (PTQL) [19] are very general trace specification and monitoring systems, whose specification formalisms allow complex properties with parameter bindings anywhere in the specification (not only at the beginning, like we do).Eagle and RuleR are based on fixed-point logics and rewrite rules, while PTQL is based on SQL relational queries.These systems tackle a different aspect of generality than we do: they attempt to define general specification formalisms supporting data binding among many other features, while we attempt to define a general parameterization approach that is logic-independent.As discussed in [4,26,14] (Eagle and PQL cases), the very general specification formalisms tend to be slower; this is not surprising, as the more general the formalism the less the potential for optimizations.Our techniques can be used as an optimization for certain common types of properties expressible in these systems: use any of these to specify the base property P , then use our generic techniques to analyze ΛX .P .1.3.Contributions.Besides proposing a formal semantics to parametric traces, properties, and monitoring, we make two theoretical contributions and discuss implementations that validate them empirically: (1) Our first result is a general-purpose online parametric trace slicing algorithm (algorithm A X in Section 6) together with its proof of correctness (Theorem 1), positively answering the following question: given a parametric execution trace, can one effectively find the slices corresponding to each parameter instance without having to traverse the trace for each instance?(2) Our second result, building upon the slicing algorithm, is an online monitoring technique (algorithms B X and C X in Section 8) together with its proof of correctness (Theorems 2 and 3), which positively answers the following question: is it possible to monitor arbitrary parametric properties ΛX .P against parametric traces, provided that the root property P is monitorable using conventional monitors?(3) Finally, our implementation of these techniques in the JavaMOP and RV systems positively answers the following question: can we implement general purpose and unrestricted parametric property monitoring tools which are comparable in performance with or even outperform existing parametric property monitoring tools on the restricted types of properties and/or traces that the latter support?Preliminary results reported in this paper have been published in a less polished form as a technical report in summer 2008 [30].Then a shorter, conference paper was presented at TACAS 2009 in York, U.K. [16].This extended paper differs from [16] as follows: (1) It defines all the mathematical infrastructure needed to prove the results claimed in [16].For example, Section 3 is new.(2) It expands the results in [16] and includes all their proofs, as well as additional results needed for those proofs.For example, Section 5 is new.(3) It discusses more examples of parametric properties.For example, Section 2 is new.(4) The implementation section in [16] presented an incipient implementation of our technique in a prototype system called PMon there (from Parametric Monitoring).In the meanwhile, we have implemented the technique described in this paper as an integral part of the runtime verification systems JavaMOP (http://javamop.org)and RV [27].
The implementation section (Section9) now refers to these systems.
1.4.Paper Structure.Section 2 discusses examples of parametric properties.Section 3 provides the mathematical background needed to formalize the concepts introduced later in the paper.Section 4 formalizes parametric events, traces and properties, and defines trace slicing.Section 5 establishes a tight connection between the parameter instances in a trace and the parameter instance used for slicing.Sections 6, 7 and 8 discuss our main techniques for parametric trace slicing and monitoring, and prove them correct.Section 9 discusses implementations of these techniques in two related systems, JavaMOP and RV.Section 10 concludes and proposes future work.

Examples of Parametric Properties
In this section we discuss several examples of parametric properties.Our purpose here is twofold.On the one hand we give the reader additional intuition and motivation for the subsequent semantics and algorithms, and, on the other hand, we justify the generality of our approach with respect to the employed specification formalism for trace properties.
The discussed examples of parametric properties are defined using various trace specification formalisms, some with more than one parameter and some with more than validating and/or violating categories of behaviors.For each of the examples, we give hints on how our subsequent techniques in Sections 6 and 8 work.In order to explain the examples in this section we also informally introduce necessary notions, such as events and traces (both parametric and non-parametric); all these notions will be formally defined in Section 4.
For each example, we also discuss which of the existing runtime verification systems can support it.Note that JavaMOP [28] and its commercial-grade successor RV [27], which build upon the trace slicing and monitoring techniques presented in this paper, are the only runtime verification systems that support all the parametric properties discussed below.
2.1.Releasing acquired resources.Consider a certain type of resource (e.g., synchronization objects) that can be acquired and released by a given procedure, and suppose that we want the resources of this type to always be explicitly released by the procedure whenever acquired and only then.This example will be broken in subparts and used as a running example in Section 4 to introduce our main notions and notations.
Let us first consider the non-parametric case in which we have only one resource.Supposing that the four events of interest, i.e., the begin/end of the procedure and the acquire/release of the resource, are E = {begin, end, acquire, release}, then the following regular pattern P captures the desired behavior requirements: The above regular pattern states that the procedure can take place multiple times and, if the resource is acquired then it is released by the end of the procedure (ǫ is the empty word).For simplicity, we here assume that the procedure is not recursive and that the resource can be acquired and released multiple times, with the effect of acquiring and respectively releasing it precisely once; Section 2.4 shows how to use a context-free pattern to specify possibly recursive procedures with matched acquire/release events within each procedure invocation.One matching execution trace for this property is, e.g., begin acquire acquire release end begin end.
Let us now consider the parametric case in which we may have more than one resource and we want each of them to obey the requirements specified above.Now the events acquire and release are parametric in the resource being acquired or released, that is, they have the form acquire r 1 , release r 2 , etc.The begin/end events take no parameters, so we write them begin and end .A parametric trace τ for our running example can be the following: τ = begin acquire r 1 acquire r 2 acquire r 1 release r 1 end begin acquire r 2 release r 2 end This trace involves two resources, r 1 and r 2 , and it really consists of two trace slices merged together, one for each resource: r 1 : begin acquire acquire release end begin end r 2 : begin acquire end begin acquire release end The begin and end events belong to both trace slices.Since we know the parameter instance for each trace slice and we know the types of parameters for each event, to avoid clutter we do not mention the redundant parameter bindings of events in trace slices.
Our trace slicing algorithm discussed in Section 6 processes the parametric trace only once, traversing it from the first parametric event to the last, incrementally calculating a collection of meaningful trace slices so that it can quickly identify and report the slice corresponding to any parameter instance when requested.
Note that the r 1 trace slice matches the specification P above, while the r 2 trace slice does not.To distinguish parametric properties referring to multiple trace slices from ordinary properties, we explicitly list the parameters using a special Λ binder.For example, our property above parametric in the resource r is Λr .P , or Λr .(begin (ǫ | (acquire (acquire | release) * release)) end) * Both Tracematches [1,4] and JavaMOP [28] can specify/monitor such parametric regular properties, the latter using its extended-regular expression (ERE) plugin.
For the sake of a terminology, P is called a non-parametric, or a root, or a basic property, in contrast to Λr .P , which is called a parametric property.As detailed in Section 4, parametric properties are functions taking a parametric trace (e.g., τ ) and a parameter instance (e.g., r → r 1 or r → r 2 ) into a verdict category for the basic property P (e.g., match or fail).In our case, the semantics of our parametric property Λr .P takes parametric trace τ and parameter instance r → r 1 to match, and takes τ and r → r 2 to fail, that is, (Λr .P )(τ )(r → r 1 ) = match (Λr .P )(τ )(r → r 2 ) = fail Our parametric monitoring algorithm in Section 8 reports a fail for instance r → r 2 precisely when the first end event is encountered.
We would like to make two observations at this stage.First, as we already mentioned, we only parameterize a property at the top, that is, the Λ binder cannot be used inside the basic property.Indeed, since we do not enforce any particular syntax for basic properties, it is not clear how to mix the Λ binder with the inexistent property constructs.Second, one should not confuse our parameters with universally quantified variables.While in our example above Λ may feel like a universal quantifier, note that one may prefer to specify the same parametric property in a more negative fashion, for example to specify the bad behaviors instead of the positive ones.Relying on the fact that the begin and end events must be correctly matched, one can only state the bad patterns, which are a begin followed by a release and an acquire followed by an end: The right way to regard a parametric property is as one indexed by all possible instances of the parameters, each instance having its own interpretation of the trace (only caring of the events relevant to it), which is orthogonal to the other instances' interpretations.
2.2.Authenticate before use.Consider a server authenticating and using keys, say k 1 , k 2 , k 3 , etc., whose execution traces contain events authenticate k 1 , use k 2 , etc.A possible trace of such a system can be A parametric property for such a system can be "each key must be authenticated before use", which, using linear temporal logic (LTL) as a specification formalism for the corresponding base property, can be expressed as Λk .(use → ⋄ • authenticate) Such parametric LTL properties can be expressed in both J-LO [9] and JavaMOP [28,14] (the later using its LTL logic plugin).For the trace above, the trace slice corresponding to k 3 is authenticate use use corresponding to the parametric subtrace authenticate k 3 use k 3 use k 3 of events relevant to k 3 in τ , but keeping only the base events; also, the trace slice corresponding to k 2 is use authenticate use.Our trace slicing algorithmin Section 6 can detect these slices.Moreover, with the finite trace LTL semantics in [32], Our parametric monitoring algorithm in Section 8 reports a violation for instance k → k 2 precisely when the first use k 2 is encountered.2.3.Safe iterators.Consider the following property for iterators created over vectors: when an iterator is created for a vector, one is not allowed to modify the vector while its elements are traversed using the iterator.The JVM usually throws a runtime exception when this occurs, but the exception is not guaranteed in a multi-threaded environment.Supposing that parametric event create v i is generated when iterator i is created for vector v, update v is generated when v is modified, and next i is generated when i is accessed using its "next element" interface, then one can write it as the parametric regular property Λv, i .create next * update + next.
Such parametric regular expression properties can be expressed in both Tracematches [1] and JavaMOP [28,14] (the latter using its ERE plugin).We here assumed that the matching of the regular expression corresponds to violation of the base property.Thus, the parametric property is violated by a given trace and a given parameter instance whenever the regular pattern above is matched by the corresponding trace slice.For example, if τ = create v 1 i 1 next i 1 create v 1 i 2 update v 1 next i 1 is a parametric trace where two iterators are created for a vector, then the slice corresponding to v 1 i 1 is create next update next and the one corresponding to v 1 i 2 is create update, so τ violates the parametric property (i.e., matches the regular pattern above) on instance v 1 i 1 , but not on instance v 1 i 2 .Note that in this example there are more than one parameters in events, traces and property, namely a vector and an iterator.Indeed, the main difficulty of our techniques in Sections 6 and 8 was precisely to handle general purpose parametric properties with an arbitrary number of parameters.The slicing algorithm in Section 6 processes parametric traces and maintains enough slicing information so that, when asked to produce slices corresponding to particular parameter instances, e.g., to v 1 i 2 , it can do so without any further analysis of the trace.Also, in this case, the monitoring algorithm in Section 8 reports a match each time a parameter instance yields a matching trace slice.
2.4.Correct locking.Consider a custom implementation of synchronization in which one can acquire and release locks manually (like in Java 5 and later versions).A basic property is that each function releases each lock as many times as it acquires it.Assuming that the executing code is always inside some function (like in Java, C, etc.), that begin and end events are generated whenever function executions are started and terminated, respectively, and that acquire l and release l events are generated whenever lock l is acquired or released, respectively, then one can specify this safety property using the following parametric context-free grammar (CFG) pattern: Λl .S → S begin S end | S acquire S release | ǫ Such parametric CFG properties can be expressed in both PQL [25] and JavaMOP [28,26] (the later using its CFG plugin).We here borrow the CFG property semantics of the CFG plugin of JavaMOP (and also RV [27]) in [26], that is, this parametric property is violated by a parametric execution with a given parameter instance (i.e., concrete lock) whenever the corresponding trace slice cannot be completed into one accepted by the grammar language.While this property can be expressed in JavaMOP and even monitored in its non-parametric form, the previous implementation of JavaMOP in [26] cannot monitor it as a parametric property because its violating traces most likely start with a property-relevant begin event, which does not contain a lock parameter; therefore, the previous limitation of JavaMOP (allowing only events that instantiate all property's parameters to create a monitor instance) did not allow us to monitor this natural CFG property.To circumvent this limitation, [26] proposed a different way to specify this property, in which the violating traces started with an acquire l event.We do not need such artificial encodings anymore in the new version of JavaMOP, and they were never needed in RV (RV improves the new JavaMOP).
For profiling reasons, one may also want to take notice of validations, or matches of the property, as well as matches followed by violation, etc.; one can therefore have different interpretations of CFG patterns as base properties, classifying traces into various categories.What is different in this example, compared to the previous ones, is that the non-parametric property cannot be implemented as a finite state machine.With the CFG monitoring algorithm proposed in [26] used to monitor the base property, our parametric monitoring algorithm in Section 8 reports a violation of this parametric CFG property as soon as a parameter instance is detected for which the corresponding trace slice has no future, that is, it admits no continuation into a trace in the language of the grammar.
2.5.Safe resource use by safe client.A client can use a resource only within a given procedure and, when that happens, both the client and the resource must have been previously authenticated as part of that procedure.Assuming the procedure fixed and given, this is a property over traces with five types of events: begin and end of the procedure (begin and end ), authenticate of client (auth-client c ) or of resource (auth-resource r ), and use of resource by client (use r c ).Using the past time linear temporal logic with calls and returns (ptCaRet) in [31], one would write it as follows: The overlined operators are abstract variants of temporal operators, in the sense that they are defined on traces that collapse terminated procedure calls (erase subtraces bounded by matched begin/end events).For example, "⋄ • begin" holds only within a procedure call, because all the nested and terminated procedure calls are abstracted away.In words, the above says: if one sees the use of the resource (use) then that must take place within the procedure and it is not the case that one did not see, within the main procedure since its latest invocation, the authentication of the client or the authentication of the resource.
JavaMOP can express this property using its ptCaRet logic plugin [31].However, until recently [28], JavaMOP could again only monitor it in its non-parametric form, because of its previous limitation allowing only completely parameterized events to create monitors.Even though it may appear that this property can only be violated when a completely parameterized use r c event is observed, in fact, the monitor must already exist at that point in the execution and "know" whether the client and the resource have authenticated since the begin of the current procedure; all the other events involved in the property are incompletely parameterized, so, unfortunately, this parametric property could not be monitored using the previous JavaMOP system, but it can be monitored with the new one.
2.6.Success ratio.Consider now parametric traces with events success a and fail a , saying whether a certain action a was successful or not.For a given action, a meaningful property can classify its (non-parametric) traces into an infinite number of categories, each representing a success ratio of the given action, which is a (rational) number s/t between 0 and 1, where s is the number of success events in the trace and t is the total number of events in the trace.Then the corresponding parametric property over such parametric traces gives a success ratio for each action.We can specify such a property in JavaMOP and RV by making use of monitor variables and event actions [28].Indeed, one can add two monitor variables, s and t, and then increment t in each event action and increment s only in the event action of the success event.The underlying parametric monitoring algorithm keeps separation between the various s and t monitor variables, one such pair for each distinct action a, guaranteeing that the correct ones will be accessed.

Mathematical Background: Partial Functions, Least Upper Bounds (lubs) and lub Closures
In this section we first discuss some basic notions of partial functions and least upper bounds of them, then we introduce least upper bounds of sets of partial functions and least upper bound closures of sets of partial functions.This section is rather mathematical.We need these mathematical notions because it turns out that parameter instances are partial maps from the domain of parameters to the domain of parameter values.As shown later, whenever a new parametric event is observed, it needs to be dispatched to the interested parts (trace slices or monitors), and those parts updated accordingly: these informal operations can be rigorously formalized as existence of least upper bounds and least upper bound closures over parameter instances, i.e., partial functions.We recommend the reader who is only interested in our algorithms but not in the details of our subsequent proofs, to read the first two definitions and then jump to Section 4, returning to this section for more mathematical background only when needed.
3.1.Partial Functions.This section discusses partial functions and (least) upper bounds over sets of partial functions.The notions and the results discussed in this section are broadly known, and many of their properties are folklore.They can be found in one shape or another in virtually any book on denotational semantics or domain theory.Since we need only a small subset of notions and results on partial functions and (least) upper bounds in this paper, and since we need to fix a uniform notation anyway, we prefer to define and prove everything we need and hereby also make our paper self-contained.
We think of partial functions as "information carriers": if a partial function θ is defined on an element x of its domain, then "θ carries the information θ(x) about x ∈ X".Some partial functions can carry more information than others; two or more partial functions can, together, carry compatible information, but can also carry incompatible information (when two or more of them disagree on the information they carry for a particular x ∈ X).
(2) θ ′ is the least upper bound (lub) of Θ iff θ ′ is an upper bound of Θ and θ ′ ⊑ θ ′′ for any other upper bound θ ′′ of Θ; A set of partial functions has an upper bound iff the partial functions in the set are pairwise compatible, that is, no two of them disagree on the value of any particular element in their domain.Least upper bounds and maximums may not always exist for any Θ ⊆ [X ⇁ V ]; if a lub or a maximum for Θ exists, then it is, of course, unique, because ⊑ is a partial order, so antisymmetric.
let ⊔Θ and max Θ be the lub and the max of Θ, respectively, when they exist.When Θ is finite, one may write If Θ has a maximum, then it also has a lub and ⊔Θ = max Θ.Here are several common properties that we use frequently in Sections 3.2 and 3.3 (these sections will present less known results with specific to our particular approach to parametric slicing and monitoring): Then (1) Θ has an upper bound iff for any θ 1 , θ 2 ∈ Θ and x ∈ X, if θ 1 (x) and θ 2 (x) are defined then θ 1 (x) = θ 2 (x); (2) If Θ has an upper bound then ⊔Θ exists and, for any x ∈ X, x ∈ X are such that θ 1 (x) and θ 2 (x) are defined then θ ′ (x) is also defined and θ 1 (x) = θ 2 (x) = θ ′ (x).Suppose now that for any θ 1 , θ 2 ∈ Θ and x ∈ X, if θ 1 (x) and θ 2 (x) are defined then θ 1 (x) = θ 2 (x).All we need to show in order to prove both results is that we can find a lub for Θ.Let θ ′ ∈ [X ⇁ V ] be defined as follows: for any x ∈ X, let First, θ ′ above is indeed well-defined, because we assumed that for any θ 1 , θ 2 ∈ Θ and x ∈ X, if θ 1 (x) and θ 2 (x) are defined then θ 1 (x) = θ 2 (x).Second, θ ′ is an upper bound for Θ: indeed, if θ ∈ Θ and x ∈ X such that θ(x) is defined, then θ ′ (x) is also defined and Proposition 3. The following hold: (1) The empty set of partial functions ∅ ⊆ [X ⇁ V ] has upper bounds and ⊔∅ = ⊥; (2) The one-element sets have upper bounds and ⊔{θ} = θ for any θ ∈ [X ⇁ V ]; (3) The bottom "⊥" does not influence the least upper bounds: then ⊔Θ exists and ⊔Θ ⊑ ⊔Θ ′ ; for example, if ⊔Θ ′ exists and Θ ⊆ Θ ′ then ⊔Θ exists and ⊔Θ ⊑ ⊔Θ ′ ; (5) Let {Θ i } i∈I be a family of sets of partial functions with Proof.1., 2. and 3. are straightforward.For 4., since for each θ ∈ Θ there is some θ ′ ∈ Θ ′ with θ ⊑ θ ′ , and since θ ′ ⊑ ⊔Θ ′ for any θ ′ ∈ Θ ′ , it follows that θ ⊑ ⊔Θ ′ for any θ ∈ Θ, that is, that ⊔Θ ′ is an upper bound for Θ.Therefore, by Proposition 2 it follows that ⊔Θ exists and ⊔Θ ⊑ ⊔Θ ′ (the latter because ⊔Θ is the least upper bound of Θ).We prove 5. by double implication, each implication stating that if one of the lub's exist then the other one also exists and one of the inclusions holds; that indeed implies that one of the lub's exists if and only if the other one exists and, if both exist, then they are equal.Suppose first that follows first that each Θ i also has u as an upper bound, so all ⊔Θ i for all i ∈ I exist, and second by 4. above that

3.2.
Least Upper Bounds of Families of Sets of Partial Maps.Motivated by requirements and optimizations of our trace slicing and monitoring algorithms in Sections 6 and 8, in this section and the next we define several less known notions and results.We are actually not aware of other places where these notions are defined, so they could be novel and specific to our approach to parametric trace slicing and monitoring.We first extend the notion of least upper bound (lub) from one associating a partial function to a set of partial functions to one associating a set of partial functions to a family (or set) of sets of partial functions: then we let the least upper bound (also lub) of {Θ i } i∈I be defined as: As before, we use the infix notation when I is finite, e.g., we may write Therefore, ⊔{Θ i | i ∈ I} is the set containing all the lub's corresponding to sets formed by picking for each i ∈ I precisely one element from Θ i .Unlike for sets of partial functions, the lub's of families of sets of partial functions always exist; ⊔{Θ i | i ∈ I} is the empty set when no collection of θ i ∈ Θ i can be found (one There is an admitted slight notational ambiguity between the two least upper bound notations introduced so far.We prefer to purposely allow this ambiguity instead of inventing a new notation for the lub's of families of sets, hoping that the reader is able to quickly disambiguate the two by checking the types of the objects involved in the lub: if partial functions then the first lub is meant, if sets of partial functions then the second.Note that such notational ambiguities are actually common practice elsewhere; e.g., in a monoid (M, * : M ×M → M, 1) with binary operation * and unit 1, the * is commonly extended to sets of elements M 1 , M 2 in M as expected: {⊔Θ} if Θ has a lub, and Proof.Recall that the least upper bound ⊔{Θ i | i ∈ I} of sets of sets of partial functions is built by collecting all the lubs of sets {θ i | i ∈ I} containing one element θ i from each of the sets Θ i .When |I| = 0, that is when I is empty, there is precisely one set {θ i | i ∈ I}, the empty set of partial functions.Then 1. follows by 1. in Proposition 3. When |I| = 1, that is when {Θ i | i ∈ I} = {Θ} for some Θ ⊆ [X ⇁ V ] like in 2., then the sets {θ i | i ∈ I} are precisely the singleton sets corresponding to the elements of Θ, so 2. follows by 2. in Proposition 3. 3. holds because there is only one way to pick an element from each singleton set {θ}, namely to pick the θ itself; this also shows how the notion of a lub of a family of sets generalizes the conventional notion of lub.When |I| ≥ 2 and at least one of the involved sets of partial functions is empty, like in 4., then there is no set {θ i | i ∈ I}, so the least upper bound of the set of sets is empty (regarded, again, as the empty set of sets of partial functions). 5. follows by 1. in Proposition 1.The first part of 6. is immediate and the second part follows from the first using 5.. Finally, 7. follows by double implication: Proof.For each j ∈ J, let Q j denote the set ⊔{Θ i j | i j ∈ I j }.Definition 4 then implies the following: Putting the two equalities above together, we get that ⊔{⊔{Θ i j | i j ∈ I j } | j ∈ J} equals the following: Since {I j } j∈J is a partition of I, the indexes i j generated by "for each j ∈ J and i j ∈ I j " cover precisely all the indexes i ∈ I.Moreover, picking partial functions θ i j ∈ Θ i j for each j ∈ J and i j ∈ I j is equivalent to picking partial functions θ i ∈ Θ i for each i ∈ I, and, in this case, Corollary 1.The following hold: (1) {⊥} ⊔ Θ = Θ (already proved as 5. in Proposition 4); Proof.These follow from Proposition 5 for various index sets I and partitions of it: for 1. take I = {1} and its partition I = ∅ ∪ I, take Θ 1 = Θ, and then use 1. in Proposition 4 saying that ⊔∅ = {⊥}; for 2. take partitions {1} ∪ {2} and {2} ∪ {1} of Proof.It follows easily from Definition 5, using the facts that ⊔∅ = ⊥ (1. in Proposition 3), ⊔{θ} = θ (2. in Proposition 3), and ⊔{⊥, θ} = θ (3. in Proposition 3 for Θ = {θ}).
4. Let θ be an arbitrary partial function in 5. Let Θ ′ be a set of partial functions included in ⊔{Θ i | i ∈ I} which admits an upper bound; moreover, for each in Proposition 3 it follows that ⊔Θ exists and ⊔Θ ′ = ⊔Θ.Since Θ = ∪{Θ ′ i | i ∈ I} and ⊔Θ exists, by 5. in Proposition 3 again we get that The proof above also implies that ⊔{Θ j | j ∈ I\{i}} is lub closed, so by 1. we get that ⊥ ∈ ⊔{Θ j | j ∈ I\{i}}.Finally, 6. in Proposition 4 implies 6. Recall from Definition 4 that ⊔{Θ i | i ∈ I} contains the existing least upper bounds of sets of partial functions containing precisely one partial function in each Θ i .If I and each of the Θ i for each i ∈ I is finite, then | ⊔ {Θ i | i ∈ I}| ≤ i∈I |Θ i |, because there at most i∈I |Θ i | combinations of partial functions, one in each Θ i , that admit an upper bound.Therefore, ⊔{Θ i | i ∈ I} is also finite.
7. Let Θ ′ ⊆ ∩{Θ i | i ∈ I} be a set of partial functions admitting an upper bound.Then Θ ′ ⊆ Θ i for each i ∈ I and, since each Θ i is lub closed, ⊔Θ ′ ∈ Θ i for each i ∈ I. Therefore, 8. Anticipating the definition of and notation for lub closures (Definition 5), we let Θ denote the set and, by 7., that Θ is lub closed.It is also the smallest lub closed set including Θ, because all such sets Θ ′ are among those whose intersection defines Θ.
be the set of partial functions in Θ that are less informative than θ ′ .
in obtaining that, we used 2. in Proposition 9 and 1. in Corollary 1.The result follows now by 6. in Proposition 7.

Parametric Traces and Properties
Here we introduce the notions of event, trace and property, first non-parametric and then parametric.Traces are sequences of events.Parametric events can carry data-values as instances of parameters.Parametric traces are traces over parametric events.Properties are trace classifiers, that is, mappings partitioning the space of traces into categories (violating traces, validating traces, don't know traces, etc.).Parametric properties are parametric trace classifiers and provide, for each parameter instance, the category to which the trace slice corresponding to that parameter instance belongs.Trace slicing is defined as a reduct operation that forgets all the events that are unrelated to the given parameter instance.
4.1.The Non-Parametric Case.We next introduce non-parametric events, traces and properties, which will serve as an infrastructure for their parametric variants in Section 4.2.Definition 8. Let E be a set of (non-parametric) events, called base events or simply events.An E-trace, or simply a (non-parametric) trace when E is understood or not important, is any finite sequence of events in E, that is, an element in E * .If event e ∈ E appears in trace w ∈ E * then we write e ∈ w.
Our parametric trace slicing and monitoring techniques in Sections 6 and 8 can be easily adapted to also work with infinite traces.Since infinite versus finite traces is not an important aspect of the work reported here, we keep the presentation free of unnecessary technical complications and consider only finite traces.
Example.(part 1 of simple running example) Like in Section 2.1, consider a certain resource (e.g., a synchronization object) that can be acquired and released during the lifetime of a given procedure (between its begin and end).Then the set of events E is {acquire, release, begin, end} and execution traces corresponding to this resource are sequences begin acquire acquire release end begin end, begin acquire acquire, begin acquire release acquire end, etc.For the time being, there are no "good" or "bad" execution traces.
There is a plethora of formalisms to specify trace requirements.Many of these result in specifying at least two types of traces: those validating the specification (i.e, correct traces), and those violating the specification (i.e., incorrect traces).stating that the procedure can (non-recursively) take place multiple times and, if the resource is acquired during the procedure then it is released by the end of the procedure.Assume that the resource can be acquired and released multiple times, with the effect of acquiring and respectively releasing it precisely once.The validating (or matching) traces for this property are those satisfying the pattern, e.g., begin acquire acquire release end begin end.
At first sight, one may say that all the other traces are violating (or failing) traces, because they are not in the language of the regular expression.However, there are two interesting types of such "failing" traces: ones which may still lead to a matching trace provided the right events will be received in the future, e.g., begin acquire acquire, and ones which have no chance of becoming a matching trace, e.g., begin acquire release acquire end.
In general, traces are not enforced to correspond to terminated programs (this is particularly useful in monitoring); if one wants to enforce traces to correspond to terminated programs, then one can have the system generate a special end-of-trace event and have the property specification require that event at the end of each trace.
Therefore, a trace property may partition the space of traces into more than two categories.For some specification formalisms, for example ones based on fuzzy logics or multiple truth values, the set of traces may be split into more than three categories, even into a continuous space of categories.Section 2.6 showed an example of a property where the space of trace categories was the set of rational numbers between 0 and 1. Definition 9.An E-property P , or simply a (base or non-parametric) property, is a function P : E * → C partitioning the set of traces into (verdict) categories C.
It is common, though not enforced, that the set of property verdict categories C in Definition 9 includes validating (or similar), violating (or similar), and don't know (or ?) categories.In general, C can be any set, finite or infinite.
We believe that the definition of non-parametric trace property above is general enough that it can easily accommodate any particular specification formalism, such as ones based on linear temporal logics, regular expressions, context-free grammars, etc.All one needs to do in order to instantiate the general results in this paper for a particular specification formalism is to decide upon the desired categories in which traces are intended to be classified, and then define the property associated to a specification accordingly.
For example, if the specification formalism of choice is that of regular expressions over E and one is interested in classifying traces in three categories as in our example above, then one can pick C to be the set {match, fail, don't know} and, for a given regular expression E, define its associated property P E : E * → C as follows: P E (w) = match iff w is in the language of E, P E (w) = fail iff there is no w ′ ∈ E * such that w w ′ is in the language of E, and P E (w) = don't know otherwise; this is the monitoring semantics of regular expressions in the JavaMOP and RV systems [28,14,27].
Other semantic choices are possible even for the simple case of regular expressions; for example, one may choose C to be the set {match, don't care} and define P E (w) = match iff w is in the language of E, and P E (w) = don't care otherwise; this is the semantics of regular expressions in Tracematches [1], where, depending upon how one writes the regular expression, matching can mean either a violation or a validation of the desired property.
Similarly, one can have various verdict categories for linear temporal logic (LTL).For example, one can report violation when a bad prefix is encountered, can report validation when a good prefix is encountered, and can report inconclusive when neither of the above; this is the current monitoring semantics of monitoring LTL in JavaMOP and RV [28,27].Semantical and algorithmic aspects regarding LTL monitoring can be found, e.g., in [21,32,33,7].
In some applications, one may not be interested in certain categories of traces, such as in those classified as don't know, don't care, or inconclusive; if that is the case, then those applications can simply ignore these, like Tracematches, JavaMOP and RV do.It may be worth making it explicit that in this paper we do not attempt to propose or promote any particular formalism for specifying properties about execution traces.Instead, our approach is to define properties as generally as possible to capture the various specification formalisms that we are aware of as special cases, and then to develop our subsequent techniques to work with such general properties.We believe that our definition of property in Definition 9 is general enough to allow us to claim that our results are specification-formalism-independent.
An additional benefit of defining properties so generally, as mappings from traces to categories, is that parametric properties, in spite of their much more general flavor, are also properties (but, obviously, over different traces and over different categories).Example.(part 3) In our running example, events acquire and release are parametric in the resource being acquired or released; if r is the name of the generic resource parameter and r 1 and r 2 are two concrete resources, then parametric acquire/release events have the form acquire r → r 1 , release r → r 2 , etc.Not all events need carry instances for all parameters; e.g., the begin/end parametric events have the form begin ⊥ and end ⊥ , where ⊥, the partial map undefined everywhere, instantiates no parameter.
Recall from Definition 1 that [A → B] and [A ⇁ B] denote the sets of total and, respectively, partial functions from A to B. Definition 10. (Parametric events and traces).Let X be a set of parameters and let V be a set of corresponding parameter values.If E is a set of base events like in Definition 8, then let E X denote the set of corresponding parametric events e θ , where e is a base event in E and θ is a partial function in [X ⇁ V ].A parametric trace is a trace with events in E X , that is, a word in E X * .Therefore, a parametric event is an event carrying values for zero, one, several or even all the parameters, and a parametric trace is a finite sequence of parametric events.In practice, the number of values carried by an event is finite; however, we do not need to enforce this restriction in our theoretical developments.Also, in practice the parameters may be typed, in which case the set of their corresponding values is given by their type.To simplify writing, we occasionally assume the set of parameter values V implicit.
Example.(part 4) A parametric trace for our running example can be the following: begin ⊥ acquire θ 1 acquire θ 2 acquire θ 1 release θ 1 end ⊥ begin ⊥ acquire θ 2 release θ 2 end ⊥ , where θ 1 maps r to r 1 and θ 2 maps r to r 2 .To simplify writing, we take the freedom to only list the parameter instance values when writing parameter instances, that is, r 1 instead of r → r 1 , or τ↾ r 2 instead of τ↾ r →r 2 , etc.This notation is formally introduced in the next section, as Notation 1.With this notation, the above trace becomes begin acquire r 1 acquire r 2 acquire r 1 release r 1 end begin acquire r 2 release r 2 end .This trace involves two resources, r 1 and r 2 , and it really consists of two trace slices, one for each resource, merged together.The begin and end events belong to both trace slices.The slice corresponding to θ 1 is begin acquire acquire release end begin end, while the one for θ 2 is begin acquire end begin acquire release end.
Recall from Definition 1 that two partial maps of same source and target are compatible when they do not disagree on any of the elements on which they are both defined, and that one is less informative than another, written θ ⊑ θ ′ , when they are compatible and the domain of the former in included in the domain of the latter.With the notation in the example above we have, for our running example, that is compatible with r 1 and with r 2 , but r 1 and r 2 are not compatible; moreover, ⊑ r 1 and ⊑ r 2 .
Definition 11. (Trace slicing) Given parametric trace τ ∈ E X * and partial function θ in [X ⇁ V ], we let the θ-trace slice τ↾ θ ∈ E * be the non-parametric trace in E * defined as: • ǫ↾ θ = ǫ, where ǫ is the empty trace/word, and Therefore, the trace slice τ↾ θ first filters out all the parametric events that are not relevant for the instance θ, i.e., which contain instances of parameters that θ does not care about, and then, for the remaining events relevant to θ, it forgets the parameters so that the trace can be checked against base, non-parametric properties.It is crucial to discard parameter instances that are not relevant to θ during the slicing, including those more informative than θ, in order to achieve a correct slice for θ: in our running example, the trace slice for should contain only begin and end events and no acquire or release.Otherwise, the acquire and release of different resources will interfere with each other in the trace slice for .
One should not confuse extracting/abstracting traces from executions with slicing traces.The former determines the events to include in the trace, as well as parameter instances carried by events, while the latter dispatches each event in the given trace to corresponding trace slices according to the event's parameter instance.Different abstractions may result in different parametric traces from the same execution and thus may lead to different trace slices for the same parameter instance θ.For the (map, collection, iterator) example in Section 1, X = {m, c, i} and an execution may generate the following parametric trace: createColl m 1 , c 1 createIter c 1 , i 1 next i 1 updateMap m 1 .The trace slice for m 1 is updateMap for this parametric trace.Now suppose that we are only interested in operations on maps.Then X = {m} and the trace abstracted from the execution generating the above trace is createColl m 1 updateMap m 1 , in which events and parameter bindings irrelevant to m are removed.Then the trace slice for m 1 is createColl updateMap.In this paper we focus only on trace slicing; more discussion about trace abstraction can be found in [15].
Specifying properties over parametric traces is rather challenging, because one may want to specify a property for one generic parameter instance and then say "and so on for all the other instances".In other words, one may want to specify a sort of a universally quantified property over base events, but, unfortunately, the underlying specification formalism may not allow such quantification over data; for example, none of the conventional formalisms to specify properties on linear traces listed above (i.e,linear temporal logics, regular expressions, context-free grammars) or mentioned in the rest of the paper has data quantification by default.We say "by default" because, in some cases, there are attempts to add data quantification; for example, [23] investigates the implications and the necessary restrictions resulting from adding quantifiers to LTL, and [33] investigates a finite-trace variant of parametric LTL together with a translation to parametric alternating automata.Definition 12. Let X be a set of parameters together with their corresponding parameter values V , like in Definition 10, and let P : E * → C be a non-parametric property like in Definition 9. Then we define the parametric property ΛX .P as the property (over traces defined as (ΛX .P )(τ )(θ) = P (τ↾ θ ) for any τ ∈ E X * and any θ ∈ [X ⇁ V ].If X = {x 1 , ..., x n } we may write Λx 1 , ..., x n .P instead of (Λ{x 1 , ..., x n } .P .Also, if P ϕ is defined using a pattern or formula ϕ in some particular trace specification formalism, we take the liberty to write ΛX .ϕ instead of ΛX .P ϕ .
Parametric properties ΛX .P over base properties P : E * → C are therefore properties taking traces in E X * to categories [[X ⇁ V ] → C], i.e., to function domains from parameter instances to base property categories.ΛX .P is defined as if many instances of P are observed at the same time on the parametric trace, one property instance for each parameter instance, each property instance concerned with its events only, dropping the unrelated ones.
Example.(part 5) Let P be the non-parametric property specified by the regular expression in the second part of our running example above (using the mapping of regular expressions to properties discussed in the second part of our running example and after Definition 9 -i.e., the JavaMOP/RV semantic approach to parametric monitoring [14]).Since we want P to hold for any resource instance, we define the following parametric property: If τ is the parametric trace and θ 1 and θ 2 are the parameter instances in the fourth part of our running example, then the semantics of the parametric property above on trace τ is validating for parameter instance θ 1 and violating for parameter instance θ 2 .

Slicing With Less
Consider a parametric trace τ in E X * and a parameter instance θ.Since there is no apriori correlation between the parameters being instantiated by θ and those by the various parametric events in τ , it may very well be the case that θ contains parameter instances that never appear in τ .In this section we show that slicing τ by θ is the same as slicing it by a "smaller" parameter instance than θ, namely one containing only those parameters instantiated by θ that also appear as instances of some parameters in some events in τ .Formally, this smaller parameter instance is the largest partial map smaller than θ in the lub closure of all the parameter instances of events in τ ; this partial function is proved to indeed exist.We first formalize a notation used informally so far in this paper: Notation 1.When the domain of θ is finite, which is always the case in our examples in this paper and probably will also be the case in most practical uses of our trace slicing algorithm, and when the corresponding parameter names are clear from context, we take the liberty to write partial functions compactly by simply listing their parameter values; for example, we write a partial function θ with θ(a) = It may be the case that some of the base events appearing in a trace are the same; for example, e 1 may be equal to e 2 and to e 5 .It is actually frequently the case in practice (at least in PQL [25], Tracematches [1], JavaMOP [14] and RV [27]) that parametric events are specified apriori with a given (sub)set of parameters, so that each event in E is always instantiated with partial functions over the same domain, i.e., if e θ and e θ ′ appear in a parametric trace, then Dom(θ) = Dom(θ ′ ).While this restriction is reasonable and sometimes useful, our trace slicing and monitoring algorithms in this paper do not need it.
Recall from Definition 11 that the trace slice τ ↾ θ keeps from τ only those events that are relevant for θ and drops their parameters.In order for the partial functions above to make sense, we assumed that the set V in which parameters X = {a, b, c} take values includes {a 1 , a 2 , b 1 , c 1 }.
Definition 13.Given parametric trace τ ∈ E X * , we let Θ τ denote the lub closure of all the parameter instances appearing in events in τ , that is, Proposition 12.For any parametric trace τ ∈ E X * , the set Θ τ is a finite lub closed set.
Proof.Θ τ is already defined as a lub closed set; since τ is finite, Corollary 3 implies that Θ τ is finite.
Proof.It follows by the following sequence of equalities: The first equality follows by Definition 13, the second by separating the case e ′ θ ′ = e θ , the third again by Definition 13, the fourth by Corollary 2, and the fifth by Proposition 12. Therefore, Θ τ e θ is the smallest lub closed set that contains θ and includes Θ τ .
Alternatively, one could have also done the proof above by induction on τ , not on its length, but the proof would be more involved, because one would need to prove that the domain over which the property is universally quantified, namely "any τ ∈ E X * with Θ τ ⊆ Θ" is inductively generated.We therefore preferred to choose a more elementary induction schema.

Algorithm for Online Parametric Trace Slicing
Definition 11 illustrates a way to slice a parametric trace for given parameter bindings.However, it is not suitable for online trace slicing, where the trace is observed incrementally and no future knowledge is available, because we cannot know all possible parameter instances θ apriori.We next define an algorithm A X that takes a parametric trace τ ∈ E X * incrementally (i.e., event by event), and builds a partial function T ∈ [[X ⇁ V ] ⇁ E * ] of finite domain that serves as a quick lookup table for all slices of τ .More precisely, Theorem 1 shows that, for any θ ∈ [X ⇁ V ], the trace slice τ↾ θ is T(max (θ] Θ ) after A X processes τ , where Θ = Θ τ is the domain of T, a finite lub closed set of partial functions also calculated by A X incrementally (see Definition 13 for Θ τ ).Therefore, assuming that A X is run on trace τ , all one has to do in order to calculate a slice τ ↾ θ for a given θ ∈ [X ⇁ V ] is to calculate max (θ] Θ followed by a lookup into T.This way the trace τ , which can be very long, is processed/traversed only once, as it is being generated, and appropriate data-structures are maintained by our algorithm that allow for retrieval of slices for any parameter instance θ, without having to traverse the trace τ again, as an algorithm blindly following the definition of trace slicing (Definition 11) would do.
Figure 2 shows our trace slicing algorithm A X .In spite of A X 's small size, its proof of correctness is surprisingly intricate, making use of almost all the mathematical machinery developed so far in the paper.The algorithm A X on input τ , written more succinctly A X (τ ), traverses τ from its first event to its last event and, for each encountered event e θ , updates both its data-structures, T and Θ.After processing each event, the relationship between T and Θ is that the latter is the domain of the former.Line 1 initializes the datastructures: T is undefined everywhere (i.e., ⊥) except for the undefined-everywhere function ⊥, where T(⊥) = ǫ; as expected, Θ is then initialized to the set {⊥}.The code (lines 3 to 6) inside the outer loop (lines 2 to 7) can be triggered when a new event is received, as in most online runtime verification systems.When a new event is received, say e θ , the mapping T is updated as follows: for each θ ′ ∈ [X ⇁ V ] that can be obtained by combining θ with the compatible partial functions in the domain of the current T, update T(θ ′ ) by adding the non-parametric event e to the end of the slice corresponding to the largest (i.e., most "knowledgeable") entry in the current table T that is less informative or as informative as θ ′ ; the Θ data-structure is then extended in line 6 (see Proposition 13 for why this way).
Example.Consider again the sample trace in Section 5 with events parametric in {a, b, c}, namely τ = e 1 a 1 e 2 a 2 e 3 b 1 e 4 a 2 b 1 e 5 a 1 e 6 e 7 b 1 e 8 c 1 e 9 a 2 c 1 e 10 a 1 b 1 c 1 e 11 .Table 1 shows how A X works on τ .An entry of the form θ : w in a table cell corresponding to a current parametric event e θ means that T(θ) = w after processing all the parametric events up to and including the current one; T is undefined on any other partial function.Obviously, the Θ corresponding to a cell is the union of all the θ's that appear in pairs θ : w in that cell.Note that, as each parametric event e θ is processed, the non-parametric event e is added at most once to each slice, and that Θ stays lub closed.
A X computes trace slices for all combinations of parameter instances observed in parametric trace events.Its complexity is therefore O(n × m) where n is the length of the trace and m is the number of all possible parameter combinations.However, A X is not intended to be implemented directly; it is only used as a correctness backbone for other trace analysis algorithms, such as the monitoring algorithms discussed below.An alternative and apparently more efficient solution is to only record trace slices for parameter instances that actually appear in the trace (instead of for all combinations of them), and then construct the slice for a given parameter instance by combining such trace slices for compatible parameter instances.However, the complexity of constructing all possible trace slices at the end using such an algorithm is also O(n × m), so it would not bring any benefit overall compared to A X .In addition, A X is more suitable as a backbone for developing online monitoring algorithms such as those in Section 7, because each event is sent to its slices (that will be consumed by corresponding monitors) and never touched again.A X compactly and uniformly captures several special cases and subcases that are worth discussing.The discussion below can be formalized as an inductive (on the length of τ ) proof of correctness for A X , but we prefer to keep this discussion informal and give a rigorous proof shortly after.The role of this discussion is twofold: (1) to better explain the algorithm A X , providing the reader with additional intuition for its difficulty and compactness, and (2) to give a proof sketch for the correctness of A X .
Let us first note that a partial function added to Θ will never be removed from Θ; that's because Θ ⊆ {⊥, θ} ⊔ Θ.The same holds true for the domain of T, because line 4 can only add new elements to Dom(T); in fact, the domain of T is extended with precisely the set {θ} ⊔ Θ after each event parametric in θ is processed by A X .Moreover, since Dom(T) = Θ = Θ ǫ = {⊥} initially and since 5. and 7. in Proposition 4 imply Θ∪({θ}⊔Θ) = {⊥, θ} ⊔ Θ while Proposition 13 states that Θ τ e θ = {⊥, θ} ⊔ Θ τ , we can inductively show that Dom(T) = Θ = Θ τ each time after A X is executed on a parametric trace τ .
A tricky observation which is crucial for this is that 3. in Proposition 8 implies that the updates of T(θ ′ ) do not interfere with each other for different θ ′ ∈ {θ} ⊔ Θ; otherwise the non-parametric event e may wrongly be added multiple times to some trace slices T(θ ′ ).
Let us next informally argue, inductively, that it is indeed the case that T(θ ′ ) = τ↾ θ ′ after T(θ ′ ) is updated in line 4 (it vacuously holds on the empty trace).Since max (θ ′ ] Θ ∈ Θ, the inductive hypothesis tells us that T(max (θ ′ ] Θ ) = τ↾ max (θ ′ ] Θ ; these are further equal to τ↾ θ ′ by Proposition 14.Since θ ⊑ θ ′ , the definition of trace slicing implies that (τ e θ )↾ θ ′ = τ↾ θ ′ e.Therefore, T(θ ′ ) is indeed (τ e θ )↾ θ ′ after line 4 of A X is executed while processing the event e θ that follows trace τ .This concludes our informal proof sketch; let us next give a rigorous proof of correctness for our trace slicing algorithm A X .Definition 14.Let A X (τ ).T and A X (τ ).Θ be the two data-structures (T and Θ) maintained by the algorithm A X in Figure 2 after it processes τ .Theorem 1.With the notation in Definition 14, the following hold for any τ ∈ E X * : (1) Proof.Since A X processes the events in the input trace in order, when given the input τ e θ , the Θ and T structures after A X processes τ but before it processes e θ (i.e., right before the last iteration of the loop at lines 2-7) are precisely A X (τ ).Θ and A X (τ ).T, respectively.Further, the loop at lines 3-5 updates T on all θ ′ ∈ {θ} ⊔ Θ; in case T was not defined on such a θ ′ , then it will be defined after e θ is processed.The definitional domain of T is thus continuously growing or potentially remains stationary as parametric events are processed, but it never decreases.With these observations, we can prove 1. by induction on τ .If τ = ǫ then Dom(A X (ǫ).T) = A X (ǫ).Θ = Θ ǫ = {⊥}.Suppose now that Dom(A X (τ ).T) = A X (τ ).Θ = Θ τ holds for τ ∈ E X * , and let e θ ∈ E X be any parametric event.Then the following concludes the proof of 1.: where the first equality follows from how the loop at lines 3-5 updates T, the second by the induction hypothesis, the third by 5. in Proposition 4, the fourth by 7. in Proposition 4, the fifth by how Θ is updated at line 6, the sixth again by the induction hypothesis, and, finally, the seventh by Proposition 13.Before we continue, let us first prove the following property: for any e θ ∈ E X and any θ ′ ∈ {θ} ⊔ A X (τ ).Θ.One should be careful here to not get tricked thinking that this property is straightforward, because it says only what line 4 of A X does.The complexity comes from the fact that if there were two different θ 1 , θ 2 ∈ {θ} ⊔ A X (τ ).Θ such that θ 1 = max (θ 2 ] A X (τ ).Θ , then an unfortunate enumeration of the partial functions θ ′ in {θ} ⊔ A X (τ ).Θ by the loop at lines 3-5 may lead to the non-parametric event e to be added twice to a slice: indeed, if θ 1 is processed before θ 2 , then e is first added to the end of T(θ 1 ) when θ ′ = θ 1 , and then T(θ 1 ) e is assigned to T(θ 2 ) when θ ′ = θ 2 ; this way, T(θ 2 ) ends up accumulating e twice instead of once, which is obviously wrong.Fortunately, since A X (τ ).Θ is lub closed (by 1. above and Proposition 12), 3. in Proposition 8 implies that there are no such different θ 1 , θ 2 ∈ {θ} ⊔ A X (τ ).Θ.Therefore, there is no interference between the various assignments at line 4, regardless of the order in which the partial functions θ ′ ∈ {θ} ⊔ Θ are enumerated, which means that, indeed, A X (τ e θ ).T(θ ′ ) = A X (τ ).T(max (θ ′ ] A X (τ ).Θ ) e for any e θ ∈ E X and for any θ ′ ∈ {θ} ⊔ A X (τ ).Θ.This lack of interference between updates of T also suggests an important implementation optimization: The loop at lines 3-5 can be parallelized without duplicating the table T! Of course, the loop can be parallelized anyway if the table is duplicated and then merged within the original table, in the sense that all the writes to T(θ ′ ) are done in a copy of T. However, experiments show that the table T can be literally huge in real applications, in the order of billions of entries, so duplicating and merging it can be prohibitive.
3. is the main result concerning our trace slicing algorithm and it follows now easily: The first equality follows by Proposition 14, the second equality by 1. above, and the third equality by 2. above, because max (θ] A X (τ ).Θ ∈ A X (τ ).Θ.This concludes the correctness proof of our trace slicing algorithm A X .
G. ROS ¸U AND F. CHEN

Monitors and Parametric Monitors
In this section we first define monitors M as a variant of Moore machines with potentially infinitely many states; then we define parametric monitors ΛX .M as monitors maintaining one state of M per parameter instance.Like for parametric properties, which turned out to be just properties over parametric traces, we show that parametric monitors are also just monitors, but for parametric events and with instance-indexed states and output categories.
We also show that a parametric monitor ΛX .M is a monitor for the parametric property ΛX .P , with P the property monitored by M .
7.1.The Non-Parametric Case.We start by defining non-parametric monitors as a variant of (deterministic) Moore machine [29] that allows infinitely many states: , where S is a set of states, E is a set of input events, C is a set of output categories, ι ∈ S is the initial state, σ is the transition function, and γ is the output function.The transition function is extended to σ : S × E * → S as expected: σ(s, ǫ) = s and σ(s, we) = σ(σ(s, w), e) for any s ∈ S, e ∈ E, and w ∈ E * .
The notion of a monitor above is rather conceptual.Actual implementations of monitors need not generate all the state space apriori, but on a "by need" basis.Consider, for example, a monitor for a property specified using an NFA which performs an NFA-to-DFA construction on the fly, as events are received.Such a monitor generates only those states in the DFA that are needed by the monitored execution trace.Moreover, the monitor only needs to store one such state of the DFA, i.e., set of states in the NFA, namely the current one: once an event is received, the next state is (deterministically) computed and the old one is discarded.Therefore, assuming that one needs constant space to store a state of the original NFA, then the memory needed by this monitor is linear in the number of states of the NFA.An alternative and probably more conventional monitor could be one which generates the corresponding DFA statically, paying upfront the exponential price in both time and space.As empirically suggested by [35], if one is able to statically generate and store the corresponding DFA then one should most likely take this route, because in practice it tends to be much faster to jump to a known next state than to compute it.
Allowing monitors with infinitely many states is a necessity in our context.Even though only a finite number of states is reached during any given (finite) execution trace, there is, in general, no bound on how many states are reached.For example, monitors for context-free grammars like the ones in [26] have potentially unbounded stacks as part of their state.Also, as shown shortly, parametric monitors have domains of functions as state spaces, which are infinite as well.Nevertheless, what is common to all monitors is that they can classify traces into categories.When a monitor does not have enough information about a trace to put it in a category of interest, we can assume that it actually categorizes it as a "don't know" trace, where "don't know" can be regarded as a special category; this is similar to regarding partial functions as total functions by adding a special "undefined" value in their codomain.The following is therefore natural: Definition 16.Monitor M = (S, E, C, ι, σ, γ) is a monitor for property P : E * → C if and only if γ(σ(ι, w)) = P (w) for each w ∈ E * .
A property can be associated to each monitor, in a similar style to which we can associate a language to each automaton: Definition 17. Monitor M = (S, E, C, ι, σ, γ) defines the M -property P M : E * → C as follows: P M (w) = γ(σ(ι, w)) for each w ∈ E * .
The following result is straightforward, it follows immediately from Definitions 16 and 17.The only reason we frame it as a numbered proposition is because we need to refer to it in the proof of Corollary 5.
Proposition 15.With the notation in Definition 17, monitor M is indeed a monitor for its corresponding M -property P M .Moreover, a monitor can only be a monitor for one property, that is, if M is a monitor for property P then P = P M .
Since we allow monitors to have infinitely many states, there is a strong correspondence between properties and monitors: Definition 18. Property P : E * → C defines the P -monitor M P = (S P , E, C, ι P , σ P , γ P ) as follows: S P = E * , ι P = ǫ, σ P (w, e) = we for each w ∈ S P = E * and e ∈ E, γ P (w) = P (w) for each w ∈ S P = E * .
Thus, M P w holds traces as states, appends events to them as transition and, as output, it looks up the category of the corresponding trace using P .The following results are also straightforward and, again, we frame them as numbered propositions only because we will refer to them later.
Proposition 16.With the notation in Definition 18, the monitor M P is indeed a monitor for property P .
Proposition 17.With the notations in Definitions 17 and 18, P M P = P for any property P : E * → C.
The equality of monitors M P M = M does not hold for any monitor M ; it does hold when M = M P for some property P , though.Proof.By Definition 19, M P M ≡ M iff P M P M = P M , and the latter follows by Proposition 16 taking P to be P M .7.2.The Parametric Case.We next define parametric monitors in the same style as the other parametric entities defined in this paper: starting with a base monitor and a set of parameters, the corresponding parametric monitor can be thought of as a set of base monitors running in parallel, one for each parameter instance.Definition 20.Given parameter set X with corresponding values V and a monitor M = (S, E, C, ι, σ : S × E → S, γ : S → C), we define the parametric monitor ΛX .M as the monitor Therefore, a state δ of parametric monitor ΛX .M maintains a state δ(θ) of M for each parameter instance θ, takes parametric events as input, and outputs categories indexed by parameter instances (one output category of M per parameter instance).Proposition 19.If M is a monitor for P then parametric monitor ΛX .M is a monitor for parametric property ΛX .P , or, with the notation in Definition 17, P ΛX .M = ΛX .P M .
// a message may be output here 6 . . .We next propose two monitoring algorithms for parametric properties.Our unoptimized but easier to understand algorithm is easily derived from the parametric trace slicing algorithm in Figure 2. Our second algorithm is an online optimization of the first, which significantly reduces the size of the search space for compatible parameter instances when a new event is received.
8.1.Unoptimized but Simpler Algorithm.Analyzing the definition of a parametric monitor (Definition 20), the first thing we note is that its state space is not only infinite, but it is not even enumerable.Therefore, a first challenge in monitoring parametric properties is how to represent the states of the parametric monitor.Inspired by the algorithm for trace slicing in Figure 2, we encode functions [[X ⇁ V ] ⇁ S] as tables with entries indexed by parameter instances in [X ⇁ V ] and with contents states in S. Following similar arguments as in the proof of the trace slicing algorithm, such tables will have a finite number of entries provided that each event instantiates only a finite number of parameters.Figure 3 shows our monitoring algorithm for parametric properties.Given parametric property ΛX .P and M a monitor for P , B X (M ) yields a monitor that is equivalent to ΛX .M , that is, a monitor for ΛX .P .Section 9 shows one way to use this algorithm: a monitor M is first synthesized from the base property P , then that monitor M is used to synthesize the monitor B X (M ) for the parametric property ΛX .P .B X (M ) follows very closely the algorithm for trace slicing in Figure 2, the main difference being that trace slices are processed, as generated, by M : instead of calculating the trace slice of θ ′ by appending base event e to the corresponding existing trace slice in line 4 of A X , we now calculate and store in table ∆ the state of the monitor instance corresponding to θ ′ by sending e to the corresponding existing monitor instance (line 4 in B X (M )); at the same time we also calculate the output corresponding to that monitor instance and store it in table Γ.In other words, we replace trace slices in A X by local monitors processing online those slices.In our implementation in Section 9, we also check whether Γ(θ ′ ) at line 5 violates the property and, if so, an error message including θ ′ is output to the user.3 for efficient online monitoring.Since no complete trace is given in online monitoring, C X focuses on actions to carry out when a parametric event e θ arrives; in other words, it essentially expands the body of the outer loop in B X (lines 3 to 7 in Figure 3).The direct use of B X would yield prohibitive runtime overhead when monitoring large traces, because its inner loop requires search for all parameter instances in Θ that are compatible with θ; this search can be very expensive.C X introduces an auxiliary data structure and illustrates a mechanical way to accomplish the search, which also facilitates further optimizations.While B X did not require that θ in e θ be of finite domain, C X needs that requirement in order to terminate.Note that in practice Dom(θ) is always finite (because the program state is finite).C X uses three tables: ∆, U and Γ. ∆ and Γ are the same as ∆ and Γ in B X , respectively.U is an auxiliary data structure used to optimize the search "for all θ ′ ∈ {θ} ⊔ Θ" in B X (line 3 in Figure 3).It maps each parameter instance θ into the finite set of parameter instances encountered in ∆ so far that are strictly more informative than θ, i.e., U (θ) = {θ ′ | θ ′ ∈ Dom(∆) and θ ⊏ θ ′ }.Another major difference between B X and C X is that C X does not maintain Θ during computation; instead, Θ is implicitly captured by the domain of ∆ in C X .Intuitively, the Θ at the beginning/end of the body of the outer loop in B X is the Dom(∆) at the beginning/end of C X , respectively.However, Θ is fixed during the loop at lines 3 to 6 in B X and updated atomically in line 7, while Dom(∆) can be changed at any time during the execution of C X .
C X is composed of two functions, main and defineTo.The defineTo function takes two parameter instances, θ and θ ′ , and adds a new entry corresponding to θ into ∆ and U .Specifically, it sets ∆(θ) to ∆(θ ′ ) and adds θ into the set U (θ ′′ ) for each θ ′′ ⊏ θ.
The main function differentiates two cases when a new event e θ is received and processed.The simpler case is that ∆ is already defined on θ, i.e., θ ∈ Θ at the beginning of the iteration of the outer loop in B X .In this case, {θ} ⊔ Θ = {θ ′ | θ ′ ∈ Θ and θ ⊑ θ ′ } ⊆ Θ, so the lines 3 to 6 in B X become precisely the lines 16 to 19 in C X .In the other case, when ∆ is not already defined on θ, main takes two steps to handle e.The first step searches for new parameter instances introduced by {θ} ⊔ Θ and adds entries for them into ∆ (lines 2 to 14).We first add an entry to ∆ for θ at lines 2 to 7. Then we search for all parameter instances θ comp that are compatible with θ, making use of U (lines 8 and 9); for each such θ comp , an appropriate entry is added to ∆ for its lub with θ, and U updated accordingly (lines 10 to 12).This way, ∆ will be defined on all the new parameter instances introduced by {θ} ⊔ Θ after the first step.In the second step, the related monitor states and outputs are updated in a similar way as in the first case (lines 16 to 19).It is interesting to note how C X searches at lines 2 and 8 for the parameter instance max (θ] Θ that B X refers to at line 4 in Figure 3: it enumerates all the θ max ⊏ θ in reversed topological order (from larger to smaller); 1. in Proposition 8 guarantees that the maximum exists and, since it is unique, our search will find it.
Correctness of C X .We prove the correctness of C X by showing that it is equivalent to the body of the outer loop in B X .Suppose that parametric trace τ has already been processed by both C X and B X , and a new event e θ is to be processed next.
Let us first note that C X terminates if Dom(θ) is finite.Indeed, if Dom(θ) is finite then there is only a finite number of partial maps less informative than θ, that is, only a finite number of iterations for the loops at lines 2 and 8 in main; since U is only updated at line 3 in defineTo, U (θ) is finite for any θ ∈ [X ⇁ V ] and thus the loop at line 9 in main also terminates.Assuming that running the base monitor M takes constant time, the worst case complexity of C X (M ) is O(k × l) to process e θ , where k is 2 |Dom(θ)| and l is the number of incompatible parameter instances in τ .Parametric properties often have a fixed and small number of parameters, in which case k is not significant.Depending on the trace, l can unavoidably grow arbitrarily large; in the worst case, each event may carry an instance incompatible with the previous ones.
The next theorem proves the correctness of C X .Before we state and prove it, let us recall some previously introduced notation and also introduce some new useful notation.First, recall from Definition 21 that B X (M )(τ ).∆ and B X (M )(τ ).Γ are the ∆ and Γ data-structures of B X (M ) after it processes trace τ .Also, recall that we fixed parametric trace τ and event e θ .For clarity, let U C , ∆ C , and Γ C be the three data-structures maintained by C X (M ) (in other words, we index the data-structures with the symbol C).(a) For line 7, the loop at lines 2 to 6 checks all the parameter instances that are less informative than θ to find the first one in Θ C in reversed topological order (i.e., if θ 1 ⊏ θ 2 then θ 2 will be checked before θ 1 ).Since by 1. in Proposition 8 we know that max (θ] Θ C ∈ Θ C exists (and it is unique), the loop at lines 2 to 6 will break precisely when θ max = max (θ] Θ C , so the result holds when θ ′ = θ because of the entry introduced for θ in ∆ C at line 7 and because the remaining lines 8 to 14 do not change ∆ C (θ).
(b) When ∆ C (θ ′ ) is set at line 11, note that the loop at lines 8 to 14 also iterates over all θ max ⊏ θ in reversed topological order, so θ ′ = θ comp ⊔ θ for some θ comp ∈ Θ C compatible with θ such that θ max ⊏ θ comp , where θ max ⊏ θ is such that there is no other θ ′ max with We claim that there is only one such θ comp , which is precisely max (θ ′ ] Θ C : Let θ ′ comp be the parameter instance max (θ ′ ] Θ C .The above implies that that is, the largest with θ ′ max ⊑ θ ′ comp and θ ′ max ⊑ θ (we let its existence as exercise).It is relatively easy to see now that θ comp ⊏ θ ′ comp implies θ max ⊏ θ ′ max (we let it as an exercise, too), which contradicts the assumption of this case that ∆ C was not defined on θ ′ .Therefore, θ comp = max (θ ′ ] Θ C before line 11 is executed, which means that, after line 11 is executed, ∆ C (θ ′ ) = ∆ C (max (θ ′ ] Θ C ); moreover, none of these will be changed anymore until line 16 is reached, which proves our result.
3. Since Γ is updated according to ∆ in both C X and B X , it is enough to prove that ∆ e C = ∆ B (τ e).For B X , we have 1) So we only need to prove that 1) We conclude this section with a discussion on the complexity of the parametric monitoring algorithms A X and C X above.Note that, in the worst case, to process a newly received parametric event e θ after A X or C X has already processed a parametric trace τ , each of A X or C X takes at least linear time/space in the number of θ-compatible parameter instances occurring in events in τ .Indeed, A X iterates explicitly through all such parameter instances (line 3 in Figure 3), while C X optimizes this traversal by only enumerating through maximal parameter instances; in the worst case, we can assume that τ is such that each event comes with a new parameter instance which is maximal, so in the worst case A X and C X can take linear time/space in τ to process e θ , which is, nevertheless, bad.Indeed, it means that monitoring some traces is incrementally slower (with no upper bound) as events are received, until the monitor eventually runs out of resources.
Unfortunately, there is nothing to be fundamentally done to avoid the problem above.It is an inherent problem of parametric monitoring.Consider, for example, the "authenticate before use" parametric property specified in Section 2.2 using parametric LTL as Λk .(use k → ⋄ • authenticate k ); to make it clear that events depend on the parameter key k, we tagged them with the key.Without any knowledge about the semantics of the program to monitor, any monitor for this property must store all the authenticated keys, i.e., all the instances of the parameter k.Indeed, without that, there is no way to know whether a key instance has been authenticated or not when a use event is observed on that key.The number of such key instances is theoretically unbounded, so, in the worst case, any monitor for this property can be incrementally slower and eventually run out of resources.
As seen in Section 9, the runtime overhead due to opaque monitoring of parametric properties tends to be manageable in practice.By "opaque" we mean that no semantic information about the source code of the monitored program is used.If the lack of an efficiency guarantee is a problem in some applications, then the alternative is to statically analyze the monitored program and to use the obtained semantic information to eliminate the need for monitoring.For example, static analyses like those in [25,10,12,18] may significantly reduce the need for instrumentation, even eliminate it completely.Moreover, model-checking techniques for parametric properties could also be used for actually proving that the properties hold and thus they need not be monitored; however, we are not aware of model checking approaches to verifying parametric properties as presented in this paper.

Implementation in JavaMOP and RV
The discussed parametric monitoring technique is now fully implemented in two runtime verification systems, namely in JavaMOP (see http://javamop.org) and in RV [27] (developed by a startup company, Runtime Verification, Inc.; the RV system is currently publicly unavailable -contact the first author for an NDA-protected version of RV).Here we first informally discuss several optimizations implemented in the two runtime verification systems, and then we discuss our experiments and the evaluation of the two systems.9.1.Implementation Optimizations.Both JavaMOP and RV apply several optimizations to the algorithm C X in Section 8.2, to reduce its runtime overhead.These are not discussed in depth here, because they are orthogonal to the main objective of this paper.9.1.1.Optimizations in JavaMOP.Note that C X iterates through all the possible parameter instances that are less informative than θ in three different loops: at lines 2 and 8 in the main function, and at line 2 in the defineTo function.Hence, it is important to reduce the number of such instances in each loop.Even though our semantics and theoretical algorithms for parametric monitoring in this paper work with infinite sets of parameters, our current implementation in JavaMOP assumes that the set of parameters X is bounded and fixed apriori (declared as part of the specification to monitor).A simple analysis of the events appearing in the specification allows to quickly detect parameter instances that can never appear as lubs of instances of parameters carried by events; maintaining any space for those in ∆, or Γ, or iterating over them in the above mentioned loops, is a waste.For example, if a specification contains only two event definitions, e 1 p 1 and e 2 p 1 , p 2 , parameter instances defining only parameter p 2 can never appear as lubs of observed parameter instances.A static analysis of the specification, discussed in [13,10], exhaustively explores all possible event combinations that can lead to situations of interest to the property, such as to violation, validation, etc.Such information is useful to reduce the number of loop iterations by skipping iterations over parameter instances that cannot affect the result of monitoring.These static analyses are currently used at compile time in our new JavaMOP implementation to unroll the loops in C X and reduce the size of ∆ and U .
Another optimization is based on the observation that it is convenient to start the monitoring process only when certain events are received.Such events are called monitor creation events in [14].The parameter instances carried by such creation events may also be used to reduce the number of parameter instances that need to be considered.An extreme, yet surprisingly common case is when creation events instantiate all the property parameters.In this case, the monitoring process does not need to search for compatible parameter instances even when an event with an incomplete parameter instance is observed.The old JavaMOP [14] supported only traces whose monitoring started with a fully instantiated monitor creation event; this was perceived (and admitted) as a performance-tradeoff limitation of JavaMOP [4] (and [14]).Interestingly, it now becomes just a common-case optimization of our novel, general and unrestricted technique presented here.9.1.2.Optimizations in RV.The RV system implements all the optimizations in JavaMOP and adds two other important optimizations that significantly reduce the overhead.
The first additional optimization of RV is a non-trivial garbage-collector [20].Note that JavaMOP also has a garbage collector, but it only does the obvious: it garbage collects a monitor instance only when all its corresponding parameter instances are collected.RV performs a static analysis of the property to monitor and, based on that, it garbage collects a monitor instance as soon as it realizes that it can never trigger in the future.This can happen when any triggering behavior needs at least one event that can only be generated in the presence of a parameter instance that is already dead.Consider, for example, the safe iterator example in Section 2.3, and consider that iterator i 7 is created for collection c 3 .Then a monitor instance corresponding to the parameter instance c 3 i 7 is created and manged.Suppose that, at some moment, the iterator i 7 is garbage collected by the JVM.Can the monitor instance corresponding to c 3 i 7 be garbage collected?Not in JavaMOP, because, for safety, JavaMOP collects a monitor only when all its parameter instances are collected, and in this case c 3 is still alive.However, this monitor is flagged for garbage collection in RV.The rationale for doing so is that the only way for the monitor to trigger is to eventually encounter a next event with i 7 as parameter, but that event can never be generated because i 7 is dead.Note, on the other hand, that the monitor c 3 i 7 cannot be garbage collected if c 3 is collected but i 7 is still alive, because the iterator alone can still violate the safe-iterator property, even if its corresponding collection is already dead.
Runtime verification systems like JavaMOP and Tracematches use off-the-shelf weak reference libraries to implement their garbage collectors.However, it turns out that these libraries, in order to be general and thus serve their purpose, perform many checks that are unnecessary in the context of monitoring.The second optimization of RV in addition to those of JavaMOP consists of a collection of data structures based on weak references, which was carefully engineered to take full advantage of the particularities of monitoring parametric properties.These data structures allow for effective indexing and lazy collection of monitors, to minimize the number of expensive traversals of the entire pool of monitors.Moreover, RV caches monitor instances to save time when the same monitor instances are accessed frequently.For example, there is a high chance that the same iterator is accessed several times consecutively by a program, in which case saving and then retrieving the same corresponding monitor instances from the data-structures at each iterator access can take considerable unnecessary overhead.9.2.Experiments and Evaluation.We next discuss our experience with using the two runtime verification systems that implement optimized variants of the parametric property monitoring techniques describe in this paper.Also, we compare their performance with that of Tracematches, which is, at our knowledge, the most efficient runtime verification system besides JavaMOP and RV.Recall that Tracematches achieves virtually the same semantics of parametric monitoring like ours, but using a considerably different approach.9.2.1.Experimental Settings.We used a Pentium 4 2.66GHz / 2GB RAM / Ubuntu 9.10 machine and version 9.12 of the DaCapo (DaCapo 9.12) benchmark suite [8], the most upto-date version.We also present some of the results of our experiments using the previous version of DaCapo, 2006-10 MR2 (DaCapo 2006-10), namely those for the bloat and jython benchmarks.DaCapo 9.12 does not provide the bloat benchmark from the DaCapo 2006-10, which we favor because it generates large overheads when monitoring iterator-based properties.The bloat benchmark with the UnsafeIter specification causes 19194% runtime overhead (i.e., 192 times slower) and uses 7.7MB of heap memory in Tracematches, and causes 569% runtime overhead and uses 147MB in JavaMOP, while the original program uses only 4.9MB.Also, although the DaCapo 9.12 provides jython, Tracematches cannot instrument jython due to an error that we were not able to understand or fix.Thus, we present the result of jython from the DaCapo 2006-10.The default data input for DaCapo was used and the -converge option to obtain the numbers after convergence within ±3%.Instrumentation introduces a different garbage collection behavior in the monitored program, sometimes causing the program to slightly outperform the original program; this accounts for the negative overheads seen in both runtime and memory.
We used the Sun JVM 1.6.0 for the entire evaluation.The AspectJ compiler (ajc) version 1.6.4 is used for weaving the aspects generated by JavaMOP and RV into the target benchmarks.Another AspectJ compiler, abc [3] 1.3.0, is used for weaving Tracematches properties because Tracematches is part of abc and does not work with ajc.For JavaMOP, we used the most recent release version, 2.1.2.For Tracematches, we used the most recent release version, 1.3.0,from [36], which is included in the abc compiler as an extension.To figure out the reason that some examples do not terminate when using Tracematches, we also used the abc compiler for weaving aspects generated by JavaMOP and RV.Note that JavaMOP and RV are AspectJ compiler-independent.They show similar overheads and terminate on all examples when using the abc compiler for weaving as when ajc is used.Because the overheads are similar, we do not present the results of using abc to weave JavaMOP and RV generated aspects in this paper.However, using abc to weave  JavaMOP and RV properties confirms that the high overhead and non-termination come from Tracematches itself, not from the abc compiler.
The following properties are used in our experiments.Some of them were already discussed in Sections 1.1 and 2, others are borrowed from [10,11,26,13].
• HasNext: Do not use the next element in an iterator without checking for the existence of it; • UnsafeIter: Do not update a collection when using the iterator interface to iterate its elements; • UnsafeMapIter: Do not update a map when using the iterator interface to iterate its values or its keys; • UnsafeSyncColl: If a collection is synchronized, then its iterator also should be accessed synchronously; • UnsafeSyncMap: If a collection is synchronized, then its iterators on values and keys also should be accessed synchronized.
All of them are tested on Tracematches, JavaMOP, and RV for comparison.We also monitored all five properties at the same time in RV, which was not possible in other monitoring systems for performance reasons or structural limitations.Note that the structure of the DaCapo 9.12 allows us to instrument all of the benchmarks plus all supplementary libraries that the benchmarks use, which was not possible for Da-Capo 2006-10.Therefore, fop and pmd show higher overheads than the benchmarks using DaCapo 2006-10 from [13].While other benchmarks show overheads less than 80% in JavaMOP, bloat, avrora, and pmd show prohibitive overhead in both runtime and memory performance.This is because they generate many iterators and all properties in this evaluation are intended to monitor iterators.For example, bloat creates 1,625,770 collections and 941,466 iterators in total while 19,605 iterators coexist at the same time at peak, in an execution.avrora and pmd also create many collections and iterators.Also, they call hasNext() 78,451,585 times, 1,158,152 times and 4,670,555 times and next() 77,666,243 times, 352,697 times and 3,607,164 times, respectively.Therefore, we mainly discuss those three examples in this section, although RV shows improvements for other examples as well.Figure 5 (A) shows the percent runtime overhead of Tracematches, JavaMOP, and RV.Overall, RV averages two times less runtime overhead than JavaMOP and orders of magnitude less runtime overhead than Tracematches (recall that these are the most optimized runtime verification systems).With bloat, RV shows less than 260% runtime overhead for each property, while JavaMOP always shows over 440% runtime overhead and Tracematches always shows over 1350% for completed runs and crashed for UnsafeMapIter.With avrora, on average, RV shows 62% runtime overhead, while JavaMOP shows 139% runtime overhead and Tracematches shows 203% and hangs for UnsafeMapIter.With pmd, on average, RV shows 94% runtime overhead, while JavaMOP shows 231% runtime overhead and Tracematches shows 1139% and hangs for UnsafeMapIter and UnsafeSyncMap.
Also, RV was tested with all five properties together and showed 982%, 275%, and 620% overhead, respectively, which are still faster or comparable to monitoring one of many properties alone in JavaMOP or Tracematches.The overhead for monitoring all the properties simultaneously can be slightly larger than the sum of their individual overheads since the additional memory pressure makes the JVM's garbage collection behave differently.
Figure 5 (B) shows the peak memory usage of the three systems.RV has lower peak memory usage than JavaMOP in most cases.The cases where RV does not show lower peak memory usage are within the limits of expected memory jitter.However, memory usage of RV is still higher than the memory usage of Tracematches in some cases.Tracematches has several finite automata specific memory optimizations [4], which cannot be implemented in formalism-independent systems like RV and JavaMOP.Although Tracematches is sometimes more memory efficient, it shows prohibitive runtime overhead monitoring bloat and pmd.There is a trade-off between memory usage and runtime overhead.If RV more actively removes terminated monitors, memory usage will be lower, at the cost of runtime performance.Overall, the monitor garbage collection optimization in RV achieves the most efficient parametric monitoring system with reasonable memory performance.
Figure 6 shows the number of triggered events, of created monitors, of monitors flagged as unnecessary by RV's optimization, and of monitors collected by the JVM.Among the DaCapo examples, bloat, avrora, h2, pmd and sunflow generated a very large number of events (millions) in all properties, resulting in millions of monitors created in most cases.h2 does not exhibit large overhead because monitor instances in h2 have shorter lifetimes, therefore the created monitor instances are not used heavily like in bloat.sunflow has millions of events but does not create as many monitor instances as as other benchmarks.When monitoring the HasNext and UnsafeIter properties, RV's garbage collector effectively flagged monitors as unnecessary and most were collected by the JVM.
The experimental evaluation in this section shows that the approach to parametric trace slicing and monitoring discussed in this paper is indeed feasible, provided that it is not implemented naively.Indeed, as seen in the tables in this section, implementation optimizations make a huge difference in the runtime and memory overhead.This paper was not dedicated to optimizations and implementations; its objective was to only introduce the mathematical notions, notations, proofs and abstract algorithms underlying the semantical foundation of parametric properties and their monitoring.Current and future implementations are and will build on this foundation, applying specific optimizations and heuristics to reduce the runtime or the memory overhead caused by monitoring.

Concluding Remarks, Future Work and Acknowledgments
A semantic foundation for parametric traces, properties and monitoring was proposed.A parametric trace slicing technique, which was discussed and proved correct, allows the extraction of all the non-parametric trace slices from a parametric slice by traversing the original trace only once and dispatching each parametric event to its corresponding slices.It thus enables the leveraging of any non-parametric, i.e., conventional, trace analysis techniques to the parametric case.A parametric monitoring technique, also discussed and proved correct, makes use of it to monitor arbitrary parametric properties against parametric execution traces using and indexing ordinary monitors for the base, non-parametric property.Optimized implementations of the discussed techniques in JavaMOP and RV reveal that their generality, compared to the existing similar but ad hoc and limited techniques in current use, does not come at a performance expense.Moreover, further static analysis optimizations like those in [25,10,12,18] may significantly reduce the runtime and memory overheads of monitoring parametric properties based on the techniques and algorithms discussed in this paper.
The parametric trace slicing technique in Section 6 enables the leveraging of any nonparametric, i.e., conventional, trace analysis techniques to the parametric case.We have only considered monitoring in this paper.Another interesting and potentially rewarding use of our technique could be in the context of property mining.For example, one could run the trace slicing algorithm on large benchmarks making intensive use of library classes, and then, on the obtained trace slices corresponding to particular classes or groups of classes of interest, run property mining algorithms.The mined properties, or the lack thereof, may provide insightful formal documentation for libraries, or even detect errors.Preliminary steps in this direction are reported in [22].

Figure 1 :
Figure 1: Typestate property describing the correct use of the next() and hasnext() methods.

4. 2 .
The Parametric Case.Events often carry concrete data instantiating parameters.

a 2 ,
θ(b) = b 1 and θ(c) = c 1 as the sequence "a 2 b 1 c 1 ".The function ⊥ then corresponds to the empty sequence.Example.Here is a parametric trace with events parametric in {a, b, c}, where the parameters take values in the set {a 1 , a 2 , b 1 , c 1 }: τ = e 1 a 1 e 2 a 2 e 3 b 1 e 4 a 2 b 1 e 5 a 1 e 6 e 7 b 1 e 8 c 1 e 9 a 2 c 1 e 10 a 1 b 1 c 1 e 11 .

Definition 19 .
Monitors M and M ′ are property equivalent, or just equivalent, written M ≡ M ′ , iff they are monitors for the same property (see Definition 16).With the notation in Definition 17, we have that M ≡ M ′ iff P M = P M ′ .Proposition 18.With the notations in Definitions 17 and 18, M P M ≡ M for any monitor M = (S, E, C, ι, σ, γ). endfor

Figure 5 :
Figure 5: Comparison of Tracematches (TM), JavaMOP (MOP), and RV: (A) average percent runtime overhead; (B) total peak memory usage in MB. (convergence within 3%, ∞: not terminated after 1 hour) By 5.in Proposition 3 we then infer that ⊔{θ i | i ∈ I} exists if and only if ⊔{⊔{θ i j | i j ∈ I j } | j ∈ J} exists, and if both exist then

Table 1 :
A run of the trace slicing algorithm A X (top-left table first, followed by bottomleft table, followed by the right table).
undefined then 2 . . .foreach θ max ⊏ θ (in reversed topological order) do Corollary 5.If M is a monitor for P and X is a set of parameters, then M B X (M ) is a monitor for parametric property ΛX .P .Proof.With the notation in Definition 17, Theorem 2 implies that P M B X (M ) = P ΛX .M .By Proposition 19 we have that P ΛX .M = ΛX .P M .Finally, since P = P M by Proposition 15, we conclude that P M B X (M ) = ΛX .P .8.2.Optimized Algorithm.Algorithm C X in Figure 4 refines Algorithm B X in Figure Figure 6: Monitoring statistics: number of events (E), number of created monitors (M), number of flagged monitors (FM), number of collected monitors (CM).9.2.2.Results and Discussions.Figures 5 and 6 summarize the results of the evaluation.