- Email: [email protected]
Achieving Hard Real-Time Java
Copyright Cl IFAC Real-Time Programming, Palma, Spain, 2000
ACIDEVING HARD REAL-TIME JAVA
M.J.Baner and J.M.Bass University of Wales, Bangor
Abstract: Real-time systems engineers have, for some time, identified Java as an attractive programming language, but have been unable to exploit its benefits as it cannot provide the fundamental temporal predictability required. However, this is all changing, as academic and industrial experts propose extensions to the Java environment. On the basis of this study, significant agreement has been found in how some ofthe critical areas of Java may be addressed for real-time, such as memory management and portability. However, areas such as scheduling and interprocess communication, have been contentious, even among expert opinion. This paper considers the current status ofthis exciting and emerging, soon to become, real-time programming language, with a focus on process control application. In addition, it will overview a preliminary performance assessment ofthe alleged real-time java virtual machine (NM) from NewMonics Inc and compared upfront with the Sun JVM. Copyright ~ 2000 IFAC Keywords: Object-oriented programming; Real-time systems; Process control; Distributed control
engineers have regarded Java as an attractive language for their embedded applications for all these features, but have been fundamentally unable to embrace the technology as it cannot capture the predictable timeliness required by these systems. A number of issues have been raised in the real-time community in this regard, areas such as memory management, scheduling, inter-process communications and synchronisation are some of the important areas that have impact and must be considered, ifthe language is to be levered to real-time systems application.
I. INTRODUCTION This paper emerges from a research programme that collaborates with companies involved in the process control industries, including: BICCGeneral, Hewlett Packard, Eurotherm and Wind River Systems. It has been found that the process control industries are moving away from proprietary control solutions, and are interested in exploring fully decentralised distributed control systems (FDDCS), exploiting emerging SMART remote I/O technology. Industry estimates material cost savings to be in the range of3080% using this scheme. However, the scheme is not easily realised due to the increased design complexity, and requires the support of design tools and modem software engineering technology, possibly including Java.
2. BACKGROUND Typically, Java runs upon a virtual machine, which performs run-time interpretation of the Java code. These, so called, Java Virtual Machines (JVMs) contribute greatly to the portability of Java, as any hardware platform can run Java providing it has a conforming JVM. Simply stated, a JVM can be seen as a software abstraction of a computer. The JVM in turn runs upon the services provided by the operating system, that has the computing hardware underlying that, see Figure I. Java source code, like most programming languages, is compiled. The resulting byte-codes are then executed, or more accurately, interpreted by the JVM. Although Java is usually interpreted, and execution performance is low, it is considered satisfactory for most applications. However, more advanced features permit compilation during runtime, through the availability of just-in-time (nn compilers, such as those available from Syrnantec and Inprise. The process here is to compile the byte codes into native code during run-time, providing significant speed-up of 10-20 times for some applications [1].
Java Application Java Virtual Machine Operating System Computing Hardware Figure I: Layers of a typical Java environment
Java has often been mistaken as a language for web technologies only, ofcourse it is much more. A general purpose programming language, object-oriented, heavily typed, multithreaded, reusable code and with great strengths in portability. Real-time systems
ISl
RELATED WORK
considered an attractive idea, as this will have impact on the portability of Java.
Real-time systems engineering is the development of temporally predictable systems, these systems are often 'fast' and 'quick', but they need not necessarily be so. For a system to be predictable, it must be time analysable and produce not only correct output, but output at a specified time. For hard real-time systems, a failure can result in the loss oflife. For soft real-time systems, some degree of failure is considered acceptable. Real-time systems are often embedded, although embedded systems are not necessarily realtime. Embedded systems are often required to be fast, small and cheap. Sun is providing two variants of the Java environment for embedded systems, these are personal Java and embedded Java. However, neither of these environments address the requirements of the real-time system domain.
3. THE REAL-TIME JAVA CONSORTIA Real-time Java has become ofgreat interestto industry, and as a result a number of consortium have been assembled in an attempt to formulate specifications of real-time Java. The two most significant groups are the Real-time for Java Experts Group 'RTJEG', and the other is the J-Consortium. These groups encompass experts from a variety of blue-chip companies.
3.1 The Rea/-time For Java Experts Group (RTJEG) The RTJEG is addressing issues ofreal-time systems in the Real-time Specification for Java (RTSJ) that extends the existing Java Language Specification [5]. Convened under the Java Community Process and JSR00000 I, the group has embraced developments from The National Institute for Standards and Technology (NIST). The collaborative team includes representatives from: IBM; Cyberonics; Aonix; Microware; QNX; Sun Microsystems; aJile and Nortel.
All that is required to execute Java is a NM platform, and the NM includes the mechanisms such as garbage collection and scheduling. For real-time systems, the NM must provide predictability and typically it does not. If the regular NM was sitting upon the Windows NT platform for example, it would make use of the time-sliced scheduling mechanisms within it. However, there are real-time NMs available, such as PERC from a company called NewMonics (www.newmonics.com). allegedly providing real-time performance [2].
The development of the RTJEG specification initially layed down a number of guiding principles in order to delimit the scope of the work and to introduce compatibility requirements. The full detail ofthe work can be found in the publicly available specification accessible from their web site at www.rtj.org. The public review ofthis specification has recently closed, and the specification is now in the process of being developed into a number ofreference implementations.
However, there is no reason why Java cannot be executed on conforming hardware directly, which is an attractive idea from the perspective of real-time systems due to improved predictability. J. Kreuzinger et aI, have made progress in this direction, with the development of the Komodo microcontroller, which executes a variant of standard Java natively [3]. Another example of Java hardware comes from aJile Systems (www.ajile.com)whohave developed a single board Java computer on a PC-I04 based card, which exploits the JEM2 chipset from Rockwell.
3.2 The J-Consortium The J-Consortium is a group of industrial representatives involved in promoting real-time Java technologies, derived from the technical specification developments ofthe Real-time Java Working Group. A diversity of companies are involved, including the charter members: Aonix; Hewlett-Packard; Microsoft; NewMonics; OMRON; Perennial and Plum Hall, Inc. Again, the group has formulated the specification with due regard to the core requirements of the NIST [6].
There are aspects of the Java environment that are criticised for not conforming to the predictability required by real-time systems. Threads have come under scrutiny in Java, as their temporal requirements cannot be easily expressed and certainly not guaranteed, Miyoshi et al [4]. Within the execution environment of Java, there are other undesirable activities. The Just-in-time (HT) compilation facilities are available for some NMs, and this is undesirable for real-time systems as it is difficult to predict when a HT compilation will occur. This is especially troublesome in event driven systems, with randomly occurring events eroding predictability.
A number of principles have been laid down in this document to preserve code portability, whilst providing the required real-time provisions. In addition, statements have been made with regard to requiring execution speed to be comparable to code generated by modem optimising compilers. Further, the temporal performance of a real-time application must not be compromised when in co-operation with a non realtime components. In fact maximum throughput and minimum latency are key issues that this specification addresses, and despite that the fundamental issue of real-time systems is predictability, which is also addressed, this is also a very pragmatic approach to the
For Java to conform to temporal predictability, many areas must be considered. The Java environment will incorporate extensions to the compiler, the NM and additional class libraries in order to fulfill this. Syntactic extensions to the language itself is not
152
subject. It is important to note that this hundred plus page document elaborates issues to great detail, so this paper will only consider primary statements of realtime systems issue. See their web site at www.j-consortium.com.
brilliance of memory management, in so far as realtime systems engineers are concerned, it falls far short of the temporal requirements. GC is an unpredictable reclamation scheme and it is consequentially difficult to analyse temporally, a premise of real-time systems development. In addition, it must be non-disruptive, allowing incremental calls and ensuring any memory allocation requests are fulfilled [8].
4. CORE TOPICS OF HARD REAL-TIME JAVA A number oftopics are repeatedly raised by those with an interest in real-time Java. However, there is varied opinion on how these topics may be addressed. The section outlines some of the commonality.
Both the specifications identify memory management as one of the primary hurdles in the engineering of real-time Java. Similarly, both the specifications approach this critical matter with depth and concernation. Firstly, the RTJEG specify an open framework to allow the implementor free choice ofGC algorithm. This is furthered through the definition of new memory types that serve to support the predictability of real-time systems. These memory types are as follows:
4.1 Maintaining Portability and Compatibility A primary feature of the Java language is portability, and attempting to make Java real-time threatens to erode this characteristic. Both the specifications acknowledge this issue and in close agreement on the requirements here. The risk to portability simply stems from the divergence of specification from the original Sun specification, with a resulting implementation becoming more real-time systems domain specific. However, both the specifications recognise and clearly state that the portability of Java must be maintained. Both the specifications agree that there should be no syntactic extensions, that application code is transportable across multiple Java platforms, albeit with reduced temporal function. In addition any 'vanilla' Java must also run on the revised platform. The specification also states that the extensions must not restrict use of alternative Java environments, backwards compatibility must be maintained, recognises the importance of 'write once run anywhere' and must allow future improvements to be searnlessly integrated. A significant issue raised in the J-Consortium document is the maintenance of portability, conformance with the Java specification and compatibility with other non real-time Java components. The J-Consortium make reference to performance, in that co-operating standard Java and extended Java should not result in performance degradation. The specification goes further with this requirement, to also cover any future enhancements to extended Java. It also states that extended Java will run on a variety ofoperating systems, microprocessors and JVMs.
Scoped Memory. Scoped memory provides memory resources to objects that have a limited lifetime. Two subclasses are available, the first providing constant allocation times and the other not having timing restrictions. It is unclear whether these two classes are in fact adding unnecessary complexity to the analysis ofa real-time system built in the Java environment. For example, the GC mechanism is permitted to operate on the variable time memory. The authors are unable to see any real advantages here, as those areas in which the specification states they are addressing are in fact covered within the other memory types. Physical Memory. Real-time systems often require access to particular areas of memory, for the purposes of device drivers, memory mapped input/output, "flash" memory or battery-backed RAM for example. The RTJEG augments Java with a new class permitting the reservation, reading and writing of physical memory. Additionally, another class permits the placement ofobjects in particular areas ofmemory, for example a region of fast static RAM, so as to improve execution performance. Obviously, in real-time systems speed is not of fundamental importance, only predictability. Although, real-time systems are required to fulfIll their temporal constraints, and this provides a useful means to support this. Immortal Memory. Objects allocated to immortal memory exist throughout the lifetime ofthe application and are not subject to GC, and the allocation process is of constant time. In addition, all threads within the application have access to this memory resource.
4.2 Memory Management With a focus on alleviating the problems of GC for real-time systems, a significant point of both specifications has been with memory management Memory management in Java is technically advanced when compared to languages such as C++, and programmatically it is far simpler. An automated mechanism called garbage collection (GC) operates during run time, and will periodically expunge memory that becomes unused. typically the scheme runs to completion and is uninterruptible. Despite this
The RTJEG approach to memory management has been outlined. and clearly identifies that any reclamation scheme must be deterministic to ensure that temporal system behaviour will be predictable. Again, the specification supports an open approach which does not restrict the implementors choice of algorithm, and this is furthered through the definition
153
of new memory types.
specified, where threads will increase the priority of other threads where a required lock is held. Again an open approach is used where new monitor control policies can be incorporated in the implementation. The J Consortium utilises a very similar approach, although clearly states that multiprocessor systems are not addressed.
The J-Consortium specification takes a simpler, yet more brutal approach. It suggests Java programs need not incur the run-time overhead ofGC at all, and where it is used, to utilise a defragmenting and paced GC. Considering GC as entirely unsuitable for real-time systems, it is favouring its removal for the real-time components. In replacement, traditional static methods are used, augmented with programmer controlled dynamic allocation. Static memory Illa?agement is known to provide a more temporally predictable runtime environment and this document states that programs written using the extensions utilise this approach. A JVM supporting the extensions is required to maintain two heaps, one for extended Java objects (managed under programmer control) the other for the standard Java (managed by the GC). Automatic memory reclamation has been one of the attractive features of the language, and handing back the control of memory management to the programmer could be seen as a retrograde step. However, it is a pragmatic consideration that will help leverage many other advantages of this language to real-time systems.
4.4 Thread Termination
The termination of threads that hold a lock of a synchronised shared resource can lead to deadlock, this has been addressed through a scheme that involves the use the Asynchronous Event Handling and Transfer of Control mechanisms that will invoke the finalising code of a thread that is required to be terminated. The J-Consortium draft has also identified thread termination to be an issue for consideration. In addition, a focus has been placed on the restrictions necessary to make the termination requests to be executed quickly. To this extent, some degree of assistance is required by the programmer to ensure that finalising statements are executed in small bounded time.
However, all memory requirements cannot be known ahead of time and that application development must also broach the memory management during development. Considering GC, it has been suggested that a GC that conforms to real-time requirements will be more computationally intensive thus introducing penalties in latency and throughput, but of course this is in shadow of the primary issues of predictability.
Real-time Java is evolving, however, there are some aspects that are controversial. This section examines some of the features that are being proposed.
4.3 Synchronisation and Resource Sharing
5. J Thread Scheduling and Dispatching
Java is a multi-threaded execution environment and where there are shared resources, such as input and output devices. Maintaining shared resources is a wellunderstood problem and a variety of solutions exist, these must be shared and synchronised in a controlled manner[7]. Simply stated, if a shared resource is in the process of being written to by a thread and becomes switched for another thread, the write operation may be incomplete. The new thread may then access the same resource, reading or writing from it, and obviously the data may be corrupt or at least invalid.
The RTJEG addresses this troublesome area of realtime systems by providing an open architecture that permits choice ofthe underlying scheduling polices for any given implementation. As the real-time systems industry has varied requirements on scheduling, it is clear why flexibility is required here. However, this puts the portability ofreal-time Java at great risk. This trade-off of flexibility and portability needs very careful assessment, if applications are not to be unnecessarily bound to particular real-time Java implementations. However, a base scheduling strategy has been specified, and this is outlined as a preemptive fixed-priority, and FIFO within priority mechanism. The authors ofthis paper suggest that simple strategies, such as this, lend themselves well to temporal analysis and improve overall system predictability and determinism. In addition, two new two new subclasses of thread have been introduced that also address timeliness issues.
5. CONTENTIOUS TOPICS OF HARD REALTIME JAVA
Real-time systems have demands ofresources, such as memory or I/O. The multithreading paradigm of Java demands that resources are shared and synchronised. Java provides synchronise mechanisms, but they fall short for real-time systems. Miyoshi et ai, state that using these facilities without care will cause unbounded priority inversion to occur. Resource management is also correspondingly inadequate, as there is no notion of shared resources [4].
The J-Consortium draft requires the scheduling to be deadline driven but does not discuss scheduling directly as a topic, but relates it to synchronisation. However, the algorithm is overviewed as time-sliced and fixed priority run-time scheduling.
The RTJEG suggest threads requiring a particular resource are queued in priority order, and FIFO within priority. A default priority inheritance protocol is
154
context switching overheads, to be similar to those found in other real-time operating systems. Again, this is attractively pragmatic, as the time available to perform these operations is often a hard constraint of system operation, and is typically small.
5.2 Asynchronous Transfer ofControl
The computational cost of recursive algorithms can often be highly variable, and in real-time systems this is undesirable from the view ofpredictable behaviour. The RTJEG specification addresses the issue by providing 'asynchronous transfer of control', here the running thread can be interrupted and requested to finalise results. This incurs significant software complexity in the underlying mechanisms required and much responsibility lies with the programmer to implement this strategy. This issue is also under consideration by the J-Consortium.
6. PERC VIRTUAL MACHINE PRELIMINARY ASSESSMENT NewMonics Inc. are aligned with the J-Consortium, and have developed the PERC virtual machine and companion tools. They allege this product is a RTJVM, and as such caused the authors much interest. A number oftests are currently being applied to this JVM and the Sun JVM, and preliminary results are emerging. For example, consider Figure 2, it shows the results ofa thread scalability assessment. The objective was to explore the thread scalability of the two virtual machines in hand. This is an important aspect for process control systems, as a controller for implementation would typically consist of a large number of tasks, and threads are considered an appropriate means of representing these. Obviously, this is an issue of execution performance, and not directly of real-time predictability.
5.3 Inter-process Communication (IPC)
Bakkers et al consider multi-threading in Java to be hazardous, and have proposed that the communicating sequential processes (CSP) paradigm to provide improved reliability and analysability [8][9]. CSP is rooted in mathematical formalism, and clears away multithreading and some scheduling complexity. The approach has been demonstrated to achieve similar performance to vanilla Java, but is inherently more predictable. 5.4 Execution-time Analysable Code
Here, a Java application was written that repeatedly fired off a fixed number of identical threads that each consisted of a fIXed code fragment incorporating some 100MFLOPs of basic arithmetic. The number of threads would increase from 1 to 1000, and then repeated. The time for the thread set to complete computation was recorded for subsequent analysis. The platform was a PC (InteI550MHz, 128Mbyte) running Windows 98. The Java code was compiled using the standard 'javac' Sun compiler into bytecodes.
The J-Consortium extends the functionality ofthe Java Verifier, and lays down requirements for the extended Java compiler and verifier to be able to assess whether the code is execution-time analysable. 5.5 Throughput. Latency and Context Switching
These performance measures have been outlined for address by the J-Consortium specification. Their pragmatic approach requires these measures to be comparable to with those measures of other industrial real-time OS implementations. Throughput is the rate at which computation is performed, interrupt latency is the delay between an interrupt being made and serviced, fmally, context switching is the delay involved in swapping processing attention from one task to another. The authors suggest this is a bold statement when considering that the NM sits between the Java byte codes and the underlying hardware, when compared to optimised 'C' code executing natively. As described earlier, the use of JIT technology is considered unsuitable for real-time systems due to poor predictability. Although, the interrupt latency and context switching may be achievable as these are more related to the efficiency of the mechanisms within the NM itself, the throughput is the most unlikely metric to be comparable. The specification also requires the implementation to have a small resource footprint.
'00
110
-"'200
2!10
400
Figure 2: Multi-threading Overheads The graph shows the startling difference between the thread scalability of the Sun JVM and the NewMonics NM. For a small number of threads the Sun NM out performs PERC. However, notice how quickly the overheads increase for the Sun NM, well beyond
Fundamentally, hard real-time systems are about predictability and not speed. However, the draft does require performance ofinterrupt handling latencies and
155
those for PERC. It is interesting to note that both experimental sessions used the same byte-codes outputed from the same Java compiler, and compiler optimisation can not be contributing to this difference. These experiments demonstrated good repeatability, and scalability. Another experiment run on the same platform was to determine the variation in execution performance, measured in terms of FLOPs. Here, the PERC virtual machine achieved 33MFLOP/second, with Sun achieving a score of200MFLOP/second.
predictability. However, the authors opinion is that PERC demonstrates improved applicability to real-time systems, and more specifically, process control systems. In summary, real-time Java will undoubtedly become a reality. Although, there is still much work between the current status and a functioning environment, the technological concepts are maturing. Clearly, once the technology becomes available the real-time systems engineer is likely to embrace and find great favour in using Java over other languages, for most of the attractively advanced features.
7. CONCLUSIONS Clearly, recent developments take Java closer to hard real-time systems. Whilst attempting to maintain portability, they target on many areas of Java that are known to be unable to fulfill the temporal predictability requirements of hard real-time systems. As with any specification and requirements document, there is great elaboration of detail and in this respect both these documents seem wholly different. However, stepping back from the detail it is found that in many aspects they are found to be in close agreement with issues such as portability, memory management and thread termination.
ACKNOWLEDGEMENTS This paper acknowledges the support of the EPSRC, grant number GR/M55282. The paper also acknowledges the technical contributions made by George Tumbull (Group Technical Director) and Kevin Toon (Chief Engineer) of Industrial Control Systems Group, Plc.
REFERENCES [1] Horstmann, C.S., Comell, G., (1997), 'Core Java', Voll,PPIO.
Portability has been an important characteristic ofJava, and any extensions must attempt to maintain this. The standard GC memory reclamation scheme is unsuitable for real-time systems, and a there are several approaches to resolving the issue. Static memory allocation techniques may appear a retrograde step, but contribute greatly to the predictability of a software system.
[2] Nilsen, K., Lee, S., (1998), 'PERC Real-time API', Draft 1.3 [3] Kreuzinger, 1., Marston, R., Ungerer, Th., Brinkschulte, U., Krakowski, C., (1999), 'The Komodo Project: Thread-based Event Handling Supported bu a Multithreaded Java Microcontroller', Proceedings of the 25 th EUROMICRO Conference, Vol2, ppI22-128.
Beyond these issues however, lie significant divergence, the J-Consortium have a strong focus on throughput and other execution performances, with these being required to be similar to other RTOS attempts. This may be intractable, as Java is typically interpreted and not executed natively, like C for example. In addition, the J-Consortium have given little merit to the issue of scheduling algorithms, whereas RTJEG expand on this subject and provide a open framework for algorithm replacement. The JConsortium consider execution-time analysability to be of great importance and suggest this should be supported through the use of tools. The J-Consortium are currently limited by only supporting single processor systems, although their difficulties in supporting multiple processors may be found in the use of CSP. Moreover, the use of CSP also assists in the disposal of some of the more complex synchronisation and scheduling mechanisms suggested.
[4] Miyoshi, A, Kitayarna, T., Tokuda, H., (1997), 'Implementation and Evaluation of Real-time Java Threads', Proceedings of the 18 th IEEE Real-time Systems Symposium, Vo131, pp166-175 [5] The Real-time for Java Experts Group, (1999), 'Real-time Specification for Java', Draft, Version 0.8.1 [6] The J Consortium, (1999), 'Real-time Core Extensions for the Java Platform', Draft, Version 1.0.2 [7] Tanenbaum, AS., (1987), 'Operating Systems: Design and Implementation' [8] Hoare, CAR., (1985), 'Communicating Sequential Processes' , Prentice Hall International Series in Computer Science
A preliminary assessment of PERC has demonstrated significant divergence of temporal behaviour when compared to the Sun JVM. These experiments are being developed to encompass other aspects of execution performance, and more importantly
[9] Bakkers, A, Hilderink, G., Broenink, 1., (1999), 'A Distributed Real-time Java Systems Based on CSP', Proceedings ofWoTUG 22: Architectures, Languages and Techniques for Concurrent Computing, pp229-241
156
ACIDEVING HARD REAL-TIME JAVA
M.J.Baner and J.M.Bass University of Wales, Bangor
Abstract: Real-time systems engineers have, for some time, identified Java as an attractive programming language, but have been unable to exploit its benefits as it cannot provide the fundamental temporal predictability required. However, this is all changing, as academic and industrial experts propose extensions to the Java environment. On the basis of this study, significant agreement has been found in how some ofthe critical areas of Java may be addressed for real-time, such as memory management and portability. However, areas such as scheduling and interprocess communication, have been contentious, even among expert opinion. This paper considers the current status ofthis exciting and emerging, soon to become, real-time programming language, with a focus on process control application. In addition, it will overview a preliminary performance assessment ofthe alleged real-time java virtual machine (NM) from NewMonics Inc and compared upfront with the Sun JVM. Copyright ~ 2000 IFAC Keywords: Object-oriented programming; Real-time systems; Process control; Distributed control
engineers have regarded Java as an attractive language for their embedded applications for all these features, but have been fundamentally unable to embrace the technology as it cannot capture the predictable timeliness required by these systems. A number of issues have been raised in the real-time community in this regard, areas such as memory management, scheduling, inter-process communications and synchronisation are some of the important areas that have impact and must be considered, ifthe language is to be levered to real-time systems application.
I. INTRODUCTION This paper emerges from a research programme that collaborates with companies involved in the process control industries, including: BICCGeneral, Hewlett Packard, Eurotherm and Wind River Systems. It has been found that the process control industries are moving away from proprietary control solutions, and are interested in exploring fully decentralised distributed control systems (FDDCS), exploiting emerging SMART remote I/O technology. Industry estimates material cost savings to be in the range of3080% using this scheme. However, the scheme is not easily realised due to the increased design complexity, and requires the support of design tools and modem software engineering technology, possibly including Java.
2. BACKGROUND Typically, Java runs upon a virtual machine, which performs run-time interpretation of the Java code. These, so called, Java Virtual Machines (JVMs) contribute greatly to the portability of Java, as any hardware platform can run Java providing it has a conforming JVM. Simply stated, a JVM can be seen as a software abstraction of a computer. The JVM in turn runs upon the services provided by the operating system, that has the computing hardware underlying that, see Figure I. Java source code, like most programming languages, is compiled. The resulting byte-codes are then executed, or more accurately, interpreted by the JVM. Although Java is usually interpreted, and execution performance is low, it is considered satisfactory for most applications. However, more advanced features permit compilation during runtime, through the availability of just-in-time (nn compilers, such as those available from Syrnantec and Inprise. The process here is to compile the byte codes into native code during run-time, providing significant speed-up of 10-20 times for some applications [1].
Java Application Java Virtual Machine Operating System Computing Hardware Figure I: Layers of a typical Java environment
Java has often been mistaken as a language for web technologies only, ofcourse it is much more. A general purpose programming language, object-oriented, heavily typed, multithreaded, reusable code and with great strengths in portability. Real-time systems
ISl
RELATED WORK
considered an attractive idea, as this will have impact on the portability of Java.
Real-time systems engineering is the development of temporally predictable systems, these systems are often 'fast' and 'quick', but they need not necessarily be so. For a system to be predictable, it must be time analysable and produce not only correct output, but output at a specified time. For hard real-time systems, a failure can result in the loss oflife. For soft real-time systems, some degree of failure is considered acceptable. Real-time systems are often embedded, although embedded systems are not necessarily realtime. Embedded systems are often required to be fast, small and cheap. Sun is providing two variants of the Java environment for embedded systems, these are personal Java and embedded Java. However, neither of these environments address the requirements of the real-time system domain.
3. THE REAL-TIME JAVA CONSORTIA Real-time Java has become ofgreat interestto industry, and as a result a number of consortium have been assembled in an attempt to formulate specifications of real-time Java. The two most significant groups are the Real-time for Java Experts Group 'RTJEG', and the other is the J-Consortium. These groups encompass experts from a variety of blue-chip companies.
3.1 The Rea/-time For Java Experts Group (RTJEG) The RTJEG is addressing issues ofreal-time systems in the Real-time Specification for Java (RTSJ) that extends the existing Java Language Specification [5]. Convened under the Java Community Process and JSR00000 I, the group has embraced developments from The National Institute for Standards and Technology (NIST). The collaborative team includes representatives from: IBM; Cyberonics; Aonix; Microware; QNX; Sun Microsystems; aJile and Nortel.
All that is required to execute Java is a NM platform, and the NM includes the mechanisms such as garbage collection and scheduling. For real-time systems, the NM must provide predictability and typically it does not. If the regular NM was sitting upon the Windows NT platform for example, it would make use of the time-sliced scheduling mechanisms within it. However, there are real-time NMs available, such as PERC from a company called NewMonics (www.newmonics.com). allegedly providing real-time performance [2].
The development of the RTJEG specification initially layed down a number of guiding principles in order to delimit the scope of the work and to introduce compatibility requirements. The full detail ofthe work can be found in the publicly available specification accessible from their web site at www.rtj.org. The public review ofthis specification has recently closed, and the specification is now in the process of being developed into a number ofreference implementations.
However, there is no reason why Java cannot be executed on conforming hardware directly, which is an attractive idea from the perspective of real-time systems due to improved predictability. J. Kreuzinger et aI, have made progress in this direction, with the development of the Komodo microcontroller, which executes a variant of standard Java natively [3]. Another example of Java hardware comes from aJile Systems (www.ajile.com)whohave developed a single board Java computer on a PC-I04 based card, which exploits the JEM2 chipset from Rockwell.
3.2 The J-Consortium The J-Consortium is a group of industrial representatives involved in promoting real-time Java technologies, derived from the technical specification developments ofthe Real-time Java Working Group. A diversity of companies are involved, including the charter members: Aonix; Hewlett-Packard; Microsoft; NewMonics; OMRON; Perennial and Plum Hall, Inc. Again, the group has formulated the specification with due regard to the core requirements of the NIST [6].
There are aspects of the Java environment that are criticised for not conforming to the predictability required by real-time systems. Threads have come under scrutiny in Java, as their temporal requirements cannot be easily expressed and certainly not guaranteed, Miyoshi et al [4]. Within the execution environment of Java, there are other undesirable activities. The Just-in-time (HT) compilation facilities are available for some NMs, and this is undesirable for real-time systems as it is difficult to predict when a HT compilation will occur. This is especially troublesome in event driven systems, with randomly occurring events eroding predictability.
A number of principles have been laid down in this document to preserve code portability, whilst providing the required real-time provisions. In addition, statements have been made with regard to requiring execution speed to be comparable to code generated by modem optimising compilers. Further, the temporal performance of a real-time application must not be compromised when in co-operation with a non realtime components. In fact maximum throughput and minimum latency are key issues that this specification addresses, and despite that the fundamental issue of real-time systems is predictability, which is also addressed, this is also a very pragmatic approach to the
For Java to conform to temporal predictability, many areas must be considered. The Java environment will incorporate extensions to the compiler, the NM and additional class libraries in order to fulfill this. Syntactic extensions to the language itself is not
152
subject. It is important to note that this hundred plus page document elaborates issues to great detail, so this paper will only consider primary statements of realtime systems issue. See their web site at www.j-consortium.com.
brilliance of memory management, in so far as realtime systems engineers are concerned, it falls far short of the temporal requirements. GC is an unpredictable reclamation scheme and it is consequentially difficult to analyse temporally, a premise of real-time systems development. In addition, it must be non-disruptive, allowing incremental calls and ensuring any memory allocation requests are fulfilled [8].
4. CORE TOPICS OF HARD REAL-TIME JAVA A number oftopics are repeatedly raised by those with an interest in real-time Java. However, there is varied opinion on how these topics may be addressed. The section outlines some of the commonality.
Both the specifications identify memory management as one of the primary hurdles in the engineering of real-time Java. Similarly, both the specifications approach this critical matter with depth and concernation. Firstly, the RTJEG specify an open framework to allow the implementor free choice ofGC algorithm. This is furthered through the definition of new memory types that serve to support the predictability of real-time systems. These memory types are as follows:
4.1 Maintaining Portability and Compatibility A primary feature of the Java language is portability, and attempting to make Java real-time threatens to erode this characteristic. Both the specifications acknowledge this issue and in close agreement on the requirements here. The risk to portability simply stems from the divergence of specification from the original Sun specification, with a resulting implementation becoming more real-time systems domain specific. However, both the specifications recognise and clearly state that the portability of Java must be maintained. Both the specifications agree that there should be no syntactic extensions, that application code is transportable across multiple Java platforms, albeit with reduced temporal function. In addition any 'vanilla' Java must also run on the revised platform. The specification also states that the extensions must not restrict use of alternative Java environments, backwards compatibility must be maintained, recognises the importance of 'write once run anywhere' and must allow future improvements to be searnlessly integrated. A significant issue raised in the J-Consortium document is the maintenance of portability, conformance with the Java specification and compatibility with other non real-time Java components. The J-Consortium make reference to performance, in that co-operating standard Java and extended Java should not result in performance degradation. The specification goes further with this requirement, to also cover any future enhancements to extended Java. It also states that extended Java will run on a variety ofoperating systems, microprocessors and JVMs.
Scoped Memory. Scoped memory provides memory resources to objects that have a limited lifetime. Two subclasses are available, the first providing constant allocation times and the other not having timing restrictions. It is unclear whether these two classes are in fact adding unnecessary complexity to the analysis ofa real-time system built in the Java environment. For example, the GC mechanism is permitted to operate on the variable time memory. The authors are unable to see any real advantages here, as those areas in which the specification states they are addressing are in fact covered within the other memory types. Physical Memory. Real-time systems often require access to particular areas of memory, for the purposes of device drivers, memory mapped input/output, "flash" memory or battery-backed RAM for example. The RTJEG augments Java with a new class permitting the reservation, reading and writing of physical memory. Additionally, another class permits the placement ofobjects in particular areas ofmemory, for example a region of fast static RAM, so as to improve execution performance. Obviously, in real-time systems speed is not of fundamental importance, only predictability. Although, real-time systems are required to fulfIll their temporal constraints, and this provides a useful means to support this. Immortal Memory. Objects allocated to immortal memory exist throughout the lifetime ofthe application and are not subject to GC, and the allocation process is of constant time. In addition, all threads within the application have access to this memory resource.
4.2 Memory Management With a focus on alleviating the problems of GC for real-time systems, a significant point of both specifications has been with memory management Memory management in Java is technically advanced when compared to languages such as C++, and programmatically it is far simpler. An automated mechanism called garbage collection (GC) operates during run time, and will periodically expunge memory that becomes unused. typically the scheme runs to completion and is uninterruptible. Despite this
The RTJEG approach to memory management has been outlined. and clearly identifies that any reclamation scheme must be deterministic to ensure that temporal system behaviour will be predictable. Again, the specification supports an open approach which does not restrict the implementors choice of algorithm, and this is furthered through the definition
153
of new memory types.
specified, where threads will increase the priority of other threads where a required lock is held. Again an open approach is used where new monitor control policies can be incorporated in the implementation. The J Consortium utilises a very similar approach, although clearly states that multiprocessor systems are not addressed.
The J-Consortium specification takes a simpler, yet more brutal approach. It suggests Java programs need not incur the run-time overhead ofGC at all, and where it is used, to utilise a defragmenting and paced GC. Considering GC as entirely unsuitable for real-time systems, it is favouring its removal for the real-time components. In replacement, traditional static methods are used, augmented with programmer controlled dynamic allocation. Static memory Illa?agement is known to provide a more temporally predictable runtime environment and this document states that programs written using the extensions utilise this approach. A JVM supporting the extensions is required to maintain two heaps, one for extended Java objects (managed under programmer control) the other for the standard Java (managed by the GC). Automatic memory reclamation has been one of the attractive features of the language, and handing back the control of memory management to the programmer could be seen as a retrograde step. However, it is a pragmatic consideration that will help leverage many other advantages of this language to real-time systems.
4.4 Thread Termination
The termination of threads that hold a lock of a synchronised shared resource can lead to deadlock, this has been addressed through a scheme that involves the use the Asynchronous Event Handling and Transfer of Control mechanisms that will invoke the finalising code of a thread that is required to be terminated. The J-Consortium draft has also identified thread termination to be an issue for consideration. In addition, a focus has been placed on the restrictions necessary to make the termination requests to be executed quickly. To this extent, some degree of assistance is required by the programmer to ensure that finalising statements are executed in small bounded time.
However, all memory requirements cannot be known ahead of time and that application development must also broach the memory management during development. Considering GC, it has been suggested that a GC that conforms to real-time requirements will be more computationally intensive thus introducing penalties in latency and throughput, but of course this is in shadow of the primary issues of predictability.
Real-time Java is evolving, however, there are some aspects that are controversial. This section examines some of the features that are being proposed.
4.3 Synchronisation and Resource Sharing
5. J Thread Scheduling and Dispatching
Java is a multi-threaded execution environment and where there are shared resources, such as input and output devices. Maintaining shared resources is a wellunderstood problem and a variety of solutions exist, these must be shared and synchronised in a controlled manner[7]. Simply stated, if a shared resource is in the process of being written to by a thread and becomes switched for another thread, the write operation may be incomplete. The new thread may then access the same resource, reading or writing from it, and obviously the data may be corrupt or at least invalid.
The RTJEG addresses this troublesome area of realtime systems by providing an open architecture that permits choice ofthe underlying scheduling polices for any given implementation. As the real-time systems industry has varied requirements on scheduling, it is clear why flexibility is required here. However, this puts the portability ofreal-time Java at great risk. This trade-off of flexibility and portability needs very careful assessment, if applications are not to be unnecessarily bound to particular real-time Java implementations. However, a base scheduling strategy has been specified, and this is outlined as a preemptive fixed-priority, and FIFO within priority mechanism. The authors ofthis paper suggest that simple strategies, such as this, lend themselves well to temporal analysis and improve overall system predictability and determinism. In addition, two new two new subclasses of thread have been introduced that also address timeliness issues.
5. CONTENTIOUS TOPICS OF HARD REALTIME JAVA
Real-time systems have demands ofresources, such as memory or I/O. The multithreading paradigm of Java demands that resources are shared and synchronised. Java provides synchronise mechanisms, but they fall short for real-time systems. Miyoshi et ai, state that using these facilities without care will cause unbounded priority inversion to occur. Resource management is also correspondingly inadequate, as there is no notion of shared resources [4].
The J-Consortium draft requires the scheduling to be deadline driven but does not discuss scheduling directly as a topic, but relates it to synchronisation. However, the algorithm is overviewed as time-sliced and fixed priority run-time scheduling.
The RTJEG suggest threads requiring a particular resource are queued in priority order, and FIFO within priority. A default priority inheritance protocol is
154
context switching overheads, to be similar to those found in other real-time operating systems. Again, this is attractively pragmatic, as the time available to perform these operations is often a hard constraint of system operation, and is typically small.
5.2 Asynchronous Transfer ofControl
The computational cost of recursive algorithms can often be highly variable, and in real-time systems this is undesirable from the view ofpredictable behaviour. The RTJEG specification addresses the issue by providing 'asynchronous transfer of control', here the running thread can be interrupted and requested to finalise results. This incurs significant software complexity in the underlying mechanisms required and much responsibility lies with the programmer to implement this strategy. This issue is also under consideration by the J-Consortium.
6. PERC VIRTUAL MACHINE PRELIMINARY ASSESSMENT NewMonics Inc. are aligned with the J-Consortium, and have developed the PERC virtual machine and companion tools. They allege this product is a RTJVM, and as such caused the authors much interest. A number oftests are currently being applied to this JVM and the Sun JVM, and preliminary results are emerging. For example, consider Figure 2, it shows the results ofa thread scalability assessment. The objective was to explore the thread scalability of the two virtual machines in hand. This is an important aspect for process control systems, as a controller for implementation would typically consist of a large number of tasks, and threads are considered an appropriate means of representing these. Obviously, this is an issue of execution performance, and not directly of real-time predictability.
5.3 Inter-process Communication (IPC)
Bakkers et al consider multi-threading in Java to be hazardous, and have proposed that the communicating sequential processes (CSP) paradigm to provide improved reliability and analysability [8][9]. CSP is rooted in mathematical formalism, and clears away multithreading and some scheduling complexity. The approach has been demonstrated to achieve similar performance to vanilla Java, but is inherently more predictable. 5.4 Execution-time Analysable Code
Here, a Java application was written that repeatedly fired off a fixed number of identical threads that each consisted of a fIXed code fragment incorporating some 100MFLOPs of basic arithmetic. The number of threads would increase from 1 to 1000, and then repeated. The time for the thread set to complete computation was recorded for subsequent analysis. The platform was a PC (InteI550MHz, 128Mbyte) running Windows 98. The Java code was compiled using the standard 'javac' Sun compiler into bytecodes.
The J-Consortium extends the functionality ofthe Java Verifier, and lays down requirements for the extended Java compiler and verifier to be able to assess whether the code is execution-time analysable. 5.5 Throughput. Latency and Context Switching
These performance measures have been outlined for address by the J-Consortium specification. Their pragmatic approach requires these measures to be comparable to with those measures of other industrial real-time OS implementations. Throughput is the rate at which computation is performed, interrupt latency is the delay between an interrupt being made and serviced, fmally, context switching is the delay involved in swapping processing attention from one task to another. The authors suggest this is a bold statement when considering that the NM sits between the Java byte codes and the underlying hardware, when compared to optimised 'C' code executing natively. As described earlier, the use of JIT technology is considered unsuitable for real-time systems due to poor predictability. Although, the interrupt latency and context switching may be achievable as these are more related to the efficiency of the mechanisms within the NM itself, the throughput is the most unlikely metric to be comparable. The specification also requires the implementation to have a small resource footprint.
'00
110
-"'200
2!10
400
Figure 2: Multi-threading Overheads The graph shows the startling difference between the thread scalability of the Sun JVM and the NewMonics NM. For a small number of threads the Sun NM out performs PERC. However, notice how quickly the overheads increase for the Sun NM, well beyond
Fundamentally, hard real-time systems are about predictability and not speed. However, the draft does require performance ofinterrupt handling latencies and
155
those for PERC. It is interesting to note that both experimental sessions used the same byte-codes outputed from the same Java compiler, and compiler optimisation can not be contributing to this difference. These experiments demonstrated good repeatability, and scalability. Another experiment run on the same platform was to determine the variation in execution performance, measured in terms of FLOPs. Here, the PERC virtual machine achieved 33MFLOP/second, with Sun achieving a score of200MFLOP/second.
predictability. However, the authors opinion is that PERC demonstrates improved applicability to real-time systems, and more specifically, process control systems. In summary, real-time Java will undoubtedly become a reality. Although, there is still much work between the current status and a functioning environment, the technological concepts are maturing. Clearly, once the technology becomes available the real-time systems engineer is likely to embrace and find great favour in using Java over other languages, for most of the attractively advanced features.
7. CONCLUSIONS Clearly, recent developments take Java closer to hard real-time systems. Whilst attempting to maintain portability, they target on many areas of Java that are known to be unable to fulfill the temporal predictability requirements of hard real-time systems. As with any specification and requirements document, there is great elaboration of detail and in this respect both these documents seem wholly different. However, stepping back from the detail it is found that in many aspects they are found to be in close agreement with issues such as portability, memory management and thread termination.
ACKNOWLEDGEMENTS This paper acknowledges the support of the EPSRC, grant number GR/M55282. The paper also acknowledges the technical contributions made by George Tumbull (Group Technical Director) and Kevin Toon (Chief Engineer) of Industrial Control Systems Group, Plc.
REFERENCES [1] Horstmann, C.S., Comell, G., (1997), 'Core Java', Voll,PPIO.
Portability has been an important characteristic ofJava, and any extensions must attempt to maintain this. The standard GC memory reclamation scheme is unsuitable for real-time systems, and a there are several approaches to resolving the issue. Static memory allocation techniques may appear a retrograde step, but contribute greatly to the predictability of a software system.
[2] Nilsen, K., Lee, S., (1998), 'PERC Real-time API', Draft 1.3 [3] Kreuzinger, 1., Marston, R., Ungerer, Th., Brinkschulte, U., Krakowski, C., (1999), 'The Komodo Project: Thread-based Event Handling Supported bu a Multithreaded Java Microcontroller', Proceedings of the 25 th EUROMICRO Conference, Vol2, ppI22-128.
Beyond these issues however, lie significant divergence, the J-Consortium have a strong focus on throughput and other execution performances, with these being required to be similar to other RTOS attempts. This may be intractable, as Java is typically interpreted and not executed natively, like C for example. In addition, the J-Consortium have given little merit to the issue of scheduling algorithms, whereas RTJEG expand on this subject and provide a open framework for algorithm replacement. The JConsortium consider execution-time analysability to be of great importance and suggest this should be supported through the use of tools. The J-Consortium are currently limited by only supporting single processor systems, although their difficulties in supporting multiple processors may be found in the use of CSP. Moreover, the use of CSP also assists in the disposal of some of the more complex synchronisation and scheduling mechanisms suggested.
[4] Miyoshi, A, Kitayarna, T., Tokuda, H., (1997), 'Implementation and Evaluation of Real-time Java Threads', Proceedings of the 18 th IEEE Real-time Systems Symposium, Vo131, pp166-175 [5] The Real-time for Java Experts Group, (1999), 'Real-time Specification for Java', Draft, Version 0.8.1 [6] The J Consortium, (1999), 'Real-time Core Extensions for the Java Platform', Draft, Version 1.0.2 [7] Tanenbaum, AS., (1987), 'Operating Systems: Design and Implementation' [8] Hoare, CAR., (1985), 'Communicating Sequential Processes' , Prentice Hall International Series in Computer Science
A preliminary assessment of PERC has demonstrated significant divergence of temporal behaviour when compared to the Sun JVM. These experiments are being developed to encompass other aspects of execution performance, and more importantly
[9] Bakkers, A, Hilderink, G., Broenink, 1., (1999), 'A Distributed Real-time Java Systems Based on CSP', Proceedings ofWoTUG 22: Architectures, Languages and Techniques for Concurrent Computing, pp229-241
156