d`ici 2006

Introduction
Expert-solutions est éditeur de sa propre version de CLAIRE nommée « XL CLAIRE »
et créée il y a 4 ans. Au cours des différents projets menés par XL, CLAIRE a pris une place
de plus en plus dominante dans les développements et devient aujourd’hui le seul langage
utilisé pour la réalisation des (nouveaux) projets : XL fait du « tout CLAIRE ». Pour assurer
cette position industriellement, XL à développé des compétences sur les couches basses du
langage CLAIRE afin de pouvoir comprendre, maîtriser et corriger « rapidement » tout type
de dysfonctionnement. Aujourd'hui, XL peut intervenir à la fois sur le noyau/GC de
CLAIRE, sur les « meta » et autres modules et dans une moindre mesure sur le compilateur
CLAIRE.
XL à mis en place son propre environnement de production de code. A l'origine intégré
dans l'IDE Eclaireur pour win32, la gestion des projets multi-modules et le partage des
modules a été re-développé en CLAIRE et accessible à la ligne de commande. Cette étape a
été nécessaire car la plateforme de développement et déploiement préférée est aujourd'hui
UNIX.
XL réalise des projets type « application internet » et a développé toute une
infrastructure dédiée à ce type d'application. Cela comprend la génération dynamique de
pages HTML multilingues, la production de documents PDF signés numériquement et
l'envoie de message électroniques. De telles applications prennent la forme d'agent CLAIRE
placé derrière un serveur web.
Enfin XL est très sensible aux problèmes de performances, sur les algorithmes de
recherche de solution d'une part, et sur les problèmes de montée en charge des serveurs
derrière lesquels peuvent se trouver de multiples agents d'autre part.

Vers le noyau XL
Dans ce document on fait référence au noyau développé par Yves Caseau par <ycs>. Le
noyau XL est une évolution du noyau <ycs>, certaines fonctionnalités ont étés ajoutées
d'autre modifiées mais sans jamais changer la sémantique du langage.
* Traces du noyau
Tous les traces du noyau XL (par exemple le trace GC) sont systématiquement
redirigés vers ctrace() plutôt que sur stdout. On le vera plus loin il est nécessaire dans un
environnement CGI que la sortie (redirigée) du processus ne soit pas polluée. Pour cela le
noyau XL dispose de sa propre méthode de trace analogue à printf.
* La classe module
Un slot verbose a été ajouté à la classe module dans le noyau XL. Ainsi chaque module
peut avoir sa propre politique de trace. C'est particulièrement pratique pour filtrer les traces
d'applications ayant 10 voir 20 modules. Par défault le champ verbose d'un module est à false
ce qui correspond au comportement du noyau <ycs>. Ce champ peut prendre les valeur
suivantes :
• false (défault) : identique à <ycs>
• true : tout les traces du module sont issus
• <int> : comme si la verbose système valait <int> pour ce module
• Interval : les traces sont issus seulement si leur niveau appartient à
l'intervale
La façon dont est traitée l'instruction de trace a donc été modifiée. De plus, le message
de trace est automatiquement préfixé par :
[<module>:<niveau>] le message du trace
Si, de plus, le processus qui génère le trace est un processus « forké » alors le prefixe
devient :
[<pid>][<module>:<niveau>] le message du trace
Dans le noyau XL, les modules ont également un slot version qui permet de partager (le
partage de module est décrit en deuxième partie) plusieurs version d'un même module. La
version d'un module est une chaîne de caractère.
Enfin le slot made_of d'un module peut contenir dans XL CLAIRE des fichiers .cpp ou
.h. Les .cpp seront ajouter au makefile lors de la compilation et les .h seront inclus dans le .h
du module généré (via compiler.headers).

* Séquences d'échappement
Le Reader XL CLAIRE supporte des séquences d'échappement pour exprimer des
nombres des chaînes ou des caractères dans les base binaires octale et hexadécimales. Une
séquence est introduite par le caractère anti-slash « \ », suivi d'un indicateur de base :
Pasted Graphic 9.tiff ¨
* Représentation des chaînes de caractère
Les chaînes <ycs> sont à l'image des string en C/C++. Pour en connaître la longueur on
utilise strlen, ces chaînes ne peuvent contenir de caractère nul. C'est une limitation quand on
manipule des données binaires (arbitraire). Dans le noyau XL, on adopte le style pascal pour
la représentation des chaînes CLAIRE. Dans cette représentation, la longueur d'une chaîne est
stockée en entête de la zone mémoire qui contient la chaîne, par exemple la chaîne "toto" est
représenté ainsi :
Pasted Graphic 10.tiff ¨
La longueur d'une chaîne se calcule quasi-instantanément avec ce type de
représentation alors que strlen doit parcourir la chaîne entièrement pour en donner la
longueur. Les chaînes C/C++ restent cependant supportées pour toutes les chaînes qui
résident en dehors de Cmemory (cas des chaînes statiques ou importées). Les API de
manipulation de chaîne ont donc été modifiées pour utiliser la nouvelle API length_string :
int length_string(char *s) {
return CLMEM(s) ?
*((int*)s - 1) :
strlen(s);
}
Note : on réserve systématiquement un caractère nul en fin de chaîne, ainsi les chaînes
CLAIRE sont entièrement compatibles avec les chaînes C/C++ et peuvent êtres passées en
argument à des appels fonctionnels de bibliothèques externes sans causer de dommage.
* Destructeurs: freeable_object
Le besoin d'un destructeur a été évoqué sur le forum claire-language et implementé
dans le noyau XL pour un nouveau type d'objet:
freeable_object <: ephemeral_object(
freeme?:boolean = false)
Un objet de type freeable_object est éphémère, lorsque le GC détruit une instance de ce
type il appelle free! donnant l'opportunité de faire un nettoyage, par exemple :
long_double* <: import()
long_double <: freeable_object(value:long_double*)

close(self:long_double) : long_double ->
(sel.value := externC(
"(long double*)::malloc(sizeof(long double))",
long_double*),
self)
free!(self:long_double) : void ->
externC("::free(self->value)")
Une liste d'instances de freeable_object est maintenue par le noyau. Lors d'un GC, le
conteneur de cette liste est d'abord marqué, puis, à la suite de l'opération de marquage les
instances de cette liste qui n'ont pas étés marqués sont marqué « à la main » et leur slot
freeme? est mis à true de sorte qu'a la fin du GC (lorsque la mémoire est dans un état sain) on
peut reparcourir cette liste et appeler free! pour les objets qui ont freeme? à true.
L'appel à free! peut générer un GC (récursif), auquel cas le traitement ci-dessus n'est
pas effectué, l'ensemble des freeable_object sont marqués et leur slot freeme? reste inchangé.
Note : Lorsque CLAIRE se termine free! est appelé pour tous les freeable_object
encore en mémoire afin de terminer proprement l'exécution.
* freeContent
Dans le noyau XL lorsqu'un bag est ré-alloué (par exemple à la suite d'une insertion)
l'ancien contenu est désalloué immédiatement. Une méthode freeContent à été ajoutée au GC
à cet effet.

* GC & congestion mémoire
Egalement évoqué sur le forum claire-language, le noyau XL apporte une solution au
problème de congestion mémoire. L'idée principale est de profiter de la gestion efficace de la
mémoire virtuelle (VM) sous une architecture UNIX. Les schémas ci-dessous illustrent la
congestion :
Pasted Graphic 11.tiff ¨
Lorsque l'option « -auto » est utilisée et qu'une congestion mémoire intervient, la
mémoire est automatiquement augmentée. Avec cette option, le plus grand block possible est
alloué lors de l'initialisation de Cmemory (comme si « -s 9 j » était donné). Cependant
CLAIRE est contraint dans un espace plus petit conformément à l'option « -s i j ». En cas de
congestion de la mémoire (chunk ou object) on opère à un simple décalage de la borne de la
mémoire concerné ce qui est instantané et ne provoque aucune ré-allocation dynamique.
On prend en compte deux type de congestion :
• spatiale : il n'y a de toute façon pas assez de place pour alloué un objet
donc on augmente la mémoire
• temporelle : on passe plus de temps à faire des GC que du calcul donc
on donne plus d'espace au programme afin d'éviter de passer trop de temps dans le
GC.
Note 1: Sous win32, ceci est totalement inefficace car la gestion de la mémoire
virtuelle est en fait physique! En revanche sous UNIX ceci est particulièrement efficace:
temps que la mémoire n'est accédée qu'en lecture aucune page mémoire n'est effectivement
allouée.
Note 2: En « -auto » les différentes piles allouées par le noyau (GC, exécution et
monde) supportent la congestion. Les piles sont automatiquement ré-allouées pour prévenir
un dépassement. Seule la table des symboles ne supporte pas la congestion.
Note 3: Aucun mécanisme de décongestion n'est supporté: la mémoire utilisée ne peut
qu'augmenter.