Ce travail a \u00e9t\u00e9 r\u00e9alis\u00e9 en grande partie par Claes Redestad (Oracle) lors du d\u00e9veloppement de Java 9.<\/p>\n
J’ai donc d\u00e9cid\u00e9 de tester la diff\u00e9rence entre un HelloWorld (en version standard et avec utilisation de Lambda) entre Java 8 (update 51 pour ne pas risquer de backport des optimisations en question sur cette version) et Java 9 (ea build 176). Pour r\u00e9aliser ces tests j’ai utilis\u00e9 les images docker azul\/zulu-openjdk:8u51 et azul\/zulu-openjdk:9ea et les deux classes suivantes :<\/p>\n
\npublic class HelloWorld {\n public static void main(String[] args) {\n System.out.println(\"Hello World\");\n }\n}\npublic class HelloWorldLambda {\n public static void main(String[] args) {\n Runnable hello = () -> System.out.println(\"Hello lambda world\");\n hello.run();\n }\n}\n<\/pre>\nJ’ai ensuite utilis\u00e9 la commande Linux time<\/strong> pour conna\u00eetre le temps de traitement et la fonctionnalit\u00e9 de Native Memory Tracking<\/strong> de Java pour conna\u00eetre la m\u00e9moire allou\u00e9e.<\/p>\nJava 8<\/h2>\n\ntime java HelloWorld\nreal 0m0.085s\nuser 0m0.078s\nsys 0m0.019s\ntime java HelloWorldLambda\nreal 0m0.185s\nuser 0m0.236s\nsys 0m0.032s\n<\/pre>\n\njava -XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary \\\n -XX:+PrintNMTStatistics -Xmx16m -Xms16m HelloWorld\nTotal: reserved=1356124KB, committed=57156KB\njava -XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary \\\n -XX:+PrintNMTStatistics -Xmx16m -Xms16m HelloWorldLambda\nTotal: reserved=1358869KB, committed=59901KB\n<\/pre>\nConstatation<\/strong> : une JVM \u00e7a d\u00e9marre vite (moins de 100ms) mais \u00e7a utilise quand m\u00eame plus de 57Mo de RAM juste pour un HelloWorld! L’utilisation de Lambda implique un temps de d\u00e9marrage plus que doubl\u00e9 et un overhead de m\u00e9moire de 2Mo.<\/p>\nHum, 57Mo quand m\u00eame d’utilisation m\u00e9moire pour un simple HelloWorld, je me suis souvenu d’un article fort int\u00e9ressant sur le sujet \u00e9crit par Alexey Shipilev, je me suis replong\u00e9 dedans pour creuser la question : https:\/\/shipilev.net\/jvm-anatomy-park\/12-native-memory-tracking\/<\/a><\/a> et ai ajout\u00e9 quelques options au d\u00e9marrage de ma JVM :<\/p>\n- SerialGC : le garbage collector qui d\u00e9marre le plus vite et n\u00e9cessite le moins de m\u00e9moire<\/li>\n\n
- Une heap \u00e0 16Mo : largement suffisant pour un HelloWorld<\/li>\n\n
- D\u00e9sactivation du TieredCompilation qui lui aussi n\u00e9cessite plus de m\u00e9moire<\/li>\n<\/ul>\n
\njava -XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary -XX:+PrintNMTStatistics \\\n -Xmx16m -Xms16m -XX:+UseSerialGC -XX:-TieredCompilation HelloWorld\nTotal: reserved=1134567KB, committed=35279KB\njava -XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary -XX:+PrintNMTStatistics \\\n -Xmx16m -Xms16m -XX:+UseSerialGC -XX:-TieredCompilation HelloWorldLambda\nTotal: reserved=1135918KB, committed=36630KB\n<\/pre>\n\ntime java -Xmx16m -Xms16m -XX:+UseSerialGC -XX:-TieredCompilation HelloWorld\nreal 0m0.084s\nuser 0m0.077s\nsys 0m0.014s\ntime java -Xmx16m -Xms16m -XX:+UseSerialGC -XX:-TieredCompilation HelloWorldLambda\nreal 0m0.172s\nuser 0m0.197s\nsys 0m0.018s\n<\/pre>\nConstatation :<\/strong> Le temps de d\u00e9marrage n’est pas significativement r\u00e9duit dans le cas standard (mais l’est avec lambda) mais l’occupation m\u00e9moire l’est grandement. On gagne pr\u00e8s de 20Mo gr\u00e2ce ces options de d\u00e9marrage.<\/p>\nJava 9<\/h2>\n\ntime java HelloWorld\nreal 0m0.161s\nuser 0m0.177s\nsys 0m0.048s\ntime java HelloWorldLambda\nHello lambda world\nreal 0m0.199s\nuser 0m0.228s\nsys 0m0.042s\n<\/pre>\n\njava -XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary \\\n -XX:+PrintNMTStatistics -Xmx16m -Xms16m HelloWorld\nTotal: reserved=1389612KB, committed=97536KB\njava -XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary \\\n -XX:+PrintNMTStatistics -Xmx16m -Xms16m HelloWorldLambda\nTotal: reserved=1390008KB, committed=98188KB\n<\/pre>\nConstatation :<\/strong> En Java 9, malgr\u00e9 le travail d’optimisation du d\u00e9marrage de la JVM, le temps de d\u00e9marrage est moins bon hors lambda mais meilleur avec lambda qu’en Java 8. Il reste donc du travail \u00e0 faire, JPMS (project Jigsaw) est peut-\u00eatre le fautif ici. C\u00f4t\u00e9 m\u00e9moire, il y a une forte augmentation.<\/p>\n\njava -XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary -XX:+PrintNMTStatistics \\\n -Xmx16m -Xms16m -XX:+UseSerialGC -XX:-TieredCompilation HelloWorld\nTotal: reserved=1137041KB, committed=38117KB\njava -XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary -XX:+PrintNMTStatistics \\\n -Xmx16m -Xms16m -XX:+UseSerialGC -XX:-TieredCompilation HelloWorldLambda\nTotal: reserved=1137178KB, committed=38510KB\n<\/pre>\n\ntime java -Xmx16m -Xms16m -XX:+UseSerialGC -XX:-TieredCompilation HelloWorld\nreal 0m0.152s\nuser 0m0.143s\nsys 0m0.022s\ntime java -Xmx16m -Xms16m -XX:+UseSerialGC -XX:-TieredCompilation HelloWorldLambda\nreal 0m0.202s\nuser 0m0.188s\nsys 0m0.020s\n<\/pre>\nConstatation :<\/strong> En optimisant les options JVM, le temps de d\u00e9marrage n’\u00e9volue pas beaucoup mais l’utilisation m\u00e9moire baisse drastiquement et retourne quasiment au m\u00eame niveau qu’en Java 8 dans la m\u00eame configuration. Sachant que Java 9 vient avec Le garbage collector G1 par d\u00e9faut (au lieu du Parallel GC), la consommation excessive doit provenir de celui-ci.<\/p>\nEssayons donc de v\u00e9rifier en activant le ParallelGC qui \u00e9tait le d\u00e9faut en Java 8.<\/p>\n
\njava -XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary -XX:+PrintNMTStatistics \\\n -Xmx16m -Xms16m -XX:+UseParallelOldGC -XX:-TieredCompilation HelloWorld\nTotal: reserved=1157722KB, committed=58798KB\n\njava -XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary -XX:+PrintNMTStatistics \\\n -Xmx16m -Xms16m -XX:+UseParallelOldGC -XX:-TieredCompilation HelloWorldLambda\nTotal: reserved=1157860KB, committed=59192KB\n<\/pre>\nConstatation :<\/strong> C’est donc bien l’utilisation de G1 par d\u00e9faut dans Java 9 qui est la cause de l’augmentation de l’utilisation m\u00e9moire plus importante en 9 qu’en 8.<\/p>\nConclusion<\/h2>\n
Premi\u00e8re constatation : L’id\u00e9e pr\u00e9con\u00e7ue que java est lent \u00e0 d\u00e9marrer et ne peux \u00eatre utilis\u00e9 pour des applications de type ligne de commande est erron\u00e9e! Une JVM d\u00e9marre en moins de 100ms!<\/p>\n
Deuxi\u00e8me constatation : Malgr\u00e9 tout le travail fait par les ing\u00e9nieurs d’Oracle Java 9 d\u00e9marre plus lentement que Java 8 et utilise plus de m\u00e9moire. Certain choix entre en contradiction directe avec l’optimisation du d\u00e9marrage d’une JVM (entre autre, le passage de G1 comme garbage collector par d\u00e9faut).<\/p>\n
Troisi\u00e8me constatation : L’\u00e9cart entre code utilisant et n’utilisant pas les lambda s’est \u00e9norm\u00e9ment r\u00e9duit entre Java 8 et Java 9<\/p>\n
Attention : le protocole de test utilis\u00e9 ici n’\u00e9tait peut-\u00eatre pas tr\u00e8s rigoureux, lancer plusieurs fois un process via la commande time n’est pas la panac\u00e9e. De plus le d\u00e9veloppent de Java 9 n’est pas encore termin\u00e9, on peut esp\u00e9rer que la version finale comblera en partie ou totalement l’\u00e9cart de temps de d\u00e9marrage entre une JVM 8 et 9. A tester donc avec une version finale.<\/p>","protected":false},"excerpt":{"rendered":"
Introduction En parcourant la mailing liste d’open JDK (core-lib-dev) j’ai vu plusieurs threads de mail \u00e0 propos d’optimisation de temps de d\u00e9marrage et d’occupation m\u00e9moire d’une JVM \u00ab\u00a0minimale\u00ab\u00a0. Ce travail a \u00e9t\u00e9 r\u00e9alis\u00e9 en grande partie par Claes Redestad (Oracle) lors du d\u00e9veloppement de Java 9. J’ai donc d\u00e9cid\u00e9 de tester la diff\u00e9rence entre un HelloWorld (en version standard et avec utilisation de Lambda) entre Java 8 (update 51 pour ne pas risquer de backport des optimisations en question sur…