Untersuchung der Einsetzbarkeit von Echtzeit-Java in der ... · Java-System aufbauend auf einem...

Untersuchung der Einsetzbarkeit von Echtzeit-Java in der

Radarsignalverarbeitung

Ralf Holzheu

30. Oktober 2004

Ralf HolzheuFachhochschule Ulm

Studiengang Technische InformatikSommersemester 2004

Diplomarbeit wurde angefertigt bei:

EADS UlmRadartechnik, Abteilung OPE 52

Worthstrasse 8589077 Ulm

Firmenbetreuung durch:Dr. T. Mahr

betreuende Professoren:Prof. Dr. rer. nat. K. ResselProf. Dr. T. Hasbargen

1

Untersuchung der Einsetzbarkeit von Echtzeit-Java in der Radarsignalverarbeitung 30. Oktober 2004

3 Echtzeitprogrammierung mit Java

3.1 Eignung von Java fur Echtzeitsysteme

[BHK2000]Die Grundgesetze der Echtzeitfahigkeit werdenmit Java nicht außer Kraft gesetzt. Das heisst:garantierte kurze Reaktionszeiten konnen nur erreicht werden, wenn gerade laufende Aktivitaten zu je-der Zeit unterbrochen und durch die angeforderte Tatigkeit hoherer Prioritat solange verdrangt werdenkonnen, bis die geforderte Reaktion erfolgt ist. Betriebssysteme unterstutzen dies durch ein prioritatsge-steuertes, preemptives Multitasking. Die unverzugliche Unterbrechbarkeit einer gerade laufenden Ak-tivitat heisst, dass Java-Threading ebenfalls prioritatsgesteuert und preemptiv realisiert werden muss.In der Java-Spezifikationwerden Thread-Prioritaten definiert, es werden jedoch keine Aussagen darubergamacht, wie die Abarbeitung genau zu erfolgen hat. Fur eine harte Echtzeitfahigkeit kann aus diesemGrund ein preemptives Threading gewahlt werden, ohne die Java-Spezifikation zu verletzen. Wird einJava-System aufbauend auf einem Betriebssystem realisiert, so heisst dies, dass Java-Threads auf dieThreads oder Tasks des darunter liegenden Betriebssystem abgebildet werden mussen, siehe Abbil-dung 9.

OS-Task/Thread

OS-Task/Thread

OS-Task/Thread

OS-Task/Thread

OS-Task/Thread

Java-Thread

Java-Thread

Java-Thread

OS- Win2k- vxWorks- ....

Abbildungsschicht fürThread-Management Aufrufe

- Erzeugung- Synchronisation- ...

Abbildung 9: Abbildung von Java-Threads auf native Task. Quelle: [BHK2000]

So ist sichergestellt, dass der hochstpriore Java-Thread auch die hochste Prioritat des Gesamtsystemshaben kann. Ein auf ein Betriebssystem aufsetzendes Java-System kann nicht echtzeitfahiger sein alsdas unterlagerte System. Hochste Prioritat fur einenAnwender-Thread ist nicht immer gleich bedeutendmit hochster Prioritat im gesamten System. Dies ist der Unterschied zwischen einem System mit harterEchtzeitfahigkeit und einem nichtechtzeitfahigen System wie Win2k oder Unix. Es muss immer diePrioritatsstruktur des Gesamtsystems betrachtet werden. Entscheidend in einem nichtechtzeitfahigen

EADS Deutschland GmbH 30 von 75


System ist, dass Systemleistungen wie z.B. Ein-Ausgabe-(EA)-Treiber hohere Prioritat besitzen als derhochstpriore Anwenderthread. Eine Obergrenze fur die Reaktionszeit tR lasst sich nicht angegeben,weil diese vom EA-Verkehr abhangig ist. Folgedessen kann die Einhaltung einer oberen Schranke nichtgarantiert werden.Bei einem Echtzeitbetriebssystem-Kern werden die zulassigen Prioritaten fur Anwendungen nicht aufeinen bestimmten (niederprioren) Ausschnitt des gesamten Prioritatsbereiches des Systems eingeschrankt.Anwender-Threads konnen eine hohere Prioritat als System-Threads besitzen. Dies hat zur Folge, dasseine solche hochstpriore Anwendung immer das gleiche Reaktionsverhalten zeigt unabhangig davon,wie sonstige Aktivitaten, z.B EA-Treiber, das System belasten. Die Prioritatsstruktur eines solchen Sys-tems zeigt, Abbildung 10.

Priorität

Interrupts

AnwenderInterruptHandler

AnwenderThreads/Tasks

SystemThreads/Tasksz.B. EA-Treiber

InterruptHandler

Gemeinsamer, permanenter Adressraum

Abbildung 10: Prioritatsstruktur eines Echtzeitsystems. Quelle: [BHK2000]



Wenn ein preemptivesMultithreadingwie bei Echtzeitbetriebssystem-Kernen (engl. realtimekernel) rea-lisiert werden kann, und wenn durch die Vorabubersetzung AOT (engl. ahead of time) in Maschinen-code eine schnelle und deterministische Befehlsabarbeitung moglich ist, was macht dann ubliche Java-Systeme nicht echtzeitfahig? Die Antwort liegt in der automatischen Speicherplatzverwaltung durchden Garbage Collector (GC).

Eines der grossten Probleme hinsichtlich vorhersagbaren Verhaltens eines zeitkritischen Tasks ist derGarbage Collector. Ein Garbage Collector verwaltet und organisiert den Heap, nichtreferenzierte Ob-jekte werden geloscht, und der Speicher wird defragmentiert. Der GC ist hoher priorisiert als ein ja-va.lang.thread und kann somit alle Anwenderthreads auf unbestimmte und unvorhersehbare Zeit un-terbrechen. Abbildung 11 illustriert das Verhalten des GC einer Standardimplementierung. AllokierteObjekte werden durch den GC auf dem Heap verwaltet und damit der Kontrolle des Programmierersentzogen. Echtzeitverhalten ist dadurch nicht moglich.

Abbildung 11: Anwendungsthreads werden vom Garbage Collector unterbrochen. Quelle: aicas

Garbage Collection

Das Speichermanagement in Java unterscheidet sich von dem in Sprachen wie C und C++. Ein Pro-gramm muss keine Prozeduren wie malloc() oder free() aufrufen, um Speicher zuzuweisen oder freizu-geben, sondern erhalt von der Java-Runtime-Environment einen Automatismus bereitgestellt der denSpeicher verwaltet. Dieser Automatismus heißt Garbage Collector. Die Aufgabe des Garbage Collectorist es:

