Instrumentation de code Java

Instrumentation de code Java Mickaël Delahaye mickael.delahaye@etudiant.univ-rennes1.fr Étude bibliographique Master 2 Recherche Informatique 2007 Résumé Cette étude bibliographique présente un état de l art de l instrumentation de code Java. L instrumentation a pour objectif la collecte d informations dynamiques sur le programme. Elle peut se réaliser à plusieurs niveaux (code source, bytecode, machine virtuelle) et à plusieurs moments (avant, au moment ou en cours d exécution). Encadrant : François Bodin, bodin@irisa.fr Projet CAPS

Table des matières Introduction 2 1 Instrumentation statique 2 1.1 Au niveau du code source.................... 3 1.2 Au niveau du bytecode...................... 3 1.3 Approche orientée aspect..................... 4 1.3.1 Le paradigme....................... 5 1.3.2 Points de jonction..................... 5 1.3.3 Exemple d utilisation................... 5 1.3.4 Pour l instrumentation.................. 6 2 Instrumentation dynamique 6 2.1 Instrumentation du bytecode au chargement.......... 7 2.2 Gestion d événements....................... 7 2.3 Solutions hybrides......................... 8 2.4 Tissage d aspect dynamique................... 9 Conclusion 9 1

Introduction La collecte d informations sur les programmes est aujourd hui essentielle. Elle permet de déterminer des propriétés sur le comportement, les performances, la sécurité, etc. Alors que l analyse statique déduit des propriétés du programme à partir du texte du programme, l analyse dynamique se fonde sur l exécution. De nombreuses analyses dynamiques sont mises en oeuvre par instrumentation du code : couverture du code, trace d appels, temps d exécution, création et synchronisation des threads, accès aux données, etc. Même si les données sont toujours collectées à l exécution, l instrumentation de code peut être réalisée de manières variées suivant les propriétés que l on souhaite collecter et l impact sur les performances du code. Selon la manière dont l instrumentation est réalisée, on qualifie l instrumentation de statique ou bien de dynamique. L instrumentation statique analyse le code du programme et y ajoute des sondes avant son exécution. L instrumentation dynamique opère quant à elle à l exécution du programme, par exemple à l aide d interface de surveillance de la machine virtuelle. La plateforme Java repose sur une machine virtuelle exécutant du bytecode. Aussi, il paraît naturel de demander à la machine virtuelle de collecter les données dynamiques de l exécution. De plus, alors que les fichiers objet sont peu instrumentés (si ce n est par le compilateur), le bytecode est souvent instrumenté, notamment parce qu il est commun à toutes les architectures matérielles. Ainsi, l instrumentation de programme Java peut se faire à trois niveaux : le code source, le bytecode et la machine virtuelle. L instrumentation du code source relève bien sûr de l approche statique, et l instrumentation de la machine virtuelle de l approche dynamique. Mais l instrumentation du bytecode peut être réalisée avant l exécution, pendant le chargement des classes ou bien même à l exécution. Ce rapport a pour objectif de montrer les différentes méthodes d instrumentation, de savoir quelles informations dynamiques peuvent être collectées, mais également de connaître leur impact sur le programme instrumenté. Il présente les deux voies d instrumentation, c est-à-dire l instrumentation statique et l instrumentation dynamique, avec leurs principes, leurs caractéristiques et leurs limitations. 1 Instrumentation statique En Java, l instrumentation statique peut avoir lieu soit au niveau du code source, soit au niveau du bytecode en conservant la même portabilité. La principale contrainte de l instrumentation statique est de disposer de tout 2

