A Real-Time Java System on a Multithreaded Java Microcontroller

Transcription

1 A Real-Time Java System on a Multithreaded Java Microcontroller M. Pfeffer, S. Uhrig, Th. Ungerer Institute for Computer Science University of Augsburg D Augsburg fpfeffer, uhrig, U. Brinkschulte Institute for Process Control, Automation and Robotics University of Karlsruhe D Karlsruhe, Germany brinks@ira.uka.de Abstract Keywords: real-time Java, real-time scheduling, embedded systems, real-time kernel and operating system, multithreading This paper presents a real-time Java hardware and software system for use in embedded applications. The system includes a multithreaded Java microcontroller, an adapted Java Virtual Machine (JVM) and an extended Application Programming Interface (API). The microcontroller core is designed with a multithreaded pipeline and hardware support for real-time scheduling algorithms. The Java Virtual Machine consists of trap routines for complex Java bytecodes, a real-time garbage collection and a class loader for creating real-time data structures. On a higher level, the Application Programming Interface provides easy realtime thread management and access to hardware components like serial interfaces and timer/counter s. 1. Introduction The target market of our project is the widespread market of embedded systems, in particular, embedded realtime systems. The typical requirements of embedded systems, i.e. low-cost, robustness and programmability, will be extended in future ubiquitous and pervasive systems by additional requirements: support for embedded networks, small size, dynamic reconfigurability, platformindependence, and low power. Real-time requirements additionally introduce fast context switching and deterministic timing behavior of program execution. In this area microcontrollers are typically preferred over general-purpose processors because of their on-chip integration of RAM and peripheral controllers, resulting in smaller and cheaper hardware. Moreover for real-time applications, predictability is a more essential requirement than performance. In particular, a hard real-time application requires that the number of processor cycles for its execution can be pre-calculated to ensure that its deadline is never missed. Our microcontroller design takes this requirement seriously and eliminates all processor-internal arbitration situations that may result in an unpredictable number of execution cycles. One of the key requirements for a microcontroller in an embedded real-time environment is the ability of very rapid context switching. This is ideally reached by the multithreading technique known from multithreaded processors [14]. A multithreaded processor is characterized by the ability to execute instructions of different threads within the processor pipeline simultaneously. Multiple onchip register sets are employed to reach an extremely fast context switch. Multithreading techniques are proposed in processor architecture research to mask latencies of instructions of the presently executed thread by execution of instructions of other threads. We propose hardware multithreading as an event handling mechanism that allows efficient handling of simultaneous overlapping events with hard real-time requirements. Moreover, helper threads, e.g. for garbage collection, class loading, or real-time debugging, can run concurrently to the real-time threads in separate thread slots. The hardware scheduler guarantees that the real-time threads are not affected in their timing behavior. Our Komodo microcontroller [3] features a multithreaded Java processor core that allows to trigger so-called Interrupt Service Threads (ISTs) instead of Interrupt Service Routines (ISRs) for event handling [4]. Its zero-cycle context switching in combination with multiple register sets enables the Komodo microcontroller to react very fast on external events. ISTs are triggered without the typical overhead of ISRs in conventional processors. This allows embedding the hardware scheduler deeply in the processor pipeline, to be able to schedule on an instruction-perinstruction basis due to a hardware-implemented real-time scheduling scheme. Instruction scheduling is determined first by the real-time scheduling scheme and second by la-

