Extended Code Coverage for AspectJ-Based Runtime Verification Tools

  • Omar Javed
  • Yudi Zheng
  • Andrea Rosà
  • Haiyang Sun
  • Walter Binder
Conference paper
Part of the Lecture Notes in Computer Science book series (LNCS, volume 10012)


Many runtime verification tools for the Java virtual machine rely on aspect-oriented programming, particularly on AspectJ, to weave the verification logic into the observed program. However, AspectJ imposes several limitations on the verification tools, such as a restricted join point model and the inability of weaving certain classes, particularly the Java and Android class libraries. In this paper, we show that our domain-specific aspect language DiSL can overcome these limitations. While offering a programming model akin to AspectJ, DiSL features an extensible join point model and ensures weaving with complete bytecode coverage for Java and Android. We present a new compiler that translates runtime-verification aspects written in AspectJ to DiSL. Hence, it is possible to use existing, unmodified runtime verification tools on top of the DiSL framework to bypass the limitations of AspectJ. As a case study, we show that the AspectJ-based runtime verification tool JavaMOP significantly benefits from the automated translation of AspectJ to DiSL code, gaining increased code coverage. Thanks to DiSL, JavaMOP analyses are able to unveil violations in the Java class library that cannot be detected when using AspectJ.

1 Introduction

Many state-of-the-art runtime verification tools, such as JavaMOP [1], LARVA [2], Tracematches [3], and MARQ [4], target the Java Virtual Machine (JVM). Often, such tools rely on Aspect-Oriented Programming (AOP), in particular on AspectJ [5], to weave the verification logic into the observed program at specified join points1.

Unfortunately, while offering a convenient programming model, AspectJ suffers from severe shortcomings that may impair the development of effective runtime verification tools. First, AspectJ provides only a limited set of join points that can be instrumented. Second, AspectJ is unable to weave aspects in certain classes, in particular, those in the class libraries of Java and Android. While the first limitation has been addressed in the approach described in [6], the second limitation results in monitoring tools with only limited code coverage2, which may fail to fully verify program correctness.

In this paper, we argue that the aforementioned limitations of AspectJ can be overcome by DiSL [7], our instrumentation framework for runtime verification. In particular, our work targets runtime verification tools that generate aspects to express the verification logic and rely on AspectJ to weave that logic into the observed program. By translating verification aspects expressed in AspectJ into DiSL instrumentations, the code coverage of existing AspectJ-based tools [1, 2, 3, 4] can be significantly extended, enabling runtime verification on classes (such as those in the Java class library) which otherwise cannot be processed with AspectJ, as well as on Android applications. Such feature enables library developers to easily apply out-of-the-box tools on the library code, which demands a better code quality than the application code. To this end, we present a novel AspectJ-to-DiSL compiler that can be readily integrated with unmodified AspectJ-based runtime verification tools.

This work makes the following contributions. We show that DiSL achieves better code coverage than AspectJ, which results in the discovery of violations in Java that cannot be found by AspectJ. Moreover, we present a novel compiler to translate a subset of AspectJ constructs into DiSL code (detail of supported subset is mentioned in Sect. 3.1). The constructs supported by the compiler are particularly important for runtime monitoring and verification.

Our evaluation results demonstrate that applying our compiler to the JavaMOP runtime verification tool [1] results in a more versatile, enhanced tool that presents a considerably increased code coverage and is able to detect violations in the Java class library. In particular, this enhanced tool has led to the discovery of previously unknown violations found by JavaMOP analyses in the Java Development Kit (JDK) 8.

In the rest of the paper, we present an overview of DiSL in Sect. 2, while we detail our novel AspectJ-to-DiSL compiler in Sect. 3. Section 4 shows the benefits of using DiSL over AspectJ for runtime verification, discussing our evaluation results on both the JVM and on Android. Finally, we discuss related work in Sect. 5 and conclude in Sect. 6.

2 DiSL Overview

In this section we give a brief overview of DiSL; see [7] for more information.
Fig. 1.

DiSL architecture (configuration for JVM in-process analysis).