le code à instrumenter avant son exécution, ce qui est parfois plus facile au niveau du bytecode en raison des licences. Les deux premiers paragraphes de cette partie sont consacrés aux solutions existantes d instrumentation du code source et du bytecode. Le dernier paragraphe se détache des considérations de lieu d instrumentation pour explorer le paradigme de la programmation orientée aspect. 1.1 Au niveau du code source L instrumentation du code source commence par une analyse du code source, à l aide d analyseurs lexical et syntaxique, puis place des sondes dans le code source. Ainsi, Cenqua Clover Code Coverage for Java [7], par exemple, analyse le code source Java, à l aide d analyseurs générés par ANTLR (ANother Tool for Language Recognition). Cette technique lui permet de découvrir naturellement les structures de contrôles de flot pour placer les sondes permettant de découvrir les branches mortes. Mais cette technique est surtout employée avec d autres langages. Par exemple, le système de mesures de performance TAU [15] instrumente les sources C, C++ et Fortran. Les événements instrumentés sont principalement l entrée/sortie de procédure et la gestion des threads. Même si on peut choisir quelles procédures instrumenter, on peut remarquer que l analyse du code source mise en place est très limitée. L instrumentation du code source permet de réaliser une analyse statique poussée avant de placer les sondes. De plus, le contrôle de la machine virtuelle, intégré à l API Java, permet de récupérer des données d exécution pourtant totalement transparente du point de vue du langage (notamment via les classes Runtime et Thread et le paquetage java.lang.management) : nombre de threads actifs, utilisation du tas, mémoire utilisé, taille du tas, etc. L instrumentation statique du code source est assez peu utilisée dans le monde Java, au profit de l instrumentation du bytecode, plus simple à analyser et tout aussi portable. 1.2 Au niveau du bytecode L injection de bytecode est une technique très utilisée aujourd hui, que ce soit pour le tissage d aspect, la mesure de performance ou l analyse de couverture. Le bytecode Java, désigné par l extension.class, est assez facile à analyser, mais certaines informations peuvent êtres perdues. La modification du bytecode est assuré par des bibliothèques, comme BCEL [3](Apache Jakarta), SERP [17] ou le plus récent ASM, permettant 3

de manipuler ces fichiers.class. Leur rôle principal est d extraire les données du bytecode et de pouvoir reconstruire un fichier.class avec ses mêmes données. La bibliothèque ASM [5], utilisée notamment par AspectJ (voir la Section 1.3), est particulièrement adaptée à l instrumentation de code : gestion transparente de la pool de constantes ; grande légèreté par rapport à BCEL et SERP (surtout utile dans le cas d une instrumentation dynamique) ; modèle original basé sur les événéments (utilisé aussi bien pour lire que pour écrire). Pour instrumenter une méthode, il suffit d intercepter un événement et de le modifier avant de le renvoyer. La modification des fichiers de bytecode a cependant une limitation : toute instrumentation nécessite la réécriture totale du fichier. En effet, un fichier.class contient exactement une classe ou interface Java, en conservant la structure objet de la classe. Mais le point noir de ce format, du point de vue de l instrumentation, est le partage des constantes et des noms entre les méthodes de la classe. En effet, le fichier.class contient un pool de constantes, qui contient les constantes proprement dites (chaînes, flottants et grands entiers), mais aussi les noms des classes, des méthodes et des champs utilisés. Comme ce pool est commun à toutes les méthodes, l instrumentation, qui appelle une fonction pour enregistrer les informations dynamiques, oblige à réécrire tout le fichier. Les instructions présentes dans la description des méthodes d un fichier.class permettent de réaliser une analyse de flot de contrôle ou de donnée. Ainsi, EMMA [10] peut vérifier la couverture par bloc de base en instrumentant le bytecode. Cependant, certaines informations peuvent être perdues en fonction d options de compilation : noms des variables, numéros de ligne, etc. De plus, si le compilateur Java réalise des optimisations, les informations dynamiques collectées seront très difficiles à interpréter. On notera tout de même que le compilateur Sun Microsystems (depuis la JDK 1.3) a abandonné les optimisations importantes du bytecode, comme l inlining, laissant l optimisation à la machine virtuelle. 1.3 Approche orientée aspect Lorsqu on instrumente un programme, on ajoute à l existant une nouvelle préoccupation, un nouvel aspect : la collecte d informations. Cette section présente en quoi le paradigme de la programmation orientée aspect peut répondre à notre attente. 4

