X hits on this document

PDF document

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

98 views

0 shares

0 downloads

0 comments

21 / 40

21

the original method has a shorter argument list. We found by sys- tematic testing that, for the IBM Java platform, the best position for the ThreadCPUAccount is the 2nd, both for virtual methods (the this object reference being number zero), and for static methods. Figure 11 illustrates the insertion of dummy arguments for this configuration, with methods 1–3 being virtual, and methods 5–7 static. Note that for the first two methods in Figure 11, ThreadCPUAccount is successfully set as second argument. In contrast, the third example method already takes three arguments (including the implicit this reference), therefore ThreadCPUAccount has to come at the third position. 10

1: 2: 3:

v() v(int) v(int,long)

  • --

    >

  • --

    >

  • --

    >

v(Dummy,ThreadCPUAccount)

v(int, v(int,

ThreadCPUAccount) long, ThreadCPUAccount)

5: static s() 6: static s(int) 7: static s(int,long)

  • --

    >

  • --

    >

  • --

    >

static s(Dummy,Dummy,ThreadCPUAccount)

static s(int, static s(int,

Dummy,ThreadCPUAccount) long, ThreadCPUAccount)

Figure 11. Examples of the insertion of ‘dummy’ arguments.

According to Table I, this scheme only seems to be profitable to the IBM platform, and then only marginally so. However, with all accounting code incorporated, this transformation reduces the total overhead by 2–3% on that JVM.

6. Reducing the Overhead of Accounting

As we have seen in Figure 7, the accounting itself (i.e. keeping the value of the CPU account up-to-date), is a fairly expensive task, responsible for about 50% of the overhead. This is due to the frequent accesses to the CPU account, which take place at each conditional branch in code transformed with the Simple scheme. Therefore, we introduce a new path prediction scheme, the role of which is to reduce the number of updates made to the CPU account, by trying to predict statically

  • i.e. during the bytecode transformation – the outcome of the condi-

tional branches that will be taken at runtime. The resulting effect is that chains of accounting blocks that are predicted to be executed in sequence will be merged into a single block requiring only one update of the CPU account. As a consequence, overheads will be reduced if

10 Whereas it is relatively trivial to append new items to the end of an argu- ment list, shifting the position of existing arguments is more difficult to implement efficiently, since it requires the transformation tool to analyze the operand stack upstream of each invocation site.

Document info
Document views98
Page views98
Page last viewedMon Dec 05 21:25:10 UTC 2016
Pages40
Paragraphs801
Words13591

Comments