• nicht referenzierte Objekte auf dem Heap zu detektieren und dessen Speicher freigeben.

• die Heapfragmentierung so gering wie moglich zu halten.

Um herauszufinden, welche Objekte nicht mehr referenziert werden, werden sogennante Wurzelkno-ten (engl. “roots“) angelegt und die Erreichbarkeit der einzelnen Elemente von diesen Wurzeln unter-sucht. Ein Objekt ist erreichbar, wenn es einen Pfad von Referenzen ausgehend von der Wurzel gibt,uber die ein Programm das Objekt erreichen kann. Die Wurzeln sind immer vom Programm erreich-bar. Der Mark-Sweep-Compact Algorithmus besteht aus vier Phasen (Abbildung 1. Die Aufgabe derersten Phase ist es, alle Wurzelelemente zu markieren. In der zweiten Phase werden alle root Objekterekursiv durchlaufen, alle referenzierbare Objekte detektiert und markiert. Anschliessend scannt derGC-Algorithmus in der dritten Phase den Heap und sucht nach nicht markierten Objekten und entferntdiese gegebenenfalls aus dem Speicher. Die letzte und vierte Phase ist fur die Kompaktifizierung undDefragmentierung des Heap zustandig.



Abbildung 12: Phasen des Mark and Sweep Algorithmus. Quelle: aicas

Listing 1: Mark and Sweep

1 for each root va r i ab l e r2 mark ( r ) ;3 sweep ( )45 void mark ( Object p )6 i f ( ! p . marked )7 p . marked = t rue ;8 for each Object q re ferenced by p9 mark ( q ) ,1011 void sweep ( )12 for each Object p in the heap13 i f (p . marked )14 p . marked = f a l s e ;15 else16 heap . r e l e a s e (p ) ;



3.2 Java-Echtzeitspezifikationen

Im Juni 1998 fand sich unter der Fuhrung von NIST (National Institute for Standards and Technology)eine Gruppe zusammen, die Anforderungen fur ein echtzeitfahiges Java erarbeitete. Insgesamt warendaran 37 Firmen beteiligt. Aus diesen Firmen bildeten sich zwei Gruppen, eine die unter dem Sun JavaCommunity Process (JCP) arbeitet und das J-Consortium, ein Zusammenschluss von Herstellern, dievon Sun unabhangig bleiben wollten. Die Ziele dieser Anforderungen sind:

• Echtzeit-Java soll als oberste Prioritat deterministisches Antwortverhalten garantieren.

• Echtzeit-Java soll abwartskompatibel sein. Nicht echtzeitfahige Javaprogramme sollen uneinge-schrankt auch unter RTSJ-Implementationen ausfuhrbar sein.

• Echtzeit-Java soll portabel und plattformunabhangig sein. Die Portabilitat und die Plattformun-abhangigkeit muss gewahrleistet werden.

• Echtzeit-Java soll keine syntaktischen Spracherweiterungen haben.

Das Ergebnis sind drei Vorschlage fur ein echtzeitfahiges Java (engl. Realtime Java): Ein Vorschlag vonSun, die Real-Time Specification for Java [BHK2000] und zwei Vorschlage des J-Consortiums, die Real-Time Core [RTSJ1999] Extensions for the Java Platform und der Real-Time Data Access [RTCE1999].Die Firma aicas implementierte die RTSJ in ihre echtzeitfahige virtuellen Maschine. Da diese in dieserArbeit verwendet wird, wird im folgenden der Vorschlag von Sun, die RTSJ genauer vorgestellt. Eswerden nicht alle Details dieser Spezifikation behandelt, sondern eine sinnvolle Auswahl getroffen, diedas Gesamtkonzept wiedergeben.

3.2.1 The Real-Time-Specification for Java

Die Real-Time-Specification for Java erweitert die Java-Spezifikation in sechs Bereichen, die nachfol-gend eingefuhrt werden [RTSJ1999]. Eine genauere Beschreibung der einzelnen Bereiche sowie eineEinfuhrung zur Programmierung mit der RTSJ befinden sich in [Dib2002]. Nach dieser Einfuhrung wirdin Kapitel 3.3 die JamaicaVM vorgestellt.

Threads und Scheduling: Die RTSJ definiert Realtime-Threads, also Threads die den vorgegebenenzeitlichen Restriktionen hinreichend genau genugen mussen. Dabei ist das Scheduling von zen-traler Bedeutung. Die RTSJ definiert fogende Schedulingstrategien: Priority Scheduling, PeriodicScheduling sowie Deadline Scheduling. Beim Priority Scheduling wird jedem Rechenprozess ei-ne Prioritatsebene zugeordnet. Prozesse mit hoherer Prioritat werden zuerst abgearbeitet. SieheKapitel 3.2.1.1.

Speicherverwaltung und Garbage Collection: Die RTSJ definiert zwei neue Speicherbereiche fur No-Heap-Threads, die nicht vom GC beintrachtigt werden: immortal memory und scoped memory.Siehe Kapitel 3.2.1.2.

Asynchrones Eventhandling: Echtzeitanwendungen sind ereignisgesteuert. Die RTSJ definiert happe-nings als eine Verbindung zwischen extern auftretenden Ereignissen und asynchronen Event Hand-lers. Siehe Kapitel 3.2.1.3.

Asynchroner Kontrollfluss: Asynchronous transfer of control (ATC) ist ein Mechaninsmus, welchereinem Thread erlaubt eine Exception in einen anderen Thread zu werfen. Siehe Kapitel [Dib2002].

Physikalischer Speicherzugriff Die RTSJ unterstuzt mit Load and Store Operationen den direkten Zu-griff auf Speicheradressen. Siehe Kapitel 3.2.1.4.



3.2.1.1 Threads und Scheduling Um den Echtzeitanforderungen in Realtime-Environments (RTE)gerecht zu werden, definiert die RTSJ RealtimeThread und NoHeapRealtimeThread Objekte. Diese Threadskonnen mit 28 Prioritatslevels belegt werden. Diese liegen dabei alle uber den 10 Prioritatslevels einesjava.lang.thread Objektes. Abbildung 13 zeigt, daß RealtimeThreads nicht von den Unterbrechungen desGarbage Collectors betroffen sind.Im Folgenden werden die Eigenschaften von RealtimeThread und deren Anwendung in Code-Beispielengezeigt.

Abbildung 13: RealTimeThreads in der RTSJ sind nicht von Unterbrechungen des GC betroffen.Quelle: aicas

RealtimeThread

Diese Threadklasse kann ausschließlich auf dem Heap allokierte Objekte ansprechen.Die Klasse javax.realtime.RealtimeThread ist von java.lang.thread abgeleitet. Somit erbt der ReatimeThreadalle Eigenschaften und Operationen eines java.lang.thread Objektes. Listing 2 erzeugt und startet einenRealtimeThread.

Listing 2: Erzeugen eines RealtimeThread durch einen java.lang.thread

1 import j avax . rea l t ime . ∗ ;23 public c l a s s HelloRTJava{4 public s t a t i c void main ( S t r ing [ ] args ){5 RealtimeThread r t = new RealtimeThread ( ) ;6 public void run ( ) {7 System . out . p r i n t l n ( ”Hello RTJava” ) ;8 } ;9 r t . s t a r t ( ) ;10 }11 }

Der Aufruf des unparameteriesierten Konstruktors der Klasse RealtimeThread, aus einem java.lang.thread,startet einen Thread mit den in Tabelle 3.2.1.1 gezeigten Werten.



Field Defaultmemory area Der Thread wird im Heap gestartet.memory parameters Der Thread ist keinen Speicherrestriktionen unterzogen.processingGroupParameters Der Thread gehort keiner Gruppe an.releaseParameters Der Thread unterliegt keiner Zeitrestriktion.scheduler Der Thread wird durch den Standardscheduler dem Betriebsmittel zugeteilt.schedulingParameters Der Thread startet mit NORM PRIORITY.

Soll der zu erzeugende Thread nicht mit den in Tabelle 3.2.1.1 gelisteten Werten erzeugt werden, somuss dieser parametrisiert aufgerufen werden. Der Konstruktor eines RealtimeThreads besitzt sechsParameter, die im folgenden genauer Beschrieben werden.

Listing 3: Konstruktor fur einen RealtimeThread.

1 public RealtimeThread (2 SchedulingParameters scheduling ,3 ReleaseParameters re l ease ,4 MemoryParameters memory ,5 MemoryArea area ,6 ProcessingGroupParameters group ,7 java . lang . Runnable l og i c ) ;

Scheduling Parameter: Die Laufzeitprioritat eines Thread wird durch den Scheduling Parameter fest-gelegt. Dabei gilt

PriorityScheduler.MINPriority ≥ 11 (16)

somit liegt die Prioritat eines RealtimeThread uber den 10 Prioritatslevels eines java.lang.thread Ob-jektes.

Release Parameter: Das Zeitverhalten eines RealtimeThread Objektes wird durch den Release Prameterspezifiziert, dieser definiert die TStartzeit, TPeriode, Tdeadline, TmaxAus f uehrungszeit, sowie einen Over-RunHandler und einenMissHandler.

Memory Parameter: Das Speicherfenster welches von einem RealtimeThread addressiert werden kann,wird durch denMemory Parameter spezifiziert, er definiert eine max. Speicherbereich im HeapMe-mory, ImmortelMemory oder im ScopedMemory.

Memory Area: Der Speicherbereich in dem ein RealtimeThread instanziert werden kann, wird durch denMemoryArea Parameter spezifiziert.MemoryArea area = HeapMemory.instance();

Processing Group: RealtimeThreads konnen in ProcessingGroups verwaltet werden. Wie auch der Relea-se Parameter, besteht die ProcessingGroup aus TStartzeit, TPeriode, Tdeadline, TmaxAus f uehrungszeit, sowieeinen OverRunHandler und einen MissHandler. Bei der Zuordnung eines RealtimeThread Objekteszu einer ProcessingGroup ubernimmt das Thread Objekt die Eigenschaften der ProcessingGroup.

Logic: Referenz auf ein Objekt, dass das Interface Runnable implementiert.Runnable logic = new MyThread();

Listing 4 zeigt wie ein RealtimeThread parametrisiert und gestartet wird.



Listing 4: Erzeugen und starten eines parametrisierten RealtimeThread Objektes

1 import j avax . rea l t ime . ∗ ;23 public c l a s s Ful lCons t ruc tor {4 public s t a t i c void main ( S t r ing [ ] args ){5 SchedulingParameters scheduling =6 new Pr ior i tyParameters ( Pr io r i tySchedu le r . MIN Priority + 2 0 ) ;7 ReleaseParameters r e l e a s e =8 new AperdicParameters ( null , null , null , null ) ;9 MemoryParameters memory =10 new MemoryParameters (MemoryParameters .NOMAX, 0 ) ;11 MemoryArea area = HeapMemory . ins tance ( ) ;12 ProessingGroupParameters group = null ;13 Runnable l og i c = new MyThread ( ) ;14 RealtimeThread r t =15 new RealtimeThread ( scheduling , re l ease , memory , area , group , l og i c ) ;16 r t . s t a r t ( ) ;17 t ry {18 r t . j o i n ( ) ;19 }20 catch ( Exception e ){}21 }22 }23 }