1.3.1 Le paradigme La programmation orientée aspect a pour objectif d augmenter la modularisation et séparer les préoccupations. En effet, on constate que certaines préoccupations, dites transverses (cross-cuting concerns), tel que le logging, la sécurité ou la persistance, se retrouve dispersé dans l ensemble du programme. Dans la programmation orientée apect, les préoccupations transverses sont réalisés séparemment, puis elles sont entremelées, tissées, dans le code métier du programme, pour obtenir le programme fonctionnel. Le tisseur d aspect se charge d insérer le code des préoccupations tranverses à des points particuliers, appelés points de jonction (joint points). Pour chaque fragment de code d une préoccupation, appelé greffon (ou advice), l utilisateur peut choisir un point d action (pointcut), c est-à-dire un ensemble des points de jonction sélectionnés grâce à un motif. Le tisseur d aspect injecte ensuite les greffons aux emplacements sélectionnés par les points d action. Le tissage d aspect peut se faire à plusieurs moments : statiquement, avant ou après la compilation en bytecode, ou dynamiquement à l exécution. Ici, seul le tissage statique nous intéresse, la Section 2.4 discute du tissage dynamique. Dans le monde Java, une solution de programmation orientée objet se distingue particulièrement. En effet, AspectJ [1] est un projet soutenu par IBM et BEA Systems, qui permet le tissage statique d aspects et depuis la fusion avec le projet AspectWerkz [2] le tissage dynamique. À l origine, AspectJ tissait le code source, mais il il s est finalement tourné vers un tissage du bytecode (aujourd hui en utilisant ACM). 1.3.2 Points de jonction Les tisseurs d aspect offrent à peu près tous les mêmes points de jonctions sur le papier : appel de méthode ou de constructeur ; exécution de méthode ou de constructeur ; accès à un champs (set/get) ; initialisation d un objet, initialisation statique d une classe ; exécution d une clause catch. 1.3.3 Exemple d utilisation La Figure 1 montre comment on peut très rapidement mettre en place un aspect qui enregistre le temps d exécution de toutes les méthodes publiques des classes du paquetage fr.irisa (et de ses sous-paquetages). 5

Fig. 1 Mesure du temps d exécution de méthode aspect P r o f i l i n g { private f i n a l static PrintStream output = new PrintStream (new FileOutputStream ( " p r o f i l e " ) ) ; } Object around ( ) : execution ( public f r. i r i s a... (.. ) ) { long time = System. c u r r e n t T i m e M i l l i s ( ) ; try { return proceed ( ) ; } f i n a l l y { time = System. c u r r e n t T i m e M i l l i s ( ) time ; output. p r i n t l n ( t h i s J o i n P o i n t S t a t i c P a r t. g e t S i g n a t u r e ( ) + " executed in " + time + "ms. " ) ; } } 1.3.4 Pour l instrumentation Du point de vue de l instrumentation, la programmation orientée aspect arrive avec des outils de qualité. À partir d un greffon, toutes les informations dynamiques collectables par les autres techniques statiques sont disponibles, mais elles ne peuvent être collectées qu à certains moments de l exécution. Même si les points d actions peuvent être choisis assez précisément (classe, paquetage, méthode ou champ), le tisage d aspect ne peut pas, par principe, vérifier le passage du contrôle de flot dans les structures de contrôle, ou suivre l évolution de la valeur d une variable. On perd ainsi les avantages que peut procurer une analyse statique du code avant l instrumentation. 2 Instrumentation dynamique L instrumentation dynamique d un programme repose principalement sur deux techniques. La première consiste à instrumenter le bytecode des classes Java au cours de leur chargement. La seconde, en revanche, utilise la machine virtuelle pour intercepter des événements qui nous intéressent, grâce à des hooks. Mais il existe une troisième voie d instrumentation utilisant à la fois l instrumentation du bytecode et de la machine virtuelle. Cette partie présente les trois solutions et termine par un point de vue «orienté aspect» de l instrumentation dynamique. 6

2.1 Instrumentation du bytecode au chargement Sur toutes les machines virtuelles, il existe au moins un moyen simple permettant de modifier le bytecode au chargement des classes. Cette technique permet de bénéficier de tous les avantages de l instrumentation statique du bytecode, mais ne s effectue que sur les classes à charger et sans avoir à les sélectionner a priori. Pour instrumenter le bytecode au chargement d une classe, il est assez évident pour un développeur Java de surcharger la classe ClassLoader. La sous-classe de ClassLoader devra modifier les octets du fichier.class chargé avant de les renvoyer à la superclasse. Cette technique nécessite un moyen d imposer ce nouveau ClassLoader. Certaine machine virtuelle accepte un argument en ligne de commande pour choisir le ClassLoader par défaut. Mais le plus simple est encore d utiliser un lanceur, c est-à-dire un petit programme Java qui crée ce nouveau ClassLoader et charge ensuite le programme client avec lui. Depuis Java 5, la machine virtuelle Java propose une manière standard pour instrumenter le bytecode grâce à un agent d instrumentation programmé en Java [16]. Ainsi, d après D. Schwarz [13], un agent d instrumentation utilisant une bibliothèque de manipulation du bytecode (voir la Section 1.2), dans son cas BCEL [3], peut extraire de l information du bytecode et modifier le bytecode, en conséquence, au chargement des classes.. 2.2 Gestion d événements La gestion d événements requiert que la machine virtuelle dispose d une interface pour intercepter des événements comme le chargement d une classe ou l exécution d une fonction. Cette technique est limitée par le nombre d événements observés, par leurs précisions. Il existe des interfaces natives (accessibles en C/C++) pour surveiller l exécution de programme Java. Avant Java 5, le standard (supporté à la fois par les machines virtuelles de Sun Microsystems, BEA Systems et IBM) s appelait JVMPI (Java Virtual Machine Profiler Interface). Il permet de placer des hooks notamment sur les événements suivants : le chargement de classe ; le démarrage et fermeture de thread ; l entrée et la sortie de méthode ; le chargement et le déchargement de méthode compilée (JIT). La limitation de JVMPI réside donc dans le nombre limité d événements observés. Mais, cette interface permet de consulter directement un certain nombre d informations sur la machine virtuelle (trace d appels notamment), 7