2 tency bridging. I.e. an instruction of another thread can be issued if the real-time scheme schedules an instruction that cannot be fed into the pipeline because of a control, data or structural hazard arising from previously issued instructions. Recently, multithreading has also been proposed in future high-end processors for event-handling of internal events by rapidly spawning helper threads that are executed simultaneously to the main thread [8, 16]. However, the fast context switching ability of multithreading has rarely been explored in context of microcontrollers for handling of external hardware events. Moreover we transfer the idea of helper threads to the microcontroller level and demonstrate possible applications. Previous papers presented the first ideas about the whole Komodo project [2], the IST concept [4], the architecture of the Komodo processor core [3], evaluations of the hardware-implemented real-time scheduling schemes [10, 6] and of garbage collection algorithms for the Komodo microcontroller [7]. This paper summarizes the overall system architecture and presents the following new concepts: the cooperation between the different hardware and system software components, the extended Java Virtual Machine (JVM), and the Application Programming Interface (API). The next section introduces the Komodo system architecture, which is the framework of our microcontroller. Section 3 discusses the Interrupt Service Thread (IST) concept for event handling in more detail and describes the implemented real-time scheduling algorithms. Section 4 presents the microarchitecture of the Komodo microcontroller including the multithreaded pipeline, the hardware scheduling algorithms, the peripheral components and the cooperation of these items. Two important features of our embedded real-time Java Virtual Machine the class loader and the garbage collection are explained in section 5. Section 6 describes the Application Programming Interface and section 7 concludes the paper. 2. The Komodo System Architecture Our Komodo 1 -project explores the suitability of multithreading techniques in embedded real-time systems. We propose multithreading as an event handling mechanism that allows efficient handling of simultaneous overlapping events with hard real-time requirements. An additional aim of the Komodo-project is the ease of programming by envisioning Java as programming language for embedded realtime applications. State-of-the-art embedded systems are programmed in assembly or C/C++ languages. Java features several advantages with respect to real-time systems: The object orientation of the Java language supports easy programming, 1 Komodo is a small island east of Java, home of the Komodo dragon. Middleware API KJM Hardware Standard classes Class loader Trap routines Multithreaded Java core Garbage collection OSA+ Priority manager RT Thread class Signal Extended API I/O I/O classes I/O-Modules IO-Modules Data transfer buffer Figure 1. The layers of the Komodo-project reusability, and robustness. Java bytecode is portable, of small size, and secure due to the bytecode verifier in the Java-Virtual-Machine (JVM). However, to date the use of Java in embedded real-time systems is hardly possible because of its high hardware requirements and unpredictable real-time behavior. Both problems are solved with the design of a multithreaded Java microcontroller enhanced by an adapted JVM. Java microprocessors, like Sun s picojava- I and II processors [13, 12], execute Java bytecode instructions directly in hardware raising the performance of Java applications and decreasing the hardware requirements compared to a Java interpreter or Just-In-Time (JIT) compiler. In enhancement to the picojava approach the Komodo project supports real-time issues by applying the multithreading technique and by hardware support for advanced real-time scheduling schemes. Figure 1 depicts the four layers and the components of the Komodo project. The foundation of the project is a Java processor core, which has been extended to multithreading. The priority manager realizes several advanced scheduling schemes in hardware suitable for real-time event handling. The signal- reacts to external events and activates waiting threads. Connections to peripheral components are an integral part of the I/O. On top of the hardware resides an adapted Java Virtual Machine (JVM), called Komodo Java Machine (KJM) that executes complex Java bytecodes by trap routines. It includes a class loader, which creates real-time data structures in memory, and performs the memory management with real-time garbage collection [7]. The KJM offers an Application Programming Interface (API) with the well-known Java standard classes and more specific Komodo classes. Examples are the class for realtime threads, and device driver classes to control the peripheral components. The top level of the Komodo-project is a distributed realtime middleware called OSA+ 2 [5] that allows to distribute a real-time application over a network of (possibly heterogeneous) computers to overcome the hardware limitations 2 Open System Architecture - Platform for Universal Services

3 of a single microcontroller. 3. Interrupt Service Threads and Real-Time Scheduling 3.1. The Interrupt Service Thread Concept The basic idea of the Interrupt Service Thread (IST) concept for event handling is that an occurring event activates an assigned thread. Conventional processors and microcontrollers react on interrupts or traps caused by external events by triggering an Interrupt Service Routine (ISR) that interrupts normal program execution. The IST concept activates threads directly in hardware and is most powerful in combination with a fast context switching processor, i.e. in particular with multithreaded processors or multithreaded processor cores of microcontrollers. Using threads instead of ISRs in combination with a multithreaded processor core has several advantages: ffl Thread activation is extremely fast due to the multiple register sets on the multithreaded processor chip, thus enabling single-cycle event reaction. ffl Because of the parallel execution, ISTs are not blocked by ISTs with higher priority, in contrast to ISRs. ffl Latencies within the pipeline can be utilized by other concurrently executed threads. ffl The IST concept allows a unique use of threads for a parallel program organization of typical application tasks and for the handling of external and internal events. In contrast, ISRs can only be interrupted by other ISRs, but not by threads. ffl ISTs allow more flexible priority schemes than conventional processors and microcontrollers. Instructions are scheduled due to real-time scheduling algorithms (see next section) Real-Time Scheduling Algorithms Applying a multithreaded processor eliminates the latencies of IST activation and context switching and allows an additional optimization: the scheduling can be done by hardware. This avoids a software scheduler call after an IST activation and allows the immediate processing of an occurring event. However, the scheduling scheme must be implemented in hardware and the hardware scheduler should provide a scheduling decision within one clock cycle. The following real-time scheduling schemes are adapted to the needs of a multithreaded microcontroller and implemented in the Komodo processor core: Memory interface External wake-up Multithreaded Java pipeline Parallel I/O port Signal I/O Serial interface 0 Serial interface 1 Capture/ compare Timer/counter Data transfer buffer Figure 2. The Komodo microcontroller The Fixed Priority Preemptive (FPP) scheme assigns a fixed constant priority to each thread. The processor always executes the thread with the highest priority among all active threads. If a thread with a higher priority becomes active, the currently executed thread is preempted. The Earliest Deadline First (EDF) scheme executes the thread closest to its deadline. Therefore, the only necessary parameter for this scheme is the deadline. [11] and [15] show, that for periodic threads on a single processor system this is an optimal scheme. It guarantees all deadlines up to 100% processor utilization. The Least Laxity First (LLF) scheme can be considered as an extension to the Earliest Deadline First scheme. Additionally to the deadline, the execution time of each thread is used to calculate its laxity. The laxity is the difference between the remaining time to the deadline and the remaining execution time of a thread. The thread with the least laxity gets the processor. Guaranteed Percentage (GP) [6] is a scheme that has been newly designed for real-time scheduling on multithreaded processors. It aims to implement a scheduler for hard real-time requirements simply in hardware. The basic idea is to statically assign percentages of the available processor time to the threads and to guarantee these percentages in short time intervals. This ensures a definite and predictable proceeding of the threads solving the problem of isolation of event-handling threads against each other. A thread cannot harm the timing behavior of any other thread. Such an isolation is important, if dynamic reconfigurability is needed. Threads can be removed or replaced without affecting the behavior of the remaining threads in the system. So real-time constraints can be kept even during reconfiguration. 4. The Komodo Microcontroller The Komodo microcontroller consists of a processor core attached to typical controllers as e.g. a timer/counter, capture/compare, serial and parallel interfaces via an I/O bus (see fig. 2).

4 Memory interface Address Instructions μrom Instruction fetch PC1 PC2 PC3 PC4 IW1 IW2 IW3 IW4 Instruction decode Priority manager Signal I/O components operands for executing the operation submitted by the decode stage. In case of a load/store instruction, the memory is addressed by one of the operands. Address calculation is made by software. Operand fetch 4.2. The Priority Manager Address Data Memory access Stack register set set1 Stack register set set2 Execute Stack register set set3 Stack register set set4 I/O access Address Data Figure 3. The Komodo processor core 4.1. Processor Core In the following we focus on the processor core [3], which is a multithreaded Java processor with a four-stage pipeline. Because of its application in embedded systems, the processor core of the Komodo microcontroller is kept at a simple hardware level. In these systems low power consumption and a small die size are very important. Figure 3 shows the multithreaded pipeline enhanced by the priority manager and the signal. The pipeline consists of the following four pipeline stages: instruction fetch (IF), instruction decode (ID), operand fetch (OF), and execute/memory/io access (EXE). These four stages perform the following tasks: Instruction fetch: In each cycle, the IF tries to fetch a new instruction package from the memory interface. Each instruction package consists of four bytes. Because of the variable length of bytecode, each package contains up to four bytecodes. Instruction decode: The decoding of instructions starts after writing a received instruction package in the corresponding IW. Only 3 bytes are necessary for decoding; longer bytecodes are executed by trap routines, which read the parameters directly from the memory. The decoding results in a hardware instruction or it starts a sequence of microcodes. After decoding, the bytes needed by the actual instruction are deleted from the IW. Operand fetch: This pipeline stage reads the operands needed by the actual operation from the stack. Because of the stack architecture of Java, a lot of data dependencies occur. To manage this problem without adding latencies, the data received from the execution stage is passed through the stack without any time loss. Execution, Memory and I/O access: The execution stage is responsible for all instructions except of load/store instructions. The execution stage uses the given The implementation of the real-time scheduling strategies is encapsulated within the priority manager. Four different priority manager implementations with the scheduling algorithms FPP, EDF, LLF and GP were investigated. In spite of the different algorithms, the four implementations are very similar. The task of the PM consists of three phases. In the first step, for each thread a characteristic value depending on the scheduling algorithm is generated. In the second step, these values are compared in a comparison tree to determine, which thread s instruction has to be executed in the next cycle. The last step actualizes the characteristic value of each thread depending on the scheduling decision and algorithm. To initialize an IST the real-time requirements like execution time and deadline are forwarded to the priority manager and a scheduling scheme is chosen according to the abilities of the hardware. After that the IST is activated and runs through its initialization phase. Then the IST tells the signal for which event it is responsible and deactivates itself. Up to this point no real-time requirements are fulfilled. As soon as an event occurs, the signal wakens the corresponding IST and informs the priority manager. The priority manager now monitors the execution of this thread and is responsible for keeping the real-time requirements. After event handling is finished, the IST informs the signal and deactivates itself. The cycle can start again The Peripheral Modules An important part of every microcontroller is the presence of integrated peripheral components. These components are usually parallel and serial interfaces, timer/counter s, capture/compare s, s for pulse width modulation, and analog-digital converters (ADC). Because of the implementation of our microcontroller on a FPGA prototype board, the realization of an ADC is out of question. All other components are implemented on the prototype. Some of these components generate event signals that are routed to the processor core where the software is able to handle them. In single-threaded systems, an interrupt controller is responsible for routing the occurring signals to the processor core, because only one event can be handled at a time. Due to multithreading, the Komodo microcontroller is able to handle more than one event at a time. The so-called