3.2.1.2 Speicherverwaltung und Garbage Collection Die Standard JavaVM-Spezifikation sieht kei-nen Garbage Collector vor, fordert dagegen aber eine Moglichkeit dynamisch Speicher zu allokieren,ohne einen Mechanismus bereitzustellen, der den allokierten Speicher wieder frei gibt.Die RTSJ folgt diesem Ansatz und fuhrt zu dem bereits existierenden HeapMemory zusatzlich zwei neueSpeicherbereiche ein, die nicht vom GC beintrachtigt werden. Die zwei neuen Speicherbereiche heissenImmortalMemory und ScopedMemory

HeapMemory: Auf einer Heapinstanz operiert ein GC-Thread, der die hochste Prioritat besitzt. Diesimpliziert, dass der GC jeden Thread der auf dem Heap arbeitet, unterbrechen kann, was wieder-um in harten Echtzeitumgebungen nicht toleriert wird.

Die Non-HeapMemory Klassen der RTSJ geben dem Programmierer Freiheitsgrade, die es ermoglichen,die Verzogerungen des GC zu umgehen. Um dies zu erreichen durfen Objekte nicht auf dem Heap,sondern mussen auf dem Immortal- oder ScopedMemory allokiert werden.

ImmortalMemory: Der ImmortalMemory besitzt keine Speicherverwaltung. Diese Instanz wird nichtvom GC beintrachtigt. Diese MemoryArea kann wahrend der gesamten Laufzeit von allen aktivenObjekten der Anwendung referenziert werden. Objekte die im ImmortalMemory erzeugt werden,bleiben bis zum Ende der Anwendung im Speicher - sie sind unsterblich.