Language Constructs. With DiSL, any region of bytecodes can be used as a join point. Pointcuts are expressed with markers that select bytecode regions. DiSL provides an extensible library of such markers, including those for selecting method bodies, exception handlers, basic blocks, and single bytecodes. Join points selected by a marker can be further restricted by guards, i.e., side-effect-free predicate methods executed at weave-time. Advice in DiSL are expressed in the form of code snippets, which serve as code templates to be inserted at certain join points indicated by annotations. Snippets are instantiated by the weaver using contextual information.

Context Information. Snippets have access to complete context information provided via method arguments. Context information can be of two types: static (i.e., static reflective join point information limited to constants: primitive values, strings, or class literals) or dynamic (i.e., including local variables and the operand stack). DiSL provides an extensible library of both kinds of context information. Guards have access only to static context information.

Data Passing. DiSL supports synthetic local variables that enable efficient data passing between snippets woven into the same method body. To allow snippets to access the same variables, snippets are inlined by the DiSL weaver. Synthetic local variables are expressed as annotated static fields. DiSL also supports thread-local variables that are efficiently implemented by extra instance fields in java.lang.Thread. They are also expressed as annotated static fields.

Architecture. The architecture of DiSL (when instrumenting applications on the JVM) is shown in Fig. 1. DiSL uses a separate process for instrumentation to reduce perturbations and interferences in the observed JVM. All classes (including those from the Java class library) are intercepted at load-time by the DiSL JVMTI agent and forwarded to the instrumentation process, which executes the DiSL weaver. Instrumented classes are then returned to the observed JVM where they are linked.

Instrumentation. When a snippet is selected to be woven at a join point, it is first instantiated using the context of the join point. The DiSL weaver replaces invocations of static-context methods with the corresponding constants, i.e., static-context method invocations in a snippet are pseudo method calls that are substituted with concrete constants. Similarly, dynamic-context method invocations in a snippet are pseudo method calls that are replaced with bytecode sequences to access local variables or to copy operands from the stack. DiSL relies on polymorphic bytecode instrumentation [8] to achieve complete bytecode coverage.

Out-of-Process Analysis. DiSL also supports a deployment setting to enforce isolation between the analysis and the observed program [9]. In this setting analysis code in executed in a separate process, avoiding any shared state between the analysis and the observed program. This setting prevents interference problems often found in systems that execute the analysis code and the observed program within the same process [10].

Android Support. DiSL supports instrumentation on the Dalvik Virtual Machine (DVM) employed in Android [11]. The DiSL instrumentation server receives Dalvik bytecode from Android, converts it to Java bytecode, instruments it, and converts the result to Dalvik bytecode before sending it back. By intercepting class loading on Android, DiSL achieves load-time weaving and ensures full bytecode coverage [12], enabling also the instrumentation of the Android system library and of dynamically loaded classes. Moreover, DiSL integrates a bypass mechanism which dynamically activates or deactivates an instrumentation [13]. This approach is useful for shared libraries and allows applying multiple instrumentations in a single weaving pass, as each instrumentation can be selectively enabled or disabled.

3 AspectJ-to-DiSL Compiler

Here we present our compiler that translates AspectJ aspects to DiSL instrumentations. It allows unmodified AspectJ-based runtime verification tools to take advantage of the increased bytecode coverage of DiSL. We refer any interested reader to [13] for how DiSL achieves comprehensive code coverage. We start with an overview of the compiler in Sect. 3.1, followed by an explanation of the implementation in Sect. 3.2. Finally, we illustrate the compiler with a running example in Sect. 3.3.

3.1 Overview

Our AspectJ-to-DiSL compiler takes compiled AspectJ classes as input and generates a corresponding DiSL instrumentation. We employ ASM3, a Java bytecode manipulation framework, to parse the AspectJ constructs. An alternative approach would be to modify the AspectJ compiler to directly emit a DiSL instrumentation. While the latter approach would require more development effort, it would result in a tighter integration of DiSL with AspectJ.

Our compiler transforms AspectJ pointcuts and advice. Because DiSL only supports instrumentations for monitoring tasks and prevents structural modifications of the woven code, our AspectJ-to-DiSL compiler supports neither around advice that alters the control flow4, nor inter-type declarations that may modify the class structure or even the class hierarchy.

