ByCounter: Portable Runtime Counting of Bytecode Instructions and Method Invocations
|
|
- Malcolm Ross
- 6 years ago
- Views:
Transcription
1 ByteCode 2008 ByCounter: Portable Runtime Counting of Bytecode Instructions and Method Invocations Michael Kuperberg 1 Martin Krogmann 2 Ralf Reussner 3 Chair for Software Design and Quality Institute for Program Structures and Data Organisation Faculty of Informatics, Universität Karlsruhe (TH) Abstract For bytecode-based applications, runtime instruction counts can be used as a platform-independent application execution metric, and also can serve as the basis for bytecode-based performance prediction. However, different instruction types have different execution durations, so they must be counted separately, and method invocations should be identified and counted because of their substantial contribution to the total application performance. For Java bytecode, most JVMs and profilers do not provide such functionality at all, and existing bytecode analysis frameworks require expensive JVM instrumentation for instruction-level counting. In this paper, we present ByCounter, a lightweight approach for exact runtime counting of executed bytecode instructions and method invocations. ByCounter significantly reduces total counting costs by instrumenting only the application bytecode and not the JVM, and it can be used without modifications on any JVM. We evaluate the presented approach by successfully applying it to multiple Java applications on different JVMs, and discuss the runtime costs of applying ByCounter to these cases. Key words: Java, bytecode, counting, portable, fine-grained 1 Introduction The runtime behaviour of applications has functional aspects such as correctness, but also extra-functional aspects, such as performance. The runtime behaviour of a Java application can be described by analysing the execution of the application s Java bytecode instructions. Execution counts of these instructions are needed for bytecode-based performance prediction of Java applications [1], and also for dynamic bytecode metrics [2]. 1 michael.kuperberg@informatik.uni-karlsruhe.de 2 martin.krogmann@informatik.uni-karlsruhe.de 3 reussner@ipd.uka.de This paper is electronically published in Electronic Notes in Theoretical Computer Science URL:
2 As different instruction types have different execution durations, they must be counted separately. Also, method invocations should be identified due to the substantial contribution of methods to the total application performance. Thus, each method signature should have its own counter. To obtain all these runtime counts, static analysis (i.e. without executing the application) could be used, but it would have to be augmented to evaluate runtime effects of control flow constructs like loops or branches. Even if control flow consideration is attempted with advanced techniques such as symbolic execution, additional effort is required for handling infinite symbolic execution trees [3, pp ]. Hence, it is often faster and easier to use dynamic (i.e. runtime) analysis for counting executed instructions and invoked methods. However, dynamic counting of executed Java bytecode instructions is not offered by Java profilers or conventional Java Virtual Machines (JVMs). Existing program behaviour analysis frameworks for Java applications (such as JRAF [4]) do not differentiate between bytecode instruction types, do not identify method invocations performed from bytecode, or do not work at the level of bytecode instructions at all. These frameworks frequently rely on the instrumentation of the JVM, however, such instrumentation requires substantial effort and must be reimplemented for different JVMs. The contribution of the paper is a novel approach for lightweight portable runtime counting of Java bytecode instructions and method invocations. Its implementation is called ByCounter and it works by instrumenting the application bytecode instead of instrumenting the JVM. Through this, By- Counter can be used with any JVM, and the instrumented application can be executed by any JVM, making the ByCounter approach truly portable. Furthermore, ByCounter does not alter existing method signatures in instrumented classes nor does it require wrappers, so the instrumentation does not lead to any structural changes in the existing application. To make performance characterisation through bytecode counts more precise, runtime parameters of some bytecode instructions must be considered, as they can have significant impact on their performance [1]. For these cases, ByCounter provides basic parameter recording (e.g. for the array-creating instructions), and it also offers extension hooks for the recording mechanism. The presented approach is evaluated on two different Java virtual machines using applications that are subsets of three Java benchmarks. For these applications, our evaluation shows that despite accounting of single bytecode instructions, the ByCounter overhead during the counting phase at runtime is reasonably low (between ca. 1% and 85% in all cases except one outlier), while instrumenting the bytecode requires < 0.3 s in all studied cases. The paper is structured as follows: in Section 2, we outline the foundations of our approach. Section 3 provides an overview over how ByCounter works, while Section 4 describes its implementation. Section 5 presents our evaluation, before related work is presented in Section 6. Finally, we list our assumptions and limitation in Section 7 and conclude the paper in Section 8. 2
3 2 Foundations Java bytecode is executed on the Java Virtual Machine (JVM), which abstracts the specific details of the underlying software/hardware platform, making compiled Java classes portable across different platforms for which JVMs are offered. Each JVM is supplied with a set of Java classes that form the (vendor-specific) implementation of the Java API. In Java bytecode, four instructions are used to invoke Java methods, including those of the Java API: INVOKEINTERFACE, INVOKESPECIAL, INVOKE- STATIC and INVOKEVIRTUAL (hereafter called INVOKE*). The signature of the invoked method appears as the parameter of the INVOKE* instruction, while the parameters of the invoked method are prepared on the stack before method invocation. If an invoked method is part of the Java API, its implementation can be different across operating systems, as it may call platform-specific native methods (e.g. for file system access). To avoid platform-dependent counts, invocations of API and all other methods must initially be counted as they appear in application s bytecode, without decomposing them into the elements of their implementation. This results in a flat view, which summarises the execution of the analysed method in a platform-independent way. If needed, counts for the invoked methods can be obtained using the same approach, too. Using this additional information, counts for the entire (expanded) calling tree of the analysed method can be computed, and such stepwise approach promotes reuse of counting results. For bytecode-based performance prediction, parameters of invoked methods, but also parameters of non-invoke* bytecode instructions can be significant, because they influence the execution speed of the instruction [1]. The latter parameters and their locations are described in the JVM specification [5]; for example, the MULTIANEWARRAY instruction is followed by the array element type and the array dimensionality directly in the bytecode, while the sizes of the individual array dimensions have to be prepared on the stack. Hence, in order to describe the runtime behaviour of programs as precisely as possible, the approach must be able to record such parameters. However, parameter recording slows down the execution of the instrumented methods, and parameters may be relevant only in specific cases and only for some instructions or methods. As Java bytecode instructions or methods can have parameters of arbitrary object types, persistent parameter recording by simply saving the parameter value may be irrational, or even technically impossible. In such a case, a characterisation of the parameter object instance should be recorded: for a (custom) data structure, its size could be a suitable characterisation. Hence, to allow users to provide their own characterisations for Java classes of their choice, the approach must offer suitable extension hooks. In the next section, we provide an overview on our implementation of this approach, and how it handles the issues described in this section. 3
4 3 Overview of the ByCounter Process Parse program bytecode Instrument bytecode before execution ILOAD 2. Instrument ILOAD IINC C1 IADD parsed program IADD representation IINC C8 3. Convert into executable bytecode Execute instrumented bytecode 4. Create parameters 5. Replace original 6. Run instrumented for class constructors with instrumented bytecode, collect + method invocations bytecode classes counting results 27865*ILOAD 11108*IADD Fig. 1. Bytecode instrumentation and instruction counting using ByCounter In Fig. 1, all 6 steps of the process performed by ByCounter are shown. Following these process steps, this section describes the design rationale behind ByCounter and explains important design decisions that were made. Further details of the ByCounter implementation and of executing the instrumented bytecode will be described in Section 4. In step 1, ByCounter parses the existing bytecode class file into a navigable, structured representation, because direct manipulation of bytecode is very complex and error-prone. ByCounter uses the ASM bytecode engineering framework [6], which offers a bytecode class representation that includes semantic details (method signatures, fields, etc.). ASM s bytecode representation can be accessed and changed through the ASM API, which follows the visitor pattern. Using the ASM API, custom visitors can be created to add, change or delete the elements of the class representation down to the level of individual bytecode instructions. In step 2, ByCounter inserts counting instrumentation into the bytecode representation using a special ASM class visitor that we have written. The basic principle behind the visitor is to add new counters to existing bytecode. Later, during the execution the instrumented method, these counters will be initialised, incremented, evaluated and finally reported. Step 2 has to be implemented with the following objectives in mind: (i) it must not change the existing fields, variables, method signatures, class structure and execution semantics; (ii) the instrumentation has to account for each instruction individually with as few additional instructions and overhead as possible and (iii) for methods with control flow constructs (loops, ) that depend on the input parameters, counts must be reported correctly for any execution path, i.e. for all allowed values of input parameters. In step 3, the instrumented representation of the class is converted back into executable bytecode, which can be written into a class file and which can 4
5 also be used by ByCounter-provided ClassLoader. Step 3 concludes the instrumentation part and is followed by the execution part, which consists of steps 4 to 6. In step 4, execution of the instrumented method is prepared. In any case, it is the responsibility of the user to provide the prerequisites for the execution of the instrumented class. If the instrumented class will be run in the same context as the uninstrumented one, the preparations are absolutely identical to those for executing the uninstrumented class, and should already be fulfilled by the existing context. However, for running the instrumented class and its methods in isolation, preparations would include providing the parameters for class construction/initialisation and for method invocation, as well as providing required services. In step 5, the instrumented class must replace the original, uninstrumented class inside the deployed application. The most straightforward way to do this is to restart the application after replacing the original class bytecode with the new, instrumented version. If such a restart is not possible or not desirable, ByCounter can be connected to the JDK s Java Instrumentation API (java.lang.instrument package) or other tools that support class/method replacement and redefinition even after the application has started. In step 6, the instrumented method is run to count and to report executed bytecode instructions and method invocations. If needed, this step can be repeated with different input parameters of the instrumented method. Step 6 is the final step performed by ByCounter, after which the original, uninstrumented class can be reinstated if needed. 4 Implementation of ByCounter Following the overview in Fig. 1, the first step of ByCounter is to parse a Java class using the ASM framework [5]. Then, in step 2, ByCounter adds instrumentation for three tasks: for setup of the counting infrastructure, for counter incrementation and finally for reporting of the results. Users can specify which methods should be instrumented for counting and which methods should be left in the original, uninstrumented state. Otherwise, no manual intervention is needed from the user. 4.1 Creating and Using the Counters A suitable data structure must be selected for the counters. The JVM specification [5] lists 200 working bytecode instructions, including four INVOKE* instructions. Hence, these instructions require a fixed number of counters. In contrast to that, it depends on the application which and how many different methods will be invoked using INVOKE* in the instrumented method. Hence, in principle, method invocations inside the instrumented bytecode should be counted using a data structure which allows a dynamic addition of new counters for found method signatures. For ByCounter, the counters for 5
6 method invocations could be stored in a java.util.map-like data structure. At runtime, this structure can be easily extended, however, each access to a Map-like structure for incrementing a counter is very expensive. Thus, a more efficient technique is used in ByCounter by creating int counters for both method invocations and other bytecode instructions. The basic idea behind this technique is to perform an initial discovery pass over the bytecode for identifying all method signatures that occur in the bytecode of the considered method. Using the results of this pass, ByCounter can create precisely the required number of int counters. Incrementing an int counter can be done efficiently using a single IINC instruction. The list of method signatures will not grow at runtime, except in cases where other bytecode-instrumenting operations take place after ByCounter instrumentation. Hence, for correct counting results, we require that By- Counter is the last tool in the bytecode instrumentation chain. It must further be noted that the same discovery pass could identify non-invoke* instructions that really occur in the considered bytecode, but this enhancement ultimately results in more overhead than simply creating counters for all instructions. This list of found signatures might contain some methods that will not always be executed at runtime, because the execution path does not reach them for some values of input parameters passed to the instrumented method. The case-specific non-execution of these methods is not problematic, as the corresponding counts will simply maintain their initial value of 0. After the list of found method signatures has been populated in the discovery pass, ByCounter performs its main pass over bytecode. In the main pass, counters of type int for method invocations (as many as different signatures found during the discovery pass) are added to bytecode through instrumentation. Additionally, counters of type int are added for all 200 defined bytecode instructions. From the bytecode view, these counters are local variables. The maximum number of local variables in the bytecode of a Java method is (incl. those variables that existed before instrumentation), and this number shouldn t be a limitation in realistic cases. Additionally, to support bytecode-based performance prediction, the current version of ByCounter is able to record the dimension(s) and the element types of arrays created using ANEWARRAY, MULTIANEWARRAY and NEWARRAY instructions. The recording is optional; it is done using a set of additional Lists that save these details. In the future, functionality for recording parameters of other instructions and methods will be added to ByCounter. After creating the counters, ByCounter adds instrumentation to update (i.e. increment) them when the corresponding instructions and methods are executed. The IINC instruction does not modify the stack (it directly increments the underlying local variable ), so no side effects will occur at runtime. Recording of the dimensions of created arrays is also implemented in a way that does not produce any side effects. 6
7 4.2 Reporting the Counting Results Kuperberg, Krogmann, Reussner For reporting of counting results, two alternatives have been implemented in ByCounter, and both preserve the integrity of method signatures in the instrumented class. The first alternative instruments the method with code to directly write a log file with the counting results; for this, no additional classes must be loaded manually into the JVM. Details of the log file writing, such as the log file path, can be configured by the ByCounter user before the instrumentation starts. The second alternative is based on ByCounter s ResultCollector class, and has the advantage that it can aggregate and reference counts of different methods. In order to report the state of counters using ResultCollector, a call to its collectresults method is inserted by the instrumentation. Additionally, the ResultCollector class must be loaded into the JVM. Instead of reporting counting results periodically (e.g. after a certain time, or after a certain number of instructions has been counted), ByCounter is implemented to report the complete results immediately before the instrumented method exits. However, if a method declares possible exceptions in its signature (instead of the exception table), there is no way to foresee from the bytecode where and when method execution will exit due to an exception; in such a case, it can be assumed that the obtained counts are not representative. At the same time, exceptions declared using try/catch/finally are handled properly in ByCounter, as they are a part of the normal control flow. Thus, the ByCounter implementation ensures that the counting results are reported if and only if the method exits properly (i.e. if it returns without an uncaught exception). To achieve this, for both reporting alternatives (log file and ResultCollector), ByCounter adds instructions that report the result immediately preceeding every return -like bytecode instruction. These instructions include areturn, dreturn etc., depending on the type of returned value (bytecode of methods returning void also uses a return instruction). As the proper execution of a method always terminates with exactly one *return instruction, any such *return instruction is accounted for properly by pre-initialising the corresponding counter with 1. For the interpretation of the counting results, it can be important to have knowledge about the runtime parameters of the instrumented method itself. Hence, ByCounter is designed to store the characterisations of these parameters at the beginning of the method s execution and can report them together with the counting results. These characterisations can be the length of a String, size of an array etc. After the instrumentation has been completed, ByCounter converts the instrumented ASM bytecode representation into a Java class which is to substitute the original, uninstrumented class. The instrumented class can be saved as a class file, or passed to a suitable ClassLoader for immediate, reflectionbased invocation. 7
8 5 Case Study and Evaluation In this section, a case study is presented to show the efficiency and the precision of instrumentation and counting performed by ByCounter. The precision of ByCounter was evaluated by comparing ByCounter counting results with manually obtained results. For manual calculation of counts, the input parameters and their impact on the control flow of the considered method have to be evaluated. To make counting results comparable, it was required that an evaluated method has a deterministic execution when it is executed with the same set of input parameters. As described in Section 5.1 below, suitable Java methods have been selected and evaluated. The efficiency of ByCounter was evaluated by measuring (1) the duration of the instrumentation phase performed by ByCounter, (2) the execution duration of a method run before instrumentation and (3) the execution duration of the instrumented method. For (2) and (3), the same input parameters were used to be able to compare the results. From (2) and (3), the relative overhead caused by the counting process at runtime was computed and is reported below. 5.1 Study Setup For evaluating ByCounter, three Java benchmarks that are publicly available with their source code were used. The following methods have been instrumented and measured: (i) JavaGrande benchmark [7, 8]: method JGFrun() of class JGFCastBench, 216 LOC (lines of Java source code excluding comments and empty lines) (ii) Linpack benchmark [9] (Java implementation available from [10]): method run_benchmark() of class Linpack, 60 LOC (iii) SciMark 2.0 benchmark [11]: method integrate(int Num_samples) of class MonteCarlo, only 9 LOC (parameter is passed to the method, so the contained loop with 5 LOC is repeated times) To ensure deterministic behaviour in repeated runs, loop conditions in JGFCast Bench.JGFrun() were slightly modified. Furthermore, JGFCastBench bytecode contained many effectless casting instructions whose execution can be skipped (and is actually skipped after JIT compilation by some JVMs). Hence, we have enhanced and recompiled the source code of JGFCastBench to prevent skipping of these instructions by the JVMs that were used in this case study. Of course, the platform on which ByCounter is executed has an influence on the performance, both for instrumentation phase and for the execution of instrumented bytecode. For the JVM as a part of this platform, different vendors implement optimisations of bytecode execution in different ways, and the resulting impact on the performance is of particular interest. 8
9 Thus, we compared Bea JRockit JDK 6 Update 2 R (32bit) and Sun JDK JVM on a computer with the Intel Core Duo T2400 CPU at 1.83 GHz, 1.50 GB of RAM and with Windows XP Pro operating system. The load on the machine has been minimised during measurements, and thread/process priorities have not been changed. The JVMs were run in server mode using the -server flag. If a measurement is repeated several times in a row, the JVM may have more opportunities to optimise the measured code. While the instrumentation phase will likely be performed only once, an (un)instrumented method can be executed several times in a realistic application. Thus, for evaluating the counting-caused overhead, measurements of both uninstrumented and instrumented methods must be repeated appropriately. As a consequence, for each of the three studied benchmarks and for each of the JVMs, we have performed 100 JVM runs with 200 repetitions of these measurements in each JVM run. 5.2 Measurements and Results After the precision of counting results was successfully verified through aforementioned manual bytecode inspection, measurements were performed. Table 1 aggregates the results of the measurements; due to space limitations, we do only report the median values and not the full statistical evaluation. The most interesting metric in Table 1 is the overhead introduced by By- Counter, which is between <1% (Linpack, Bea JVM) and 84.6% (Java- Grande, Sun JVM), except for one outlier (SciMark, Bea JVM). benchmark name JavaGrande Linpack SciMark Java VM Bea Sun Bea Sun Bea Sun instrumentation [ms] uninstrumented method execution duration [ms] instrumented method execution duration [ms] , , counting overhead [%] < total count of executed bytecode instructions total count of executed method invocations 103,050,724 4,912 20,784, ,000,001 Table 1 ByCounter evaluation for 3 benchmarks and 2 JVMs (obtained individual counts of bytecode instructions and method invocations are not shown) 9
10 We have studied measurements of this outlier to understand the reason for such exceptionally large overhead, and have come to the conclusion that the optimisation mechanism of the Bea JVM does not work well for the instrumented version of SciMark: if optimisations are turned off using -Xnoopt flag, the uninstrumented version of SciMark runs in ms, while the instrumented one runs in ms, resulting in a counting overhead of 68.9%. In fact, the counting overhead for running SciMark using -Xnoopt is very close to the overhead for SciMark executed in the Sun JVM. Also, when normal and -Xnoopt runs are compared for the instrumented SciMark version in the Bea JVM, the -Xnoopt run is slower by a factor of But if normal and -Xnoopt Bea runs are compared for the uninstrumented SciMark version, the slowdown factor is 3.48 (28.92 ms vs ms), i.e. exceptionally high. Observed differences between the overhead percentages in Table 1 are explained through the different structure of the instrumented methods. For example, in the JavaGrande case, there is a very large number of counted instructions, but a small number of method invocations (and the invoked methods are computationally expensive), so the relative counting overhead is between 27.4% (Bea) and 84.5% (Sun). In the Linpack case, significantly fewer instructions must be counted, yet the invoked methods are computationally expensive (i.e., they have longer execution durations). As these invoked methods have not been instrumented, they have the same execution duration no matter whether they are called from the instrumented or uninstrumented version of Linpack s run_benchmark method. Hence, for Linpack s run_benchmark method, the costs of counting these invoked methods are very small in relation to their execution duration of the invoked methods. It can also be observed that the used JVMs lead to very different method execution durations, and that none of the JVMs is the fastest for all three benchmarks. The cost of the instrumentation phase is also reasonably small (below 300ms for all benchmarks in all JVMs). Before assumptions and limitations are discussed in Section 7, we describe related work and compare it to our approach in the next section. 6 Related Work Bytecode instruction counts can be considered as a dynamic bytecode metric. In [2], a collection of other metrics for Java bytecode is presented, but that collection does not include execution counts for individual bytecode instructions and method invocations. Existing approaches for dynamic (runtime) counting of Java bytecode instructions and method invocations can be grouped into three categories, according to the technology they rely upon: (a) using monitoring/reporting interfaces provided by the JVM (b) by instrumenting the JVM or its API-implementing library (c) by instrumenting the actual application bytecode or source. 10
11 For case (a), different interfaces are explicitly exposed by JVMs, such as JVMTI [12], which must be programmed in a native language. These interfaces are used by standalone Java tools and profilers, such as Intel VTUNE [13]. In general, profilers measure resource usage and need manual supervision and interpretation. In contrast to that, ByCounter obtains exact counts of executed instructions without human supervision of the counting process. Since Java 6, direct access to individual bytecode instructions with Javaown means is possible only with JVMTI - for this, execution of bytecode must be single-stepped, substantially slowing down bytecode execution. JVMTI is not a mandatory part of the JVM standard, and many virtual machines (such as Jikes RVM [14]) do not implement JVMTI at all. Hence, JVMTI is not suitable as a portable basis for platform-independent bytecode counting when compared to bytecode instrumentation. In category (b), two parts of a JVM must be differentiated: the bytecode interpreter with its components and the JVM s Java API implementation, which consists of (partially platform-specific) Java classes. Instrumenting the first part means dealing with native (non-java) code or binaries, which is generally a complicated, both platform-specific and JVM-specific task. Instrumenting the API implementation means instrumenting Java bytecode or source code of a very large number of Java classes. For both JVM parts, commercial JVMs usually do not provide the source code. JVM instrumentation is done for replaying the behaviour of multi-threaded Java programs, for example in [15] and similar approaches; however, only high-level constructs and not bytecode instructions or method invocations are considered. Vertical profiling approaches such as [16], [17] or [18] also use JVM instrumentation, and only consider high-level events, too. JRAF / FER- RARI [19] instruments the entire Java API, but it could not be obtained for evaluation. The available documentation shows that it does not offer counting of individual bytecode instructions and method invocations, as its instrumentation maintains only one counter for all bytecode instructions. Furthermore, FERRARI captures JVM-specific calling context trees and not an expandable flat view as ByCounter does. To instrument bytecode, the Java API itself does not provide any means, but only methods to read/load already instrumented bytecode. Instead, external frameworks for bytecode engineering (such as ASM [6] or SOOT [20]) can be used, as they offer rich APIs for analysing and modifying bytecode. However, they do not include bytecode-counting functionality or instrumentation templates. For case (c), the actual application code must be instrumentated and then executed by the JVM. This approach is used in ByCounter. Generic frameworks for bytecode manipulation, such as SOOT [20], do not offer the functionality provided by ByCounter, they serve as tools to implement this functionality. For example, the ASM framework [6] was used for ByCounter. Aspect-oriented bytecode-analysing frameworks such as in [21] do not pro- 11
12 vide the instruction-counting functionality itself, but merely offer a different way to implement instrumentation when compared to ASM or other bytecode engineering frameworks. 7 Assumptions and Limitations We assume that it is possible to pass the final class bytecode that will be executed to ByCounter for instrumentation. For applications where bytecode is generated on the fly and not by the Java compiler (for example in Java EE application servers), additional provisions must be taken. We also assume that the bytecode to instrument conforms to the JVM specification, even if it has been protected using obfuscation. The ASM library that is used in ByCounter has one small limitation: ASM does not generate a 1:1 representation of parsed bytecode in a few cases. For example, ASM visitors consider the parameterless LLOAD_0 bytecode instruction to be the same as the (different) LLOAD instruction with parameter 0. Hence, ByCounter reports the four LLOAD_* instructions and the LLOAD instruction using one counter. However, as there is no semantical difference between the two instructions in the above example, it does not invalidate the semantical accuracy of ByCounter. If needed, this small limitation can be overcome by modifying the ASM library. Another current limitation of ByCounter is grounded in polymorphism. For example, when methods of interfaces are invoked, only the type of the interface is visible at bytecode level. Hence, the class implementing the interface cannot be identified unambiguously in the current implementation of ByCounter. However, handling of polymorphism can be achieved with additional effort. The obtained instruction counts depend on the input parameters that have been provided to the instrumented method, for example due to control flow constructs that depend on these parameters. Currently, this dependency cannot be expressed by ByCounter because neither control flow constructs are recognised by it, nor states of variables/fields during method execution are inspected. Finally, superfluous bytecode instructions can exist in an application, i.e. bytecode which can be optimized away by Just-In-Time (JIT) compiler of the JVM without effects on execution results. These instructions are instrumented by ByCounter as it cannot anticipate later JIT optimisations. The instrumentation instructions cannot be optimised away by JIT, with the effect that they increment counters even for those (superfluous) instructions that have been removed by JIT. We have observed such effect for a benchmark where counting would seem to slow down the execution by a factor of more than 900 in some cases (which is unrealistic given the ByCounter implementation). Hence, we assume that ByCounter is run on code that has been engineered effectively and does not 12
13 contain large portions of superfluous code. At the same time, ByCounter can hint at the existence of superfluous code through an exceptionally high runtime counting costs. 8 Conclusions This paper presents a novel, evaluated approach for dynamic counting of executed instructions and method invocations in bytecode-based applications. The approach is called ByCounter and it works by instrumenting the application bytecode, without the need to instrument or modify the JVM or the Java API implementation. An example usage of the counting results is the bytecode-based performance prediction [1], and these results could also be used for characterising the execution of a bytecode application. ByCounter will be made publicly available at By instrumenting the application bytecode and not the JVM, ByCounter simplifies the entire counting process and becomes truly portable accross JVMs. The instrumentation added by ByCounter is lightweight, leading to low runtime costs of counting. The evaluation of these costs and the overall counting effort is performed in this paper for several Java applications on different JVMs. In addition to being portable, the presented approach has been designed for easy use: no understanding of bytecode internals is needed to use it, and the application methods available for instrumentation are automatically identified and proposed to the user. To minimise disruptions, ByCounter instrumentation preserves the signatures of all methods and constructors, and it also preserves the application architecture. For reporting of counting results, ByCounter offers two alternatives: either using structured log files or using a result collector framework (the latter can aggregate counting results accross methods and classes). In the future, our work will be extended into several directions. First, it will be integrated into Palladio [22], which is an approach to predict the performance of component-based software architectures. Palladio uses models of software components, for which behaviour specifications with performance annotations must be created. For existing bytecode components, these annotations can be obtained through bytecode-based performance prediction. Such prediction needs two inputs: execution durations of individual bytecode instructions and invoked methods, as well as the counts of these instructions and invocations. Hence, the role of ByCounter in the Palladio approach is to support bytecode-based performance prediction by providing the counts of executed instructions and of method invocations. For the next version of ByCounter, several enhancements are being evaluated. For example, we have envisioned support for instrumenting userdefined sections of methods. Another feature could be polymorphic instrumentation: with this option, instrumentation of a method C.m() in class C 13
14 will be automatically accompanied by instrumentation of all methods m() in classes that extend class C. Finally, extending our approach to other virtual machines and their bytecode languages (for example.net runtime and its CIL bytecode) would allow the use ByCounter in heterogenous systems. Acknowledgements The authors would like to thank Klaus Krogmann for insightful discussions and the anonymous reviewers for their helpful comments. References [1] M. Kuperberg and S. Becker, Predicting Software Component Performance: On the Relevance of Parameters for Benchmarking Bytecode and APIs, in Proceedings of the 12th International Workshop on Component Oriented Programming (WCOP 2007), R. Reussner, C. Czyperski, and W. Weck, Eds., July [2] B. Dufour, K. Driesen, L. Hendren, and C. Verbrugge, Dynamic Metrics for Java, in OOPSLA 03: Proceedings of the 18th annual ACM SIGPLAN conference on Object-oriented programing, systems, languages, and applications. New York, NY, USA: ACM, 2003, pp [3] J. Lee, Program Validation by Symbolic and Reverse Execution, PhD thesis, BRICS Ph.D. School, Department of Computer Science, University of Aarhus, Aarhus, Denmark, November [Online]. Available: jlee/papers/thesis-jooyong.pdf [4] W. Binder and J. Hulaas, Using Bytecode Instruction Counting as Portable CPU Consumption Metric, Electr. Notes Theor. Comput. Sci., vol. 153, no. 2, pp , [5] T. Lindholm and F. Yellin, The Java Virtual Machine Specification, 2nd ed. Addison-Wesley, [6] E. Bruneton, R. Lenglet, and T. Coupaye, ASM: a code manipulation tool to implement adaptable systems, Adaptable and Extensible Component Systems, [7] M. Philippsen, R. F. Boisvert, V. Getov, R. Pozo, J. E. Moreira, D. Gannon, and G. Fox, JavaGrande - High Performance Computing with Java, in PARA, 2000, pp [8] The Java Grande Forum Sequential Benchmarks 2.0, 2007, last visit: December 21st, [Online]. Available: computing/research activities/java grande/sequential.html [9] J. Dongarra, P. Luszczek, and A. Petitet, The LINPACK Benchmark: past, present and future, Concurrency and Computation: Practice and Experience, vol. 15, no. 9, pp ,
15 [10] Linpack Benchmark Java Version, 2007, last visit: December 21st, [Online]. Available: [11] Java SciMark 2.0, 2007, last visit: December 21st, [Online]. Available: [12] Sun Microsystems, Inc., Java Virtual Machine Profiler Interface (JVMPI), 2007, last visit: December 21st, [Online]. Available: j2se/1.5.0/docs/guide/jvmti/ [13] J. Donnell, Java Performance Profiling using the VTune Performance Analyzer, , retrieved [14] B. Alpern, S. Augart, S. Blackburn, M. Butrico, A. Cocchi, P. Cheng, J. Dolby, S. Fink, D. Grove, M. Hind, K. McKinley, M. Mergen, J. Moss, T. Ngo, V. Sarkar, and M. Trapp, The Jikes Research Virtual Machine project: building an open-source research community, IBM Systems Journal, vol. 44, no. 2, pp , [15] V. Schuppan, M. Baur, and A. Biere, JVM Independent Replay in Java, Electr. Notes Theor. Comput. Sci., vol. 113, pp , [16] J. Maebe, D. Buytaert, L. Eeckhout, and K. D. Bosschere, Javana: a system for building customized Java program analysis tools, in OOPSLA, 2006, pp [17] M. Hauswirth, P. F. Sweeney, A. Diwan, and M. Hind, Vertical profiling: understanding the behavior of object-priented applications, in OOPSLA, 2004, pp [18] J. Steven, P. Chandra, B. Fleck, and A. Podgurski, jrapture: A Capture/Replay tool for observation-based testing, in ISSTA, 2000, pp [19] W. Binder, J. Hulaas, and P. Moret, Advanced Java Bytecode Instrumentation, in PPPJ 2007, Lisboa, Portugal, September 5-7, ACM, 2007, pp [20] R. Vallée-Rai, L. Hendren, V. Sundaresan, P. Lam, E. Gagnon, and P. Co, Soot - a Java Optimization Framework, in Proceedings of CASCON 1999, 1999, pp [21] S. Yamazaki, M. Matsumoto, T. Nakanishi, T. Kitasuka, and A. Fukuda, A Case Study of Development of a Java Bytecode Analyzer Framework Using AspectJ, IPSJ Digital Courier, vol. 1, no. 0, pp , [22] S. Becker, H. Koziolek, and R. Reussner, Model-based Performance Prediction with the Palladio Component Model, in Proceedings of the 6th International Workshop on Software and Performance (WOSP2007). ACM Sigsoft, February
ByCounter: Portable Runtime Counting of Bytecode Instructions and Method Invocations
ByteCode 2008 ByCounter: Portable Runtime Counting of Bytecode Instructions and Method Invocations Michael Kuperberg 1 Martin Krogmann 2 Ralf Reussner 3 Chair for Software Design and Quality Institute
Heuristics-based Parameter Generation for Java Methods
Universität Karlsruhe (TH) Research University founded 1825 Heuristics-based Parameter Generation for Java Methods Michael Kuperberg (mkuper@ipd.uka.de) Fouad Omri (fouad.omri@stud.uni-karlsruhe.de) Chair
Visual Amortization Analysis of Recompilation Strategies
2010 14th International Information Conference Visualisation Information Visualisation Visual Amortization Analysis of Recompilation Strategies Stephan Zimmer and Stephan Diehl (Authors) Computer Science
Untyped Memory in the Java Virtual Machine
Untyped Memory in the Java Virtual Machine Andreas Gal and Michael Franz University of California, Irvine {gal,franz}@uci.edu Christian W. Probst Technical University of Denmark probst@imm.dtu.dk July
Method-Level Phase Behavior in Java Workloads
Method-Level Phase Behavior in Java Workloads Andy Georges, Dries Buytaert, Lieven Eeckhout and Koen De Bosschere Ghent University Presented by Bruno Dufour dufour@cs.rutgers.edu Rutgers University DCS
Offloading Java to Graphics Processors
Offloading Java to Graphics Processors Peter Calvert (prc33@cam.ac.uk) University of Cambridge, Computer Laboratory Abstract Massively-parallel graphics processors have the potential to offer high performance
CalFuzzer: An Extensible Active Testing Framework for Concurrent Programs Pallavi Joshi 1, Mayur Naik 2, Chang-Seo Park 1, and Koushik Sen 1
CalFuzzer: An Extensible Active Testing Framework for Concurrent Programs Pallavi Joshi 1, Mayur Naik 2, Chang-Seo Park 1, and Koushik Sen 1 1 University of California, Berkeley, USA {pallavi,parkcs,ksen}@eecs.berkeley.edu
Coupling On-Line and Off-Line Profile Information to Improve Program Performance
Coupling On-Line and Off-Line Profile Information to Improve Program Performance Chandra Krintz Computer Science Department University of California, Santa Barbara ckrintz@cs.ucsb.edu Abstract In this
TRIREME Commander: Managing Simulink Simulations And Large Datasets In Java
TRIREME Commander: Managing Simulink Simulations And Large Datasets In Java Andrew Newell Electronic Warfare & Radar Division, Defence Science and Technology Organisation andrew.newell@dsto.defence.gov.au
A Quantitative Evaluation of the Contribution of Native Code to Java Workloads
A Quantitative Evaluation of the Contribution of Native Code to Java Workloads Walter Binder University of Lugano Switzerland walter.binder@unisi.ch Jarle Hulaas, Philippe Moret EPFL Switzerland {jarle.hulaas,philippe.moret}@epfl.ch
Improving Mobile Program Performance Through the Use of a Hybrid Intermediate Representation
Improving Mobile Program Performance Through the Use of a Hybrid Intermediate Representation Chandra Krintz Computer Science Department University of California, Santa Barbara Abstract We present a novel
Isolating Failure-Inducing Thread Schedules
Isolating Failure-Inducing Thread Schedules by Jong-Deok Choi - IBM T.J. Watson Research Center and Andreas Zeller - Saarland University Marlene Hochrieser FMV - Institute for Formal Models and Verification
Java Garbage Collector Performance Measurements
WDS'09 Proceedings of Contributed Papers, Part I, 34 40, 2009. ISBN 978-80-7378-101-9 MATFYZPRESS Java Garbage Collector Performance Measurements P. Libič and P. Tůma Charles University, Faculty of Mathematics
Parley: Federated Virtual Machines
1 IBM Research Parley: Federated Virtual Machines Perry Cheng, Dave Grove, Martin Hirzel, Rob O Callahan and Nikhil Swamy VEE Workshop September 2004 2002 IBM Corporation What is Parley? Motivation Virtual
YETI. GraduallY Extensible Trace Interpreter VEE Mathew Zaleski, Angela Demke Brown (University of Toronto) Kevin Stoodley (IBM Toronto)
YETI GraduallY Extensible Trace Interpreter Mathew Zaleski, Angela Demke Brown (University of Toronto) Kevin Stoodley (IBM Toronto) VEE 2007 1 Goal Create a VM that is more easily extended with a just
Improving Mobile Program Performance Through the Use of a Hybrid Intermediate Representation
Improving Mobile Program Performance Through the Use of a Hybrid Intermediate Representation Chandra Krintz Computer Science Department University of California, Santa Barbara Abstract Abstract. We present
JPROFILE102: A System for Experimental Analysis of Algorithms
JPROFILE102: A System for Experimental Analysis of Algorithms Tanin Krajangthong and Somchai Prasitjutrakul Department of Computer Engineering Chulalongkorn University Bangkok, Thailand Abstract This paper
Summary: Open Questions:
Summary: The paper proposes an new parallelization technique, which provides dynamic runtime parallelization of loops from binary single-thread programs with minimal architectural change. The realization
MetaVM: A Transparent Distributed Object System Supported by Runtime Compiler
MetaVM: A Transparent Distributed Object System Supported by Runtime Compiler Kazuyuki Shudo Yoichi Muraoka School of Science and Engineering Waseda University Okubo 3-4-1, Shinjuku-ku, Tokyo 169-8555,
Dynamic Metrics for Java
Dynamic Metrics for Java Bruno Dufour, Karel Driesen, Laurie Hendren and Clark Verbrugge McGill University Presented by: Kiran Nagaraja Rutgers University Motivation Compiler optimization techniques span
Introduction to Visual Basic and Visual C++ Introduction to Java. JDK Editions. Overview. Lesson 13. Overview
Introduction to Visual Basic and Visual C++ Introduction to Java Lesson 13 Overview I154-1-A A @ Peter Lo 2010 1 I154-1-A A @ Peter Lo 2010 2 Overview JDK Editions Before you can write and run the simple
Using Adaptive Optimization Techniques To Teach Mobile Java Computing
Using Adaptive Optimization Techniques To Teach Mobile Java Computing Chandra Krintz Computer Science Department University of California, Santa Barbara Abstract Dynamic, adaptive optimization is quickly
Trace Compilation. Christian Wimmer September 2009
Trace Compilation Christian Wimmer cwimmer@uci.edu www.christianwimmer.at September 2009 Department of Computer Science University of California, Irvine Background Institute for System Software Johannes
Executing Legacy Applications on a Java Operating System
Executing Legacy Applications on a Java Operating System Andreas Gal, Michael Yang, Christian Probst, and Michael Franz University of California, Irvine {gal,mlyang,probst,franz}@uci.edu May 30, 2004 Abstract
Automated Benchmarking of Java APIs
Automated Benchmarking of Java APIs Michael Kuperberg 1, Fouad Omri 1, Ralf Reussner 1 1 Chair Software Design & Quality, Karlsruhe Institute of Technology (KIT) Am Fasanengarten 5, 76131 Karlsruhe, Germany
Future of JRockit & Tools
Future of JRockit & Tools Or finding the right layer to attack Joakim Dahlstedt 15 September 2004 A Short Background on JRockit Server-centric JVM Java compatible (most of the Java libraries are Suns)
Reverse Engineering of Parametric Behavioural Service Performance Models from Black-Box Components
Reverse Engineering of Parametric Behavioural Service Performance Models from Black-Box Components Klaus Krogmann, Michael Kuperberg, and Ralf Reussner Institute for Program Structures and Data Organisation
Interaction of JVM with x86, Sparc and MIPS
Interaction of JVM with x86, Sparc and MIPS Sasikanth Avancha, Dipanjan Chakraborty, Dhiral Gada, Tapan Kamdar {savanc1, dchakr1, dgada1, kamdar}@cs.umbc.edu Department of Computer Science and Electrical
Acknowledgements These slides are based on Kathryn McKinley s slides on garbage collection as well as E Christopher Lewis s slides
Garbage Collection Last time Compiling Object-Oriented Languages Today Motivation behind garbage collection Garbage collection basics Garbage collection performance Specific example of using GC in C++
CSE P 501 Compilers. Java Implementation JVMs, JITs &c Hal Perkins Winter /11/ Hal Perkins & UW CSE V-1
CSE P 501 Compilers Java Implementation JVMs, JITs &c Hal Perkins Winter 2008 3/11/2008 2002-08 Hal Perkins & UW CSE V-1 Agenda Java virtual machine architecture.class files Class loading Execution engines
An Approach to the Generation of High-Assurance Java Card Applets
An Approach to the Generation of High-Assurance Java Card Applets Alessandro Coglio Kestrel Institute 3260 Hillview Avenue, Palo Alto, CA 94304, USA Ph. +1-650-493-6871 Fax +1-650-424-1807 http://www.kestrel.edu/
On the Algorithm for Specializing Java Programs with Generic Types
On the Algorithm for Specializing Java Programs with Generic Types Daniel Selifonov, Nathan Dahlberg, Elena Machkasova Computer Science Discipline University of Minnesota Morris Morris MN, 56267 selif004,dahlb061,elenam@umn.edu
Class Analysis for Testing of Polymorphism in Java Software
Class Analysis for Testing of Polymorphism in Java Software Atanas Rountev Ana Milanova Barbara G. Ryder Rutgers University, New Brunswick, NJ 08903, USA {rountev,milanova,ryder@cs.rutgers.edu Abstract
Using Adaptive Optimization Techniques To Teach Mobile Java Computing
Using Adaptive Optimization Techniques To Teach Mobile Java Computing Chandra Krintz Computer Science Department University of California, Santa Barbara Abstract Abstract. Dynamic, adaptive optimization
Java On Steroids: Sun s High-Performance Java Implementation. History
Java On Steroids: Sun s High-Performance Java Implementation Urs Hölzle Lars Bak Steffen Grarup Robert Griesemer Srdjan Mitrovic Sun Microsystems History First Java implementations: interpreters compact
High-Level Language VMs
High-Level Language VMs Outline Motivation What is the need for HLL VMs? How are these different from System or Process VMs? Approach to HLL VMs Evolutionary history Pascal P-code Object oriented HLL VMs
Embedded Device Cooperative System Using Java Bytecode Instrumentation
THE SCIENCE AND ENGINEERING REVIEW OF DOSHISHA UNIVERSITY, VOL. 51, NO. 1 April 2010 Embedded Device Cooperative System Using Java Bytecode Instrumentation Ryota AYAKI *, Kohei KADOWAKI *, Hideki SHIMADA
Static Analysis of Dynamic Languages. Jennifer Strater
Static Analysis of Dynamic Languages Jennifer Strater 2017-06-01 Table of Contents Introduction............................................................................... 1 The Three Compiler Options...............................................................
Parallelizing SPECjbb2000 with Transactional Memory
Parallelizing SPECjbb2000 with Transactional Memory JaeWoong Chung, Chi Cao Minh, Brian D. Carlstrom, Christos Kozyrakis Computer Systems Laboratory Stanford University {jwchung, caominh, bdc, kozyraki}@stanford.edu
Just-In-Time Compilation
Just-In-Time Compilation Thiemo Bucciarelli Institute for Software Engineering and Programming Languages 18. Januar 2016 T. Bucciarelli 18. Januar 2016 1/25 Agenda Definitions Just-In-Time Compilation
A Type System for Object Initialization In the Java TM Bytecode Language
Electronic Notes in Theoretical Computer Science 10 (1998) URL: http://www.elsevier.nl/locate/entcs/volume10.html 7 pages A Type System for Object Initialization In the Java TM Bytecode Language Stephen
Compiling Techniques
Lecture 10: Introduction to 10 November 2015 Coursework: Block and Procedure Table of contents Introduction 1 Introduction Overview Java Virtual Machine Frames and Function Call 2 JVM Types and Mnemonics
Chapter 1 GETTING STARTED. SYS-ED/ Computer Education Techniques, Inc.
Chapter 1 GETTING STARTED SYS-ED/ Computer Education Techniques, Inc. Objectives You will learn: Java platform. Applets and applications. Java programming language: facilities and foundation. Memory management
Performance analysis basics
Performance analysis basics Christian Iwainsky Iwainsky@rz.rwth-aachen.de 25.3.2010 1 Overview 1. Motivation 2. Performance analysis basics 3. Measurement Techniques 2 Why bother with performance analysis
An analysis of object-based intelligent image
An analysis of object-based intelligent image processing and retrieval system Abstract-In order to improve the process of analysis and retrieval of images, it is necessary to examine the execution of such
Parallelism of Java Bytecode Programs and a Java ILP Processor Architecture
Australian Computer Science Communications, Vol.21, No.4, 1999, Springer-Verlag Singapore Parallelism of Java Bytecode Programs and a Java ILP Processor Architecture Kenji Watanabe and Yamin Li Graduate
ICSA 2017 Tutorial Runtime Modeling and Visualization -- Introduction to Palladio
DFG Priority Programme 1593 Design For Future - Managed Software Evolution ICSA 2017 Tutorial Runtime Modeling and Visualization -- Introduction to Palladio R. Heinrich ICSA 2017 Tutorial Introduction
Operating- System Structures
Operating- System Structures 2 CHAPTER Practice Exercises 2.1 What is the purpose of system calls? Answer: System calls allow user-level processes to request services of the operating system. 2.2 What
1 Publishable Summary
1 Publishable Summary 1.1 VELOX Motivation and Goals The current trend in designing processors with multiple cores, where cores operate in parallel and each of them supports multiple threads, makes the
An Object Oriented Runtime Complexity Metric based on Iterative Decision Points
An Object Oriented Runtime Complexity Metric based on Iterative Amr F. Desouky 1, Letha H. Etzkorn 2 1 Computer Science Department, University of Alabama in Huntsville, Huntsville, AL, USA 2 Computer Science
Agent-Enabling Transformation of E-Commerce Portals with Web Services
Agent-Enabling Transformation of E-Commerce Portals with Web Services Dr. David B. Ulmer CTO Sotheby s New York, NY 10021, USA Dr. Lixin Tao Professor Pace University Pleasantville, NY 10570, USA Abstract:
Notes of the course - Advanced Programming. Barbara Russo
Notes of the course - Advanced Programming Barbara Russo a.y. 2014-2015 Contents 1 Lecture 2 Lecture 2 - Compilation, Interpreting, and debugging........ 2 1.1 Compiling and interpreting...................
Run-time Program Management. Hwansoo Han
Run-time Program Management Hwansoo Han Run-time System Run-time system refers to Set of libraries needed for correct operation of language implementation Some parts obtain all the information from subroutine
Reducing the Overhead of Dynamic Compilation
Reducing the Overhead of Dynamic Compilation Chandra Krintz y David Grove z Derek Lieber z Vivek Sarkar z Brad Calder y y Department of Computer Science and Engineering, University of California, San Diego
Object-Oriented Genetic Improvement for Improved Energy Consumption in Google Guava
Object-Oriented Genetic Improvement for Improved Energy Consumption in Google Guava Nathan Burles 1, Edward Bowles 1, Alexander E. I. Brownlee 2, Zoltan A. Kocsis 2, Jerry Swan 1, Nadarajen Veerapen 2
UPnP Services and Jini Clients
UPnP Services and Jini Clients Jan Newmarch School of Network Computing Monash University jan.newmarch@infotech.monash.edu.au Abstract UPnP is middleware designed for network plug and play. It is designed
WHITE PAPER: ENTERPRISE AVAILABILITY. Introduction to Adaptive Instrumentation with Symantec Indepth for J2EE Application Performance Management
WHITE PAPER: ENTERPRISE AVAILABILITY Introduction to Adaptive Instrumentation with Symantec Indepth for J2EE Application Performance Management White Paper: Enterprise Availability Introduction to Adaptive
Jazz: A Tool for Demand-Driven Structural Testing
Jazz: A Tool for Demand-Driven Structural Testing J. Misurda, J. A. Clause, J. L. Reed, P. Gandra, B. R. Childers, and M. L. Soffa Department of Computer Science University of Pittsburgh Pittsburgh, Pennsylvania
On the Design of the Local Variable Cache in a Hardware Translation-Based Java Virtual Machine
On the Design of the Local Variable Cache in a Hardware Translation-Based Java Virtual Machine Hitoshi Oi The University of Aizu June 16, 2005 Languages, Compilers, and Tools for Embedded Systems (LCTES
Black-Box Program Specialization
Published in Technical Report 17/99, Department of Software Engineering and Computer Science, University of Karlskrona/Ronneby: Proceedings of WCOP 99 Black-Box Program Specialization Ulrik Pagh Schultz
Course Overview. PART I: overview material. PART II: inside a compiler. PART III: conclusion
Course Overview PART I: overview material 1 Introduction (today) 2 Language Processors (basic terminology, tombstone diagrams, bootstrapping) 3 The architecture of a Compiler PART II: inside a compiler
Atropos User s manual
Atropos User s manual Jan Lönnberg 22nd November 2010 1 Introduction Atropos is a visualisation tool intended to display information relevant to understanding the behaviour of concurrent Java programs,
An approach to quantifying the run-time behaviour of Java GUI applications
An approach to quantifying the run-time behaviour of Java GUI applications Aine Mitchell, James F. Power Abstract This paper outlines a new technique for collecting dynamic trace information from Java
CE221 Programming in C++ Part 1 Introduction
CE221 Programming in C++ Part 1 Introduction 06/10/2017 CE221 Part 1 1 Module Schedule There are two lectures (Monday 13.00-13.50 and Tuesday 11.00-11.50) each week in the autumn term, and a 2-hour lab
USING JAVA HARTSTONE BENCHMARK IN A REAL-TIME SYSTEMS COURSE
USING JAVA HARTSTONE BENCHMARK IN A REAL-TIME SYSTEMS COURSE Andy Ju An Wang 1 Abstract This paper shows how a Java benchmark program can be utilized in a real-time systems course to emphasize fundamental
A Trace-based Java JIT Compiler Retrofitted from a Method-based Compiler
A Trace-based Java JIT Compiler Retrofitted from a Method-based Compiler Hiroshi Inoue, Hiroshige Hayashizaki, Peng Wu and Toshio Nakatani IBM Research Tokyo IBM Research T.J. Watson Research Center April
CSc 453 Interpreters & Interpretation
CSc 453 Interpreters & Interpretation Saumya Debray The University of Arizona Tucson Interpreters An interpreter is a program that executes another program. An interpreter implements a virtual machine,
Agenda. CSE P 501 Compilers. Java Implementation Overview. JVM Architecture. JVM Runtime Data Areas (1) JVM Data Types. CSE P 501 Su04 T-1
Agenda CSE P 501 Compilers Java Implementation JVMs, JITs &c Hal Perkins Summer 2004 Java virtual machine architecture.class files Class loading Execution engines Interpreters & JITs various strategies
Oak Intermediate Bytecodes
Oak Intermediate Bytecodes A summary of a paper for the ACM SIGPLAN Workshop on Intermediate Representations (IR 95) James Gosling 100 Hamilton Avenue 3rd floor Palo Alto CA 94301 Oak
Practical Java Card bytecode compression 1
RENPAR 14 / ASF / SYMPA Practical Java Card bytecode compression 1 Gabriel Bizzotto Gilles Grimaud LIFL, Universite de Lille 1 Gemplus Research Lab bizzotto@dea.lifl.fr grimaud@lifl.fr Abstract Our work
WHITE PAPER Application Performance Management. The Case for Adaptive Instrumentation in J2EE Environments
WHITE PAPER Application Performance Management The Case for Adaptive Instrumentation in J2EE Environments Why Adaptive Instrumentation?... 3 Discovering Performance Problems... 3 The adaptive approach...
Java Instrumentation for Dynamic Analysis
Java Instrumentation for Dynamic Analysis and Michael Ernst MIT CSAIL Page 1 Java Instrumentation Approaches Instrument source files Java Debug Interface (JDI) Instrument class files Page 2 Advantages
SOFTWARE ARCHITECTURE 7. JAVA VIRTUAL MACHINE
1 SOFTWARE ARCHITECTURE 7. JAVA VIRTUAL MACHINE Tatsuya Hagino hagino@sfc.keio.ac.jp slides URL https://vu5.sfc.keio.ac.jp/sa/ Java Programming Language Java Introduced in 1995 Object-oriented programming
Dynamic Race Detection with LLVM Compiler
Dynamic Race Detection with LLVM Compiler Compile-time instrumentation for ThreadSanitizer Konstantin Serebryany, Alexander Potapenko, Timur Iskhodzhanov, and Dmitriy Vyukov OOO Google, 7 Balchug st.,
Thread-Aware Garbage Collection for Server Applications
Thread-Aware Garbage Collection for Server Applications Woo Jin Kim, Kyungbaek Kim, Jaesun Han, Keuntae Park and Daeyeon Park Department of Electrical Engineering & Computer Science Korea Advanced Institute
VM instruction formats. Bytecode translator
Implementing an Ecient Java Interpreter David Gregg 1, M. Anton Ertl 2 and Andreas Krall 2 1 Department of Computer Science, Trinity College, Dublin 2, Ireland. David.Gregg@cs.tcd.ie 2 Institut fur Computersprachen,
Extended Dataflow Model For Automated Parallel Execution Of Algorithms
Extended Dataflow Model For Automated Parallel Execution Of Algorithms Maik Schumann, Jörg Bargenda, Edgar Reetz and Gerhard Linß Department of Quality Assurance and Industrial Image Processing Ilmenau
Optimising Multicore JVMs. Khaled Alnowaiser
Optimising Multicore JVMs Khaled Alnowaiser Outline JVM structure and overhead analysis Multithreaded JVM services JVM on multicore An observational study Potential JVM optimisations Basic JVM Services
Reflection-based implementation of Java extensions: the double-dispatch use-case
Reflection-based implementation of Java extensions: the double-dispatch use-case Abstract Reflection-based libraries could sometimes be used to extend the expressive power of Java without modifying the
Optimization Coaching for Fork/Join Applications on the Java Virtual Machine
Optimization Coaching for Fork/Join Applications on the Java Virtual Machine Eduardo Rosales Advisor: Research area: PhD stage: Prof. Walter Binder Parallel applications, performance analysis Planner EuroDW
Deriving Java Virtual Machine Timing Models for Portable Worst-Case Execution Time Analysis
Deriving Java Virtual Machine Timing Models for Portable Worst-Case Execution Time Analysis Erik Yu-Shing Hu, Andy Wellings and Guillem Bernat Real-Time Systems Research Group Department of Computer Science
Approaches to Capturing Java Threads State
Approaches to Capturing Java Threads State Abstract This paper describes a range of approaches to capturing the state of Java threads. The capture and restoration of Java threads state have two main purposes:
Dimensions of Precision in Reference Analysis of Object-oriented Programming Languages. Outline
Dimensions of Precision in Reference Analysis of Object-oriented Programming Languages Dr. Barbara G. Ryder Rutgers University http://www.cs.rutgers.edu/~ryder http://prolangs.rutgers.edu/ Research supported,
A Study of Type Analysis for Speculative Method Inlining in a JIT Environment
A Study of Type Analysis for Speculative Method Inlining in a JIT Environment Feng Qian and Laurie Hendren {fqian, hendren}@sable.mcgill.ca School of Computer Science, McGill University Abstract. Method
When Java technology burst onto the Internet scene in 1995,
MOBILE CODE SECURITY SECURE JAVA CLASS LOADING The class loading mechanism, LI GONG Sun Microsystems central to Java, plays a key role in JDK 1.2 by enabling When Java technology burst onto the Internet
metaxa and the Future of Reflection
metaxa and the Future of Reflection Michael Golm, Jürgen Kleinöder University of Erlangen-Nürnberg Dept. of Computer Science 4 (Operating Systems) Martensstr. 1, D-91058 Erlangen, Germany {golm, kleinoeder}@informatik.uni-erlangen.de
Building a Whole-Program Type Analysis in Eclipse
Building a Whole-Program Type Analysis in Eclipse Mariana Sharp Jason Sawin Atanas Rountev ABSTRACT Eclipse has the potential to become a widely-used platform for implementation and dissemination of various
A Type Graph Model for Java Programs
A Type Graph Model for Java Programs Arend Rensink and Eduardo Zambon Formal Methods and Tools Group, EWI-INF, University of Twente PO Box 217, 7500 AE, Enschede, The Netherlands {rensink,zambon}@cs.utwente.nl
JOVE. An Optimizing Compiler for Java. Allen Wirfs-Brock Instantiations Inc.
An Optimizing Compiler for Java Allen Wirfs-Brock Instantiations Inc. Object-Orient Languages Provide a Breakthrough in Programmer Productivity Reusable software components Higher level abstractions Yield
Mixed Mode Execution with Context Threading
Mixed Mode Execution with Context Threading Mathew Zaleski, Marc Berndl, Angela Demke Brown University of Toronto {matz,berndl,demke}@cs.toronto.edu (CASCON 2005, Oct 19/2005.) Overview Introduction Background:
Reducing the Overhead of Dynamic Compilation
Reducing the Overhead of Dynamic Compilation Chandra Krintz David Grove Derek Lieber Vivek Sarkar Brad Calder Department of Computer Science and Engineering, University of California, San Diego IBM T.
FedX: A Federation Layer for Distributed Query Processing on Linked Open Data
FedX: A Federation Layer for Distributed Query Processing on Linked Open Data Andreas Schwarte 1, Peter Haase 1,KatjaHose 2, Ralf Schenkel 2, and Michael Schmidt 1 1 fluid Operations AG, Walldorf, Germany
Towards Performance Measurements for the Java Virtual Machine s invokedynamic
Towards Performance Measurements for the Java Virtual Machine s invokedynamic Chanwit Kaewkasi School of Computer Engineering Suranaree University of Technology Nakhon Ratchasima, Thailand 30000 chanwit@sut.ac.th
InsECTJ: A Generic Instrumentation Framework for Collecting Dynamic Information within Eclipse
InsECTJ: A Generic Instrumentation Framework for Collecting Dynamic Information within Eclipse Arjan Seesing and Alessandro Orso College of Computing Georgia Institute of Technology a.c.seesing@ewi.tudelft.nl,
RATCOP: Relational Analysis Tool for Concurrent Programs
RATCOP: Relational Analysis Tool for Concurrent Programs Suvam Mukherjee 1, Oded Padon 2, Sharon Shoham 2, Deepak D Souza 1, and Noam Rinetzky 2 1 Indian Institute of Science, India 2 Tel Aviv University,
Single-pass Static Semantic Check for Efficient Translation in YAPL
Single-pass Static Semantic Check for Efficient Translation in YAPL Zafiris Karaiskos, Panajotis Katsaros and Constantine Lazos Department of Informatics, Aristotle University Thessaloniki, 54124, Greece
Hardware-Supported Pointer Detection for common Garbage Collections
2013 First International Symposium on Computing and Networking Hardware-Supported Pointer Detection for common Garbage Collections Kei IDEUE, Yuki SATOMI, Tomoaki TSUMURA and Hiroshi MATSUO Nagoya Institute
Intel VTune Performance Analyzer 9.1 for Windows* In-Depth
Intel VTune Performance Analyzer 9.1 for Windows* In-Depth Contents Deliver Faster Code...................................... 3 Optimize Multicore Performance...3 Highlights...............................................
ANALYZE OF PROGRAMMING TECHNIQUES FOR IMPROVEMENT OF JAVA CODE PERFORMANCE
ANALYZE OF PROGRAMMING TECHNIQUES FOR IMPROVEMENT OF JAVA CODE PERFORMANCE Ognian Nakov, Dimiter Tenev Faculty of Computer Systems And Technologies, Technical University-Sofia, Kliment Ohridski 8, Postal
EVALUATING DATA STRUCTURES FOR RUNTIME STORAGE OF ASPECT INSTANCES
MASTER THESIS EVALUATING DATA STRUCTURES FOR RUNTIME STORAGE OF ASPECT INSTANCES Andre Loker FACULTY OF ELECTRICAL ENGINEERING, MATHEMATICS AND COMPUTER SCIENCE (EEMCS) CHAIR OF SOFTWARE ENGINEERING EXAMINATION