Listing 5: Erzeugen eines Objektes im ImmortalMemory

12 ImmortalMemory . ins tance ( ) . en ter (3 new Runnable ( ) {4 public void run ( ) {5 / / in t h i s s c o p e immorta l i s t h e d e f a u l t f o r6 / / memory a l l o c a t i o n7 o = new Object ( ) ; / / Th i s Ob j e c t i s immorta l8 }9 }10 } ;



ScopedMemory: Diese Speicherinstanz hat eine begrenzte Lebenszeit. Objekte die im Adressraum die-ses Speichertyps existieren, konnen nicht deallokiert werden. Ein Objekt von ScopedMemory undsomit alle in ihm gespeicherte Objekte existieren so lange, wie noch mindestens ein Thread denScopedMemory referenziert. ScopedMemory wird in LTMemory (engl. linear time memory) und VT-Memory (engl. variable time memory) unterteilt. LTMemory garantiert eine lineare Abhanigkeit derZeit bei der Zuteilung eines Objektes zu einem Speicherberich. Die Abhanigkeit bezieht sich da-bei auf die Grosse des Adressbereiches. VTMemory unterliegt nicht den Restriktion der linearenAbhanigkeit von Zeit zur Objektgrosse. Bei der Zuweisung darf hier beliebige, wenn auch nichtunendliche Zeit vergehen. Die Verwendung von VTMemory ist aus den oben genannten Grundenabzuraten.

Listing 6: Erzeugen eines Objektes im ScopedMemory

12 / / c r e a t e s a 16− k i l o b y t e s memory a r e a o b j e c t named mem3 LTMemory mem = new LTMeory (1024∗16 , 1024∗16 ) ; mem. enter ( new4 Runnable ( ) {5 public void run ( ) {6 o = new Object ( ) ; / / Th i s Ob j e c t w i l l be a l l o c a t e d in7 / / ScopedMemory8 }9 } ) ;



3.2.1.3 Asynchrones Eventhandling In einem RTS treten unabhangige Ereignisse oft asynchron zumregularen Programmablauf auf. Mogliche Ereignisse sind: die maximale Temperatur eines Systems isterreicht, ein Thread verfehlt seine Deadline. Die Echtzeitsoftware muss auf diese Ereignisse (extern alsauch intern) rechtzeitig reagieren, ohne die Zeitrestriktionen der laufenden Threads zu uberschreiten.Zu diesem Zweck fuhrt die RTSJ sogenannte schedulable objects ein. Der AsyncEventHandler (AEH)als auch die RealtimeThreads implementieren das Interface Schedulable und konnen somit dem Sche-duler parametrisiert zur Ausfuhrung ubergeben werden. Ein AEH kann einem AsyncEvent (AE) mitevent.addHandler(handler) ubergebenwerden. Die Assoziation zwischen Systeminterrupt und einemAsyn-cEvent wird mit event.bindTo(“signalname“) realisiert. Der Signalname ist plattformabhangig. Listing 7erzeugt einen AsyncEventHandler und zeigt dessen Anwendung.

Listing 7: Beispielanwendung eines AEH

1 import j avax . rea l t ime . ∗ ;23 public c l a s s SigEvt extends RealtimeThread{4 public void run ( ) {5 MemoryArea immortal = ImmortalMemory . ins tance ( ) ;6 AsyncEventHandler handler = null ;7 AsyncEvent event = null ;8 t ry { handler = ( AsyncEventHandler ) immortal . newInstance ( SigHandler . c l a s s ) ;9 event = ( AsyncEvent ) immortal . newInstance ( AsyncEvent . c l a s s ) ;10 }11 catch ( I n s t an t i a t i onExcep t i on e ){12 e . pr in tS tackTrace ( ) ;13 }14 catch ( I l l ega lAcces sExcep t ion e ){15 e . pr in tS tackTrace ( ) ;16 }17 event . addHandler ( handler ) ;18 event . bindTo ( 2 5 ) ; / / S igna lnumber 2519 event . f i r e ( ) ; event . f i r e ( ) ; event . f i r e ( ) ;20 t ry { Thread . s leep ( 1 0 0 0 ) ; / / L e t t h e AEH run21 }22 catch ( Exception e ){}23 event . removeHandler ( handler ) ;24 System . e x i t ( 0 ) ;25 }2627 public s t a t i c void main ( S t r ing [ ] args ){28 sigEvent r t = new SigEvent ( ) ;29 r t . s t a r t ( ) ;30 t ry {31 r t . j o i n ( ) ;32 } catch ( InterruptedExcept ion e ){}33 System . e x i t ( 0 ) ;34 }35 }



3.2.1.4 Physikalischer Speicherzugriff Durch die Klassen RawMemoryAccess und RawMemoryFloa-tAccess wurde in der RTSJ die Moglichkeit geschaffen Speicheradressen mittels Zeiger zu referenzieren.Dies ermoglicht eine effiziente Art direkten Zugriffs auf die Memory Mapped Hardware zu erlangen.Ein Objekt der Klasse RawMemoryAccess ist an einen Speicherbereich gebunden, welcher dem Konstruk-tor ubergeben wird.RawMemoryAccess( java.lang.object type, long size );

type: Der Parameter type klassifiziert die Hardware, welche auf einen Speicherbereich gemapped wer-den soll, er definiert desweiteren die Art des Zugriffes der VM. DieMenge der unterstutzten Hard-waretypen ist Plattformabhangig.

size: Definiert die zu reservierende Speichergrosse.

Listing 8: Speicherzugriff

12 S t r ing [ ] type = new S t r ing [ 4 ] ;3 type [ 0 ] = new S t r ing ( device ) ;4 type [ 1 ] = new S t r ing ( e therne t ) ;5 type [ 2 ] = new S t r ing ( I n t e l ) ;6 type [ 3 ] = new S t r ing ( no cache ) ;78 RawMemoryAccess eDvc = new RawMemoryAccess ( type , 5 1 2 ) ;