An overview of the AspectJ-to-DiSL compiler is shown in Fig. 2. The compiler first parses the AspectJ pointcut declarations and advice specifications, instantiates custom DiSL markers, and assembles them into concrete DiSL snippet annotations. Then, it copies the body of the AspectJ advice and adapts code accessing context information.
Fig. 2.

Overview of the AspectJ-to-DiSL compiler.

3.2 Implementation

AspectJ advice is translated into DiSL snippets. Depending on the advice specification, the corresponding DiSL snippet is annotated with @Before, @AfterReturning, @AfterThrowing, or @After5. For around advice which does not alter the control flow in the observed program (i.e., proceed is guaranteed to be invoked exactly once, which is checked by a static analysis), our compiler transforms the advice into two DiSL snippets annotated with @Before and @After, respectively, and introduces synthetic local variables for sharing data between these two DiSL snippets if necessary.

Pointcut declarations in AspectJ aspects are translated to custom DiSL markers as follows. For each type of pointcut, we create a method template that selects the corresponding bytecode regions. This method template must be specialized with the parameter of the pointcut before being instantiated to a custom marker class. For instance, a call(* Iterator.hasNext()) pointcut will be mapped to our CallMarkerTemplate. During compilation, we instantiate a custom CallMarker class with a parameter to the call pointcut, i.e., "* Iterator.hasNext()". For a pointcut that composes multiple pointcuts using logical operators such as && or ||, the custom DiSL marker embeds such logic into its top level marking method, and composites the marker classes instantiated from the corresponding method templates.

The body of the AspectJ advice is reused in the DiSL snippet, yet access to the context information is adapted. Our compiler maintains a mapping from each kind of join point context into specific methods for accessing the same context information in the DiSL library. When the compiler encounters an access to the join point context in the AspectJ advice, including those defined in the pointcut or advice declaration (e.g. target, arg or this), it will be replaced with an invocation to the corresponding method. For optimization purposes, the compiler distinguishes between static context information and dynamic context information. The compiler folds multiple identical accesses to the latter, and place them at the beginning of the DiSL snippet.
Fig. 3.

(a) AspectJ code for the HasNext property in JavaMOP. The naming convention is derived from JavaMOP. (b) DiSL code generated for the AspectJ code in Fig. (a).

3.3 Example

To illustrate our AspectJ-to-DiSL compiler, we use the HasNext property in JavaMOP as an example. This property is used for specifying constraints on the invocation of Iterator.hasNext() and Iterator.next() for each Iterator instance. Figure 3(a) shows the AspectJ code related to the HasNext property, while Fig. 3(b) demonstrates the output of our AspectJ-to-DiSL compiler. The semantics of the pointcuts are encapsulated into two custom DiSL markers, i.e., NextInvocationMarker and HasNextInvocationMarker. The two markers apply the library method corresponding to the call pointcut, marking bytecodes that invoke Iterator.next() or Iterator.hasNext(). In the body of the DiSL snippets, the compiler adapts the access to the receiver of the invocations by using ArgumentProcessorContext6.
Table 1.

JavaMOP properties evaluated.




Program should always call hasNext() before next() on an iterator.


When the iterator associated with a collection is accessed, the collection should not be updated.


When the iterator associated with a map is accessed, the map should not be updated.


A synchronized collection should always be accessed by a synchronized iterator, and the iterator should always be accessed in a synchronized manner

4 Evaluation

In this section, we demonstrate the prominence of DiSL over AspectJ in terms of code coverage and violation detection, and show how existing runtime verification tools can benefit from our AspectJ-to-DiSL compiler. In particular, we apply the proposed compiler to the JavaMOP [1] verification tool, and show how the compiler enhances JavaMOP analyses by converting AspectJ aspects generated by JavaMOP into DiSL instrumentation7.

We start by describing the setting of our evaluation in Sect. 4.1; then, we compare AspectJ and DiSL instrumentation along different dimensions, i.e., the number of join points executed (Sect. 4.2), violations detected in the Java class library (Sect. 4.3) and bytecode coverage on the Android platform (Sect. 4.4.).

4.1 Evaluation Setup

We choose multiple well-known JavaMOP properties (shown in Table 1), and evaluate two versions of each property: (1) the AspectJ aspect as generated by JavaMOP, and (2) the translated DiSL instrumentation.