et permet d interagir avec l objet source de l événement grâce à l interface native Java (JNI). Certaines informations demeurent cependant indisponibles. Ainsi, lorsque le hook intercepte un appel de fonction, les paramètres effectifs ne sont pas connus, ce qui rend impossible tout contrôle des flux de données. Pour lever cette limitation, le système de mesures de performance TAU [14], qui peut mesurer les performances d un système parallèle programmé en Java, utilisant MPI (bibliothèque de communication), est obligé d utiliser une implémentation C de MPI instrumentée. La surveillance de la machine virtuelle paraît une bonne solution pour réaliser des mesures de performances. Malheureusement, comme indiqué dans les articles [11] et [9] (voir la Section 2.3), lorsque JVMPI ou un de ses équivalents place un hook sur l entrée et la sortie de méthodes, ce n est pas pour une méthode en particulier mais pour toutes les méthodes, ce qui obligent à maintenir des tables de hâchage, entrainant un surcoût à l exécution. Avec l arrivé de Java 5, JVM TI (JVM Tool Interface) prend le relais en tenant compte de ce problème. Comme indiqué dans [12], il offre moins d événements. Cette interface mise d avantage sur les solutions hybrides à base d injection de bytecode. 2.3 Solutions hybrides Les solutions mixtes utilisent des interfaces de la machine virtuelle pour instrumenter le bytecode, en utilisant exactement les mêmes techniques que dans la première méthode, mais cette fois-ci à partir d un environnement natif (en C/C++). De nombreux articles [9, 4, 11] décrivent des machines virtuelles personnalisées, ce qui peut entraîner la perte de la portabilité. D. Brear [4], par exemple, utilise une machine virtuelle Java, s exécutant sur une machine virtuelle Java, qui fragmente le bytecode utilisateur pour pouvoir placer des sondes dans chaque bloc de base, pendant l exécution. Le défaut majeur de cette technique est bien sûr le surcoût à l exécution. La technologie HotSwap intégrée à certaines machines virtuelles permet de modifier le code des classes chargées au cours de l exécution à partir d une interface de déboggage. Selon M. Dmitriev [8], cette technologie peut être utilisée pour l instrumentation de code. Grâce à la fonction RedefineClasses de JVMDI (JVM Debugger Interface), une autre interface expérimentale qui existait en parallèle de JVMPI, il est possible d instrumenter le bytecode des classes déjà chargées. Cependant, les performances de JMVDI sont perfectibles [9]. Avec JVMTI, les plateformes compatibles Java 5 promettent de meilleures performances que JVMDI. 8

Ces méthodes ont quelques avantages par rapport aux méthodes simples : leur performance par rapport à la gestion d événements ; la possibilité de réaliser une analyse statique du bytecode, qui se limite aux classes chargées ; la possibilité d instrumenter le bytecode durant l exécution. Leur défaut est qu elle repose sur des interfaces peu implémentées (JVMDI), ou des machines virtuelles non portables. 2.4 Tissage d aspect dynamique Comme on l a vu dans la Section 1.3, l instrumentation de code peut se voir comme un aspect. Si l instrumentation peut être dynamique, le tissage peut l être également. Le tissage dynamique est surtout utilisé en associationant avec les serveurs d applications. La principale différence avec le tissage statique réside dans la manière dans les aspects sont associé au code métier. Dans AspectJ, par exemple, l approche statique spéficie dans la définition de l aspect avec quelles classes il doit être tissés. Mais les solutions dynamiques, comme JBoss AOP, AspectWerkz [2] ou encore AspectJ 5, préfèrent utilisés un document XML pour associer les aspects au code métier. Le tissage proprement est réalisé au niveau du bytecode. Les tisseurs d aspects se prémunisent des problèmes de compatibilité en autorisant plusieurs méthodes d instrumentation des classes au chargement. AspectWerkz, par exemple, en possède plus de dix, notamment : un agent JVMTI pour les plateformes compatibles Java 5 ; un debugger JVMDI pour quelques machines virtuelles Sun Microsystems ; une classe ClassLoader personnalisée ; differents systèmes propriétaires, par exemple pour JRockit, la machine virtuelle de BEA Systems pour processeur Intel. Comme le démontre [6], le tissage dynamique peut profiter des possibilités du HotSwap. L avantage étant de pouvoir tisser pendant l exécution du programme. Conclusion Cette étude présente les différentes méthodes d instrumentation de code, qu elle soit réalisée avant ou au cours de l exécution. On peut voir que, parmis toutes les méthodes décrites, aucune ne domine plus que les autres. 9

