Corosol, une JVM modulaire paramétrable à la volée

Corosol, une JVM modulaire paramétrable
à la volée
Christophe Deleray —Nicolas Bedon —Gilles Roussel
Etienne Duris
Institut Gaspard Monge
Université de Marne-la-Vallée
5, boulevard Descartes
F-77454 Marne-la-Vallée cedex 2
{cdeleray, bedon, roussel, duris}@univ-mlv.fr
RÉSUMÉ. Pour étendre les fonctionnalités du langage ou pour affinerle contrôle du programmeur
sur l’exécution des programmes, de nombreux travaux s’intéressent à des modifications de la
machine virtuelle Java. Motivés par des problèmes spécifiques, ces travaux aboutissent souvent
à des implantations ad hoc qui sont difficiles à comparer ou à combiner. Dans cet article,
nous présentons Corosol, une nouvelle plate-forme de test et d’intégration pour ces extensions.
Corosol est une machine virtuelle Java ouverte, écrite en Java, dont l’architecture est basée sur
des composants auxquels le programmeur des applications a accès. Il peut bien sûr changer
ces composants avant le démarrage de la machine virtuelle, mais il peut surtout les modifier,
les remplacer ou en ajouter de nouveaux au cours de l’exécution du programme via une API
d’introspection de la machine virtuelle.
ABSTRACT. In order to extend the functionalities of the language or to refine the control of the
developper over the software execution, several research works focus on modifications of the
Java virtual machine. Since these works try to solve specific problems, most of them lead to
ad-hoc solutions that are difficult to compare or combine. In this article, we present Corosol, a
new test and integration platform for those extensions. Corosol is an open Java virtual machine,
written in Java, whose architecture is based on components to which the programmer of the ap-
plications has access. These components could be changed before virtual machine startup, but
also be modified, replaced or added at run-time by the running application through a reflection
API.
MOTS-CLÉS : Java, machine virtuelle, composants logiciels, introspection.
KEYWORDS: Java, virtual machine, component-based software, reflection.
RSTI - L’objet – 10/2004. LMO’04, pages 89 à 102

90 RSTI - L’objet – 10/2004. LMO’04
1. Introduction
Cet article présente nos travaux en cours sur Corosol, une machine virtuelle Java
qui offreune API permettant de modifier à la volée son comportement.L’objectif de ce
travail est de fournir un environnement de développementportable facilitant la spécia-
lisation et l’extension des applications relativement à leur contexte d’exécution. Pour
cela, l’architecture de Corosol est organisée en composants fonctionnels, accessibles
et modifiables par introspection.
Grâce à l’introspection, l’application dispose d’une vue de son environnement
d’exécution; elle peut ainsi s’y adapter et même, dans certains cas, le spécialiser
pour ses propres besoins. Parmi les nombreux travaux de recherche concernant l’in-
trospection, certains s’intéressent à son pouvoir d’expression [SMI 84] (pour un tu-
torial cf. [MAL 96]) et d’autres à la conception de plates-formes d’exécution qui
offrent un mécanisme d’introspection aux applications qu’elles exécutent. En particu-
lier, [PIU 00] décrit une machine virtuelle générique qui est entièrement paramétrable
au démarrage de l’application,mais également au cours de l’exécutionde l’application
via une interface d’introspection comportementale.
Par ailleurs, il semble naturel d’exprimer les spécialisations et les extensions de
l’environnement d’exécution dans le langage de l’application, surtout quand elles sont
réalisées par introspection. Le plus simple est alors d’utiliser le même langage pour
spécifier l’application et son environnement d’exécution, comme cela a déjà été ex-
périmenté avec les langages LISP [SMI 84], SmallTalk [GOL 83] ou Java [TAI 98].
Dans le cas où l’environnementd’exécution est une machine virtuelle,cette caractéris-
tique présente un autre avantage important : la machine virtuelle peut être vue comme
une partie de l’application, ce qui implique que la modifier n’entraîne pas de perte de
portabilité de l’application.
Corosol est donc une machine virtuelle Java ouverte écrite en Java. Son architec-
ture est basée sur des composants clairement identifiés. Chacun dispose d’une im-
plantation par défaut qui émule le fonctionnement d’une machine virtuelle classique.
Toutefois, ces implantations peuvent être aisément modifiées pour définir un compor-
tement particulier. Pour cela, deux niveaux de paramétrage de la machine virtuelle
sont disponibles : au démarrage, par un fichier de propriétés, ou à la volée, depuis
l’application qui s’exécute, via une API. Celle-ci étend à l’ensemble des composants
de la machine virtuelle les fonctionnalités de réflexion déjà offertes pour les classes
par le paquetage . Elle permet aux applications d’accéder aux
composants de la machine virtuelle comme à leurs propres objets.
Parmi les travaux de recherche sur la machine virtuelle Java, certains [DOY 01,
ALP 00, ANT 02, TUL 01] ont pour objectif d’améliorer les performances dans un
contexte donné.D’autres [LEW 00, TJA 99] étendent les fonctionnalités des machines
standards. Plus proches de notre objectif, certains travaux proposent des machines
virtuelles ouvertes, sans fonctionnalités particulières mais dont les composants sont
modifiables. La plupart sont écrites en C [GAG 01, DOY 01], certaines nécessitent
un mélange de C ou C++ et de Java [ALP 00, WHA 03] et d’autres, beaucoup plus

