A plan of action for the remainder of the research [55].
To validate that an interpreter is fast enough to support handlers inside the kernel, we will compare a kernel embedded interpreter approach with a trusted compiler solution as well as software based fault isolation. The measurements will be performed using the Puma operating system. This system is currently running on the Intel Paragon using Intel i860 RISC CPUs. It also runs on the Intel Teraflop architecture which uses Intel Pentium Pro (P6) CISC CPUs.
Puma will be modified to let a user program install a portal event handler at runtime. The handler can be written in R-code and will be interpreted when a message arrives. The handler can also be a binary that has undergone software based fault isolation. Alternatively, the handler can simply be trusted, assuming it came from a trusted compiler. In the latter two cases no interpretation during execution time takes place; the inserted handler is executed directly. Baseline comparisons will be made against the standard user-level portal event handlers of Puma. A handler that takes longer to execute inside the kernel, than the same handler at user level including the context switch overhead, should probably be run at user level.
During the insertion of software isolated code, the algorithm described in [102] should be applied. However, since we are mainly interested in the measurement of execution time, not code insertion time, we will most likely forgo this verification step.
The simplest way to integrate code from a trusted compiler, is to directly link it into the kernel. Insertion then consists of selecting the appropriate routine to be executed on message arrival. This is a sufficient procedure to measure execution time of such handlers. It does not address the cost of linking and binding, nor the runtime system overhead of a type-safe language. Linking and binding costs are paid at code insertion and will be more or less ignored by this research. Runtime system overhead has to be taken into consideration, though. All handlers, whether trusted, interpreted, or software fault isolated, should be represented by the same C source to make the comparison fair. To estimate the runtime system overhead of a type-safe language, we will modify the C compiler to insert instructions that model bounds checks.
We will measure the performance of representative handlers for broadcast, MPI, Split-C, and Cilk. Ideal test conditions require that the same source code is used for each handler in any of the three insertion methods. For this reason we will use the retargetable C compiler lcc [35], and modify it in the following manner.
For the first experiment, we will retarget lcc so that it produces R-code. R-code will be the same for the i860 and x86 architecture. There exists already a back-end for lcc that produces x86 code. A member of the Puma team is currently building a back-end for the i860. For the second experiment, these back-ends will be modified to insert software isolation code before each load, store, and jump instruction. This will produce software isolated code. For the third set of experiments we will modify the x86 and i860 back-ends to introduce range checks, and other runtime checks typically performed by the runtime environment of a type-safe language such as Modula-3 used in the SPIN project.
Therefore, the same compiler (with different back-ends) will be used to generate code for all three techniques on a RISC and a CISC architecture. The operating system and the test applications are going to be the same for all six possible configurations. Table 5.1 shows all six configurations under which each test will be performed.
Table 5.1: Test Configurations
To determine the tradeoff between kernel insertion and up-calls, we will also measure the cost of using the Puma portal event handler up-call mechanism. Again, the handlers will be compiled using lcc. No protection mechanisms will be compiled into these handlers, since they run at user level.
Table 5.2 lists the steps to be performed and approximate completion dates:
