Optimisation JVM

Optimisation JVM
Fred RIVARD : [email protected]
I.Présentation des entreprises et de l'intervenant
II.Introduction : java et ses composantes, un ex d'optimisation.
III.Compilateurs Java et classfiles.
IV.Machines virtuelles Java et classfiles.
V.Implications sur les programmes Java.
I.Présentation des entreprises et de l'intervenant
Liemur : www.liemur.com
IST (patron : l'intervenant : une à nantes et une ?) www.ist-eu.com
environ 30personnes
Objectif du cours :
comprendre les différents « composants opérationels » de JAVA
– chaine de compil et son résultat : le classfile
– machine virtuelle java, JVM
– les liens entre les composants
etre capable de faire des choix et des compromis
– vitesse, mémoire
– design, framework
mieux appréhender son métier d'informaticien
– vision globale : desigh, implémentation, éxécution, optimisation
– maitrise des implications des choix effectués
•
maintenace, évolutivité, fiabilité, coûts délais
II.Introduction : java et ses composantes, un ex d'optimisation.
Fichier source (evm.java)
librairie (object.class)
|
JVM
--> JAVA compilateur
-> Classfile (Bytecode) (evm.class)
A cause du bytecode verifier => empêche que l'on prenne le contrôle sur la JVM
Un objet à la même taille qlq soit le chemin par lequel on y accède.
Pas mal de langage compile le JVM : même si le langage JAVA a évolué, la JVM elle non.
Langage et JVM = 2 composants interfacés par le « classfile »
Faire une optimisation, TEST : est-ce q je suis ds le cas de mon optimisation ?
Diapo : La machine vituelle Java
Methode native : celle qu'on ne peut écrire en java et qui sont donc en assembleur, en C.
8milliards de micro contrôleur dans le monde.
Gestion de mémoire = 50% des bugs.
Garbage collected (GC) gère la mémoire de la machine pour nous !
Execution engine = moteur d'exécution.
Diapo : Classfiles et Bytecodes
5ingénieur en C pour 1 en JAVA pour faire une application
byte b <127;
b++;
=> b=-128
car les bytes sont circulaire : de -128 à 127
ARM9_J => J indique q certains code de la machines virtuelles sont en hardware (environ 70%)
=> la machine virtuelle = processeur JAVA multitâche avec en plus une gestion de la mémoire et un
jeu d'instruction.
Diapo : un exemple d'optimisation
Le ratio : le premier code, plus long et appelant des librairies (+=) qui n'existe pas ds la JVM est 13
fois plus long.
Diapo 13: Optimisation de code
voir coloration de graphe
Il vaut mieux optimisé le code une fois qu'on a fait le bench.
III.Compilateurs Java et classfiles.
Diapo 15: Paser et scanner
tableau : val=i+2*10;\n
Diapo 16: Difficultés & Solution
\u0041 => implique les test de \ puis u puis le numéro pour associer la lettre
«==»
« equals »
meme objet
compar l'intérieur des objets =>plus long
Donc optimisation : minimisation du nombre d'objet
Diapo 16: Arbre de syntaxe
Diapo 21 : Propagation des constantes
tout ce qui est final ect...
ce qui veut dire que en interne le compilateur est capale de faire des calculs : il est capable de mettre
21 dans les autres prog.
Diapo 21 : Analyse sémantique
dans le premier on a une valeur pour i dans le second(avec le || ) pas forcément !
IV.Machines virtuelles Java et classfiles.
Diapo 21 : Le classfile
Diapo 26 : Constants POOLS
2 types de string :
– Référencé à la volé
– Référencée dans les constantes pool (on peut utiliser = = )
=> string littéraux (« Hello ») si on la met ainsi dans une classe et dans l'autre, ce sont les même
sémantiquement.
UTF8 = chaîne sous forme de bytes pour référencé les chaîne ASCII, gère si c'est plus gd qu'une
chaîne ASCII.
Diapo 26
- numéro de version
- numéro de version du JVM? JBB?
- classe du constant pool
version, longueur (0001 ou 0003)
Diapo 29
[8]
NameAndType <init>....
=
constructeur
Diapo 30
native int foo(byte b1, byte b2, int i);
java.lang.Object
Ljava/lang/Object;
(BBI)I
Si on a :
native int foo(byte b1, byte b2, Object i);
java.lang.Object
Ljava/lang/Object;
(BBLjava/Lang/Object;)I
Diapo 31
Méthode qui n'ont pas de code : les abstracts (les interface qui sont des abstracts par défaut), les
natives
Diapo 32
Méthode qui n'ont pas de code : les abstracts (les interface qui sont des abstracts par défaut), les
natives
Diapo 34
Chaque thread dans une machine java à sa propre pile d'exécution.
Le compilateur a été capable de déterminer lui même la taille de la pile nécessaire.
0000 007F
0000 0080
FFFF FF80
127
128
-128
0111 1111
1000 0000
car bit de poids fort à 1 : négatif
Diapo 35
bytecode : sipush pour mettre le -128. et on met un Add devant.
Diapo 36 : Manipulation de la pile
a load_o //chargemnet du receveur
i load_4 //chargemnet du bloc 4
bar(){
int i ; //4
this.floo(i);
}
Tout est fortement typé => on ne peut pas déférencé des pointeurs dans autre choise
Diapo 38 : Exemple
on retourne 300 à la fin
Le dup est là pour garder le résultat à envoyé sur la pile ainsi qu'avoir un résultat à envoyer
Diapo 39 : Les tableaux & les objets
le constructeur appelle la classe pour nous
Diapo 40 : Accès aux fiels & type objets
Point
x
y
<init>
x<-10
y<-10
=>
aload_0
bipush 10
putfield x
aload_0 (dépile l'ensemble)
bipush 10
putfield y
diapo 42
bug : manque un « dup »
diapo 52
Le compilateur aujourd'hui duplique le code de finaly => ne pas mettre trop de code dans le finaly
diapo 66
Le hashCode permet décrire des hashTable : permet de rechercher dans une table, à partir d'un
indice (une clef) donné.
diapo 69
chaque méthode pointe sur la méthode de l'objet précédent si elle est pas définis dans l'objet
courrant.
main(A a){
a.foo(); //invokevirtual 1
a.bar(); //invokevirtual 2
}
diapo 70/71
L'invoque interface est lent.
diapo 74
La politique des threads en java n'est pas spécifiée !
=> Vérifier q lorsque l'on fait des threads on n'est pas dépendant de la politique de schéduligue =>
ne pas faire de supposition sur l'ordonnancement.
Problème de l'inversion de prioriré : un threduler qui prend la main car un autre es dans la zone
critique, et qui veut lui meme entrer dans la section critique.
diapo 76
Un objet vivant = racine = objet atteingnable depuis un autre objet vivant.
Diapo 79 Les racines dans les stacks !
Certaines machines hardware sont capable de tager un pointeur afin qu'on sache ce qui s'y trouve
(basetype ou reference..)
Diapo 81
on a du JIT code, le compil java compile et embarque à la volée ce code
pb avec le natif : qd il faut enlever l'exception
Diapo 83
field versus local
charger objet, vérifier qu'il est pas null et renvoyer la valeur
La val est local au thread on y a accès directemnt
parcourire les tableaux à l'envers
Parcours du tableau à l'envers, 2intêret, ça évite les org? De plus c plus rapide car on fait les tests à
0 plutot qu'à n or les tests à 0 sont toujours optimisés.
On veut savoir si un objet de la classe A est bien égal à a
equals(Object a){
if(a = = null) return false;
if(a instant of A){
try {
a' <- (A)a;
....
}catch(){}
return false;
}
}
Code objet = sans if
Plus ya de if, plus ça va vite !
Attention aux codes multi-threadé : les librairies viennent avec du code multi-threadé.
eviter les synchronize qd le code n'a pas besoin d'être multithread car ça y bouffe 10% du temps.
Les décalages sur les bites, char, short ne marche pas bien !
Regarder ou sont les natives des API, appelés tout de suite les natives
V.Implications sur les programmes Java.