To guarantee a fair comparison between AspectJ and DiSL, we did not include any class or method in the exclusion list8 of both frameworks. Because the generated JavaMOP aspects exclude the Java class library using the !within pointcut, we also manually modify the generated DiSL markers to enable the instrumentation of the Java class library. Concerning the experiments on the Android platform, since the AspectJ load-time weaver is not available on Android, we conduct the evaluation by comparing the DiSL instrumentation applied on application code only \(V_{DISL}\) (i.e., excluding the Android class library) and with full coverage \(V_{DISL+}\).

We have confirmed the correctness of our compiler as follows. First, we defined an exclusion list for DiSL with all the classes that could not be woven by AspectJ9; then, for each JavaMOP property, we compared the number of joint points executed by both the original AspectJ code and the translated DiSL instrumentation. In all cases, the results showed no relevant differences (apart from minor fluctuations due to non-determinism between different runs of some benchmarks) between the two frameworks, confirming that the same join points were intercepted by both AspectJ and DiSL.

On the JVM, our base programs come from the DaCapo10 and Scala benchmark suites11. The experiments are run on a 64-bit multicore platform with Oracle Hotspot Server VM12. We use JavaMOP 4.2, AspectJ 1.8.9, and DiSL 2.1. On Android, the base programs are applications in the Android Open Source Project (AOSP)13. We evaluate theses applications on Android 4.4.

4.2 Join Point Executions on the JVM

Figure 4 shows the number of join point executions for each JavaMOP property. The shaded region of each bar denotes the number of join points intercepted by AspectJ, while the unshaded region of the bar denotes the difference between the join points intercepted by DiSL and those intercepted by AspectJ. In all benchmarks DiSL intercepts more join points than AspectJ, because DiSL provides full bytecode coverage, allowing the same JavaMOP property to cover the Java class library as well as all AspectJ dependencies (i.e., classes that are implicitly excluded from load-time weaving in AspectJ). We expect the increase in the number of join points intercepted to expose more violation of JavaMOP properties, especially within the Java class library.
Fig. 4.

Number of join points executed in different benchmarks for the four considered properties of JavaMOP. Pattern Open image in new window shows the number of join points in AspectJ. Pattern Open image in new window shows the difference of join points executed between AspectJ and DiSL (DiSL - AspectJ).

From the figure, we can see that there is a significant coverage difference between AspectJ and DiSL in most of the benchmarks. However, the difference is smaller for avrora and h2, because most intercepted join points stem from an application class. The two join points java.util.Iterator.hasNext() and java.util.Iterator.next() are the most frequent ones, and in the case of h2 and avrora, they occur frequently in application classes. This behavior is different from other benchmarks, where the major contribution to the total number of join point executions is within the Java class library. When weaving with AspectJ, we observe that h2 shows the same number of join points in three different properties: HasNext, SafeSyncCollection, and SafeSyncMap, caused by a common pointcut which intercepts calls to both java.util.Iterator.hasNext() and java.util.Iterator.next(). For instance, org.h2.command.dml.Select.is Everything()14 contains join points which are intercepted by all three properties.

Amongst the four properties, SafeSyncMap yields the biggest difference between the number of join points executed by AspectJ and DiSL, with an exception in the avrora benchmark. In this benchmark, method calls to java.util.List.iterator() and java.util.Iterator.hasNext() are intercepted most of the time, and, among all properties, only SafeSyncCollection employs pointcuts to intercept the aforementioned two join points. For many benchmarks, the property HasNext shows the lowest number of joint point executions among all properties. The reason is that this property employs pointcuts which can be considered as a subset of the pointcuts employed by other properties. For example, pointcuts which intercept java.util.Iterator.hasNext() and java.util.Iterator.next(), apart from being defined in HasNext, are similarly defined in SafeSyncCollection and SafeSyncMap. An exception is h2, where java.util.Iterator.next() and java.util.Iterator.hasNext() account for the majority of join point executions. Since UnsafeIterator only intercepts java.util.Iterator.hasNext() (but not java.util.Iterator.next()), the total number of join points executed in this property is lower than for HasNext.

