{"id":739,"date":"2018-01-26T11:13:31","date_gmt":"2018-01-26T09:13:31","guid":{"rendered":"http:\/\/www.loicmathieu.fr\/wordpress\/?p=739"},"modified":"2018-01-26T11:13:31","modified_gmt":"2018-01-26T09:13:31","slug":"les-optimisations-de-performances-de-java-9","status":"publish","type":"post","link":"https:\/\/www.loicmathieu.fr\/wordpress\/fr\/informatique\/les-optimisations-de-performances-de-java-9\/","title":{"rendered":"Les optimisations de performances de Java 9"},"content":{"rendered":"

Dans un pr\u00e9c\u00e9dent article sur Java 9, j’avais parcouru les principales nouveaut\u00e9s \u00e0 destination des d\u00e9veloppeurs : http:\/\/www.loicmathieu.fr\/wordpress\/informatique\/les-nouveautes-de-java-9-pour-les-developeurs<\/a><\/a>.<\/p>\n

Je vais ici parcourir les principales nouveaut\u00e9s ax\u00e9es sur la performance<\/p>\n

Je vais encore reprendre les principales JEP :<\/p>\n

JEP 143: Improve Contended Locking<\/h2>\n

Optimisation des monitors Java (optimisation des locks) en cas de contention (quand plusieurs threads acc\u00e8dent au m\u00eame monitor). Ce sont des changements au sein de la JVM qui permettent des gains de performances significatifs (x2) sur certaines op\u00e9rations de la JVM sur les primitives de lock des objets (synchronize, wait, …)<\/p>\n

Plus d’info dans la pr\u00e9sentation de Monica Beckwith sur le sujet :<\/p>\n

https:\/\/www.slideshare.net\/MonicaBeckwith\/jfokus-java-9-contended-locking-performance<\/a><\/a><\/p>\n

JEP 193: Variable Handles<\/h2>\n

Une nouvelle API de Java, \u00e0 destination des utilisateurs avanc\u00e9s, permettant de remplacer l’usage d’Unsafe<\/strong> pour l’acc\u00e8s performant \u00e0 des variables de mani\u00e8re atomique.<\/p>\n

A variable handle is a typed reference to a variable, which supports read and write access to the variable under a variety of access modes. Supported variable kinds include instance fields, static fields and array elements.<\/blockquote>\n

Plus d’info dans la description de la JEP : http:\/\/openjdk.java.net\/jeps\/193<\/a><\/a><\/p>\n

JEP 197: Segmented Code Cache<\/h2>\n

Le code cache (une partie du Metaspace) a \u00e9t\u00e9 s\u00e9par\u00e9 par type de code (m\u00e9thode, non-m\u00e9thode, profil\u00e9, non-profil\u00e9, …) pour en optimiser les performances et permettre de futures optimisations.<\/p>\n

Plus d’info dans la description de la JEP : http:\/\/openjdk.java.net\/jeps\/197<\/a><\/a><\/p>\n

JEP 254: Compact Strings<\/h2>\n

C’est une des principales JEP autour de la performance!<\/p>\n

L\u2019impl\u00e9mentation des String en Java a \u00e9t\u00e9 revue pour en proposer une version plus compacte.<\/p>\n

Jusqu’ici les String \u00e9taient stock\u00e9es en UTF-16, chaque caract\u00e8re prenait donc deux octets car stock\u00e9s dans un tableau de char.<\/p>\n

Avec les Compact String, a la construction de la String, si elle est compatible ISO-8859-1 (ou Latin-1), chaque caract\u00e8re sera alors stock\u00e9 dans un seul octet, le stockage d’une String passant alors d’un tableau de char \u00e0 un tableau de byte. Le gain potentiel est \u00e9norme : diminution de presque 50% de la taille n\u00e9cessaire pour stocker les String. Les String sont la principale source d’utilisation de la m\u00e9moire et bien souvent elles sont compatible ISO-8859-1.<\/p>\n

Si la String est non compatible ISO-8859-1, alors les caract\u00e8res seront quand m\u00eames stock\u00e9s dans un tableau de byte mais il faudra deux bytes pour chaque caract\u00e8re. Un flag ayant \u00e9tait ajout\u00e9 \u00e0 la classe String pour connaitre l’encoding de celle-ci.<\/p>\n

Ce changement a \u00e9t\u00e9 fait sans aucun changement dans l’API publique java : en utilisant Java 9, on utilise directement les Compact Strings! StringBuilder\/Buffer ont aussi \u00e9tait mis \u00e0 jour pour en tirer parti.<\/p>\n

Lors des tests pr\u00e9liminaires \u00e0 l’impl\u00e9mentation de cette JEP, les gains suivants ont \u00e9t\u00e9 avanc\u00e9s (voir http:\/\/cr.openjdk.java.net\/~shade\/density\/state-of-string-density-v1.tx<\/a><\/a>t) :<\/p>\n