5 Signal lines Edge recognition Activation signals to the priority manager Crossbar switch with control and state registers Control registers State registers Thread 0 Thread 1 Thread 2 Thread 3 stack size of 512 entries per thread, our microcontroller has an equivalent gate count of about A synthesis of the priority manager based on the LSI10K library, which is shipped with DesignWare shows that the design is able to run at a frequency of about 30 MHz. A cycle time of about 300 MHz should be possible, when projecting this result to a contemporary gate-array technology. When implementing more than four threads, the stacks and the instruction windows have to be multiplied, which leads to larger operand fetch and instruction decode s. Also the signal and the priority manager must handle more than four threads. The feasibility of implementing 16 or more threads depends on the used hardware technology. Figure 4. Crossbar switch in the signal signal (SU) notifies occurring events to the hardware thread slots, thereby replacing a conventional interrupt controller The Signal Unit The occurrence of a hardware event has to be notified to the processor core. Thereby it is important to determine the source of the event for being able to assign it to a thread slot. When several events occur simultaneously, all events must be passed concurrently to the processor core, where the prioritization is done. All affected threads are activated and the priority manager determines the execution order. The link is realized in terms of a crossbar switch so that the assignment between hardware event and thread slot is not limited statically but can be programmed dynamically. Figure 4 shows this connection. One of the four columns is responsible for each thread slot. The signal inputs are arranged in rows. With help of the nodes, connections can be established between signal input and output. Besides this configuration logic exists a status register, which allows a thread to determine by which event it has been activated. This is necessary because the presented crossbar switch allows to sensitize one thread to several events Evaluations Using a hardware scheduler for real-time scheduling reduces the software overhead for thread management to a minimum. Additionally a performance increase of 20% up to 40% is reached for hard real-time applications due to multithreading and the resulting latency utilization [9]. We realized the Komodo pipeline, the Priority Manager, the Signal Unit and some peripheral modules on an FPGA prototype board. With four implemented thread slots and a 5. Our Real-Time Komodo Java Machine Most Java Virtual Machines cooperate with the underlying operating system and abstract from the underlying hardware. They provide a unified interface for the execution of Java classes. A Virtual Machine loads the classes with help of the class loader and it manages the classes by storing them in suitable structures. In particular, it executes the Java byte code by acting as a bytecode interpreter. The interpreter contains a connection to external peripheral devices and runs services like the garbage collection for heap memory management. The JVM offers structures like the heap, the stack, and the program counter. In contrast to most Java Virtual Machines our Komodo microcontroller executes most Java bytecode instructions directly (by hardware or microcode). Complex Java bytecodes like getstatic, invokevirtual, monitorenter, andnew are executed in terms of trap routines, which make up the software part of our Virtual Machine (besides the garbage collector). We omit an operating system layer between the Virtual Machine and the hardware. So, our system calls are mapped directly to the underlying hardware. Because of the combined hardware/software based design of our system, we call it a Komodo Java Machine (KJM) instead of a Java Virtual Machine. There are some modifications required for making our Java Machine capable for real-time. The class loader must be modified to offer predictable execution times of the loaded methods. Finally a garbage collection that fulfils real-time requirements is needed for the execution of realtime applications on the microcontroller. In our concept of helper threads, the garbage collector and the class loader run in separate thread slots concurrently to the (real-time) application threads.