Corosol 91
rares, sont entièrement écrites en Java [TAI 98]. Les machines virtuelles écrites en C
sont plus performantes, mais leur modification impose au programmeur de connaître
ce langage, et le prive des facilités de redéfinition propres à Java. Aucune d’entre-
elles n’offre aux applications qu’elles exécutent une API d’introspection permettant
d’accéder à leurs fonctionnalités ou de les paramétrer finement depuis le programme.
Dans la suite de cet article, nous présentons dans la section 2 l’architecture de Co-
rosol et les composantsqui la constituent. La section3 décrit le processus de construc-
tion et de démarrage de Corosol lorsqu’elle doit interpréter un programme Java. Les
mécanismes d’interactions entre une application exécutée par Corosol et ses compo-
sants sont présentés dans la section 4. Enfin, pour conclure, nous discutons de l’avan-
cement de notre travail et de ses perspectives d’évolutions.
2. Architecture
Cette section présente les choix et les contraintes qui ont abouti à la conception
de la machine virtuelle Corosol. Rappelons que pour des raisons de compatibilité, de
portabilité et de possibilité d’interactions avec les applications exécutées, nous sou-
haitions que cette machine virtuelle soit complètement écrite en Java. L’exécution de
Corosol repose donc naturellement sur une machine virtuelle Java standard, dite JVM
hôte. Corosol est considérée par celle-ci commen’importe quelautre programmeJava.
Par ailleurs, nous souhaitons que Corosol soit capable d’interpréter de manière
cohérente du bytecode Java standard. Elle doit disposer d’une configuration par défaut
qui lui permet d’émuler une JVM standard. L’architecture de Corosol s’appuie donc
naturellement sur la spécification de Sun [LIN 99].
Enfin, notre objectif étant de pouvoir paramétrer le plus finement possible ses dif-
férents comportements, l’architecture de Corosol doit être très modulaire. À chacune
des fonctionnalités de la machine virtuelle est associé un composant de sorte qu’il
puisse être aisément utilisé, modifié ou remplacé. Pour cela, chaque composant est
représenté par une interface particulière dont nous fournissons une implantation par
défaut simulant un comportement standard pour les fonctionnalités correspondantes.
Corosol peut donc être vue comme une couche logicielle intercalée entre la JVM
hôte et le programmeutilisateur qu’elle doit interpréter. Elle offre à ce programme,en
plus des fonctionnalités classiques d’une JVM, un accès à ses différents composants
fonctionnels. La figure 1 illustre la position qu’occupe Corosol au sein de la chaîne
d’exécution : elle est la machine virtuelle vis-à-vis du programme utilisateur, et elle
est elle-même exécutée par une JVM hôte.
Nous allons maintenant présenter les composants qui constituent la versionde base
de Corosol, et justifier leur existence en donnant des exemples de spécialisation ou de
modification de comportement dont ils peuvent être l’objet. La figure 1 fait apparaître
quelques uns de ces composants. Certains correspondent à des entités décrites dans