Overall, most of the benchmarks show a low number of join points intercepted by AspectJ, especially in Scala benchmarks (i.e., the last 12 benchmarks shown in Fig. 4). The reason is that AspectJ can only instrument application classes, in contrast to DiSL. In the case of Scala benchmarks, the number of join points executed by AspectJ are very low when compared to DiSL (in some cases, they are not even visible in the figure). With full bytecode coverage, most join point executions are in library code rather than in application code, with the exception of the actor benchmark.

4.3 Violations in the Java Class Library

JavaMOP analyses, after being translated to DiSL instrumentations, reveal the existence of two property violations in the Java class library which cannot be detected by standard AspectJ code.

The first violation concerns java.util.EnumSet.copyOf(Collection) (source code at Fig. 5), which violates the HasNext property. Further investigation reveals that this library method invokes Iterator.next() at line 8 without calling Iterator.hasNext(). While the code is valid, as it asserts whether the input Collection is empty, the implicit dependency between the assertion and the invocation of Iterator.next() is error-prone during code evolution—a developer may support copying an empty collection and drop the assertion. For this reason, we consider the reported violation as a valid one, which cannot be detected by the AspectJ code generated by JavaMOP.

The second violation is related to com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.setFeatures(Hashtable) (source code at Fig. 6), which violates the SafeSyncCollection property. After investigating this matter further, we found that this library method iterates through an instance of Hashtable, which is a synchronized Collection, without explicit synchronization (i.e., without specifying the synchronized keyword).

If the invocation to this method is not synchronized by the user, line 6 may throw a ConcurrentModificationException if the content of the Hashtable instance is modified concurrently after calling java.util.Iterator.hasNext() at line 5. In the newer version of Oracle JDK (e.g., 1.8.0_91), the responsibility of synchronization is explicitly shifted to the user by having this method accepting a Map argument instead of a Hashtable. When passing an Hashtable instance, the user should guarantee that the invocation is properly synchronized.

Overall, the increased number of join point executions intercepted by DiSL has enabled the discovery of two previously unknown property violations in the Java class library. Thanks to our AspectJ-to-DiSL compiler and to the DiSL framework, runtime verification tools such as JavaMOP can also support the developers of the Java class library.
Fig. 5.

Source code of java.util.EnumSet.copyOf(Collection).

Fig. 6.

Source code of com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.setFeatures. (Oracle JDK 1.8.0_60)

4.4 Join Point Executions on Android

Here, we show the number of join points intercepted by JavaMOP analyses in Android applications (after translation of the analyses to DiSL instrumentations), remarking that such an analysis is not possible with AspectJ’s load-time weaver. We note that the evaluation on \(V_{DISL}\) is meant to simulate the code coverage that AspectJ would have had if it had been applicable to Android applications. That is, \(V_{DISL}\) does not weave any classes that cannot be woven by AspectJ. To illustrate the effectiveness of our work, we apply the translated JavaMOP analyses on built-in applications from the AOSP, which are standard and well-known applications for the Android system. We report our results in Fig. 7.
Fig. 7.

Number of join points executed in different Android applications for the four considered properties of JavaMOP. Pattern Open image in new window shows number of join points in DiSL when excluding the Android class library. Pattern Open image in new window shows the difference of join points executed between \(V_{DISL+}\) and \(V_{DISL}\).

It can be seen from the figure that \(V_{DISL+}\) (i.e., DiSL instrumentation applied on all classes) shows a significant increase in the number of join point executions wrt. \(V_{DISL}\). This behavior follows our expectation, since \(V_{DISL+}\) intercepts join points in the Android class library, which are not covered by \(V_{DISL}\).

Amongst all applications, inputmethod shows the highest coverage at the application level, It is because two join points, Iterator.next() and Iterator.hasHext() are the most frequent ones, and in the case of inputmethod, they occur frequently in application classes. However, in all other applications, the coverage at the application level is rather low, showing the need for employing full bytecode coverage also to the Android system.

5 Related Work