Ein Nachteil der RTSJ ist, dass eine Anwendung strikt in einen Echtzeit- und in einen Nicht-Echtzeit-Anteil aufgeteilt werden muss. Eine Kommunikation zwischen den beiden Teilen ist nur stark einge-schrankt moglich. Echtzeit-Threads konnen keine Speicheranweisungen durchfuhren, wie etwa die Al-lokation auf dem Heap.



3.3 Echtzeitimplementierungen

Durch den Einsatz einer EchtzeitVM wird Java in die Domane der echtzeitkritischen Anwendungentransportiert.Eine fur diese Ausarbeitung durchgefuhrete Marktanalyse zeigt, dass es zum derzeitigen Stand derDiplomarbeit zwei konkurrierende Hersteller von Java-Echtzeitlosungen gibt. Die Firma aicas mit derechtzeitfahigen Jamaica Virtual Machine (JamaicaVM) und die Firma Aonix mit echtzeitfahigen PERCVirtual Machine. Ein von EADS Deutschland GmbH durchgefuhrter Performancevergleich zwischenJamaicaVMund PERC [BEN2003] belegt, dass die JamaicaVMdie performantere Losung ist. Aus diesemGrund wird in dieser Ausarbeitung die JamaicaVM verwendet und im Folgenden vorgestellt.

3.3.1 JamaicaVM

Die Jamaica Virtual Machine ist eine echtzeitfahige Java-Implementierung nach der RTSJ [RTSJ1999] mitfolgenden Eigenschaften [AIC2004].

Harte Echtzeitausfuhrung Die JamaicaVM garantiert harte Echtzeit fur alle Java-Operationen.

Realtime Garbage Collection: Die JamaicaVM besitzt einen deterministischen, inkrementellen Garba-ge Collector. Dieser GC arbeitet nach dem Mark and Sweep Algorithmus und gewahrleistet, dasskeine Anwendungsthreads zu unvorhersehbaren Zeitpunkten durch den GC unterbrochen wer-den. Die Separierung der Anwendung, in Echtzeit- undNicht-Echtzeitthreads entfallt - alle Threadssind Echtzeitthreads. Eine strikte Einteilung einer Anwendung in zwei Teile ist damit nicht mehrerforderlich. Threads werden nach ihrer Prioritat bzw. anderen Schedulingstrategien eingeplantund zugeteilt. Der inkrementeller Garbage Collector arbeitet deterministisch innerhalb der An-wendungsthreads bei der Zuweisung von Speicher. Der Garbage Collector ist dabei immer un-terbrechbar, sodass andere Threads aktiv werden konnen, und dringendere Aufgaben erledigenkonnen.

Abbildung 14: Echtzeit Garbage Collection: Alle Threads sind Echtzeitthreads. Quelle: aicas

ROM-fahiger Code: Klassendateien und die JamaicaVM selbst konnen in eine Binardatei gebundenwerden, die direkt aus ROM/Flash Speicher ausfuhrbar ist. Es wird kein Dateisystem benotigt umJava-Code auszufuhren.

Bibliotheken und Native Code: Existierende Bibliotheken oder performancekritischer low-level Codefur Hardwarezugriffe konnen uber das Java Native Interface in den echtzeitfahigen Code einge-bunden werden.

Portierbar auf unterschiedliche RTOS: Unterstutzt werden derzeit: VxWorks, QNXund Linux-Varianten

Klassendateien und die JamaicaVM selbst konnen in eine Binardatei gebunden werden, die direkt ausROM/Flash Speicher ausfuhrbar ist. Dabei wird aus dem Java-Bytecode ein portabler C-Code erstellt.Der C-Code wird mit einem native C-Compiler kompiliert und zusammen mit den JamaicaVM-Dateien



zu einer ausfuhrbaren Datei gelinkt. Die Firma aicas integrierte diesen Prozess in den JamaicaVM Buil-der der in Abbildung 15 dargestellt ist.

Abbildung 15: Der JamaicaVM Builder erzeugt aus dem Java-Bytecode eine ausfuhrbare Datei fur dasZielsystem. Quelle: aicas

3.3.2 PERC

Die PERCVirtual-Machine ist eine echtzeitfahige Java-Implementierung nach der Real-Time Core Exten-sions for the Java platform [RTCE1999]. Die Eigenschaften von PERC sind in [AON2004] beschrieben.



4 Performancevergleich: C vs. Java

In diesem Teil der Ausarbeitung wird die Ausfuhrungsgeschwindigkeit von Java- und C-Programmenuntersucht. Fur diesen Vergleichwerden jeweils drei Testprogramme (engl. Benchmark) auf einemWin2kund einemVxWorks5.5 System ausgefuhrt, deren Ausfuhrungsgeschwindigkeit gemessen und interpre-tiert.Diese Benchmarks werden in Kapitel 4.1 beschrieben. Kapitel 4.3 interpretiert die Testergebnisse aufden verwendeten Plattformen. Kapitel 4.4 zeigt die verwendeten Compiler-Optionen. Der Quellcodeder einzelenen Benchmarks befindet sich in Anhang A im Verzeichnis ./benchmark/

4.1 Verwendete Benchmarks

Es wurden drei Benchmarks verwendet, um die Ausfuhrungsgeschwindigkeit zu bestimmen. Verwen-det wurde:

4.1.1 SciMark2.0

SciMark2.0 [SciMark2.0] ist ein Benchmark fur numerische Losungsverfahren und misst die Performan-ce mathematischer Algorithmen. Dieser Benchmark besteht aus folgenden funf Algorithmen:

• Fast Fourier Transformation (FFT) ist die Umwandlung einer Zeitfunktion oder Folge in ein Spek-trum.

• Jacobi Successive Over-Relaxation (SOR) ist ein Verfahren zur Losung eines linearen Gleichungs-systems.

• Monte Carlo integration ist ein Verfahren zur Berechnung von π.

• Sparse matrix multiply ist die Multiplikation dunn besetzter Matritzen.

• dense LU matrix factorization ist die Zerlegung einer quadratischen Matrix A in ein ProduktA = L ·U. Dabei ist L eine untere Dreiecksmatrix mit Einsen auf der Diagonale und U eine obereDreiecksmatrix.

Dieser Benchmark testet die Floating Point Performance auf der untersuchten Plattform.

4.1.2 Loops

Loops [c’t Ausg.19] ist ein Benchmark, der die Schleifenperfomance in ms misst. Loops besteht aus dreiSchleifen, die jeweils dreifach verschachtelt sind. Dabei fuhrt eine Schleife (Empty Loop) keinen Codeaus, die zweite (Calc Loop) inkrementiert einen Zahler und die dritte Schleife (Real Calc Loop) fuhrteine Berechnung durch. Loops misst die Schleifen-Perfomance auf der untersuchten Plattform.