92 RSTI - L’objet – 10/2004. LMO’04
la spécification d’une machine virtuelle Java [LIN 99], d’autres à des mécanismes
internes, comme qui représente le mécanisme de résolution de méthodes.
Fichier de propriétés
(paramètre Corosol).
Corosol interprète le
programme utilisateur.
ImplantationComposant
"JVirtualMachine"
"JHeap"
"JThread" DefaultThreadImpl
DefaultHeapImpl
MyJVMDefaultImpl
......
Le (bytecode classique du) programme Java
utilisateur peut interagir avec Corosol.
La JVM hôte classique interprète
Corosol et stocke tous ses objets.
JResolver
JClassLoader
JStackFrame
JInstruction.Iadd
JScheduler
JVirtualMachine
JHeap
JThread
Corosol.getVirtualMachine()
Figure 1. Architecture et positionnement de Corosol dans la chaîne d’exécution
– les instructions de bytecode Java sont toutes représentées par un compo-
sant. Plus exactement, à chacune des instructions est associée un composant qui
implante l’interface . Par exemple, l’instruction correspondant à
l’addition entière, , est représentée par un composant dont l’interface est
. L’utilisation d’un composant pour chaque instruction permet
de modifier le comportementpar défaut d’uneinstruction ou d’en ajouter de nouvelles.
Par exemple, on peut simplement étendre le bytecode standard avec de nouvelles ins-
tructions réalisant l’exponentiation ou les fonctions trigonométriques classiques;
– le composant tas, représenté par l’interface , a la responsabilité du sto-
ckage et de la gestion de la mémoire (allocation, accès, désallocation...).Une applica-
tion visée par notre travail est de permettre, par des spécialisations de ce composant,
de tester et de comparer différents algorithmes de ramasse-miettes;
– le chargeur de classe recouvre des mécanismes assez complexes permettant,
à partir d’un fichier contenant du bytecode, de fournir à la machine virtuelle toutes
les informations (typage, champs, méthodes) requises pour l’exécution du programme
correspondant. Une spécialisation intéressante de ce composant consisterait à mettre
en œuvre et à tester différentes techniques de vérification de code;
– les composants correspondant aux classes,champs et méthodes sont d’une na-
ture un peu différente des autres. En effet, il sont plutôt vus comme des conteneurs
d’information que comme des composants fonctionnels. Par exemple, une méthode
contient une suite d’instructions, mais aussi d’autres informations comme les modi-
ficateurs d’accès. On peut imaginer qu’une extension du langage, comme l’héritage
multiple pour les classes, puisse nécessiter des spécialisations de ces composants;
– le composant stackframe correspond à la partie de la pile d’appel qui est dé-
diée à l’exécution d’une méthode. Par exemple, ce composant peut être modifié pour

Corosol 93
prendre en compte un nouveau type primitif ou encore pourcontrôler et gérer finement
l’espace mémoire;
– le résolveur de méthode est le composant qui détermine, étant donné un appel
de méthode, dans quelle classe se trouve le code de la méthode qui doit effectivement
être exécuté. Une implantation particulière de ce composant peut, par exemple, être
utilisée pour introduire des multi-méthodes en Java, c’est-à-dire un mécanisme de
liaison tardive sur le type des arguments [FOR 00];
– le composant thread a en charge la gestion de la portion de code et du contexte
d’exécution d’un processus léger. Il peut être spécialisé pour gérer de manière spéci-
fique la mémoire locale ou les ;
– l’ordonnanceur est le composant qui gère la répartition des ressources d’exécu-
tion (processeur, espace mémoire, données, etc.) aux différents processus légers. Ce
composant peut être spécialisé pour mettre en œuvre une gestion fine des priorités
entre processus légers, ou pour implanter une nouvelle notion de préemption;
– la machine virtuelle est le composant central de Corosol. Il initie la construc-
tion de l’application devant exécuter le programme utilisateur avec toutes les initiali-
sations nécessaires. En particulier, il est en relation avec tous les autres composants.
La position centrale de rend son remplacement dynamique assez
périlleux. Néanmoins, une implantation spécifique de ce composant peut être choisie
au démarrage.
Certaines fonctionnalités d’une machine virtuelle Java sont complètement locali-
sées dans un unique composant de Corosol, les modifier n’entraîne donc que la modi-
fication de ce composant (ex : changementde l’algorithme pour le ramasse-miettes ou
l’ordonnanceur). D’autres fonctionnalités plus transverses peuvent nécessiter le chan-
gement de plusieurs composants. Par exemple, supposons que l’on souhaite ajouter un
type primitif dans Corosol. D’une part, cela implique des modifications sur
les composants qui stockent de telles valeurs : tas, stackframe et champs. D’autre part,
des instructions de bytecode relatives au type doivent être ajoutées : sto-
ckage, opérations arithmétiques, etc. Enfin, il faut créer pour l’introspection un objet
,ajouter un littéral pour le constant pool et renseigner le chargeur de
classes sur les opcodes des nouvelles opérations. Chacune de ces modifications prend
une dizaine de lignes de code en réutilisant les composants existants.
Ainsi l’architecture logicielle de Corosol, schématisée par la figure 2, repose sur
l’abstraction d’entités fonctionnelles sous la forme de composants. Ceux-ci prennent
la forme d’interfaces Java, qui modélisent les accès offerts aux autres composants,
mais aussi au programmeur qui utilise Corosol. L’ensemble des objets constituant
un composant doit réaliser au minimum deux interfaces orthogonales. La première
est propre au composant, elle en déclare les fonctionnalités spécifiques. Par exemple,
l’interface représentant le composant “tas” déclare une méthode
qui réserve dans le tas de l’espace mémoire pour une
nouvelle instance de la classe donnée par le paramètre et retourne la réfé-
rence de ce nouvel objet. Par ailleurs, pour permettre un changement dynamique aisé
des composants, leur architecture est contrainte : l’implantation concrète des services