X hits on this document

PDF document

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

117 views

0 shares

0 downloads

0 comments

20 / 40

20 Table I. Overheads and optimizations for Step 1.

Simple–Simple

81.9%

9.1%

5.9%

18.2%

Wrapper–Simple

35.9%

4.2%

5.7%

5.3%

Wrapper–Wrapper

8%

4.3%

7.0%

2.5%

+Fixed arg passing

8.8%

4.6%

7.2%

2.4%

Rewriting mode:

JVM98-JDK

Sun 1.5.0 server

IBM 1.4.2

Sun 1.5.0

interpret

ed

Sun 1.5.0

client

Account() in the beginning of every method. We can however, at the expense of a comprehensive class hierarchy analysis process, completely duplicate most JDK methods, so that there always is one version with the original signature, and a second one with the additional Thread- CPUAccount argument. This approach works well, but is quite complex, and unfortunately results in an appreciable speedup only with certain JVMs. Further details on this are to be found in [3].

Looking at Table I, we can see that considerable progress has been made, starting from our reference, at the first line, i.e., the overhead when rewriting both SPEC JVM98 and JDK in Simple mode. The optimizations designed for Step 1 are particularly beneficial on the Sun JVM in interpreted mode, which does not have the ability to dynami- cally inline the ubiquitous invocation to jdkGetCurrentAccount(), nor the invocations that the inlined body of getCurrentAccount() itself contains. As expected, Wrapper mode rewriting brings the best speedup to applications that have the highest ratios of method invocations, like ‘mtrt’ and ‘compress’ [17]. In fact, rewriting the application layer (here: SPEC JVM98) in Wrapper mode is always a benefit, but rewriting also the JDK in Wrapper mode is only interesting on half of the platforms (Sun JVM in interpreted mode and IBM). The last line of the table, entitled +Fixed arg passing, will be described in the next section.

5.2. Fixed Argument Passing

In this section we further improve the way the ThreadCPUAccount reference is passed as an extra argument upon method invocation. Our hypothesis is that if this extra argument is passed always at the same, fixed position in the argument list, the JIT (if any) may skip some machine instructions that would be required to shift this argument from one position to another between two invocations.

To achieve this effect, the bytecode transformation tool will some- times have to insert dummy arguments at the lower positions, when

Document info
Document views117
Page views117
Page last viewedSat Dec 10 21:26:53 UTC 2016
Pages40
Paragraphs801
Words13591

Comments