In join-calculus, a name definition, all receptors on that name and all possible synchronizations on that name are grouped altogether in a single join definition. This enables the compilation of synchronization between concurrent or even distributed processes, using finite-state automata. In the distributed case, a message transport phase to the machine that currently hosts the join definition (and hence the automaton) is first performed. This strengthens our point of view that the join-calculus is the core of a distributed programming language that can be compiled in practice, mainly because it restricts reception on a channel to statically known parts of the program. The same argument applied to à la ML polymorphic typing in [6].
Taking a few benchmarks (see table 1, or here) as a set of sensible join programs, both the join and the jocaml pattern matching compilation schemes prove adequate. In particular, none of the two schemes falls into the pitfall associated to the compilation technique used.
In the join case, one can be afraid of code size, the technique exposed in section 5.3 successfully avoids code size explosion in practical cases. The jocaml technique appears expensive in runtime checks and thus a priori produces slow code. We choose such a scheme of implementing automata using generic code, because it can be implemented simply by adding code to the Objective Caml bytecode interpreter. Using bytecode specialized for automata manipulation would have implied more important modifications of the Objective Caml bytecode interpreter. Moreover, the jocaml system runs faster than the join system, even for pure join programs, showing that its weaker compilation of join definitions is more than compensated by its total integration in the Objective Caml system.
Comparison with the Bologna implementation [12] of the join-calculus is also instructive. This system also produces bytecode, which is interpreted by a C program. It proves faster than join and slower that jocaml on most of the examples. Taking a glance at the Bologna source code reveals that it uses a scheme very similar to the one of jocaml, with two slight differences. First, status is systematically encoded as an array of integers. Second when a message arrives on a name x with an empty queue, all patterns are tested (whereas in jocaml only the patterns that contain x are tested).
Performance of a given join system depends on many factors. In particular, scheduling policy and message queue management have a dramatic impact on it. Furthermore, a policy that gives good results on one benchmark can be defeated by another. For these reasons, we cannot tell which compilation technique is the best by comparing different implementations.
Clearly, we now need to integrate all our compilation techniques in the same system, in order to compare them more thoroughly and to experiment further. However, the definition of reactivity status and the automata of section 3 provide a sound basis for these future investigations. Apart from future language development and fully implementing the failure semantics of the join-calculus, we also plan to investigate more on the implementation of threads, attempting to minimize thread suspension and creation.