6 5.1. Class Loader for Real-Time Applications A Java Virtual Machine has a flexible class loader architecture that enables Java to load classes during run time. This has two advantages. First, the microcontroller loads only classes that are really needed for the execution. Second, it is able to load an actualized class during run time and thus it becomes more flexible. A class to be loaded is accessed via its name, which is declared in a string. The Virtual Machine looks up this string in the class table and, if it finds the class, returns its reference. In the other case the class is loaded from the file system or from the network. The class table is a linear index of all loaded classes and allows looking up a class when you know its name. The class table is organized as a linear list, so the maximum access time to a class can only be given if the number of entries and thus the maximum number of loaded classes is limited. But even a search in a linear list has a bad worst-case execution time that should be avoided in a real-time system. The avoidance of linear searches is one of the requirements for the design of our KJM class loader. In our first approach the class loader is executed as a separate program not on the microcontroller. A program, which is derived from the software simulator of the microcontroller, acts as class loader and creates a memory image that can be loaded into the microcontroller memory. This first approach does not offer dynamic class loading. The second approach moves the class loader into the microcontroller and executes it as a static process before starting the application. It creates all the memory structures before any application is running. Now we do not need the creation of the memory image by special software. We choose this way for reasons of simplicity, because dynamic loading raises significant problems in keeping realtime constraints. When the class loader loads a nonexistent class, there would be intense execution delays. Our approach loads all needed classes before starting the application. The disadvantage is that all referenced classes are loaded, even when they are not accessed during the execution. Loading all classes causes an unnecessary expense of processing time and memory consumption, but it is the only way that enables us to offer a good real-time capability. The second approach can be extended: The class loader is able to load classes dynamically during run-time. A class cannot be loaded in real-time, but there are some useful applications. A new class can be loaded with the objective to replace a loaded class. The class loader then switches from the old class to the newly loaded class. This demonstrates an exchange during the execution. The class loader performs the following steps: 1. Access the class file to be loaded. 2. Check the class header. 3. Read the constant pool and write it into the microcontroller RAM. 4. Recursively load the parent classes, if available. All classes except of the object class have a parent class. 5. Read the interfaces. 6. Read and link the fields and write them to the microcontroller memory. 7. Read and link the methods and write them into the RAM. The methods contain the Java bytecodes, which are executed when the application is running. 8. Initialize the class variables and perform further optimizations. Linking is the preparation of the internal structures so that they allow an efficient access. Basically linking collects information about inherited or overwritten classes and creates complete structures out of them. Complete means that all information about fields and methods that are only defined in the parent class are also saved in the subclass. Therewith we avoid the search in parent classes, when we already have found the concerning class. Loading classes via plain text names, like ordinary JVMs do, offers a lot of advantages concerning flexibility and modularity of applications, but on the other hand causes more effort in the resolving of method calls and object accesses. The repeatedly called procedure is the determination of the plain texts from the constant pool with a following search for the appropriate information from the internal class structures. A basic idea for the performance increase of this search is saving the already found results. Depending of the kind of saving we distinguish between the resolving of the constant pool and the quick variants of the bytecodes, both are known from Sun s picojava [13]. The storing of the found class information in the constant pool and the identification of this modification is called resolving. If a new object is created, the constant pool yields the class name, which must subsequently be looked up in the class table. If we now put the found entry in the constant pool by replacing the reference, every further access to this class can take place directly. After the resolving is done the processing of the single bytecodes can be accelerated even more by modifying the instruction itself. The change includes the setting of the new opcode (first byte) and the adaptation of its operands. The total length of the bytecode may not be changed. The quick variant technique requires the change of each related bytecode for profiting from a performance increase. With resolving each modification of a constant pool entry leads to a speed-up of all bytecodes, which reference this entry. The KJM supports both variants for the performance

