X hits on this document

PDF document

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





30 / 40


the required offsets are too large.13 Whereas the Simple transforma- tion scheme only slightly expands existing offsets, the more advanced schemes, like the SPP transformation, may from time to time generate new jumps over longer distances inside the method body, in order to execute accounting correction code. An enhanced version of SPP should try harder than now to minimize jumping.

Other limits that might - in extreme situations - be reached after the transformation are e.g. the number of local variables in a method, or the number of methods in a class (in the case of Wrapper rewriting with code duplication). If any of these limits is exceeded, BCEL will throw an exception and our tool will in turn reject the guilty method.

7.4. Opportunities for Further Optimizations

First, it should be noted that in our performance measurements the number of iterations of SPEC JVM98 was changed from the default setting of 2–4 up to 40. This has the effect of enabling each JVM to fully utilize its internal optimization capabilities, and hence it increases the reproducibility of the experiments. As a negative consequence, some JVMs now exhibit perceptibly higher overheads than were found in our previous experiments [21] (this concerns essentially the IBM JVM 1.4.2). We may therefore conclude that the overheads presented here are especially relevant to server environments, whereas short-running applications will often show a better relative performance.

The optimizations that we have presented here reveal the limits of our design goal of resorting only to intraprocedural optimizations. We see several research directions for further reducing the overhead:

Improving the SPP prediction capability on a per-application basis with feedback from off-line profiling, as described in [25]: this would make the SPP scheme semi-static instead of purely static, but the predictions and resulting transformations for each given applica- tion would still remain portable. The interest of this technique is supported by the measurements we made, which show that the current SPP implementation strongly benefits ‘mpegaudio’, which seems to have fairly predictable branches, whereas it actually in- creases the overhead of ‘jack’, which has a rather unusual control flow, notably a frequent use of exceptions [10, 27].

13 Unfortunately, the current version of BCEL (v 5.1) does not transparently transform conditional branches since they do not have wide equivalents, and would require instead a transformation into a combination of instructions with one short and one long offset.

Document info
Document views151
Page views151
Page last viewedSun Jan 22 06:49:40 UTC 2017