La taille maximale du tas de la JVM peut-elle être dynamique ?

Question

L'argument JVM -Xmx permet de fixer la taille maximale du tas de la JVM à une valeur donnée. Mais existe-t-il un moyen de rendre cette valeur dynamique ? En d'autres termes, je veux dire à la JVM "regarde, si tu en as besoin, continue à prendre de la RAM du système jusqu'à ce que le système soit vide".

Une raison en deux parties pour demander : Premièrement, l'application en question peut utiliser une gamme très large de RAM en fonction de ce que fait l'utilisateur, donc les valeurs conceptuelles min et max sont assez éloignées. Deuxièmement, il semblerait que la JVM réserve l'espace maximum du tas de la mémoire virtuelle au moment du démarrage. Cette application particulière est exécutée sur une grande variété de matériel, il est donc difficile de choisir un espace de tas maximal "unique", car il doit être suffisamment faible pour fonctionner sur du matériel bas de gamme, mais nous aimerions vraiment pouvoir tirer parti de machines très puissantes si elles sont disponibles.

Answer 1

Mais, y a-t-il un moyen de rendre cette valeur dynamique ?

Littéralement, non. La taille maximale du tas est fixée au moment du lancement de la JVM et ne peut être augmentée.

En pratique, vous pourrait Il suffit de fixer la taille maximale du tas au maximum autorisé par votre plate-forme, et de laisser la JVM faire croître le tas selon ses besoins. Il y a un risque évident à faire cela, à savoir que votre application sera utiliser toute la mémoire et provoquer l'arrêt de la machine de l'utilisateur. Mais ce risque est implicite dans votre question.

EDITAR

Il convient de noter qu'il existe plusieurs -XX... Options de réglage de la GC qui vous permettent de modifier la façon dont la JVM développe le tas (jusqu'au maximum).

Une autre possibilité consiste à diviser votre application en deux parties. La première partie de l'application effectue toute la préparation nécessaire pour déterminer la "taille" du problème. Elle détermine ensuite la taille maximale appropriée du tas et lance la seconde partie de l'application, affamée de mémoire, dans une nouvelle JVM.

• Cela ne fonctionne que si l'application peut raisonnablement être partitionnée comme ci-dessus.

• Cela ne fonctionne que s'il est possible de calculer la taille du problème. Dans certains cas, calculer la taille du problème équivaut à calculer le résultat.

• Il n'est pas certain que vous obtiendrez de meilleures performances globales que si vous laissiez simplement le tas atteindre une taille maximale.

Answer 2

Ce n'est pas le cas. Ça pourrait, et ça devrait probablement :

-Xmx90%  // 90% of physical memory

Cependant, une valeur implicite par défaut de 100% n'est probablement pas une bonne idée.

Un programme écrit dans un langage non CG gère sa mémoire de manière très diligente, il élague les déchets dès que possible. Il est logique de lui permettre d'obtenir toute la mémoire qu'il demande, en supposant qu'il soit responsable de l'élimination rapide des déchets.

Une langue GC est différente. Il ne collecte les déchets que lorsque cela est nécessaire. Tant qu'il y a de la place, il ne se soucie pas des déchets qui traînent. S'il pouvait obtenir toute la mémoire qu'il aimerait avoir, il obtiendrait toute la mémoire de l'ordinateur.

Ainsi, un programmeur GC n'a plus à s'inquiéter de l'élimination de chaque déchet, mais il doit toujours avoir une idée générale du ratio déchet/objet vivant tolérable, et instruire GC avec -Xmx.

Answer 3

En fait, vous ne pouvez pas vous adapter au matériel des différents utilisateurs en utilisant uniquement Java : c'est là qu'un peu de script shell/batch peut s'avérer utile.

C'est ce que je fais sur OS X et Linux : J'ai un petit bash shell script qui se charge de trouver les bons paramètres de la JVM en fonction du matériel sur lequel l'application est exécutée, puis d'appeler la JVM.

Notez que si vous fournissez une application Java de bureau, vous voudrez peut-être utiliser quelque chose comme izpack pour fournir un installateur à vos utilisateurs :

http://izpack.org

Je ne sais pas du tout si Java Web Start peut être utilisé pour fournir différents paramètres de JVM en fonction de la configuration de l'utilisateur (probablement pas, et JWS est vraiment nul de toute façon si vous envisagez de fournir une application de bureau d'aspect professionnel).

Answer 4

Il existe une proposition d'amélioration du JDK (JEP) 8204088.

• https://bugs.openjdk.java.net/browse/JDK-8204088
• http://openjdk.java.net/jeps/8204088

"Limite de mémoire maximale dynamique"

qui suggère d'introduire CurrentMaxHeapSize :

Pour limiter dynamiquement la taille de la mémoire engagée (c'est-à-dire la taille du tas), une nouvelle variable définie dynamiquement par l'utilisateur est introduite : la taille du tas. ) peut augmenter, une nouvelle variable définie par l'utilisateur est introduite : CurrentMaxHeapSize. Cette variable (définie en octets) limite la taille du tas. le tas peut être étendu. Elle peut être définie au moment du lancement et modifiée au moment de l'exécution. d'exécution. Quel que soit le moment où elle est définie, elle doit toujours avoir une valeur égale ou inférieure à MaxHeapSize (Xmx - l'option de lancement qui limite la taille du tas). qui limite la taille du tas). Contrairement à MaxHeapSize, CurrentMaxHeapSize, peut être modifié dynamiquement au moment de l'exécution.

L'utilisation prévue est de configurer la JVM avec un Xmx très conservateur. très conservatrice (il est démontré qu'elle a un impact très faible sur l'empreinte mémoire) puis de contrôler la taille du tas en utilisant la limite dynamique CurrentMaxHeapSize. limite dynamique.

Bien qu'il n'y ait aucun signe de travail actif sur cette fonctionnalité, il s'agit d'un JEP relativement récent (de 2018), donc je garderais tout de même cela à l'esprit.

Et la société Jelastic (jelastic.com) a réalisé un prototype de travail de JEP 8204088 pour le collecteur de déchets G1 :

Voir la description à l'adresse suivante http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-May/022077.html et liste des correctifs pour OpenJDK http://cr.openjdk.java.net/~tschatzl/jelastic/cmx/