L instrumentation statique, d abord, permet de placer les sondes avec un grand discernement basé sur une analyse statique, qui peut être intra- et interprocédurale. Malheureusement, il n est pas toujours facile de rassembler tout le code de l application pour instrumentation. Quant à l analyse du bytecode, elle se rélève parfois compliquée, proche des techniques de reverse engeneering, parce que la compilation peut perdre certaines données. Ensuite, les solutions dynamiques, qui sont souvent plus pratiques à mettre en place, sont affectées par un surcoût à l exécution et une perte de portabilité (code natif, machine virtuelle spécialisée, etc.). Enfin, le tissage d aspect, qui peut prendre en charge l instrumentation de code, n est en fait qu une couche d harmonisation au dessus des mêmes techniques que l instrumentation (injection de bytecode, HotSwap...). C est pourquoi son utilisation est simple, mais aussi plus limitée dans les événements observables. L objectif du stage est de trouver la ou les instrumentations adéquates pour récolter des informations permettant de décider si une optimisation réalisée dans le code source est pertinante. Références [1] AspectJ. http://www.eclipse.org/aspectj/. [2] AspectWerkz. http://aspectwerkz.codehaus.org/. [3] Apache Jakarta BCEL. http://jakarta.apache.org/bcel/. [4] Douglas J Brear, Thibaut Weise, Tim Wiffen, Kwok Cheung Yeung, Sarah A M Bennett et Paul H J Kelly : Search strategies for Java bottleneck location by dynamic instrumentation, 2003. [5] Eric Bruneton, Romain Lenglet et Thierry Coupaye : ASM : a code manipulation tool to implement adaptable systems. In Proceedings of the ASF (ACM SIGOPS France) Journées Composants 2002 : Systèmes à composants adaptables et extensibles (Adaptable and extensible component systems), 2002. [6] S. Chiba, Y. Sato et M. Tatsubori : Using HotSwap for implementing dynamic AOP systems, 2003. [7] Cenqua Clover for Java. http://www.cenqua.com/clover/. [8] M. Dmitriev : Application of the HotSwap technology to advanced profiling. In First International Workshop on Unanticipated Software Evolution (USE2002)., 2002. [9] M. Dmitriev : Profiling Java applications using code hotswapping and dynamic call graph revelation. In WOSP 04 : Proceedings of the 4th 10

international workshop on Software and performance, pages 139 150. ACM Press, 2004. [10] EMMA. http://emma.sourceforge.net/. [11] M. Harkema, D. Quartel, B. M. M. Gijsen et R. D. van der Mei : Performance monitoring of Java applications. In WOSP 02 : Proceedings of the 3rd international workshop on Software and performance, pages 114 127. ACM Press, 2002. [12] K. O Hair : The JVMPI transition to JVMTI. Sun Developper Network, 2004. [13] D. Schwarz : Peeking inside the box : Attribute-oriented programming with Java 1.5. ONJava.com, 2004. [14] Sameer Shende et Allen D. Malony : Integration and applications of the TAU performance system in parallel Java environments. In JGI 01 : Proceedings of the 2001 joint ACM-ISCOPE conference on Java Grande, pages 87 96. ACM Press, 2001. [15] Sameer S. Shende et Allen D. Malony : The TAU parallel performance system. Int. J. High Perform. Comput. Appl., 20(2):287 311, 2006. [16] Java 2 Platform SE 5.0 API Specification : java.lang.instrument. [17] A. White : SERP. http://serp.sourceforge.net/. 11