13.10.2014 Views

OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

118<br />

bytecodes. The number of specialized bytecodes increases to 8 when the top 40 store<br />

bytecodes are considered. If the selection of store bytecodes was performed perfectly,<br />

the 20 most frequently executed store bytecodes would be specialized bytecodes.<br />

It was further observed that of the 8 specialized store bytecodes that do reside in<br />

the 40 most frequently executed store instructions, only two access either slot 0 or slot<br />

1 (the slots that are used to hold method parameters with greatest frequency). This<br />

behavior is due to the parameter structure of the virtual machine and the semantics<br />

associated with method parameters in Java. As has been mentioned previously, the<br />

virtual machine arguments are stored in the first local variable slots which generally<br />

reduces the number of accesses to those slots. This is particularly true for stores to<br />

those slots because Java only supports pass by value semantics for primitive types,<br />

including object references. As a consequence, any value that is stored into a slot<br />

holding a method parameter will only be retained within the scope of the current<br />

method. The updated value will not appear in the calling scope. This design decision<br />

severely restricts the number of stores performed on slots containing method<br />

parameters. Note that this design choice does not prevent fields in objects passed as<br />

parameters to methods from changing since it is the object reference that is passed<br />

by value, not all of the data members that make up the object. As a consequence,<br />

changing the value of a field in an object is changing the value in a memory location<br />

stored on the heap, not in the local variable array.<br />

Comparing the frequency of execution of the most executed load bytecodes with<br />

that of the most frequently utilized store bytecodes reveals that loads are executed<br />

much more often than stores. This is typical of a stack based architecture as most<br />

operations load two or more values onto the stack in order to generate a single result<br />

value that must be stored back into a local variable. While it is difficult to compare<br />

the graphs directly due to their differing y-axis scales, examining the data reveals<br />

that only 7 of the most frequently executed store bytecodes execute with more frequency<br />

than aload 0x0f, the 40 th most frequently executed load bytecode. This<br />

indicates another area where future virtual machine designers should consider eliminating<br />

symmetry from their instruction set design. Since loads are performed with<br />

much greater frequency than stores on a stack based architecture, more instructions<br />

should be devoted to specialized load bytecodes than to specialized store bytecodes.<br />

Figure 6.4 shows the 40 least frequently executed store bytecodes. Examining<br />

the graph reveals that there are 5 specialized bytecodes present, 4 of which do not<br />

contribute sufficiently for their bars to be visible. Further examination of the data<br />

reveals these 4 specialized bytecodes (fstore 0, fstore 1, fstore 2 and dstore 0)

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!