mpeg- jess db javac audio
Geo . jk mtrt ac mean
Sun JDK 1.5.0, interpreted 96.6%
179.8% 149.3% 166.1% 57.3%
224.0% 152.5% 140.8%
Sun JDK 1.5.0, client
Sun JDK 1.5.0, server
IBM 1.4.2, default
180% 160% 140% 120% 100% 80% 60% 40% 20%
Figure 7. Overhead of CPU accounting without optimizations.
instructions, which makes its influence on the overheads negligible in practice.
For all tests, unless noted otherwise, both the JDK and the JVM98 benchmarks were rewritten according to the tested strategy. One diffi- culty is that many JVMs do not allow certain core JDK classes to be transformed: they will either crash, or simply use internal, hardwired implementations and disregard the corresponding bytecode-level repre- sentations. With the java.lang.Object class, we were therefore able to rewrite only a subset of the methods. The java.lang.Thread class, on the other hand, was patched, as explained in Section 3.3. On the virtual machines considered here, no other classes required any special treatment.
The measurement to which all optimizations will be compared is the result of the unoptimized transformation scheme introduced in Sec- tion 3, which we call the Simple rewriting scheme. The corresponding execution time overhead introduced by this scheme as compared to the original, non-rewritten benchmark, is shown in Figure 7. The rewriting increased the size of the corresponding class files by 17% (we refer to Section 7.3 for a discussion on code size).
4.2. Origin of Overhead
We next analyze the origin of the overhead of our bytecode transfor- mations, in order to be able to devise targeted optimization schemes.