OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

96
The issue of underutilized specialized load and store bytecodes is further complicated
by another design choice made by the designers of the Java Virtual Machine.
Any time an invokevirtual, invokespecial or invokeinterface bytecode is used,
the receiver object, on which the method is being invoked, is passed as the first argument
to the method. It is passed just like any other method parameter. Consequently,
the receiver object always resides in slot 0 in the called scope. This allows the specialized
bytecode, aload 0 to be executed frequently because a reference to the receiver
object is required for every same class field access and method invocation. In fact,
examining Table 5.1 reveals that aload 0 is the most frequently executed specialized
bytecode. However, because the receiver object always resides in local variable slot
0, the bytecodes dload 0, fload 0, iload 0 and lload 0 can never execute in any
instance method.
Specialized store instructions are executed with even less frequency than specialized
load instructions. While specialized store instructions such as istore 0,
fstore 2 and dstore 3 are available for the first four local variable slots, they are
rarely used. This is because the Java Virtual Machine only provides support for pass
by value parameter passing semantics for its primitive numeric types and object references.
Consequently, any write to a local variable that contains a parameter passed
to the method will not be visible in the calling scope. While it is possible that a
parameter variable may be updated during a computation, such code is rare.
Writes to local variable zero are even more uncommon. In an instance method,
a write to local variable slot 0 is impossible. The dstore 0, fstore 0, istore 0
and lstore 0 bytecodes cannot execute in such a method because local variable
slot zero is occupied by the receiver object. It is also impossible for astore 0 to
execute in a virtual method because that operation represents assigning a new object
reference to the receiver object – an operation that is prohibited by the Java Language
Specification because the this variable is final [51].
5.2.3 Category 2: Benchmarks that Show Decreased Performance
as a Result of Despecialization
The second category of benchmark performance covers all of those benchmarks that
showed an increase in runtime (poorer performance) as the number of despecializations
performed increased. This was the result that was initially anticipated to be
most common. However, it was found that only 25 percent of the benchmarks tested
generated results that reside in this category.