[baptiste@BMEYNIER GraalArticle]$ vi Greeting.java\n[baptiste@BMEYNIER GraalArticle]$ javac Greeting.java \n[baptiste@BMEYNIER GraalArticle]$ ls -als\ntotal 16\n4 drwxr-xr-x. 2 baptiste baptiste 4096 14 mai 10:54 .\n4 drwxr-xr-x. 3 baptiste baptiste 4096 14 mai 10:50 ..\n4 -rw-rw-r--. 1 baptiste baptiste 461 14 mai 10:54 Greeting.class <= ByteCode\n4 -rw-rw-r--. 1 baptiste baptiste 125 14 mai 10:53 Greeting.java\n[baptiste@BMEYNIER GraalArticle]$ java Greeting \nHello !<\/code><\/pre>\n\n\n\nLe bytecode n\u2019est pas un code machine, c\u2019est-\u00e0-dire que ce n\u2019est pas un code optimis\u00e9 pour un type d\u2019architecture d\u2019ordinateur en particulier. On dit du bytecode qu\u2019il est portable entre diff\u00e9rentes architectures. Ce bytecode est ensuite interpr\u00e9t\u00e9 ou bien ex\u00e9cut\u00e9 par une machine virtuelle.<\/p>\n\n\n\n![\"\"](\"http:\/\/baptiste-meynier.com\/wp-content\/uploads\/2020\/11\/compilation_circle.png\")
<\/figure>\n\n\n\nLa production de bytecode n\u2019est que la premi\u00e8re \u00e9tape d\u2019un processus d\u2019ex\u00e9cution plus complexe. Le bytecode est ensuite d\u00e9ploy\u00e9 sur le syst\u00e8me cible, lors de son execution le JIT, le traduit en code machine natif (ie. optimis\u00e9 pour l\u2019architecture de la machine ex\u00e9cutant le programme). Ceci peut \u00eatre fait sur un fichier entier, ou sp\u00e9cifiquement sur une fonction du programme.<\/p>\n\n\n\n
La compilation \u00e0 la vol\u00e9e s\u2019adapte dynamiquement \u00e0 la charge de travail courante du logiciel, en compilant le code \u00ab chaud \u00bb, c\u2019est-\u00e0-dire le code le plus utilis\u00e9 \u00e0 un moment donn\u00e9. Obtenir du code machine optimis\u00e9 se fait beaucoup plus rapidement depuis du bytecode que depuis du code source. Comme le bytecode d\u00e9ploy\u00e9 est portable, la compilation \u00e0 la vol\u00e9e est envisageable pour tout type d\u2019architecture, \u00e0 la condition d\u2019avoir un compilateur JIT pour cette architecture.<\/p>\n\n\n\n
LES SOURCES DE L\u2019OPENJDK SONT CONSULTABLES SUR GITHUB<\/a>.<\/h6>\n\n\n\n![\"\"](\"http:\/\/baptiste-meynier.com\/wp-content\/uploads\/2020\/11\/openjdk11_languages.png\")
<\/figure>\n<\/div>\n\n\nVous remarquerez qu\u2019il est compos\u00e9 de sources de plusieurs langages.<\/p>\n\n\n\n
EN PARCOURANT LES SOURCES, NOUS TROUVONS DU CODE C++ SP\u00c9CIFIQUE \u00c0 DE NOMBREUSES ARCHITECTURES :<\/h5>\n\n\n\n[baptiste@BMEYNIER hotspot]$ tree . -d\n.\n\u251c\u2500\u2500 cpu\n\u2502 \u251c\u2500\u2500 aarch64\n\u2502 \u251c\u2500\u2500 arm\n\u2502 \u251c\u2500\u2500 ppc\n\u2502 \u251c\u2500\u2500 s390\n\u2502 \u251c\u2500\u2500 sparc\n\u2502 \u251c\u2500\u2500 x86\n\u2502 \u2514\u2500\u2500 zero\n\u251c\u2500\u2500 os\n\u2502 \u251c\u2500\u2500 aix\n\u2502 \u251c\u2500\u2500 bsd\n\u2502 \u251c\u2500\u2500 linux\n\u2502 \u251c\u2500\u2500 posix\n\u2502 \u251c\u2500\u2500 solaris\n\u2502 \u2514\u2500\u2500 windows\n\u2514\u2500\u2500 os_cpu\n \u251c\u2500\u2500 aix_ppc\n \u251c\u2500\u2500 bsd_x86\n \u251c\u2500\u2500 bsd_zero\n \u251c\u2500\u2500 linux_aarch64\n \u251c\u2500\u2500 linux_arm\n \u251c\u2500\u2500 linux_ppc\n \u251c\u2500\u2500 linux_s390\n \u251c\u2500\u2500 linux_sparc\n \u251c\u2500\u2500 linux_x86\n \u251c\u2500\u2500 linux_zero\n \u251c\u2500\u2500 solaris_sparc\n \u251c\u2500\u2500 solaris_x86\n \u2514\u2500\u2500 windows_x86<\/code><\/pre>\n\n\n\nLe JIT est compos\u00e9 de deux compilateurs :<\/p>\n\n\n\n
\n- C1 est le compilateur le plus rapide \u00e0 produire du code natif. Il est aussi appel\u00e9 Client parce qu\u2019il minimise la latence et sera plus adapt\u00e9 au application de cycle vie court.<\/li>\n\n\n\n
- C2 est plus lent \u00e0 transformer le bytecode mais produit du code natif plus optimis\u00e9 que C1. Il est aussi appel\u00e9 Server car plus adapt\u00e9 aux applications au cycle de vie long tel que les serveurs.<\/li>\n<\/ul>\n\n\n\n<\/div>\n\n\n\n
LA JVM COMBINE L\u2019USAGE DE CES DEUX COMPILATEURS.<\/h5>\n\n\n\n
Lors de la premi\u00e8re ex\u00e9cution du code, la Jvm utilisera le C1. La compilation C2 se d\u00e9clenche selon une table de statistiques maintenue par la Jvm, c\u2019est elle qui d\u00e9cidera de son lancement.<\/p>\n\n\n\n
L\u2019usage de ce m\u00e9canisme a permis de faire des gains \u00e9normes en performance, mais C2 est devenu de plus en plus complexe et difficile \u00e0 maintenir. C\u2019est en ayant conscience des limitations de cette technique que la soci\u00e9t\u00e9 Oracle publia dans sa version 9 de Java une API permettant de fournir sa propre impl\u00e9mentation de compilation de code (JEP-243<\/a>). C\u2019est l\u00e0 qu\u2019intervient GraalVM !<\/p>\n\n\n\n![\"\"](\"http:\/\/baptiste-meynier.com\/wp-content\/uploads\/2020\/11\/graalvm_logo.png\")
<\/figure>\n<\/div>\n\n\n
GraalVM est une machine virtuelle d\u00e9velopp\u00e9e par Oracle. Bien que bas\u00e9e sur la HotSpot nous allons voir en quoi cette JVM en est diff\u00e9rente.<\/p>\n\n\n\n
Mise en place :<\/h4>\n\n\n\n
GraalVm est divis\u00e9e en deux \u00e9ditions la Community et l\u2019Entreprise Edition. Pour un usage personnel il est tout \u00e0 fait possible de t\u00e9l\u00e9charger la version Entreprise<\/a>. Deux versions de HotSpot sont propos\u00e9es la 8 et la 11.<\/p>\n\n\n\n[baptiste@BMEYNIER latest]$ $GRAALVM_HOME\/bin\/java -version\njava version \"11.0.7\" 2020-04-14 LTS\nJava(TM) SE Runtime Environment GraalVM EE 20.0.1 (build 11.0.7+8-LTS-jvmci-20.0-b04)\nJava HotSpot(TM) 64-Bit Server VM GraalVM EE 20.0.1 (build 11.0.7+8-LTS-jvmci-20.0-b04, mixed mode, sharing)<\/code><\/pre>\n\n\n\n<\/div>\n\n\n\nUNE NOUVELLE IMPL\u00c9MENTATION DU JIT<\/h3>\n\n\n\n
Son impl\u00e9mentation a totalement \u00e9t\u00e9 revue, le C++ a \u00e9t\u00e9 remplac\u00e9 par du Java, plus facile \u00e0 maintenir.<\/p>\n\n\n\n
Pour le tester nous suivrons un exemple propos\u00e9 sur le site de GraalVM<\/a> (n\u2019h\u00e9sitez pas \u00e0 y faire un tour).<\/p>\n\n\n\nVoici un programme permettant de compter le nombre de caract\u00e8res en majuscule dans un texte, ex\u00e9cut\u00e9 de nombreuses fois.<\/p>\n\n\n\n
public class CountUppercase {\n static final int ITERATIONS = Math.max(Integer.getInteger(\"iterations\", 1), 1);\n public static void main(String[] args) {\n String sentence = String.join(\" \", args);\n for (int iter = 0; iter < ITERATIONS; iter++) {\n if (ITERATIONS != 1) System.out.println(\"-- iteration \" + (iter + 1) + \" --\");\n long total = 0, start = System.currentTimeMillis(), last = start;\n for (int i = 1; i < 10_000_000; i++) {\n total += sentence.chars().filter(Character::isUpperCase).count();\n if (i % 1_000_000 == 0) {\n long now = System.currentTimeMillis();\n System.out.printf(\"%d (%d ms)%n\", i \/ 1_000_000, now - last);\n last = now;\n }\n }\n System.out.printf(\"total: %d (%d ms)%n\", total, System.currentTimeMillis() - start);\n }\n }\n}<\/code><\/pre>\n\n\n\nNous allons ex\u00e9cuter ce code en d\u00e9sactivant la nouvelle version du JIT avec l\u2019argument -XX:-UseJVMCICompiler<\/code><\/p>\n\n\n\n[baptiste@BMEYNIER tuto_graalvm]$ $GRAALVM_HOME\/bin\/javac CountUppercase.java\n[baptiste@BMEYNIER tuto_graalvm]$ $GRAALVM_HOME\/bin\/java -XX:-UseJVMCICompiler CountUppercase In 2020 I would like to run ALL languages in one VM.\n1 (497 ms)\n2 (433 ms)\n3 (415 ms)\n4 (410 ms)\n5 (415 ms)\n6 (414 ms)\n7 (415 ms)\n8 (414 ms)\n9 (413 ms)\ntotal: 69999993 (4239 ms)<\/code><\/pre>\n\n\n\nLe traitement a pris 4239 ms.<\/p>\n\n\n\n
En apart\u00e9, le \u2013 d\u00e9sactive (-XX:-<\/strong>UseJVMCICompiler<\/code>) et le + active (-XX:+<\/strong>UseJVMCICompiler<\/code>).<\/p>\n\n\n\nNous allons relancer la m\u00eame ex\u00e9cution en laissant le JVMCICompiler activ\u00e9 par d\u00e9faut.<\/p>\n\n\n\n
[baptiste@BMEYNIER tuto_graalvm]$ $GRAALVM_HOME\/bin\/java CountUppercase In 2020 I would like to run ALL languages in one VM.\n1 (152 ms)\n2 (152 ms)\n3 (79 ms)\n4 (77 ms)\n5 (79 ms)\n6 (78 ms)\n7 (77 ms)\n8 (80 ms)\n9 (79 ms)\ntotal: 69999993 (932 ms)<\/code><\/pre>\n\n\n\nCette fois-ci l\u2019ex\u00e9cution a pris 920 ms, soit 4 fois moins de temps !<\/p>\n\n\n\n
<\/div>\n\n\n\nLA COMPILATION NATIVE<\/h3>\n\n\n\n
Aussi appel\u00e9 AOT (Ahead Of Time), cette fonctionnalit\u00e9 a \u00e9t\u00e9 introduite dans Java 9 via la JEP 295<\/a>. L\u2019id\u00e9e est de consid\u00e9rer que tout ce qui est fait par le JIT en runtime peut \u00eatre r\u00e9alis\u00e9 en phase de compilation.<\/p>\n\n\n\nPrenons une classe dont une fonction est appel\u00e9e plusieurs fois d\u2019affil\u00e9 :<\/p>\n\n\n\n
public class MultipleCall {\n\n public int f() throws Exception {\n int a = 5;\n return a;\n }\n\n public static void main(String[] args) throws Exception {\n for (int i = 1; i <= 10; i++) {\n System.out.println(\"call \" + Integer.valueOf(i));\n long a = System.nanoTime();\n new Test().f();\n long b = System.nanoTime();\n System.out.println(\"elapsed= \" + (b-a));\n }\n\n }\n}<\/code><\/pre>\n\n\n\nCommen\u00e7ons par exp\u00e9rimenter ce programme via une HotSpot :<\/h4>\n\n\n\n[baptiste@BMEYNIER tuto_graalvm]$ $JAVA_HOME\/bin\/java -version\nopenjdk version \"11.0.5\" 2019-10-15\nOpenJDK Runtime Environment AdoptOpenJDK (build 11.0.5+10)\nOpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.5+10, mixed mode)\n[baptiste@BMEYNIER native-list-dir]$ $JAVA_HOME\/bin\/javac MultipleCall.java \n[baptiste@BMEYNIER native-list-dir]$ time $JAVA_HOME\/bin\/java MultipleCall \n[baptiste@BMEYNIER 02_AOT_HOTSPOT]$ $JAVA_HOME\/bin\/java Test\ncall 1\nelapsed= 3740\ncall 2\nelapsed= 709\ncall 3\nelapsed= 352\ncall 4\nelapsed= 317\ncall 5\nelapsed= 349\ncall 6\nelapsed= 306\ncall 7\nelapsed= 281\ncall 8\nelapsed= 297\ncall 9\nelapsed= 295\ncall 10\nelapsed= 322<\/code><\/pre>\n\n\n\nPour utiliser l\u2019AOT il nous faut utiliser l\u2019ex\u00e9cutable jaotc<\/p>\n\n\n\n
[baptiste@BMEYNIER native-list-dir]$ $JAVA_HOME\/bin\/jaotc --output MultipleCall.so MultipleCall<\/code><\/pre>\n\n\n\nCette commande va convertir notre fichier Java en une librairie dans un format appel\u00e9 SharedObjects (.so).<\/p>\n\n\n\n
[baptiste@BMEYNIER tuto_graalvm]$ ls -alhs\ntotal 8,1M\n4,0K drwxr-xr-x. 3 baptiste baptiste 4,0K 14 mai 17:58 .\n4,0K drwxr-xr-x. 9 baptiste baptiste 4,0K 14 mai 10:49 ..\n4,0K -rw-rw-r--. 1 baptiste baptiste 2,4K 14 mai 17:57 MultipleCall.class\n4,0K -rw-rw-r--. 1 baptiste baptiste 929 2 mai 11:44 MultipleCall.java\n144K -rw-rw-r--. 1 baptiste baptiste 141K 14 mai 17:58 MultipleCall.so<\/code><\/pre>\n\n\n\nNous l\u2019executerons de la mani\u00e8re suivante:<\/p>\n\n\n\n
[baptiste@BMEYNIER tuto_graalvm]$ $JAVA_HOME\/bin\/java -XX:AOTLibrary=.\/MultipleCall.so MultipleCall \ncall 1\nelapsed= 2227\ncall 2\nelapsed= 945\ncall 3\nelapsed= 368\ncall 4\nelapsed= 287\ncall 5\nelapsed= 296\ncall 6\nelapsed= 227\ncall 7\nelapsed= 263\ncall 8\nelapsed= 263\ncall 9\nelapsed= 296\ncall 10\nelapsed= 298<\/code><\/pre>\n\n\n\nOn constate de meilleurs performances au d\u00e9marrage, les r\u00e9sultats finissent ensuite par tendre vers les m\u00eames r\u00e9sultats. Il est faux de se dire que l\u2019AOT permet d\u2019avoir un programme bien plus performant, en revanche il permet d\u2019acc\u00e9der plus rapidement \u00e0 un code optimal, l\u00e0 ou le JIT aurait n\u00e9cessit\u00e9 plusieurs it\u00e9rations. A noter qu\u2019il est \u00e9galement possible d\u2019effectuer cette manipulation sur un module notamment ceux du JDK.<\/p>\n\n\n
\n![\"\"](\"http:\/\/baptiste-meynier.com\/wp-content\/uploads\/2020\/11\/graalvm_compilation_circle.png\")
<\/figure>\n<\/div>\n\n\n<\/div>\n\n\n\nExp\u00e9rimentons cette fonctionnalit\u00e9 avec GraalVM<\/h2>\n\n\n\n
Prenons le code suivant trouv\u00e9 sur le site officiel de GraalVM:<\/p>\n\n\n\n
import java.io.File;\nimport java.nio.file.Files;\nimport java.nio.file.Path;\nimport java.nio.file.Paths;\nimport java.util.stream.Stream;\n\npublic class ListDir {\n public static void main(String[] args) throws java.io.IOException {\n\n String root = \".\";\n if(args.length > 0) {\n root = args[0];\n }\n System.out.println(\"Walking path: \" + Paths.get(root));\n\n long[] size = {0};\n long[] count = {0};\n\n try (Stream<Path> paths = Files.walk(Paths.get(root))) {\n paths.filter(Files::isRegularFile).forEach((Path p) -> {\n File f = p.toFile();\n size[0] += f.length();\n count[0] += 1;\n });\n }\n\n System.out.println(\"Total: \" + count[0] + \" files, total size = \" + size[0] + \" bytes\");\n }\n}<\/code><\/pre>\n\n\n\nVoici le r\u00e9sultat d\u2019une \u00e9xecution classique:<\/p>\n\n\n\n
[baptiste@BMEYNIER native-list-dir]$ $GRAALVM_HOME\/bin\/javac ListDir.java\n[baptiste@BMEYNIER native-list-dir]$ time $GRAALVM_HOME\/bin\/java ListDir ..\nWalking path: ..\nTotal: 611 files, total size = 55309806 bytes\n\nreal 0m0,197s\nuser 0m0,242s\nsys 0m0,041s<\/code><\/pre>\n\n\n\nL\u2019ex\u00e9cutable de compilation native n\u2019est pas pr\u00e9sent par d\u00e9faut. Pour l\u2019\u00e9dition entreprise il va falloir le t\u00e9l\u00e9charger<\/a>.<\/p>\n\n\n\n[baptiste@BMEYNIER ~]$ cd $GRAALVM_HOME\/bin\n[baptiste@BMEYNIER bin]$ .\/gu -L install native-image-installable-svm-svmee-java11-linux-amd64-20.0.1.jar \nProcessing Component archive: native-image-installable-svm-svmee-java11-linux-amd64-20.0.1.jar\nInstalling new component: Native Image (org.graalvm.native-image, version 20.0.1)\n[baptiste@BMEYNIER bin]$ ls -alhs\n0 lrwxrwxrwx. 1 baptiste baptiste 27 14 mai 19:09 native-image -> ..\/lib\/svm\/bin\/native-image<\/code><\/pre>\n\n\n\nL\u2019ex\u00e9cutable gu ou Graal Updater vous permet d\u2019installer des composants en ligne de commande.<\/p>\n\n\n\n
[baptiste@BMEYNIER native-list-dir]$ $GRAALVM_HOME\/bin\/javac ListDir.java\n[baptiste@BMEYNIER native-list-dir]$ $GRAALVM_HOME\/bin\/native-image ListDir\nBuild on Server(pid: 20294, port: 43927)\n[listdir:20294] classlist: 119.83 ms, 1.00 GB\n[listdir:20294] (cap): 743.81 ms, 1.00 GB\n[listdir:20294] setup: 1,945.27 ms, 1.00 GB\n[listdir:20294] (typeflow): 5,436.31 ms, 1.20 GB\n[listdir:20294] (objects): 3,881.34 ms, 1.20 GB\n[listdir:20294] (features): 227.98 ms, 1.20 GB\n[listdir:20294] analysis: 9,894.44 ms, 1.20 GB\n[listdir:20294] (clinit): 189.02 ms, 1.20 GB\n[listdir:20294] universe: 490.97 ms, 1.20 GB\n[listdir:20294] (parse): 1,228.73 ms, 1.20 GB\n[listdir:20294] (inline): 1,114.86 ms, 1.20 GB\n[listdir:20294] (compile): 8,336.15 ms, 1.50 GB\n[listdir:20294] compile: 11,062.47 ms, 1.50 GB\n[listdir:20294] image: 686.83 ms, 1.50 GB\n[listdir:20294] write: 137.18 ms, 1.50 GB\n[listdir:20294] [total]: 24,546.82 ms, 1.50 GB<\/code><\/pre>\n\n\n\nLa premi\u00e8re chose que l\u2019on constate est que le temps de cr\u00e9ation de l\u2019image est tr\u00e8s long ! 25 secondes pour compiler une classe.<\/p>\n\n\n\n
Mais que fait GraalVM pendant tout ce temps ?<\/h4>\n\n\n\n
GraalVM va effectuer tout un tas d\u2019optimisations, notamment \u00e9tablir un graph du code appel\u00e9, pour ensuite enlever le code inutile.<\/p>\n\n\n\n
[baptiste@BMEYNIER native-list-dir]$ ls -alsh\ntotal 6,8M\n4,0K drwxrwxr-x. 2 baptiste baptiste 4,0K 15 mai 10:46 .\n4,0K drwxrwxr-x. 16 baptiste baptiste 4,0K 2 mai 12:15 ..\n6,7M -rwxrwxr-x. 1 baptiste baptiste 6,7M 15 mai 10:46 listdir<\/code><\/pre>\n\n\n\nOn constate que l\u2019ex\u00e9cutable p\u00e8se seulement 7M ! Pour le lancer, inutile de poss\u00e9der un JRE puisqu\u2019il s\u2019agit de code natif.<\/p>\n\n\n\n
IMAGINEZ LE GAIN POUR UNE IMAGE DOCKER !!!<\/h6>\n\n\n\n[baptiste@BMEYNIER native-list-dir]$ time .\/listdir ..\nWalking path: ..\nTotal: 611 files, total size = 55309806 bytes\n\nreal 0m0,034s\nuser 0m0,014s\nsys 0m0,020s<\/code><\/pre>\n\n\n\nOn constate un gain suppl\u00e9mentaire par rapport \u00e0 l\u2019AOT de la HotSpot. A noter que les applications natives s\u2019ex\u00e9cutent sur machine virtuelle appel\u00e9e SubstrateVM.<\/p>\n\n\n\n
Ce n\u2019est pas termin\u00e9, Graal propose une fonctionnalit\u00e9 (dans sa version entreprise), permettant de cr\u00e9er un fichier de profiling lors de l\u2019ex\u00e9cution. Ce fichier peut \u00eatre utilis\u00e9 pour g\u00e9n\u00e9rer une image encore plus performante.<\/p>\n\n\n\n
[baptiste@BMEYNIER native-list-dir]$ $GRAALVMEE_HOME\/bin\/native-image --pgo-instrument ListDir\n...\n[baptiste@BMEYNIER native-list-dir]$ time .\/listdir ..\nWalking path: ..\nTotal: 611 files, total size = 55309806 bytes\n\nreal 0m0,034s\nuser 0m0,014s\nsys 0m0,020s\n\n[baptiste@BMEYNIER native-list-dir]$ ls -als\ntotal 46188\n 4 drwxrwxr-x. 2 baptiste baptiste 4096 15 mai 11:19 .\n 4 drwxrwxr-x. 16 baptiste baptiste 4096 2 mai 12:15 ..\n 1840 -rw-------. 1 baptiste baptiste 1880350 15 mai 11:19 default.iprof\n \n[baptiste@BMEYNIER native-list-dir]$ $GRAALVMEE_HOME\/bin\/native-image --pgo ListDir\n[baptiste@BMEYNIER native-list-dir]$ time .\/listdir ..\nWalking path: ..\nTotal: 611 files, total size = 55309806 bytes\n\nreal 0m0,018s\nuser 0m0,006s\nsys 0m0,011s<\/code><\/pre>\n\n\n\n
![\"\"](\"http:\/\/baptiste-meynier.com\/wp-content\/uploads\/2020\/11\/archi_graalvm.png\")
<\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/baptiste-meynier.com\/wp-content\/uploads\/2020\/11\/frameworkGraal-1-1024x281.png\")
<\/figure>\n\n\n\n![\"\"](\"http:\/\/baptiste-meynier.com\/wp-content\/uploads\/2020\/11\/gitlab.png\")
<\/a><\/figure>\n<\/div>\n\n\n