Contexte

Depuis quelques jours, la tâche m'incombe de comparer les performances de la JRE face à du code natif, le benchmark porte principalement sur Kotlin vs Rust.

Depuis Java 17, les choses ont é-nor-mé-ment évoluées au point où en termes de temps de calcul CPU ou de débits I/O purs, la JRE est plus rapide que C/C++ ou Rust sauf si l'on active les options de compilation de C/C++/Rust qui retirent la portabilité des exécutables entre Intel et AMD.

L'idée est donc d'obtenir, au moyen du paramétrage de la JRE, le meilleur compromis entre :

• Les temps de calcul CPU
• La charge moyenne CPU
• Les débits I/O
• Les temps de latence I/O
• La quantité de mémoire consommée
• Les temps de démarrage
• Le poids total de l'application
• La capacité à être supervisé/debuggé

Ce poste va donc regrouper les différentes options à passer soit aux compilateurs Kotlin et Java, soit à la JRE elle-même, ainsi que les pré-requis matériels qui en découlent en expliquant le pourquoi du comment (ça va être long mais le cours est gratuit alors profitez-en 😘).

Pré-requis

Depuis Java 11, la JRE est prévue pour fonctionner de manière optimale sur du multi-threads avec une certaine quantité de mémoire (au minimum 2 threads CPU et 2 Go de RAM). Aussitôt qu'elle s'exécute sur un seul thread CPU/vCPU ou moins de 2 Go de mémoire, alors elle considère être en environnement contraint et va activer des stratégies d'exécution plus lentes afin de fonctionner correctement (notamment SerialGC).

Sur une architecture x64/Aarch64, il faut donc une configuration matérielle minimale afin de ne pas tomber dans ce mode d'exécution aux performances limitées.

C'est pourquoi toutes les options ci-après porteront sur un matériel disposant :