7 increase, whereby the needed modifications are done by the class loader before starting the application. This approach originates from the multithreaded pipeline, where several threads work together in a very fine-grained manner. Changes in the shared constant pools have to be done atomically to avoid inconsistent entries. Synchronization would influence the real-time behavior in an unpredictable manner, in particular ruin the isolation of the real-time threads. To preserve the real-time capability, we chose to generate the resolved and quick variants before starting the realtime execution. Resolving replaces the search in class structures by direct accesses. Now object accesses and method calls are executed with fixed numbers of processor cycles independent of the size of the internal data structures. Altogether we yield precise time boundaries for the execution of real-time applications Real-Time Garbage Collection For the Komodo microcontroller we developed two realtime garbage collection algorithms. They were presented in full detail in [7]. The aim of a real-time garbage collection is a simple, homogenous, and therefore computable algorithm with a predictable maximum execution time. A garbage collector is executed in one of the hardware thread slots running in parallel to the real-time application threads. Both garbage collectors required hardware adaptations. The two algorithms differ in the treatment of objects. One has a complexity of O(n 2 ), the other one O(n). The drawbacks of the better algorithm are synchronized regions, because they may not be interrupted by other threads. The computation time slice that the garbage collection needs to stay head-on-head with the object creation is calculable, because of the linear order and is for the current implementation a maximum of 30%. This is a worst-case assumption for a permanent garbage creation. Usual applications will get on with much smaller slices. The measurements showed that 5-10% are sufficient [7]. 6. Komodo API Standard Classes: Every Java Virtual Machine provides an Application Programming Interface. This interface contains a set of classes that provide standard procedures, like output, thread management, etc. Methods, which access the operating system, are often written not in Java, but in a programming language close to hardware, e.g. C++. On the Komodo Microcontroller we can only execute Java bytecode, so we cannot use native code as other Virtual Machines do. We have to write all API methods in Java bytecode. Of course we need some special instructions, e.g. for memory access. For that we introduced extended bytecodes, well known from the picojava processors. So parts of the API classes are written directly in Java code. These are the upper level API classes. The low level API classes are programmed directly in Java bytecode. Classes for real-time support: The standard API does not offer special real-time support. So we added classes for this appliance. As far as possible we followed the proposals of the Real-Time for Java Expert Group [1]. For the real-time support we offer a class for creating real-time threads. This class can be initialized with the desired scheduling scheme. We offer the scheduling schemes FPP, EDF, LLF, and GP, which are supported by the Komodo hardware. These scheduling schemes are initialized with the appropriate values, e.g. EDF with the deadline. The IST concept requires to look for a free hardware thread slot as soon as a new IST is created. This slot is then reserved for the corresponding IST. If there is no slot available, an error condition must be thrown. This limits the number of events to the number of available thread slots. If there are more events necessary, these events can be handled by several Komodo microcontrollers interconnected by the OSA+ middleware. If the real-time requirements were soft (i.e. sporadic deadline misses can be tolerated by the application), a solution sharing a thread slot between several events would be possible as well. Driver classes for peripheral components: Integrated periphery can be accessed with help of the driver classes. In the initialization phase of the microcontroller the software scans the I/O address space for peripheral components. Each interface is equipped with an identifier, which allows the software to recognize the interface s type. The advantage of this method is that it is not needed to code the microcontroller s configuration into the system software. That means the same software can be used for different configurations or derivates of our Komodo microcontroller. Realized peripheral components are the enumerated modules presented in chapter 4.3. Each type of component needs its own driver class. These classes are needed because programming of the I/O components takes place with support of Java bytecode. Also communication with the signal is required, when suspending the actual thread is wanted, i.e. when waiting for an event. The driver class of the serial interface for example offers methods for configuring the interface, sending and receiving single data packages and transmitting data via the data transfer buffer. 7. Conclusions This paper presents a Java based real-time multithreaded microcontroller system including a Java Virtual Machine and an adapted API. We base our Interrupt Service Thread (IST) concept on the idea to handle events by threads utilizing the fast context switching of multithreaded processors.

