Rapport - JXOS

Implémentation de RTSJ sur JXOS
Thierry Baldo
1 novembre 2004
Résumé
Ce document présente un début d’implémentation de RTSJ sur JXOS.
Table des matières
1 Introduction 3
2 Intérêt 3
3 JXOS 4
3.1 Présentation............................... 4
3.2 Comparaison avec un système d’exploitation “moderne” . . . . . . . 5
3.3 Restrictions............................... 5
3.4 Débogage................................ 5
3.5 Utilisation de QEMU ou VMware . . . . . . . . . . . . . . . . . . . 6
3.6 Compilation............................... 6
3.7 Présentation détaillée de JXOS . . . . . . . . . . . . . . . . . . . . . 6
3.7.1 Arborescence.......................... 6
3.7.1.1 Arborescence du noyau . . . . . . . . . . . . . . . 6
3.7.1.2 Arborescence des composants . . . . . . . . . . . . 7
3.7.1.2.1 Le fichier “META” . . . . . . . . . . . . 7
3.7.2 Le fichier “boot.rc” . . . . . . . . . . . . . . . . . . . . . . . 7
3.7.3 Le fichier “jcore/jxcore” . . . . . . . . . . . . . . . . . . . . 7
3.7.4 Le fichier “code.zip” . . . . . . . . . . . . . . . . . . . . . . 7
3.7.5 Le fichier “ADD_TO_ZIP” . . . . . . . . . . . . . . . . . . . 7
3.8 Lesportails ............................... 8
4 RTSJ 8
4.1 Présentation............................... 8
4.2 Contraintes ............................... 8
4.3 Présentation détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5 Architecture de l’implémentation 8
5.1 Architecture globale . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 Architecture au niveau du noyau . . . . . . . . . . . . . . . . . . . . 9
5.3 Architecture au niveau des composants . . . . . . . . . . . . . . . . . 9
5.4 RealtimeManager............................ 9
1

6 Détails de l’implémentation 10
6.1 Lestimers................................ 10
6.1.1 LEPIT8254 .......................... 10
6.1.2 Interruption “timer” dans un système à temps-partagé . . . . . 10
6.1.3 Les Timers dans JXOS . . . . . . . . . . . . . . . . . . . . . 10
6.1.4 Principe des timers “temps-réels” . . . . . . . . . . . . . . . 11
6.1.5 Le Time Stamp Counter . . . . . . . . . . . . . . . . . . . . 11
6.1.6 Les handlers .......................... 11
6.2 Les événements asynchrones . . . . . . . . . . . . . . . . . . . . . . 11
6.2.1 AsyncEvent........................... 11
6.2.2 AsyncEventHandler . . . . . . . . . . . . . . . . . . . . . . 11
6.2.3 BoundAsyncEventHandler . . . . . . . . . . . . . . . . . . . 12
6.3 Les listes d’attente sans verrou . . . . . . . . . . . . . . . . . . . . . 12
6.4 La mémoire à portée (Scoped Memory) . . . . . . . . . . . . . . . . 12
6.4.1 Allocation classique dans le Tas . . . . . . . . . . . . . . . . 12
6.4.2 Temps d’allocation . . . . . . . . . . . . . . . . . . . . . . . 12
6.4.3 Architecture de l’implémentation . . . . . . . . . . . . . . . 13
6.4.3.1 Allocation de la ScopedMemory ........... 13
6.4.3.2 Utilisation de la ScopedMemory ........... 13
6.4.3.3 Désallocation d’une ScopedMemory ........ 13
6.4.4 Notes sur le Garbage Collector ................ 13
6.5 L’ordonnancement ........................... 14
6.5.1 Choix d’un thread . . . . . . . . . . . . . . . . . . . . . . . 14
6.5.2 Ordonnancement dans JXOS . . . . . . . . . . . . . . . . . . 14
6.5.3 Ordonnancement Temps Réel . . . . . . . . . . . . . . . . . 14
7 Mise en route (Getting Started) 15
7.1 Introduction............................... 15
7.2 Installation ............................... 15
7.3 Compilation des programmes d’exemples . . . . . . . . . . . . . . . 16
7.4 Exécution................................ 16
7.4.1 Utilisation directe d’un PC . . . . . . . . . . . . . . . . . . . 16
7.4.2 Utilisation de QEMU . . . . . . . . . . . . . . . . . . . . . . 17
7.4.2.1 Avec minicom .................... 17
7.4.2.2 Avec redirection dans un fichier . . . . . . . . . . . 17
7.5 Liste des programmes d’exemples . . . . . . . . . . . . . . . . . . . 17
7.5.1 Plusieurs threads Temps Réel . . . . . . . . . . . . . . . . . 17
7.5.2 Evénements asynchrones et timers . . . . . . . . . . . . . . . 18
7.5.3 Manipulation des dates . . . . . . . . . . . . . . . . . . . . . 19
7.5.4 File de messages sans attente . . . . . . . . . . . . . . . . . . 19
7.5.5 Dépassement d’échéance . . . . . . . . . . . . . . . . . . . . 20
7.5.6 Mémoire à portée (ScopedMemory) .............. 20
7.5.7 Ordonnancement Temps Réel . . . . . . . . . . . . . . . . . 22
8 Performances 22
8.1 Rapidité................................. 22
8.2 Stabilité temporelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9 Conclusion 24
2