There are many runtime monitoring and verification frameworks, most of them based on AspectJ. JavaMOP [1] supports parametric properties and uses decentralized indexing to reduce the runtime overhead. LARVA [2] provides runtime verification of real-time properties, while Tracematches [3] can process traces of events instead of single events by specifying regular expressions of symbols with free variables. Finally, MARQ [4] generates monitors based on the structural characteristics of the properties being monitored in order to optimize runtime monitoring. Since all these tools use AspectJ for generating events, they suffer from the shortcomings pinpointed in this paper. By integrating our AspectJ-to-DiSL compiler in these tools, they can benefit from an increased bytecode coverage, which may yield more effective runtime verification tools.

Xiang et al. propose a framework to enhance the flexibility of JavaMOP [6]. The framework consists of a deployment controller that manipulates bytecodes for capturing events, and a translator for directly converting monitoring specifications to DiSL code instead of generating AspectJ code. The framework is applicable only to JavaMOP, as it directly generates DiSL code from JavaMOP specifications. Their work aims at addressing the limited support for pointcuts offered by AspectJ. In contrast, our compiler translates pure AspectJ constructs to DiSL, providing benefits to any runtime verification tool that uses AspectJ for instrumentation.

The AspectBench Compiler (abc) [14] is an extensible AspectJ compiler that makes it possible to add new features. It uses the Polyglot [15] framework as its front-end and the Soot framework [16] as its back-end for improving code generation. The compiler can also be applied on the Android platform [17]. However, abc supports neither load-time weaving nor the instrumentation of the core class library, which are supported by DiSL.

InterAspect [18] is an instrumentation framework for GCC that allows writing instrumentation plugins using AOP. InterAspect provides an API which defines pointcuts to ease the instrumentation, hiding the intricacies of writing GCC instrumentation plugins, which requires expert knowledge of the GCC internals. While InterAspect manipulates GIMPLE representations of Java programs, weaving takes place at the bytecode level in DiSL. It is not clear whether an instrumentation generated by InterAspect covers the Java class library, as DiSL instrumentations do.

Instrumenting Android applications with AOP is popular [19, 20], especially for monitoring security and privacy threats. RV-Droid [21] relies on third-party runtime verification tools such as JavaMOP to produce monitoring libraries on Android. The authors modified the AspectJ compiler to enable instrumentation on Android. RV-Android [22] targets safety properties and provides a unified tool for runtime verification for Android applications. It also leverages AspectJ for instrumentation. Both tools support only static weaving, whereas DiSL enables load-time weaving and is able to cover the class library and dynamically loaded code. Since AspectJ is unable to weave the Android class library, RV-Droid and RV-Android could benefit from the full bytecode coverage offered by DiSL.

6 Conclusions

Several state-of-the-art runtime verification tools for the JVM leverage AspectJ for instrumentation. Unfortunately, AspectJ suffers from severe drawbacks, such as a restricted join point model and limited weaving capabilities that reduce code coverage, especially in the Java class library. In this paper, we have demonstrated that such limitations can be overcome by DiSL, our instrumentation framework for runtime verification. Moreover, we have presented a compiler to translate a subset of AspectJ constructs to DiSL. Our evaluation results show that applying our compiler to unmodified AspectJ-based runtime verification tools results in significantly increased code coverage, which allows one to find violations in the Java class library. Thanks to DiSL, runtime verification tools can also gain complete bytecode coverage on the Android platform.