4.1.3 RSA-Angriff

RSA-Angriff [c’t Ausg.19] zerlegt eine 64-Bit Zahl in Faktorenpaare. Der Code des in zwei Varianten auf-rufbaren Programms kann als Brute-Force Schleife und als rekursiver Algorithmuns aufgerufen werden.Dieser Benchmark testet die Integer-Performance auf der untersuchten Plattform.



4.2 Verwendete Plattformen

Die in Kapitel 4.1 verwendeten Benchmarks wurden auf fogenden Systemen getestet:

4.2.1 Win2k

Microsoft Windows 2000 System mit der Version 5.00.2195 und installierten Service Pack 2. Das Testsys-tem besitzt 523.28 MB RAM. Die CPU ist ein Intel Pentium 4 mit einer Taktfrequenz von 1.7 GHz.

4.2.2 VxWorks5.5

Windriver VxWorks5.5 System. Das TestSystem besitzt 256MB RAM. Die CPU ist ein PPC 7410mit einerTaktfrequenz von 500 MHz.

Abbildung 16 zeigt eine Ubersicht uber die durchgefuhrten Testkonstulationen fur jeweils einen Bench-mark. Fur jeden Benchmark wurden sieben Tests durchgefuhrt, funf auf Plattform 4.2.1 und zwei aufPlattform 4.2.2.

MinGW PThread

C/Jamaica SunVM

JamaicaVM

C/MSVCC/gcc

C Anwendung Java Anwendung

Win2k

Pentium

C/gcc C/Jamaica

C Anwen-dung

JavaAnwen-dung

PPC

VxWorks

Abbildung 16: SciMark2 auf Win2k.



4.3 Interpretation der Testergebnisse

Laufzeituberprufungen haben einen signifikanten Einfluss auf die Ausfuhrungsgeschwindigkeit. C fuhrtkeine Uberprufungen wahrend der Laufzeit durch. Um Java und Cmiteinander vergleichen zu konnen,wurde fur die kompilierte Version mit Jamaica 2.3 beta die Laufzeituberprufung deaktiviert.Um einen Vergleich zu unterschiedlichen C-Compilern aufzeigen zu konnen, wurde jeder Benchmarksowohl mit dem gcc 2.96 als auch mit dem Microsoft VC6.0 kompiliert. Fur die Testergebnisse von Sunwurde der Interpretermit der Version 1.4.2 verwendet. Der Bytecode der kompilierten Java-Benchmarks,wurde durch den JamaicaVM Builder in C-Dateien transformiert und anschließend mit dem gcc 2.96kompiliert.

4.3.1 SciMark2.0

Abbildung 17 und 18 zeigen die Ergebnisse des SciMark2.0 [SciMark2.0] Benchmarks. Auf der Y-Achseist jeweils die Ausfuhrungsgeschwindigkeit in Million floating point operations per second (Mflops)angegeben. Auf der X-Achse sind die einzelnen Algorithmen des SciMark2.0 aufgetragen. Jeder Bench-mark ist in der Abbildung durchnummeriert, um einen direkten Bezug auf den entsprechenden Testnehmen zu konnen.

SciMark2.0 auf Win2k

Abbildung 17 zeigt die Testergebnisse des SciMark2.0 [SciMark2.0] auf Plattform 4.2.1. Test 1 und 2 wur-den interpretiert ausgefuhrt. Test 3,4 und 5 wurden kompilert. Der Vergleich von Test 1 und 2 zeigt, dassdie Interpretation durch die JamaicaVM signifikant schlechtere Ergebnisse liefert als die Interpretationdurch die VM von Sun. Der Grund liegt darin, dass Sun einen JIT-Compiler benutzt und somit denBytecode nicht mehr zu 100 Prozent interpretiert ausfuhrt.Test 3,4 und 5wurden vollstandig kompiliert. Die Ergebnisse zeigen ein ausgewogenes relatives Verhalt-nis der einzelnen Algorithmen zueinander. Uberraschend ist, dass die FFT mit Jamaica im direkten Ge-schwindigkeitsvergleich schneller ausgefuhrt werden konnte, als das korrespondierende C-Programm,welches mit dem gcc ubersetzt wurde.



1 2 3 4 50

100

200

300

400

500

600

700

Benchmark: SciMark2 auf Win2k

FFT

SOR

Monte Carlo

Sparse mult.

LU

Sun Jamaica Jamaica, gcc C, Microsoft C, gcc

Ausfü

hru

ngsgeschw

indig

keit

[Mflops]

Abbildung 17: SciMark2 auf Win2k.



SciMark2.0 auf VxWorks5.5

Abbildung18 zeigt die Testergebnisse des SciMark2.0 auf Plattform 4.2.2.Test 1 und 2 wurden mit dem gcc kompiliert. Die Ergebnisse der Benchmarks sind ausgeglichen. Esbestehen keine signifikanten Unterschiede in der Ausfuhrungsgeschwindigkeit.

1 20

20

40

60

80

100

120

140

160

180

200

Benchmark: SciMark2 auf VxWorks5.5

FFT

SOR

Monte Carlo

Sparse mult.

LU

Ausfü

hru

ngsgeschw

indig

keit

[Mflops]

Jamaica, gcc C, gcc

Abbildung 18: SciMark2 auf VxWorks5.5.



4.3.2 Loops

Abbildung 19 und 20 zeigen die Ergebnisse des Loops [c’t Ausg.19] Benchmarks. Auf der Y-Achse istjeweils die Ausfuhrungsgeschwindigkeit in 1/s angegeben. Auf der X-Achse sind die einzelnen Schlei-fen aufgetragen. Jeder Benchmark ist in der Abbildung durchnummeriert, um einen direkten Bezug aufden entsprechenden Test nehmen zu konnen.

Loops auf Win2k

