Quelques options de la JVM Hotspot

Il est important de comprendre que la JVM Hotspot possède des limites en termes de taille mémoire qui sont infranchissables. Ces limites sont au nombre de deux. L'espace occupé par le Young Space et le Old Space ne doit pas excéder la taille spécifiée par l'option -Xmx. De même le Perm Gen ne pourra pas excéder la taille spécifiée par l'option -XX:MaxPermSize. Si l'une de ces deux limites est atteinte, une exception de type java.lang.OutOfMemoryError sera déclenchée ce qui aura pour effet de stopper le thread ayant déclenché cette exception.

-Xmx800m : Permet de fixer un heap de 800 méga-octets pour les old et young spaces.
-XX:MaxPermSize=256m : Permet de fixer un Perm de 256 méga-octets

IMPORTANT : à partir de la version 8.0 du standard Java SE, Hostpot supprime le PERM. Si vous utilisez cette version de Hostspot (ou une version supérieure), oubliez l'option -XX:MaxPermSize.

Il vous est possible de contrôler, en termes de ratios, les tailles des différents espaces mémoire associés au Young Space et au Old Space. Pour ce faire, la JVM propose les options qui sont présentées ci-dessous. Imaginons que la mémoire occupe, à un instant donné, une taille de 96 méga-octets.

-XX:NewRatio=2 : indique que le Old Space (64 Mo) est deux fois plus grand que le Young Space (32 Mo).
-XX:SurvivorRatio=2 : indique que l'Eden (16 Mo) est deux fois plus grand que l'un des deux Survivor Spaces (8 Mo chaque espace).

Attention : les valeurs proposées le sont à titre d'exemple et vous ne devez pas considérer que ces valeurs soient optimales, bien au contraire. Il est donc de votre responsabilité, en fonction de la manière qu'a votre application de consommer les objets, de correctement configurer ces valeurs. Si vous ne maitrisez pas ces paramétrages, je vous conseille de conserver ceux proposés par défauts par la JVM.

Il vous est possible de surveiller l'activité du garbage collector : les traces sur cette activité peuvent être produites soit sur la sortie standard de votre JVM soit vers un fichier spécifique (en fonction des options utilisées). Qui plus est, vous pouvez obtenir un rapport simplifié (par défaut), soit un rapport détaillé de l'activité du garbage collector. Voici quelques options utiles pour surveiller cette l'activité.

-verbose:gc : permet d'afficher l'activité du GC sur la sortie standard de la JVM considérée.
-Xloggc:filename : permet de stocker des logs sur l'activité du GC dans le fichier spécifié.
-XX:+PrintGCDetails : demande à produire un rapport détaillé (zone par zone) de l'activité du GC. Cette option fonctionne aussi bien en complément de l'option -verbose:gc qu'avec l'option -XX:+PrintGCDetails.

Enfin, notez qu'il est possible de demander à la JVM de réaliser un dump de sa mémoire en cas de crash, suite à un dépassement de mémoire disponible (java.lang.OutOfMemoryError). Pour ce faire, utilisez la première option qui suit : noter qu'ensuite, il existe un ensemble d'outils permettant d'analyser ce dump mémoire (nous y revenons dans le chapitre qui suit).

-XX:+HeapDumpOnOutOfMemoryError : produit un dump mémoire en cas de saturation de la mémoire disponible.
-XX:HeapDumpPath=path : permet de contrôler le répertoire dans lequel seront produits les rapports.

Pour de plus amples informations sur les autres options que supporte la JVM (il y en a beaucoup d'autres), vous pouvez consulter le document suivant.