DiSL is open-source and available at http://disl.ow2.org/. A new release is currently under preparation. In our ongoing research, we are improving the AspectJ-to-DiSL compiler to produce highly optimized woven code, aiming at outperforming AspectJ for runtime verification tasks. We plan to add support for inter-type declarations to minimize the impact on the monitoring performance. Moreover, we are investigating how to support ART on Android.


  1. 1.

    In this paper, we use the following terms related to AOP: join points (i.e., any identifiable execution point in a system), pointcuts (i.e., a set of join points of interest), and advice (i.e., code to be executed when a join point of a pointcut is reached).

  2. 2.

    We use the term “code coverage” to refer to the degree to which the program is monitored by runtime verification tools.

  3. 3.
  4. 4.

    We show a solution for around advice that does not alter the control flow in Sect. 3.2.

  5. 5.

    Such annotations denote a DiSL snippet to be inserted, respectively, before the marked code region, after a normal exit, after an exceptional exit, and after any exit from the marked code region.

  6. 6.

    The ArgumentProcessorContext interface allows one to access method arguments within snippets. Here, this features is used to get the receivers of method invocations.

  7. 7.

    Note that some AspectJ constructs in such aspects are not supported by our compiler, as DiSL does not support them (see Sect. 3.1).

  8. 8.

    The exclusion list allows one to specify a list of classes and methods that must not be considered in the weaving process.

  9. 9.

    Such classes are hard-coded in the AspectJ weaver, and cannot be woven even when specified in the weaver’s inpath flag.

  10. 10.

    Release 9.12-bach, http://www.dacapobench.org/. We excluded tradesoap, tradebeans and tomcat due to well-known issues. See bug #70 (hardcoded timeout in tradesoap and tradebeans) and bug #68 (StackOverflowError in tomcat) in the DaCapo bugtracker at https://sourceforge.net/p/dacapobench/bugs/.

  11. 11.
  12. 12.

    Intel Core i7, 2.5 GHz, Oracle JDK 1.8.0_60 Hotspot Server VM (64-bit) on Darwin Kernel Version 15.4.0.

  13. 13.
  14. 14.

    For brevity, we do not report parameters and return type for methods.



