− Whereas polling was a relatively minor source of overhead with our unoptimized transformations, it becomes the second most im- portant source of overhead after application of all optimizations. Loops remain a source of overhead because they increase the fre- quency of polling. We are currently working on a loop unrolling technique where a dedicated, local counter is used to create an- other level of (less frequent) polling and accounting inside loops; this idea is somewhat related to the “virtual” check mentioned by Feeley . Whereas this optimization seems promising for loop- intensive, scientific applications, it is not yet certain that there will be a real benefit for more varied code, like SPEC JVM98.
− Method inlining would contribute significantly to the reduction of all overheads: by eliminating invocations, many occurrences of Step 1 and Step 2 would disappear, and by merging method bodies, it would create further opportunities for SPP to identify long, likely execution paths. We have made a preliminary test with the Soot Framework14 , to apply method inlining on SPEC JVM98 (but excluding the JDK) before rewriting with J-RAF2 (using the per-platform best settings, as described above): compared to the geometric means in Figure 13, the resulting overhead was un- changed for the IBM JVM, whereas we obtained a drastic 10–15% decrease in overhead for the Sun JVM in all execution modes. Since the effect of method inlining with Soot on JVM98 (before J- RAF2 rewriting) is noticeably lower, it confirms that inlining has a very welcome lever effect on our own optimizations. As a disad- vantage, however, whole-program optimizations are not necessarily compatible with dynamic class-loading; dynamic instrumentation capabilities would be required to address this issue.
− If the aggregation of all other optimizations does not yield suffi- ciently low overheads, it may be advisable to relax the accounting accuracy. Beyond the extreme example of aggressive approxima- tion, the exact relationship between the level of approximation and the resulting overhead remains to be studied.
The CPU accounting scheme based on our bytecode transformation techniques offers the following benefits, which make it an ideal candi- date for enhancing Java server environments and mobile object systems with resource management features: