X hits on this document

PDF document

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

85 views

0 shares

0 downloads

0 comments

29 / 40

compress

jess

db

javac

mpegaudio

mtrt

jack

4,9 · 108

7,6 · 108

1,5 · 107

1,0 · 104

2,7 · 108

6,2 · 106

6,4 · 103

Table IV. Relative inaccuracy of the computed number of executed bytecodes.

29

instructions in the accounting block not to be executed, even though they have been included in the consumption counter. Consequently, the computed consumption may indicate more bytecodes than really executed. The degree of this inaccuracy was determined by comparison with the exact number of executed bytecodes, which was obtained by modifying our accounting block analysis so that any bytecode that may throw an exception ends a block. While this allows fully precise bytecode counting, the overhead is high (code size and execution time), because many more locations are instrumented.

As illustrated in Table IV, the relative inaccuracy is below 0,1% for all benchmarks except ‘jack’, which is known to be a particularly exception-intensive program [10, 27]. We conclude that our chosen accounting block analysis reconciles accurate bytecode counting with reduced instrumentation overhead.

7.3. Impact on Code Size

One of our goals in designing the optimizations is to limit the num- ber of bytecode instructions added during the transformations. This is to avoid negative effects on locality, which may reduce overall per- formance, and also to help making J-RAF2 a reasonable option for embedded devices, with less memory than desktop and server systems. The Simple rewriting scheme expands the code by 17%, whereas the SPP transformation increases the size by 14% (averages calculated on the JDK class files of both Sun 1.5.0 and IBM 1.4.2).

The increased size may result in code validity problems if, before transformation, a method already is close to the limits defined by the JVM specification [26] (the maximum number of bytecodes in a method is 64K) and its instruction set (standard unconditional jumps and conditional branches may only express positive and negative offsets of 32K bytecodes). It is the task of the lower layer of our tool (currently provided by BCEL [15]) to ensure the transparent conversion of jumps and branches into their wide, 64K bytecodes-enabled counterparts when

Document info
Document views85
Page views85
Page last viewedSat Dec 03 05:11:41 UTC 2016
Pages40
Paragraphs801
Words13591

Comments