The research presented in this paper was supported by Oracle (ERO project 1332), by the Swiss National Science Foundation (project 200021\(\_\)141002), by the European Commission (contract ACP2-GA-2013-605442), and by the Swiss Government Excellence Scholarship (ESKAS-Nr: 2015.0989).


  1. 1.
    Jin, D., Meredith, P.O.N., Lee, C., Roşu, G.: JavaMOP: efficient parametric runtime monitoring framework. In: ICSE, pp. 1427–1430 (2012)Google Scholar
  2. 2.
    Colombo, C., Pace, G.J., Schneider, G.: LARVA–safer monitoring of real-time Java programs (tool paper). In: SEFM, pp. 33–37 (2009)Google Scholar
  3. 3.
    Bodden, E., Hendren, L., Lam, P., Lhoták, O., Naeem, N.A.: Collaborative runtime verification with tracematches. In: Sokolsky, O., Taşıran, S. (eds.) RV 2007. LNCS, vol. 4839, pp. 22–37. Springer, Heidelberg (2007). doi:10.1007/978-3-540-77395-5_3 CrossRefGoogle Scholar
  4. 4.
    Reger, G., Cruz, H.C., Rydeheard, D.: MarQ: monitoring at runtime with QEA. In: Baier, C., Tinelli, C. (eds.) TACAS 2015. LNCS, vol. 9035, pp. 596–610. Springer, Heidelberg (2015). doi:10.1007/978-3-662-46681-0_55 Google Scholar
  5. 5.
    Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., Griswold, W.G.: An overview of AspectJ. In: Knudsen, J.L. (ed.) ECOOP 2001. LNCS, vol. 2072, pp. 327–354. Springer, Heidelberg (2001). doi:10.1007/3-540-45337-7_18 CrossRefGoogle Scholar
  6. 6.
    Xiang, C., Qi, Z., Binder, W.: Flexible and extensible runtime verification for Java (Extended Version). Int. J. Softw. Eng. Knowl. Eng. 25, 1595–1609 (2015)CrossRefGoogle Scholar
  7. 7.
    Marek, L., Villazón, A., Zheng, Y., Ansaloni, D., Binder, W., Qi, Z.: DiSL: a domain-specific language for bytecode instrumentation. In: AOSD, pp. 239–250 (2012)Google Scholar
  8. 8.
    Binder, W., Moret, P., Tanter, É., Ansaloni, D.: Polymorphic bytecode instrumentation. Softw. Pract. Exp. (2015) doi:10.1002/spe.2385
  9. 9.
    Marek, L., Kell, S., Zheng, Y., Bulej, L., Binder, W., Tůma, P., Ansaloni, D., Sarimbekov, A., Sewe, A.: ShadowVM: robust and comprehensive dynamic program analysis for the Java platform. In: GPCE, pp. 105–114 (2013)Google Scholar
  10. 10.
    Kell, S., Ansaloni, D., Binder, W., Marek, L.: The JVM is not observable enough (and What to do about it). In: VMIL, pp. 33–38 (2012)Google Scholar
  11. 11.
    Sun, H., Zheng, Y., Bulej, L., Villazón, A., Qi, Z., Tůma, P., Binder, W.: A programming model and framework for comprehensive dynamic analysis on Android. In: MODULARITY, pp. 133–145 (2015)Google Scholar
  12. 12.
    Zheng, Y., Kell, S., Bulej, L., Sun, H., Binder, W.: Comprehensive multi-platform dynamic program analysis for Java and Android. IEEE Softw. 33, 55–63 (2016)CrossRefGoogle Scholar
  13. 13.
    Moret, P., Binder, W., Tanter, E.: Polymorphic bytecode instrumentation. In: AOSD, pp. 129–140 (2011)Google Scholar
  14. 14.
    Avgustinov, P., Christensen, A.S., Hendren, L., Kuzins, S., Lhoták, J., Lhoták, O., de Moor, O., Sereni, D., Sittampalam, G., Tibble, J.: Abc: an extensible AspectJ compiler. In: AOSD, pp. 87–98 (2005)Google Scholar
  15. 15.
    Nystrom, N., Clarkson, M.R., Myers, A.C.: Polyglot: an extensible compiler framework for Java. In: Hedin, G. (ed.) CC 2003. LNCS, vol. 2622, pp. 138–152. Springer, Heidelberg (2003). doi:10.1007/3-540-36579-6_11 CrossRefGoogle Scholar
  16. 16.
    Vallée-Rai, R., Gagnon, E., Hendren, L., Lam, P., Pominville, P., Sundaresan, V.: Optimizing Java bytecode using the Soot framework: is it feasible? In: Watt, D.A. (ed.) CC 2000. LNCS, vol. 1781, pp. 18–34. Springer, Heidelberg (2000). doi:10.1007/3-540-46423-9_2 CrossRefGoogle Scholar
  17. 17.
    Arzt, S., Rasthofer, S., Bodden, E.: Instrumenting Android and Java applications as easy as abc. In: Legay, A., Bensalem, S. (eds.) RV 2013. LNCS, vol. 8174, pp. 364–381. Springer, Heidelberg (2013). doi:10.1007/978-3-642-40787-1_26 CrossRefGoogle Scholar
  18. 18.
    Seyster, J., Dixit, K., Huang, X., Grosu, R., Havelund, K., Smolka, S.A., Stoller, S.D., Zadok, E.: InterAspect: aspect-oriented instrumentation with GCC. Formal Methods Syst. Des. 41, 295–320 (2012)CrossRefMATHGoogle Scholar
  19. 19.
    Falcone, Y., Currea, S.: Weave droid: aspect-oriented programming on Android devices: fully embedded or in the cloud. In: ASE, pp. 350–353 (2012)Google Scholar
  20. 20.
    Bodden, E.: Easily instrumenting Android applications for security purposes. In: CCS, pp. 1499–1502 (2013)Google Scholar
  21. 21.
    Falcone, Y., Currea, S., Jaber, M.: Runtime verification and enforcement for Android applications with RV-Droid. In: Qadeer, S., Tasiran, S. (eds.) RV 2012. LNCS, vol. 7687, pp. 88–95. Springer, Heidelberg (2013). doi:10.1007/978-3-642-35632-2_11 CrossRefGoogle Scholar
  22. 22.
    Daian, P., Falcone, Y., Meredith, P., Şerbănuţă, T.F., Shiriashi, S., Iwai, A., Rosu, G.: RV-Android: efficient parametric Android runtime verification, a brief tutorial. In: Bartocci, E., Majumdar, R. (eds.) RV 2015. LNCS, vol. 9333, pp. 342–357. Springer, Heidelberg (2015). doi:10.1007/978-3-319-23820-3_24 CrossRefGoogle Scholar

Copyright information

© Springer International Publishing AG 2016

Authors and Affiliations

  • Omar Javed
    • 1
  • Yudi Zheng
    • 1
  • Andrea Rosà
    • 1
  • Haiyang Sun
    • 1
  • Walter Binder
    • 1
  1. 1.Faculty of InformaticsUniversità della Svizzera Italiana (USI)LuganoSwitzerland

Personalised recommendations