OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

171
// iload_1:
stack[sp+1] = local_vars[1];
// iconst_1:
stack[sp+2] = 1;
// iadd:
stack[sp+1] = stack[sp+1] + stack[sp+2];
// istore_2:
local_vars[2] = stack[sp+1];
In theory, an optimizing compiler should be able to remove all of these stack
adjustments. In practice, it was found that this was not the case. Testing was performed
on the actual codelets used by the Kaffe virtual machine. They differ slightly
from the codelets presented here because Kaffe uses a pointer based representation
for the stack instead of an integer index. When those codelets were evaluated, it was
observed that the assembly language code generated by g++ using optimization level
4 is different for each of these code segments. The assembly language code for the
case when the stack adjustments were removed by hand is 3 lines shorter than the
assembly language code generated for the original code. The longer code is the result
of two places where the stack pointer is still explicitly adjusted. The third is present
because the final assignment from stack[sp+1] to local vars[2] is performed as
written when the stack adjustments are present. When the stack adjustments are
removed, this assignment is performed by making use of the fact that the value of
stack[sp+1] was already present in a register.
Further optimizations can be performed which are impossible for any optimizing
compiler to perform. While the programmer has assigned stack semantics to the stack
array, there is no way for the compiler to know this. Consequently, any optimizations
that can be derived from the properties of a stack are not available to a general
purpose compiler. Since sp points to the slot which represents the top of the stack at
any given point in time, it is known that any location beyond stack[sp] represents
a location that is beyond the top of the stack. A stack can only grow to encompass
such memory locations again by performing push operations. Therefore, it is known
conclusively that, outside of the codelet for the multicode being optimized, these
memory locations will be written to before they are read again. As a result, any
writes to such memory locations are unnecessary provided that they are not read
subsequently within the same codelet.