• De 4 threads CPU (2 physiques + 2 virtuels ou 4 physiques)
• De 8 Go de RAM (car sur du 64 bits, en-dessous, c'est du gâchis)
• D'un disque SSD ou NVMe (c'est-à-dire avec au moins 2 threads d'écriture/lecture simultanés)

Enfin, nous parlons ici de Java 17 et rien d'autre.

Quantité de mémoire réservée (non affectable à l'application)

Dans notre cas de figure, nous avons 8 Go à allouer de manière optimale. De ces 8 Go retranchons ce que nous ne pouvons pas prendre car pris par autre chose :

1. La taille de l'OS + Services (System-D, SSH Pare-feu, fail2ban, borg backup, monitoring, etc) => 136 Mo
2. La taille de la JRE qui est elle-même un programme => 24 Mo.
3. Le taux d'espace réservé par la swappiness (chez moi 1%) => 80 Mo
4. La marge d'erreur => 16 Mo

Soit un total de 256 Mo sur 8 Go qui ne seront jamais affectés à notre application.

Fonctionnement de Java 17

La mémoire est répartie en quatre zones :

• La Stack ou pile d'appels (il y en a une par thread).
• Le Young Space qui regroupe les espaces Eden et les Survivors où sont gérées les nouvelles instances.
• Le Tenured Space, aka Old Space, qui regroupe toutes les instances ayant survécus au GC dans le Young Space.
• Le Metaspace (qui reprend le rôle du PermGen) qui retrouve tout ce qui est statique, le byte-code compilé, les informations du compilateur JIT (Just In Time) et les méta-données de classes.

Depuis Java 8, on représente les nouvelles zones de la JRE par le diagramme suivant :

Dans notre cas de figure, ces zones vont se partager 8 Go - 256 Mo = 7 744 Mo. En sachant que la consommation réelle de la mémoire d'une JRE se calcule au moyen de l'addition suivante : [Taille de la pile d'appel x Nb Threads] + [Taille du Heap] + [Taille du Metaspace] + [Taille de la JRE (C-Heap)].

Choisir le bon Garbage Collector

Globalement trois choix s'imposent sur Java 17 :
G1 (Garbage-First)

• S'active via l'option -XX:+UseG1GC.
• À utiliser par défaut mais pour s'en servir de manière optimale il faut que votre application nécessite au moins 6 Go de mémoire OU qu'au moins 50% du heap contienne des objets encore en vie.

Shenandoah

• S'active via l'option -XX:+UseShenandoahGC.
• À utiliser si vous souhaitez minimiser le plus possible les temps de pause dus au GC (< 1 ms) OU que vous souhaitez des temps de pause semblables quelque soit la taille du heap entre 2 Go et 200 Go.

ZGC (expérimental)

• S'active via l'option -XX:+UnlockExperimentalVMOptions -XX:+UseZGC.
• À utiliser si votre application requiert plusieurs téraoctets de RAM (oui téra ou a minima quelques centaines de Go) OU que vous ayez besoin de régler le seuil de concurrence des cycles du GC parce que votre hardware dispose de trouze-mille threads matériels.

Je mets volontairement au rebus les GC trop lents ou dépréciés tels que Serial collector, Parallel collector, Concurrent Mark and Sweep et évidemment NoGC.

=> Dans notre cas de figure nous partirons sur Garbage-First / G1.

Paramétrage de la JRE

Toute la configuration de notre JRE se fera au moyen de la variable d'environnement JRE_OPTIONS qui sera passée en argument à la commande java. Par défaut nous exécuterons notre JRE en mode serveur.

Dimensionnement de la Stack

Nous avons un CPU à 4 threads. Dans un monde idéal, la JRE s'appuierait sur un pool de 4 threads CPU et chaque frameworks utiliserait un thread virtuel qui serait dépilé/traité par ceux du pool.

Mais nous ne vivons pas dans un monde idéal, nous allons donc limiter le nombre de threads de notre application à 16 threads physiques par threads CPU soit 4 x 16 = 64 threads au total.

Notre système ne disposant que de 8 Go de RAM, nous allons limiter la taille de chaque pile d'appels via l'option -Xss à 1 Mo soit 1 x 64 Mo = 64 Mo cumulés.

N.B : par défaut la JRE définit déjà une taille de pile d'appels à 1 Mo mais je préfère la forcer au cas où une mise à jour changerait cette valeur.

Cette limitation vient aussi du fait que je souhaite que le poids de la Stack ne dépasse pas 1% de la RAM. Il n'y a pas de raison particulière à cela mais afin de se représenter la chose, avec 1 Mo d'appels en cascade il est possible d'imbriquer dans le même algorithme :

• ~2 000 méthodes dont chaque signature expose 6 paramètres + un type de retour.
• ~3 900 méthodes dont chaque signature expose 3 paramètres sans type de retour.

Étant donné que je travail avec Jooby sur Netty il n'y aura pas de problème pour configurer le nombre de threads et la taille de la pile d'appel. Mais dans la pratique, il faut bien connaître ses frameworks ou tout profiler sinon.

Dimensionnement du Metaspace

Le Metaspace a pour comportement d'occuper tout l'espace restant afin d'éviter les OutOfMemory ; contrairement au PermGen que nous pouvions contraindre mais qui occupait l'espace du Heap.

Dans la pratique, le poids cumulé de tous les jars des frameworks que j'utilise pour un service RESTful est inférieur à 16 Mo mais une fois les jars décompressés ce sont ~40 Mo de fichiers répartis sur ~6 000 .class qui sont à charger.

En jouant avec les options -Xcomp, -Xbatch, XnoclassGC et -XCompileThreshold=1 j'ai forcé la JRE a compiler 100 % du bytecode en mémoire dans le Metaspace. Et en analysant le poids avec l'utilitaire JConsole, j'ai pu constater que 32 Mo étaient occupés.

Je suppose que la taille maximale du Metaspace devrait être égale au poids des .class + au poids des ressources chargées dans le classpath (même si a priori non). Comme mon système a beaucoup de RAM, je préfère ajouter une nouvelle fois 16 Mo de marge et ensuite profiler l'application pour déterminer si cette marge est toujours nécessaire.

Je vais donc passer la taille par défaut du Metaspace ainsi que la taille de ses partitions à 64 Mo. Je considère aussi que le Metaspace peut évoluer entre 5% et 95% de sa capacité avant d'être redimensionné à la hausse ou à la baisse.

Au final, la stratégie consistera à définir des options -Xmx et -Xms qui ne laisseront au Metaspace que les 64 Mo dont il aura besoin pour mon application. Évidemment, certains programmes codés en Spring Bouse réclameront facilement 100 Mo ou 200 Mo de Metaspace. Il faut donc mesurer l'espace occupé dans le pire cas de figure pour correctement paramétrer le reste.

Dimensionnement du Heap

Dans mon cas, ce sera facile. Il me suffit de reprendre la taille maximale disponible et de lui retrancher la taille du Metaspace, de la Thread Stack, de la JRE et de la marge d'erreur.

On obtient 7 744 - 64 - 64 - 24 - 16 = 7 576 Mo

Dimensionnement des zones du Heap

Comme vu plus haut, le Heap est décomposé en Young et Old spaces. Pour savoir quel espace allouer au Young Space (et donc à laisse au Old Space) il faut superviser l'application.

Dans mon cas de figure, comme j'ai appris à coder avec de petites instances immutables, imbriquées et jetables, j'ai besoin d'un gros Young Space par défaut, en sachant que celui-ci prendra toute la place qu'il peut dans le Heap s'il en a le besoin.

Sans profiling, je pars sur une répartition 3/4 Young et 1/4 Old, soit respectivement 5 682 Mo et 1 894 Mo sur les 7 576 Mo affectables. J'arrondis le 5 682 Mo à 5 680 Mo car ce sera plus pratique pour déclarer les ratios Eden vs Survivor.

Supervision de la JRE

La JRE produit elle-même des logs qui sont indispensables pour comprendre ses dysfonctionnement en production. L'idée est donc de définir une rolling policy ainsi qu'un fichier de sortie.

-XX:+UseGCLogFileRotation 
-XX:NumberOfGCLogFiles=< number of log files > 
-XX:GCLogFileSize=< file size >[ unit ]
-Xloggc:/path/to/gc.log

Paramètre de la ligne de commande

Au final nous obtenons ce script de démarrage

#!/usr/bin/env dash

## Mode server
JRE_OPTIONS="-server"                                                   

## Heap
* Nous avons min = max pour que la JRE s'affecte tout dès son démarrage et s'évite de perdre du temps aux resize
JRE_OPTIONS="${JRE_OPTIONS} -Xms7576m"                                  # Taille minimale du Heap
JRE_OPTIONS="${JRE_OPTIONS} -Xmx7576m"                                  # Taille maximal du Heap

## Young Space
JRE_OPTIONS="${JRE_OPTIONS} -XX:NewSize=5680m"                          # Taille par défaut du Young Space
JRE_OPTIONS="${JRE_OPTIONS} -XX:MaxNewSize=5680m"                       # Taille maximale du Young Space

## Thread Stack
JRE_OPTIONS="${JRE_OPTIONS} -Xss1m"                                     # Taille de la Stack d'un thread sur 16

## Taille du Metaspace
JRE_OPTIONS="${JRE_OPTIONS} -XX:MetaspaceSize=64m"                      # Seuil au-delà duquel le Metaspace grossi
JRE_OPTIONS="${JRE_OPTIONS} -XX:MaxMetaspaceSize=64m"                   # Taille maximale du Metaspace avant un OutOfMemory
JRE_OPTIONS="${JRE_OPTIONS} -XX:MinMetaspaceFreeRatio=5"                # Après un GC complet, pourcentage d'espace libre minimal du Metaspace avant son augmentation
JRE_OPTIONS="${JRE_OPTIONS} -XX:MaxMetaspaceFreeRatio=95"               # Après un GC complet, pourcentage d'espace libre maximal du Metaspace avant sa réduction

## Logs
JRE_OPTIONS="${JRE_OPTIONS} -Xloggc:/var/log/my-app/jre.log"            # Emplacement du fichier de log
JRE_OPTIONS="${JRE_OPTIONS} -XX:+UseGCLogFileRotation"                  # Mise en place d'une rotation des fichiers de log
JRE_OPTIONS="${JRE_OPTIONS} -XX:NumberOfGCLogFiles=10"                  # Nombre maximum de fichiers de logs
JRE_OPTIONS="${JRE_OPTIONS} -XX:GCLogFileSize=100m"                     # Taille maximale d'un fichier avant rotation

JRE_OPTIONS="${JRE_OPTIONS} -XX:+HeapDumpOnOutOfMemoryError"            # Dump de la mémoire en cas de OOM
JRE_OPTIONS="${JRE_OPTIONS} -XX:HeapDumpPath=/var/log/my-app/oom.log"   # Chemin vers le fichier
JRE_OPTIONS="${JRE_OPTIONS} -XX:OnOutOfMemoryError='shutdown -r '"      # Commande a exécuter en cas de OutOfMemory
JRE_OPTIONS="${JRE_OPTIONS} -XX:+UseGCOverheadLimit"                    # Limitation des temps GC avant qu'un OOM ne soit levé

## Optimisation du byte-code
JRE_OPTIONS="${JRE_OPTIONS} -XX:+UseStringDeduplication"                # Evite d'instancier plusieurs fois la même String
JRE_OPTIONS="${JRE_OPTIONS} -XX:+OptimizeStringConcat"                  # Utilise un StringBuffer pour concaténer des String quand c'est possible mais pas fait par le développeur

java ${JRE_OPTIONS} -cp ${CLASSPATH} ${mainClass}

Ce post a deux ans, les choses se sont améliorées mais pas toutes.

Bon, j'avais brièvement entendu parler des foulards rouges. C'est difficile de comprendre leurs intentions réelles en une seule vidéo de 3-4 minutes. Cependant, en tant que Gilet Jaune, je peux répondre sur certains arguments entendus dans la vidéo :

• Je suis entrepreneuse, mes semaines font rarement moins de 50 heures et je travaille 7 jours sur 7 (et croyez-moi même 10 minutes de papiers à remplir les dimanches ça fait chier, sachant que ça me prend systématiquement 1h).

• J'ai deux ou trois semaines de vacances par an quand la norme dans l'IT c'est sept semaines, oui 7.

• Je suis riche au vu des revenus median et moyen nationaux et même vis-à-vis de ceux dans ma profession. Je ne revendique donc pas "plus d'argent".

• Je ne contribue pas au mouvement des Gilets Jaunes pour que des glandeurs puissent empocher du fric en restant chez eux non ! Je participe au mouvement car les personnes politiques françaises sont massivement et majoritairement corrompues, parce qu'elles favorisent les intérêts d'un petit nombre au détriment de l'intérêt général. Je ne pense pas que ces hommes et femmes politiques soient corrompus par nature mais que c'est notre organisation institutionnelle qui est défaillante et encourage et permet leur corruption quasiment immédiate (puisqu'ils n'ont pas de comptes à nous rendre). En ce sens, je souhaite une réorganisation du pouvoir dans une VI-ème République dont la Constitution ne serait pas écrite par ces mêmes politiques corrompus mais par les citoyens eux-mêmes. Pour réaliser cette prouesse, le meilleur outil étant le RIC (Référendum d'Initiative Citoyenne), arme de démocratie massive convoitée par les Gilets Jaunes, je me suis naturellement rangée de leur côté par intérêt commun.

Attention, des monstres (machistes, religieux, misogynes, politiques et j'en passe) tentent par tous les moyens de faire peur aux femmes et surtout de nous empêcher d'avoir l'accès à la pilule du lendemain (que l'on devrait appeler la pilule d'urgence).

Cette article détricote tous les mensonges propagés à ce sujet et nous permet de nous rendre compte que la pilule d'urgence n'a aucun risque d'une part et qu'il y a bien une lutte insidieuse pour faire régresser le droit des femmes.

Je copie-colle au cas où :

La Coupe d'Hygie
Blog d'un pharmacien qui essaie de se mettre à la place du patient

ACTUALITES
INFORMATION PATIENT
    NOTICE
    EDUCATION PATIENT
    PLAN DE GESTION DE RISQUES
    SANTÉ 2.0
    PACKAGING
TRANSPARENCE
DIVERS
A PROPOS

C’est la pilule de la minute, pas du lendemain !

Suite au tutorial, je lis depuis une semaine un certain nombre de réactions d’étudiants en pharmacie ou de pharmaciens sur la contraception d’urgence qui me navrent. Un patient vient chercher chez un pharmacien des compétences scientifiques. Pas un jugement de valeur, un cours de morale ou une démarche irrationnelle. Alors j’ai décidé de compiler ces affirmations répétées par ces professionnels de santé (ou futurs professionnels) sur la pilule du « lendemain » afin de les déconstruire.

« Avoir une pilule du lendemain en avance diminue l’utilisation de la pilule classique et augmente les pratiques à risques et les rapports non protégés »
FAUX. Cette affirmation est non fondée scientifiquement. La Haute Autorité de santé (HAS) a effectué une revue de la littérature scientifique. Elle en conclut : « il est peu vraisemblable qu’une prescription à l’avance systématique de la contraception d’urgence entraîne une augmentation des rapports sexuels non protégés ou des infections sexuellement transmissibles ou une réduction de l’utilisation de la contraception régulière » (source ici).

« La pilule du lendemain chamboule ton corps/ est dangereux pour la santé/provoque le cancer hormonodépendant/rend stérile »
FAUX. Le RCP (le document médecin) et la notice (document patient) listent les effets indésirables de ce médicament. Le cancer et la stérilité ne font pas partie des effets identifiés lors du développement de cette pilule ni lors des 15 années de son utilisation par des millions de patientes dans le monde.
Capture d’écran 2016-08-27 à 02.18.46
Fréquence non déterminée signifie que quelques cas ont été rapportés après la commercialisation du médicament et que ce nombre de cas est insuffisant pour déterminer une fréquence.

« L’usage répétée de la pilule du lendemain est dangereux pour la santé »
FAUX. L’OMS évoque les effets secondaires listés dans le RCP et dit je cite : « une utilisation fréquente peut avoir des effets secondaires, comme l’irrégularité du cycle menstruel, bien qu’un usage répété n’entraîne aucun risque connu pour la santé. »

« La pilule du lendemain, c’est 100/500/1000 fois la dose d’une pilule classique, cette surdose d’hormone peut être dangereuse »
FAUX. Les pilules dites classique contiennent 2 substances actives : un oestrogène et un progestatif. La contraception d’urgence au Norlevo ne contient qu’un progestatif. La comparaison est hasardeuse. En fait, la dose en progestatif du Norlevo est 10 fois supérieure en comparaison d’une pilule oestro-progestative. Et on atteint dans le pire des cas 50 fois pour une pilule microprogestative (Microval). Mais même à 50 fois, est-ce un argument pertinent ? Absolument pas. Nous avons vu dans le RCP les effets indésirables de la contraception d’urgence. Et bien le RCP évoque aussi les cas de surdosages en disant, je cite : « Aucun effet indésirable grave n’a été rapporté après absorption de fortes doses de contraceptifs oraux. Le surdosage peut entraîner des nausées et des hémorragies de privation. »

Donc même si une femme décide d’enchainer 3 boites de pilules, cela n’aura pas de conséquence grave. Contrairement au paracétamol qui lui vous enverra aux urgences hospitalières avec 1 seule boite.

« Si je délivre la pilule à un homme, la patiente n’aura pas l’information »
Gné ? Et pour les autres médicaments sans prescription ? Paracétamol, laxatifs, anti-inflammatoires provoquent chaque année des décès. Aucun à ce jour avec la contraception d’urgence. Les risques de mésusage et la fréquence d’effets indésirables graves avec d’autres médicaments sans prescription sont nettement plus importants que ceux de la contraception d’urgence. Etonnamment, on ne refusera jamais à un homme d’acheter du paracétamol pour sa compagne. Par contre, on inventera toute sorte de raisons grotesques ou singulières pour la contraception d’urgence. Par exemple : « et si l’homme fait prendre à sa compagne le médicament à son insu ? » Mais jamais on ne se demandera : et si l’homme mettait une boite entière de laxatif dans le café de sa compagne ?

Grotesque. Pourquoi chercher des situations improbables, irrationnelles ou des faits divers pour justifier un frein à l’accès de la contraception d’urgence ? Il faut travailler sur ces préjugés et encourager l’implication de l’homme dans la contraception.

« La réglementation interdit au pharmacien de délivrer plus d’une seule boite à la fois »
VRAI. La contraception d’urgence contient une substance inscrite sur une liste d’exonération. Cette liste limite la dose pouvant être remise à un(e) patient(e) en 1 seule fois. Et cette dose correspond à 1 seule boite. Mais, ce n’est pas le seul médicament dans ce cas. En effet, le pharmacien ne peut pas non plus vous remettre 2 boites de :

ibuprofene 200 mg (boite de 30 – par exemple Nurofen, Advil, etc…)
lopéramide 2 mg (boite de 12 – les versions « conseil » de l’équivalent d’Imodium)
loratadine 10 mg (boite de 7 – par exemple Humex Allergie)
amorolfine (vernis contre les champignons des ongles)
néo-codion (codeine pour traiter la toux sèche)

Donc si le pharmacien respecte l’arrêté, il doit refuser de vendre 2 boites pour TOUS ces produits.

« C’est la pilule du lendemain pas de la minute. Les femmes peuvent attendre 24 h. Elles n’ont pas besoin d’en avoir chez elle »
FAUX. Le terme « lendemain » est un faux ami. Le terme adéquat est « contraception d’urgence ». Le mot urgence souligne l’importance d’une prise rapide. Plus cette pilule est prise tôt, plus la contraception d’urgence est efficace.

Capture d’écran 2016-08-27 à 03.54.07

La HAS recommande de la prendre de préférence dans les 12 heures qui suivent le rapport (source ici). 12 heures ! Donc oui, il y a bien urgence. D’où l’intérêt d’avoir une boite en avance pour ne pas chercher en panique une pharmacie ouverte un dimanche soir.

pregnancy_rate_chart

« Une pilule d’urgence n’est pas efficace si elle est prise juste avant d’avoir un rapport sexuel »
FAUX. Une revue de la littérature par le Cochrane a évalué l’indice de Pearl (% de grossesses sur un an avec une méthode de contraception) à 5 pour un moment de prise juste avant ou juste après le rapport sexuel. La pilule d’urgence peut donc être prise juste avant le rapport sexuel non protégé. Toutefois cette prise « juste avant » n’est pas reconnue dans l’AMM où il est indiqué de la prendre juste après le rapport.

Il faut éviter d’utiliser trop souvent la pilule du lendemain car ce n’est pas une méthode de contraception efficace
VRAI. Mais cette affirmation doit être pondérée. Les contraceptions les plus efficaces sont : la stérilisation, les DIU (improprement appelé stérilet) et l’implant. Les taux d’efficacité dans la vie réelle approchent les 100%. Les autres méthodes hormonales (pilule, anneau vaginal…) sont également des méthodes dite efficaces mais ont une moins bonne efficacité dans la vie réelle que le DIU, l’implant ou la stérilisation.

Viennent ensuite les autres méthodes de contraception : préservatif, spermicide, diaphragme, éponge vaginale, méthode naturelle, etc… Si une femme décide d’utiliser la contraception d’urgence comme contraception régulière, cette méthode s’inscrit alors dans cette 2e liste. Et son efficacité se compare assez favorablement aux préservatifs masculins et féminins (source ici).

Et face à ces autres méthodes (spermicides, éponges, méthodes naturelles…), elle est bien plus efficace pour éviter une grossesse non désirée. Cette contraception peut donc être une alternative pour certaines femmes qui ne souhaitent pas prendre la pilule classique, utiliser de DIU ou de préservatifs et qui n’ont pas de relations sexuelles fréquentes.

Par contre, comme toutes les autres méthodes à l’exception du préservatif, la contraception d’urgence ne protège pas des infections sexuellement transmissibles.

Une fois l’information remise, c’est à la patiente de décider en parfaite connaissance de l’efficacité de chaque méthode quelle contraception lui conviendra le mieux compte tenu de sa vie sexuelle et du risque de grossesse

N’hésitez pas à me transmettre d’autres affirmations « curieuses » que vous auriez entendu pour une mise à jour de ce billet.

Remarque : ce billet est centré sur la contraception d’urgence au lévonorgestrel (Norlevo) appelée improprement pilule du lendemain et utilisable jusqu’à 3 jours après le rapport. C’est la pilule d’urgence à utiliser en première intention. Si ce délai est passé, il existe une pilule du surlendemain (jusqu’à 5 jours). Enfin, le DIU au cuivre peut être utilisé jusqu’à 5 jours également : c’est la contraception d’urgence la plus efficace.

Si vous configurer Surefire avec certaines options, il ne vous sera plus possible de produire des rapports avec JaCoCo (le fichier jacoco.exec dédié à l'agent JaCoCo ne sera plus produit).

Ce poste explique comment résoudre le problème en remplaçant les configurations de Surefire

et never par true