Abbildung 19 zeigt die Testergebnisse von Loops auf auf Plattform 4.2.1. Test 1 und 2 wurden interpre-tiert ausgefuhrt. Test 3,4 und 5 wurden kompiliert. Der Vergleich von Test 1 und 2 zeigt, dass die Inter-pretation durch die JamaicaVM signifikant schlechtere Ergebnisse liefert als die Interpretation durch dieVM von Sun. Der Grund liegt darin, dass Sun einen JIT-Compiler benutzt und somit den Bytecode nichtmehr zu 100 Prozent interpretiert ausfuhrt.Test 3,4 und 5 wurden vollstandig compiliert. In Test 4 wurde durch die Optimierung des Compilersdie leere Schleife (Empty Loop) entfernt. In der zweiten Schleife (Calc Loop) rechnet der Compiler dassErgebnis des Zahlers Res aus und setzt ihn als konstantes Ergebnis ein. Die Zeitmessung von EmptyLoop und Calc Loop ergibt dadurch zur Laufzeit 0 ms. Durch die Inverse Interpretation der Ergebnissein Abbildung 19 wurden somit die Resultate fur Empty Loop und Calc Loop unendlich sein. Fur eineubersichtliche Darstellung, wurden die Ergebnisse fur Empty Loop und Calc Loop entfernt.

1 20

20

40

60

80

100

120

140

160

180

200

Benchmark: SciMark2 auf vxWorks5.5

FFT

SOR

Monte Carlo

Sparse mult.

LU

1 2 3 4 50

0.2

0.4

0.6

0.8

1

1.2

1.4

Benchmark: Loops auf Win2k

Empty Loops

Calc Loops

Real Calc Loops

Sun Jamaica Jamaica, gcc Microsoft, gcc C, gcc

Ausfü

hru

ngsgeschw

indig

keit

[1/s

]

Abbildung 19: Loops auf Win2k.



Loops auf VxWorks5.5

Abbildung 20 zeigt die Testergebnisse des Loop auf auf auf Plattform 4.2.2.Test 1 und 2 wurden mit dem gcc kompiliert. Test 1 zeigt hier ein deutlich performanteres Verhalten alsTest 2. Allerdings wurde bei Test 2 keine optimierenden Compilerschalter verwendet.

1 20

20

40

60

80

100

120

140

160

180

200


FFT

SOR

Monte Carlo

Sparse mult.

LU

1 2 3 4 50

0.2

0.4

0.6

0.8

1

1.2

1.4


Empty Loops

Calc Loops

Real Calc Loops

Sun Jamaica Jamaica, gcc Microsoft, gcc C, gcc

Ausfh

rungsgeschw

indig

keit

[1/s

]

1 20

5

10

15

20

25

Benchmark: Loops auf VxWorks5.5

Empty Loops

Calc Loops

Real Calc Loops

Jamaica, gcc C, gcc

Ausfü

hru

ngsgeschw

indig

keit

[1/s

]

Abbildung 20: Loops auf VxWorks5.5.



4.3.3 RSA-Angriff

Abbildung 21 und 22 zeigen die Ergebnisse des RSA-Angiff [c’t Ausg.19] Benchmarks. Auf der Y-Achseist jeweils die Ausfuhrungsgeschwindigkeit in 1/s angegeben. Auf der X-Achse sind die einzelnenSchleifen aufgetragen. Jeder Benchmark ist in der Abbildung durchnummeriert, um einen direkten Be-zug auf den entsprechenden Test nehmen zu konnen.

RSA-Angriff auf Win2k

Abbildung 21 zeigt die Testergebnisse von RSA-Angriff auf Plattform 4.2.1. Test 1 und 2 wurden inter-pretiert ausgefuhrt. Test 3,4 und 5 wurden kompilert. Der Vergleich von Test 1 und 2 zeigt, dass die In-terpretation durch die JamaicaVM signifikant schlechtere Ergebnisse liefert als die Interpretation durchdie VM von Sun. Der Grund liegt darin, dass Sun einen JIT-Compiler benutzt und somit den Bytecodenicht mehr zu 100 Prozent interpretiert ausfuhrt.Test 3, 4 und 5 wurden vollstandig kompiliert. Test 3 zeigt eine deutlich schlechtere Performance alsTest1. Die ist dadurch erklarbar, dass JamaicaVM keine native Windows Funktionen implementiert.Das MinGW ist ein zusatzlicher Layer, welcher alle POSIX Funktionen auf Windows native Funktionenabbildet.

1 20

20

40

60

80

100

120

140

160

180

200


FFT

SOR

Monte Carlo

Sparse mult.

LU

1 2 3 4 50

0.2

0.4

0.6

0.8

1

1.2

1.4


Empty Loops

Calc Loops

Real Calc Loops

Sun Jamaica Jamaica, gcc

Microsoft, gcc

Ausfh

rungsgeschw

indig

keit

[1/s

]

1 20

5

10

15

20

25

Benchmark: Loops auf vxWorks5.5

Empty Loops

Calc Loops

Real Calc Loops

Jamaica, gcc

Ausfü

hru

ngsgeschw

indig

keit

[1/s

]

1 2 3 4 50

0.05

0.1

0.15

0.2

0.25

Benchmark: RSA-Angriff auf Win2k

Brute Force

Rekursiver Ansatz

Sun Jamaica Jamaica, gcc C, Microsoft C, gcc

Ausfü

hru

ngsgeschw

indig

keit

[1/s

]

Abbildung 21: RSA-Angriff auf Win2k.



RSA-Angriff auf VxWorks5.5

Abbildung 22 zeigt die Testergebnisse des RSA-Angriffs auf Plattform 4.2.2.Test 1 und 2 wurden mit dem gcc kompiliert. Die Ergebnisse der Benchmarks sind ausgeglichen. DerUnterschied in der Ausfuhrungsgeschwindigkeit in Test 1 und Test 2 sind annahernd gleich.

1 20

20

40

60

80

100

120

140

160

180

200


FFT

SOR

Monte Carlo

Sparse mult.

LU

1 2 3 4 50

0.2

0.4

0.6

0.8

1

1.2

1.4


Empty Loops

Calc Loops

Real Calc Loops

Sun Jamaica Jamaica, gcc

Microsoft, gcc

Ausfh

rungsgeschw

indig

keit

[1/s

]

1 20

5

10

15

20

25

Benchmark: Loops auf vxWorks5.5

Empty Loops

Calc Loops

Real Calc Loops

Jamaica, gcc

Ausfü

hru

ngsgeschw

indig

keit

[1/s

]

1 2 3 4 50

0.05

0.1

0.15

0.2

0.25

Benchmark: RSA-Angriff auf Win2k

Brute Force

Rekursiver Ansatz

Sun Jamaica Jamaica, gcc C, gcc

Ausfü

hru

ngsgeschw

indig

keit

[1/s

]