10 Annexes 25
10.1 Annexe A : liste de fonctions du noyau . . . . . . . . . . . . . . . . . 25
10.1.1 curthr.............................. 25
10.1.2 curdom ............................. 25
10.1.3 thread2CPUState . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1.4 cpuState2thread . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1.5 findClassDesc.......................... 25
10.1.6 classDesc2Class . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1.7 findPrimitiveClass . . . . . . . . . . . . . . . . . . . . . . . 25
10.1.8 obj2ClassDesc ......................... 26
10.1.9 findMethod........................... 26
10.1.10 allocObjectInDomain . . . . . . . . . . . . . . . . . . . . . . 26
10.1.11 allocArrayInDomain . . . . . . . . . . . . . . . . . . . . . . 26
10.2 Annexe B : exemple d’ajout d’un portail . . . . . . . . . . . . . . . . 26
10.2.1 Création de l’interface (libs/zero/jx/zero/Essai.java) . . . . . . 26
10.2.2 Choix de l’implémentation . . . . . . . . . . . . . . . . . . . 27
10.2.3 Implémentation en C (cas 1, 2 et 3) . . . . . . . . . . . . . . 27
10.2.3.1 Ajout du fichier jcore/essai.h . . . . . . . . . . . . 27
10.2.3.2 Ajout dans le fichier jcore/portal.h . . . . . . . . . 27
10.2.3.3 Ajout dans le fichier jcore/Makefile . . . . . . . . . 27
10.2.3.4 Ajout dans la fonction init_zero_from_lib du fichier
jcore/zero.c ..................... 27
10.2.3.5 Ajout dans la méthode InitNaming du fichier init2/jx/init/InitialNaming 28
10.2.3.6 Fichier jcore/zero_Essai.c . . . . . . . . . . . . . . 28
10.2.4 Implémentation en Java . . . . . . . . . . . . . . . . . . . . 29
11 Bibliographie et Webographie 30
1 Introduction
Dans le cadre de l’UV ISTR-C2 (Intégration des systèmes temps-réel embarqués)
du CNAM (Conservatoire National des Arts et Métiers), j’ai été amené a effectuer
l’implémentation de RTSJ (Real-Time Specification for Java) sur JXOS, ie. d’ajouter
l’utilisation du temps-réel en Java.
2 Intérêt
L’intérêt de pouvoir effectuer du Temps Réel en Java et de pouvoir capitaliser la ri-
chesse de l’environnement Java dans des domaines où la fiabilité lui est refusée. Même
si Java est utilisé dans le monde embarqué (en particulier les téléphones portables avec
J2ME), utiliser Java dans un monde de fortes contraintes en terme de fiabilité n’est pas
conseillé.
Le schéma suivant représente une comparaison (théorique) entre le développement
C (ou Ada) et Java.
3

