The JVM is not observable enough (and what to do about it)

Kell, Stephen; Ansaloni, Danilo; Binder, Walter; Marek, Lukáš

doi:10.1145/2414740.2414747

Cited by 27 publications

(19 citation statements)

References 14 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Moreover, agents making use of the Java class library can interfere with the instrumentation of the Java class library itself (in practice this is often the case, unless the whole instrumentation logic is implemented as a native-code agent). To prevent interferences with class loading and JVM initialization [2,9], in-process load-time weavers often prevent instrumentation of the Java class library altogether. 9 Similar to the previous case, the resulting analyses usually suffer from limited code coverage.…”

Section: Motivating Examplementioning

confidence: 99%

“…In such a setting, the weaver can access the Class instances of the supertypes of the class under instrumentation, allowing the inspection of RSI. Unfortunately, this approach can interfere with the instrumentation of the Java class library, class loading, and JVM initialization [2,9]. To mitigate these problems, in-process load-time weavers (such as the AspectJ load-time weaver) often prevent any instrumentation of the Java class library, leading to limited code coverage.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Accurate reification of complete supertype information for dynamic analysis on the JVM

2017

Self Cite

View full text Add to dashboard Cite

Reflective supertype information (RSI) is useful for many instrumentation-based dynamic analyses on the Java Virtual Machine (JVM). On the one hand, while such information can be obtained when performing the instrumentation within the same JVM process executing the instrumented program, in-process instrumentation severely limits the code coverage of the analysis. On the other hand, performing the instrumentation in a separate process can achieve full code coverage, but complete RSI is generally not available, often requiring expensive runtime checks in the instrumented program. Providing accurate and complete RSI in the instrumentation process is challenging because of dynamic class loading and classloader namespaces. In this paper, we present a novel technique to accurately reify complete RSI in a separate instrumentation process. We implement our technique in the dynamic analysis framework DiSL and evaluate it on a task profiler, achieving speedups of up to 45% for an analysis with full code coverage. CCS Concepts • Software and its engineering → Dynamic analysis;

show abstract

Section: Motivating Examplementioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Accurate reification of complete supertype information for dynamic analysis on the JVM

2017

Self Cite

View full text Add to dashboard Cite

show abstract

“…When the libraries offering these functions are themselves instrumented, library-internal resources become shared between the application and the analysis in an uncoordinated way. Consequently, even very basic instrumentation scenarios can suffer from subtle problems including state corruption (from introduced reentrancy), deadlocks (from lock order violations), and memory exhaustion (from sharing the weak reference queue handler) [22]. A cheap way to avoid this interference, i.e.…”

Section: Coverage Versus Isolationmentioning

confidence: 99%

“…Another example is the JVM reference handling mechanism, used for notification of object death. This mechanism cannot be safely used by analysis that also observes the application reference handling behavior [22]. In general, the problem is that these hooks are neither isolated from the application nor ordered relative to other observed events.…”

Section: Resource Lifecycle Eventsmentioning

confidence: 99%

“…We wish to avoid sharing state with the observed program to the greatest extent possible. This is necessary both generally to reduce perturbation and specifically to avoid various known classes of bugs which less well-isolated approaches inherently risk introducing [22]. Our design's hook-analysis separation achieves this by factoring analyses into a remotely executed part and short local "hooks" inserted by bytecode instrumentation, which trap immediately to native code.…”

Section: Shadowvm Design Goalsmentioning

confidence: 99%

See 1 more Smart Citation

ShadowVM

et al. 2013

Self Cite

View full text Add to dashboard Cite

Dynamic analysis tools are often implemented using instrumentation, particularly on managed runtimes including the Java Virtual Machine (JVM). Performing instrumentation robustly is especially complex on such runtimes: existing frameworks offer limited coverage and poor isolation, while previous work has shown that apparently innocuous instrumentation can cause deadlocks or crashes in the observed application. This paper describes ShadowVM, a system for instrumentation-based dynamic analyses on the JVM which combines a number of techniques to greatly improve both isolation and coverage. These centre on the offload of analysis to a separate process; we believe our design is the first system to enable genuinely full bytecode coverage on the JVM. We describe a working implementation, and use a case study to demonstrate its improved coverage and to evaluate its runtime overhead.

show abstract

Large‐scale characterization of Java streams

et al. 2023

Self Cite

View full text Add to dashboard Cite

Java streams are receiving the attention of developers targeting the Java virtual machine (JVM) as they ease the development of data‐processing logic, while also favoring code extensibility and maintainability through a concise and declarative style based on functional programming. Recent studies aim to shedding light on how Java developers use streams. However, they consider only small sets of applications and mainly apply manual code inspection and static analysis techniques. As a result, the large‐scale dynamic analysis of stream processing remains an open research question. In this article, we present the first large‐scale empirical study on the use of streams in Java code exercised via unit tests. We present stream‐analyzer, a novel dynamic program analysis (DPA) that collects runtime information and key metrics, which enable a fine‐grained characterization of sequential and parallel stream processing. We use a fully automatic approach to massively apply our DPA for the analysis of open‐source software projects hosted on GitHub. Our findings advance the understanding of the use of Java streams. Both the scale of our analysis and the profiling of dynamic information enable us to confirm with more confidence the outcome highlighted at a smaller scale by related work. Moreover, our study reports the popularity of many features of the Stream API and highlights multiple findings about runtime characteristics unique to streams, while also revealing inefficient stream processing and stream misuses. Finally, we present implications of our findings for developers of the Stream API, tool builders and researchers, and educators.

show abstract

The JVM is not observable enough (and what to do about it)

Cited by 27 publications

References 14 publications

Accurate reification of complete supertype information for dynamic analysis on the JVM

Accurate reification of complete supertype information for dynamic analysis on the JVM

ShadowVM

Large‐scale characterization of Java streams

Contact Info

Product

Resources

About