X hits on this document

PDF document

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





19 / 40


void f(int x, ThreadCPUAccount cpu) { cpu.consumption += ...; if (cpu.consumption >= 0) cpu.triggerConsume(); g(cpu); Start: cpu.consumption += ...; if (cpu.consumption >= 0) cpu.triggerConsume(); if (x > 0) { cpu.consumption += ...; if (h(x, cpu)) { cpu.consumption += i(x, cpu); } cpu.consumption += --x; goto Start; } cpu.consumption += ...; ...; ...;


Figure 9. Method rewritten for CPU accounting. The ThreadCPUAccount is passed as extra argument.

This approach works when all client classes of a transformed class can also be transformed, such that all method invocation sites are updated to use the corresponding extended method signatures. Some- times, however, this is not possible, such as when a Java method is invoked by native code or via the reflection API. In order to cope with such cases, we have to leave in all classes stubs with the original method signatures, which act as wrappers for the methods with the additional ThreadCPUAccount argument, as shown in Figure 10. Therefore we call this general argument passing scheme the Wrapper rewriting scheme.

void f(int x) { ThreadCPUAccount cpu = ThreadCPUAccount.getCurrentAccount(); cpu.consumption += ...; // account for execution of wrapper f(x, cpu);


Figure 10. Example wrapper method with unmodified signature.

Another issue concerns the Wrapper rewriting of the JDK. In some cases, native code in the JDK assumes that it will find a required piece of information at a statically known number of stack frames below itself. This is unfortunately incompatible with the generation of wrapper methods, which introduces extra stack frames into the stack at runtime. For this reason, the JDK cannot take advantage of the more efficient wrapper rewriting scheme, and has to invoke jdkGetCurrent-

Document info
Document views153
Page views153
Page last viewedSun Jan 22 18:19:23 UTC 2017