La taille de tas maximale de la JVM peut-elle être dynamique?
L'argument JVM-Xmx permet de définir la taille maximale du tas pour la JVM à une certaine valeur. Mais, y a-t-il un moyen de rendre cette valeur dynamique? En d'autres termes, je veux dire à la JVM "regardez, si vous en avez besoin, continuez à prendre de la RAM du système jusqu'à ce que le système soit sorti."
Raison en deux parties pour demander: Tout d'abord, l'application en question peut utiliser une très large gamme de ram en fonction de ce que l'utilisateur fait, de sorte que les valeurs conceptuelles min et max sont assez éloignées. Deuxièmement, il semblerait que la JVM réserve l'espace de tas maximum de la mémoire virtuelle au moment du démarrage. Cette application particulière est exécutée sur une assez grande variété de matériel, donc choisir un espace de tas max "one-size-fits-all" est difficile car il doit être assez bas pour fonctionner sur du matériel bas de gamme, mais nous aimerions vraiment pouvoir profiter des machines vraiment costauds si elles sont disponibles.
3 réponses
Mais, existe-t-il un moyen de rendre cette valeur dynamique?
Littéralement, non. La taille maximale du tas est définie au moment du lancement de la JVM et ne peut pas être augmentée.
En pratique, vous pouvez simplement définir la taille maximale du tas sur aussi grande que votre plate-forme le permettra, et laisser la JVM développer le tas comme il en a besoin. Il y a un risque évident à faire cela; c'est-à-dire que votre application utilisera toute la mémoire et provoquera l'arrêt de la machine de l'utilisateur. Mais ce risque est implicite dans votre question.
Modifier
Il convient de noter qu'il existe différentes options de réglage -XX... GC qui vous permettent de modifier la façon dont la JVM étend le tas (jusqu'au maximum).
Une Autre possibilité est de diviser votre application en 2 parties. La première partie de l'application fait toute la préparation nécessaire pour déterminer la" taille " du problème. Ensuite, il travaille sur une taille de tas max appropriée, et lance la deuxième partie affamée de mémoire de l'application dans une nouvelle JVM.
Cela ne fonctionne que si l'application peut raisonnablement être partitionné comme ci-dessus.
Cela ne fonctionne que si 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 clair que vous obtiendrez une meilleure performance globale que si vous laissez simplement le tas grandir jusqu'à une taille maximale.
Ce n'est pas le cas. il pourrait, Et il devrait probablement:
-Xmx90% // 90% of physical memory
Cependant, un implicite par défaut, 100%, n'est probablement pas une bonne idée.
Un programme écrit dans un langage non-GC gère sa mémoire très diligemment, il élaguera toute poubelle dès que possible. Il est logique de lui permettre d'obtenir toute la mémoire qu'il demande, en supposant qu'il est responsable de l'élimination rapide des ordures.
Un langage GC est différent. Il ne collecte les ordures que si nécessaire. Aussi longtemps que il ya de la place, il n'a pas soins au sujet d'ordures qui traînent autour. S'il pouvait obtenir toute la mémoire qu'il aimerait avoir, il obtiendrait toute la mémoire de l'ordinateur.
Donc, un programmeur GC n'a plus à se soucier de disposer de chaque déchet, mais il doit toujours avoir une idée générale du rapport ordures/objets vivants tolérable, et instruire GC avec-Xmx.
Fondamentalement, vous ne pouvez pas vous adapter au matériel de divers utilisateurs en utilisant Java pur: c'est à ce moment-là qu'un peu de script shell/batch peut être utile.
Je fais exactement cela sur OS X et Linux: j'ai un petit script shell bash qui prend soin de trouver les paramètres JVM corrects 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 pouvez utiliser quelque chose comme izpack pour fournir vos utilisateurs un installateur:
Je ne sais pas du tout si Java Web Start peut être utilisé pour fournir différents paramètres JVM en fonction de la configuration de l'utilisateur (probablement pas, et JWS vraiment s*cks grand temps de toute façon si vous prévoyez de fournir une application de bureau professionnelle).