X hits on this document

PDF document

Program Transformations for Light-Weight CPU Accounting and Control in the Java Virtual Machine A ... - page 34 / 40





34 / 40


issue by patching the aforementioned methods of java.lang.Class to filter out the reflection objects that represent methods with extended signatures. This modification is straightforward, because in standard JDKs these methods are implemented in Java (and not in native code). Note that this issue is only relevant if an optimized program transfor- mation scheme is used; for the Simple rewriting scheme, such problems with reflection cannot happen.

7.7. Further Extensions

Whereas the primary motivation for this work was to monitor and control the CPU consumption of deployed software, we are exploring several other applications and extensions of our bytecode rewriting techniques:

  • 1.

    Profiling at the bytecode level may employ transformation tech- niques closely related to the ones described here. Profiling allows a detailed analysis of the resource consumption of programs under development. It helps to detect hot spots and performance bottle- necks, guiding the developer to the parts of a program that should be improved. We have shown in [6] that this approach allows exact profiling with overheads that are about two orders of magnitude lower15 than standard tools for Java. Thus, the developer no longer has to carefully select the sub-parts of his application that he wants to profile.

  • 2.

    While profiling provides detailed execution statistics about individ- ual methods (e.g., calling context, invocation counter, CPU time, etc.), benchmarking evaluates the overall performance (CPU con- sumption, memory utilization, etc.) of a program. Benchmarking at the bytecode level is a tool which helps compare the cost of different algorithm implementations (for a given input), at a higher level than what platform-dependent, plain execution times offer [5].

3. Most tools for aspect-oriented programming, such as AspectJ [24], allow to define pointcuts, such as method invocations, the beginning of exception handlers, etc. However, they do not give access to con- trol flow entities like loops and basic blocks, and are therefore not appropriate tools for the insertion of accounting code. Moreover, it would be difficult to specify our particular scheme of passing accounting objects as extra arguments (which involves the auto- mated creation of wrapper methods or the duplication of code)

15 This overhead is however higher than with J-RAF2 because there is much more information to collect and manage.

Document info
Document views146
Page views146
Page last viewedFri Jan 20 16:49:39 UTC 2017