3 JXOS
3.1 Présentation
Nous avons choisi d’utiliser JXOS (http://www.jxos.org) pour implémenter
RTSJ.
JXOS est un “système d’exploitation en Java” distribué sous GPL (http://www.
jxos.org/license.html). En fait, il est composé de deux grandes parties :
– le noyau (core) : écrit en C et en assembleur
– les composants (components) : écrits en Java
JXOS est utilisé dans l’optique “exécutif” plutôt que système d’exploitation. On com-
pile un ensemble de composants qui vont être “l’application”. La machine est alors
démarrée et utilise directement cette application.
Une application est vue comme un ensemble de domaines (domains). Chaque do-
maine peut communiquer avec les autres domaines via un mécanisme de portail (por-
tal), ie. qu’un domaine offre des services qu’un autre domaine peut utiliser.
Un seul domaine est obligatoire : le domaine Zéro (DomainZero), qui contient le
noyau en C. L’API externe du noyau est accessible en Java.
Par analogie avec les applications Java classique, chaque domaine (autre que le
domaine Zéro) peut être vu comme une machine virtuelle Java (JVM). Ceci entraîne
que chaque domaine :
– ne peut pas communiquer directement avec un autre domaine
– possède un tas (heap) où s’effectuent les allocations dynamiques
– possède un ramasse-miettes (Garbage Collector)
– possède un ensemble de threads
– démarre sur une (ou plusieurs) classe via la méthode “main”
JXOS ne tourne pour le moment que sur architecture x86. Un portage sur ARM4 est
en cours.
4

JXOS comporte un compilateur natif qui transforme le bytecode en code natif x86.
3.2 Comparaison avec un système d’exploitation “moderne”
JXOS diffère en outre des systèmes d’exploitation “modernes” sur différents points :
– pas de swapping
– pas de passage entre le mode utilisateur et le mode privilégié
– un adressage mémoire à “plat” (flat)
– pas de protection mémoire
– les drivers sont écrits en Java
– l’API externe du noyau est en Java
Dans un système d’exploitation “moderne” tel que Linux :
– le code qui est exécuté dans le noyau :
– est en mode privilégié
– n’est pas protégé par la MMU (Memory Management Unit)
– le code qui est exécuté hors du noyau :
– est mode non-privilégié
– est protégé par la MMU (Memory Management Unit)
Dans JXOS, tout le code s’exécute en mode privilégié, sans protection par la MMU.
Ceci n’est donc pas différent pour la partie C/assembleur. Par contre, la protection de
la partie Java est effectuée via le contrôle du bytecode (débordement de tableau par
exemple).
JXOS pourrait convenir très bien sur des systèmes ne disposant pas de MMU (par
exemple, les micro-controlleurs), mais JXOS demande des ressources mémoires assez
importantes pour ces systèmes (au moins 20 Mo).
3.3 Restrictions
JXOS souffre néanmoins de plusieurs défauts et restrictions :
– tout le bytecode n’est pas disponible (ex : l’utilisation des “longs” n’était pas
possible dans la version précédente de JXOS), même si maintenant la quasi to-
talité du bytecode est supportée
– pas d’utilisation du mot-clef “synchronized” : il n’y a pas de mutex dans chaque
objet
– pas d’utilisation de “notify” et autre moyen de réveil
– beaucoup de classes ne sont pas implémentées
– beaucoup de méthodes ne sont pas implémentées (ex : Thread.sleep ())
– la pile IP est parfois mal implémentée :
– l’ouverture d’un port TCP distant provoque l’ouverture du port local avec le
même numéro de port
– les numéros des ports TCP sont globaux à la pile TCP et non pas à chaque
interface réseau
– les interfaces réseau sont prévues uniquement pour ethernet
– il y a peu de périphériques supportés
– la documentation est quasiment inexistante
3.4 Débogage
Le débogage s’effectue via le premier port série (/dev/ttyS0 ou COM1) avec les
paramètres suivants :
5