We will analyze whether hard real-time is possible at all in an integrated environment combining a real-time synthesizer and a high-level Scheme interpreter. If this is not possible, we will be forced to define a new architecture for use in critical situations. If it is possible, we will point out what is left to be done to make the current implementation real-time.

In reality, we have several problems at hand:

• The real-time task competes for the CPU with other tasks,

• The real-time task must synchronize with a garbage collector,

• The real-time task has a very dynamic load of its own.

As we have seen in section 1.3, real-time, multi-threaded applications have been studied for long. With the rate monotonic scheduling a correct assertion can be made about the application meeting its deadlines. Still, the synchronization between the threads can cause a priority inversion. This problem can be reduced thru the technique of priority inheritance. The synthesizer thread may still have to wait on a low priority thread when accessing a shared resource. However, a careful design of the critical zones should reduce the worst case delays of this synchronization.

The second problem is the synchronization between the garbage collector and the synthesizer. We gave an overview of the subject in section 1.2. We have seen that Wilson & Johnstone [WJ93] propose a hard real-time garbage collector. The collector uses an incremental, non-copying implicit strategy and uses an efficient write barrier to synchronize the collector and the mutator. In addition, in section 1.2 we have imposed upon the synthesis processes the constraint that they cannot allocate any objects. Synchronization between the real-time synthesizer and the garbage collector is then only needed in the following situations:

• Root scanning: The root scanning is an atomic operation. All threads are suspended.

• Write barrier: Additional instruction may have to be executed at every pointer assignment and add a fixed time penalty to this assignment.

The most restrictive requirement may be the root scanning. If this action takes too much time, it reduces our chances on hard real-time. The only other synchronization is the write barrier which can be implemented very efficiently and can be realized within fixed time bounds. The real-time task can perfectly run concurrent to the garbage collection and suspend the collector thread when needed. A part from the root scanning, the synthesizer will not be blocked by the collector. A performance price has to be payed for the write barrier. Since the synthesizer thread will not move a lot of pointers around, the penalty is fairly small.

The last point on the list is the worst case execution time of the synthesizer itself. We have seen that because the load of the synthesis processes varies dynamically, it is very hard to estimate the execution time. We have mentioned the use of exceptions handling to impose a time bound delay but leave this approach for future work. In critical situations, we can also retreat from this very dynamic load and fix the number and the algorithms of the synthesis processes.

Our conclusion is that it should be possible to use the environment in real-time situations. However, the currently available Java implementation cannot provide such stringent guarantees for the following reasons:

• They should be available on hard real-time systems.

• The Java threads should be mapped onto the native system threads and benefit from the real-time scheduling.

• The garbage collector should be designed for real-time.

It would be an interesting project to port a freely available Java virtual machine implementation on top of a real-time system, the real-time Mach kernel for example. Taking great care in the design of the garbage collector, we could then take accurate measures of the real-time performance. This project is left for future work :-)

It is interesting to note, however, that the Java language was from the start designed with real-time applications in mind [GM95]. Late 1998 Sun Microsystems announced they intent to develop the real-time extensions for the Java platform. Java can count on a wide acceptance, both from academic and private institutes. We foresee that the interest in and the research on real-time Java applications will grow. When Java is ready for real-time and virtual machines will be embedded in electronic devices of all trades, we will have an integrated music system available that can run on your-every-day-yet-sophisticated washing machine. Despite the soft real-time performance of our current prototype, test with this environment are very satisfying. This suggests that the system is very much usable in non-critical situations.