Link Point Tracking

Link Point tracking is a problem created by code optimisation. The problem is there- fore only limited to Link Points in instructions. During IR optimisation, instructions may be mutated and sequences of instructions may be changed. As a result, labelled Link Points on the instruction are no longer valid if the labelled operand or instruc- tion does not exist anymore. A Link Point would be invalid in two nonexclusive situations made by code optimisation. Due to the limitations of the implementation on the optimising compiler, Link Points would not fully follow instruction mutation as described above, and would lead to the loss of relocation information. Therefore, the following solution is applied to the problem.

If the semantic description of the labelled operand changes by optimisation, the associated Link Point becomes invalid. The invalid Link Points should be removed in the compilation. For example, applying a constant propagation operation on a floating point instruction can lead to a new floating point value by performing the instruction at compilation time. As a result, the two original floating point values are removed from the code, as well as the Link Point associated with them.

In the case that a labelled location of a Link Point becomes invalid because of instruction mutation, the check point for validating the Link Point is deployed be- tween IR conversion and the optimisation phase to ensure the correctness of location information of the link point. Location information is composed of the label operand and the associated instruction. LPVP is used to recover the valid one of those two elements of location information. If any Link Point loses all the location information and becomes untraceable, as identified by any of the LPVP phases, the compilation output will not be valid for relocation purposes. The LPVP phase is setup as a guard to ensure the binary is valid for relocation.

4.10. Summary 67

4.10

Summary

This chapter introduces the design and implementation of the code migration frame- work to provide re-usability of binaries produced by dynamic compilation. It de- scribes the concepts and architecture that accommodates various user scenarios and details how to construct a mechanism to provide code relocation and a format to store compiled binary and relocation information. The Apus image production and procedure loading details in this chapter show how to ensure the binary produced by dynamic compilation can be used under different execution instances systematically.

C

h

a

p

t

e

r

5

Proxy Compilation Protocol

(PCP) Design

Research is to see what everybody else has seen, and to think what nobody else has thought. Albert Szent-gy¨orgi _{(1893–1986)}

Proxy compilation requires a mechanism to migrate binaries that are generated by the proxy compiler service to the user agent in client hosts. This problem was discussed in the previous chapter and a code migration framework was introduced to handle formatted binaries to deal with issues relevant to binary relocation, such as binary integrity and dependency verification to the corresponding bytecode.

Proxy compilation also requires a mutually agreed communication protocol be- tween the proxy compilation server and the user agent. In this chapter, we will start with the design requirements for the proxy compilation protocol. Then the protocol specification is given with an example of a PCP session. Implementation of the proxy compilation protocol over the code migration framework is described, finally followed by a further improvement on the protocol.

5.1. PCP Design Requirements 69

5.1

PCP Design Requirements

The protocol itself should not attempt to understand the binary format, that may or may not be Apus images from the compilation server (although the protocol is implemented based on code migration framework), nor should the protocol should specify the compiler behind the proxy compilation server host. The purpose of the protocol is intended to permit a JVM user agent to dynamically access a compiler on a server host in a useful fashion.

As a result, the protocol should specify how to deal with the communication for proxy compilation for JVM user agents. As the purpose of migrating is online code optimisation cost, operating the protocol itself should be light-weight without out-weighing the code optimisation. Additionally, the initial intention of the proxy compilation system is to provide code optimisation for a resource-constrained envi- ronment, although it is the fact that the implementation of the system is based on Jikes RVM, which is only currently available for the desktop environment.

From what it is described above as the background of PCP, we can easily conclude that the design requirement in principle for PCP can be described as follows:

ˆ Functionality - The protocol should specifically have to provide a proxy com-

pilation service only. It also should be able to provide what is needed to manipulate a compilation with priority constraints.

ˆ Independent - The protocol should not depend on any specific hardware, JVM,

compiler or binary format.

ˆ Efficient - The efficiency of the protocol is important, including both a time

and be cost efficient. Firstly, the protocol should minimise a compilation cycle to be able to complete more compilation in a limited period. Secondly the protocol should be able to operate in a limited resource environment. Lastly it is important to reduce the data transmission cost from and to the user agent in the client host.

ˆ Extensibility - The protocol should be such that any necessary changes can be

made consistently and easily.