1 20

0.005

0.01

0.015

0.02

0.025

Benchmark: RSA-Angriff auf VxWorks5.5

Brute Force

Rekursiver Ansatz

Jamaica, gcc C, gcc

Ausfü

hru

ngsgeschw

indig

keit

[1/s

]

Abbildung 22: RSA-Angriff auf VxWorks5.5.



4.4 Reproduzierbarkeit

Die Testergebnisse konnen jederzeit auf den verwendeten Plattformen 4.2.1 und 4.2.2 reproduziert wer-den. Die Quellcodes der Benchmarks befinden sich in Anhang A im Verzeichnis ./Benchmark/

Compiler- und Linker- Optionen

JamaicaVM: Die verwendeten Compiler- und Linker- Optionen befinden sich in Anhang A. Diese sindin der Datei ./jJamaica/jamaica.conf gespeichert.

gcc: Compiler:-O2 -mcpu=603 -mstrict-align -fno-builtin-IC:/Programme/Tornado2.2/target/h/-IC:/Programs/jamaica/target/vxworks-ppc603/include/-IC:/Programme/Tornado2.2/target/config/RIO3 370S/-IC:/Programme/Tornado2.2/host/x86-win32/i386-pc-mingw32/sys-include/-DCPU=PPC603 -DTOOL FAMILY=gnu -DTOOL=gnu

Linker:-X -N

VC6.0: Compiler:/nologo /ML /W3 /GX /O2 /D “WIN32“ /D “NDEBUG“ /D “ CONSOLE“/D “ MBCS“ /Fp“Release/d.pch“ /Yu“stdafx.h“ /Fo“Release/“ /Fd“Release/“ /FD /c

Linker:kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.libadvapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.libodbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.libcomdlg32.lib advapi32.lib shell32.lib ole32.liboleaut32.lib uuid.lib odbc32.lib odbccp32.lib/nologo /subsystem:console /incremental:no /pdb:“Release/d.pdb“ /machine:I386 /out:“Release/d.exe“



5 Interboardkommunikation via VME-Bus

5.1 Implementierung

Ein Sweep wird in einem Bytearray serialisiert. Durch das Java Native Interface wird dieses Bytear-ray einem C-Programm ubergeben. Das C-Programm ubertragt mit den nativen Treiberfunktionen dasubergebene Bytearray. Auf der Gegenstelle wird das Bytearray von einem weiteren C-Programm emp-fangen und an ein Java-Programm ubergeben. Anschließend wird das Bytearray wieder deserialisiert.

Der Quellcode befindet sich in Anhang A im Verzeichnis ./Vme/

5.2 Test

Fur den Test wurde ein Blackboxverfahren verwendet. Es wurden 1000 Sweeps nacheinander uber denVME-Bus ubertragen. Bei jeder Ubertragung fand eine positive CRC-Uberprufung statt.

5.3 Ergebnis

Es wurde gezeigt, dass eine echtzeitfahige Kommunikation mit Java uber einen VME-Bus moglich ist.


Untersuchung derEinsetzbarkeitvon Echtzeit-Java in derRadarsignalverarbeitung 30. Oktober2004

D Literatur

Literatur

[Dib2002] PeterC. Dibble - Real-Tim eJavaPlatform Program m ingSun Microsystem s, Inc., 2002

[Goe2001] Jurgen Gobel- Radartechnik, Grundlagen und Anw endungVDE Verlag, 2001

[Lud1993] AlbrechtLudloff- Handbuch Radarund RadarsignalverarbeitungView eg Verlag, 1993

[Hud1999] Bernhard Huder- Einfuhrung in dieRadartechnikTeubner, 1999

[Far1992] Georg Faber- ProzeßrechentechnikSpringer-Verlag, 1992

[SciMark2.0] SciMark 2.0

http://m ath.nist.gov/scim ark2/

2004

[c’tAusg.19] c’tm agazinAusgabe19, 08.09.2003

[HR2002] PeterHruschka, ChrisRupp - AgileSoftw areentw icklungHanser, 2002

[Kol] H. G. Kolle - DopplerfiltercoefficientsEADS, com pany confidential

[Mahr] Dr. T. Mahr- PulseCom pression AlgorithmEADS, com pany confidential

[Mahr] Dr. T. Mahr- DopplerFilterAlgorithmEADS, com pany confidential

[Kru2003] Guido Kruger- Handbuch derJava-Program m ierungAddison-Wesley, 2003

[ITG1996] ITG - Begriffeund Definitionen ausdem GebietRadarund allgem eineFunkortungHanle, 1996

[HMS1999] Hering, Martin, Stohrer- Physik furIngenieureSpringer, 1999

[BHK2000] Brich, Hinsken, Krause - Echtzeitprogram m ierung in JavaMCD Verlag, 2000

[RTSJ1999] TheReal-Tim eforJavaExpertgroup - TheReal-Tim e-Specification forJavahttp://w w w .rtj.org/rtj.pdf1999

EADSDeutschland Gm bH 74von 75

Untersuchung derEinsetzbarkeitvon Echtzeit-Java in derRadarsignalverarbeitung 30. Oktober2004

[RTCE1999] J-Consortium - Real-Tim eCoreExtensionsfortheJava platformhttp://w w w .j-consortium .org1999

[RTDA1999] J-Consortium - Real-Tim eDataAccesshttp://w w w .j-consortium .org1999

[ZW1995] Zobel, Albrecht- Echtzeitsystem e: Grundlagen und TechnikenInternationalThom sen Publishing Gm bH, 1995

[AIC2004] aicasGm bH - Jam aicaVM UserDocum entationhttp://w w w .aicas.com /jam aica/doc/htm l/index.htm l2004

[AON2004] AONIX- ProductFactSheethttp://w w w .aonix.com /pdf/PercDatasheet.pdf2004

[BEN2003] EADS Deutschland Gm bH - Com parison oftheExecution Tim esofAda, C and Javahttp://w w w .aicas.com /info/EADS benchm ark language com parison.pdf2003

[GHJV] Gam m a, Helm , Johnson, Vlissides- Entw urfsm usterAddison-Wesley, 2003, 1996

EADSDeutschland Gm bH 75von 75

Untersuchung der Einsetzbarkeit von Echtzeit-Java in der ... · Java-System aufbauend auf einem...

Documents

Transcript of Untersuchung der Einsetzbarkeit von Echtzeit-Java in der ... · Java-System aufbauend auf einem...