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.

140<br />

identify the branch targets and exception handler boundaries. A further analysis<br />

would have determined how many times each sequence of bytecodes was present.<br />

Unfortunately, such an analysis was unlikely to identify good candidates for multicodes<br />

because it entirely fails to consider which bytecodes are executed once, which<br />

bytecodes are executed many times and which bytecodes are never executed as the<br />

application runs. As a result, it was necessary to consider another profiling technique<br />

that would overcome these limitations.<br />

7.3.3 An Initial Approach to Dynamic Profiling<br />

Dynamic profiling records information about an application as it executes. It can<br />

be used to overcome the limitations associated with static profiling. A copy of the<br />

Kaffe virtual machine was modified in order to collect the profile information needed<br />

to determine which candidate sequences were executed with greatest frequency. The<br />

information collected included:<br />

• Every bytecode executed, and the program counter value for the bytecode.<br />

• The name of each method executed.<br />

• A list of branch and exception targets for each method executed.<br />

Each opcode was recorded as it was executed. The program counter value associated<br />

with the opcode was needed in order to determine the multicode block boundaries<br />

within the profile data.<br />

The first time a method was invoked, its fully qualified name and signature was<br />

recorded. In order to reduce the memory requirements of profiling, a unique integer<br />

was assigned to each method. It was used to identify subsequent invocations of the<br />

method so it was not necessary to store its fully qualified name multiple times.<br />

The branch structure for each method was also computed and stored the first time<br />

the method was invoked. This information was required in order to break the profile<br />

data into multicode blocks once it was collected.<br />

Once the profile data was collected, it was converted from a list of bytecodes<br />

and method invocations into a list of multicode blocks. This involved reading every<br />

bytecode executed and its program counter value from the profile data, and writing<br />

the bytecode to the list of multicode blocks. Because the program counter value for<br />

each bytecode, and the branch structure for each method was recorded, sufficient<br />

information was available to determine which bytecodes represented the start of a

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

Saved successfully!

Ooh no, something went wrong!