8 Up to now such processors have been designed for latency hiding and throughput increase. In contrast, our Komodo microcontroller core applies hardware multithreading for fast real-time event handling. Because the Komodo microcontroller implements a context switch without switching overhead, we implemented several well-known scheduling techniques in hardware (FPP, EDF, LLF, and GP). Because of implementing a microcontroller, we added typical peripheral components like serial interfaces, a timer/counter etc. and a newly developed signal to the multithreaded processor core. All occurring events signalized by the peripheral components are simultaneously routed through the signal to the processor core. Event handling is done corresponding to the selected scheduling algorithm and its predefined parameters. The real-time garbage collection of the KJM needs only 5-10% of computing time to provide a sufficient amount of free memory. A class loader retrieves needed classes and resolves method calls for real-time capability. Both, garbage collection and class loader are part of the Komodo Java Machines and are designed to run as helper threads in separate thread slots concurrently to real-time applications. The next higher level, the Application Programming Interface, provides methods for real-time thread management, classes for programming the integrated peripheral components and the Java standard classes. The next step is to complete the OSA+ real-time middleware, which manages the interconnection of multiple Komodo microcontrollers and of Komodo microcontrollers with other system components realizing a (heterogeneous) distributed system. The class loader will support the middleware for dynamic reconfiguration of real-time threads. We also redesign the Komodo microcontroller with the aim to reduce power consumption and plan to implement it as an ASIC prototype. The microcontroller will be applied to control an autonomous guided vehicle to test it in an industrial environment. References [1] G. Bollella, P. Bowman, B. Brosgol, P. Dibble, S. Furr, J. Gosling, D. Hardin, and M. Turnbull. Real Time Specification for Java. The Real Time for Java Experts Group, December Draft Version. [2] U. Brinkschulte, C. Krakowski, J. Kreuzinger, R. Marston, and T. Ungerer. The Komodo project: Thread-based event handling supported by a multithreaded Java microcontroller. 25th EUROMICRO Conference, Milano, 2: , September [3] U. Brinkschulte, C. Krakowski, J. Kreuzinger, and T. Ungerer. A Multithreaded Java Microcontroller for Thread- Oriented Real-Time Event-Handling. International Conference on Parallel Architectures and Compilation Techniques (PACT 99), Newport Beach, pages 34 39, October [4] U. Brinkschulte, C. Krakowski, J. Kreuzinger, and T. Ungerer. Interrupt Service Threads - A New Approach to Handle Multiple Hard Real-Time Events on a Multithreaded Microcontroller. RTSS WIP sessions, Phoenix, pages 11 15, December [5] U. Brinkschulte, C. Krakowski, J. Riemschneider, J. Kreuzinger, M. Pfeffer, and T. Ungerer. A Microkernel Architecture for a Highly Scalable Real-Time Middleware. RTAS 2000, 6th IEEE Real-time Technology and Application Symposium, Work in Progress session, Washington, June [6] U. Brinkschulte, J. Kreuzinger, M. Pfeffer, and T. Ungerer. A Scheduling Technique Providing a Strict Isolation of Realtime Threads. Seventh IEEE International Workshop on Object-oriented Real-time Dependable Systems (WORDS), San Diego, CA, January [7] S. Fuhrmann, M. Pfeffer, J. Kreuzinger, T. Ungerer, and U. Brinkschulte. Real-time Garbage Collection for a Multithreaded Java Microcontroller. The Fourth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC), Magdeburg, Germany, pages 69 76, May [8] S. W. Keckler, A. Chang, W. S. Lee, and W. J. Dally. Concurrent Event Handling through Multithreading. IEEE Transactions on computers, 48(9): , September [9] J. Kreuzinger. Echtzeitfähige Ereignisbehandlung mit Hilfe eines mehrfädigen Java-Microcontrollers. PhD Thesis, Universiy of Karlsruhe, published by: Logos Verlag, Berlin, [10] J. Kreuzinger, A. Schulz, M. Pfeffer, T. Ungerer, U. Brinkschulte, and C. Krakowski. Real-time Scheduling on Multithreaded Processors. The 7th International Conference on Real-Time Computing Systems and Applications (RTCSA 2000), Cheju Island, South Korea, pages , December [11] C. L. Liu and J. W. Layland. Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment. Journal of the ACM, 20(1):46 61, [12] S. Microsystems. PicoJava-II Microarchitecture Guide. Number Part No.: Sun Microsystems, March [13] J. O Conner and M. Tremblay. PicoJava-I: The Java Virtual Machine in Hardware. IEEE Micro, pages 45 53, March/April [14] J. Silc, B. Robic, and T. Ungerer. Processor Architecture: From Dataflow to Superscalar and Beyond. Springer-Verlag, Heidelberg, [15] J. A. Stankovic, M. Spuri, K. Ramamritham, and G. Buttazzo. Deadline Scheduling for Real-Time Systems: EDF and Related Algorithms. Kluwer Academic Publishers, Dordrecht Norwell, [16] C. Zilles, J. Emer, and G. Sohi. The Use of Multithreading for Exception Handling. MICRO-32, Haifa, pages , November 1999.