Java: Pourquoi MaxPermSize existe-t-il?

Question

Pourquoi MaxPermSize existe-t-il?

Answer 1

Voici un bon article sur la génération Permanente dans le Garbage collector:

Présentation de la Génération Permanente sur Jon Masamitsu Weblog

EDIT:

Je n'ai pas vu tout ce qui pourrait indiquer pourquoi ils ont pris la décision d'avoir un max de limite sur la génération permanente de la taille. Mais j'imagine que cela a été fait pour plusieurs raisons.

1. Il rend beaucoup plus facile à mettre en œuvre, les tables sont décidément non trivial afin de se simplifier la mise en œuvre d'une quelconque manière est probablement une bonne idée.

2. YAGNI (Vous aint gonna besoin) la plupart des applications de charge fixe le nombre de classes et normalement c'est pas particulièrement grande, de sorte qu'ils ont probablement optimisé pour le cas courant et juste pris un sain d'esprit par défaut et à gauche configurable.

3. En supposant que votre perm gen taille est de plus en plus être imprévisible grand, alors vous avez probablement une erreur dans un chargeur de classe (ou de la nécessité de repenser votre architecture). Même dans les applications qui ne générer des classes au moment de l'exécution (ou de faire d'autres trucs) le nombre de classes générées est généralement fixe, de sorte que vous devriez être en mesure de syntoniser maxperm pour s'adapter à vos besoins.

4. Je ne suis pas expert sur tous les détails de la classe java de chargement et de collecte des ordures, mais ils sont tous les deux pièces compliquées de la JVM donc j'imagine qu'ils allaient essayer de garder ces deux composants orthogonale que possible, ce qui permet de perm gen à croître de façon dynamique serait probablement couple ces deux composantes de façon compliquée (et surtout parce que les deux composants ont de graves filetage considérations)

5. Il y a probablement certains avantages de performance à plafonner le max de perm génération, lui permettre de se développer pourrait impliquer supplémentaire de la copie de la collection, ou pourrait signifier que votre perm génération n'existe plus dans une zone contiguë de l'espace d'adresse, ce qui pourrait affecter la façon dont votre autre travail d'algorithmes pour la gestion de la collection.

Évidemment ce sont toutes les spéculations. Mais même si tous ces éléments sont mal, je ne pense pas que c'est "idiot" pour soleil pour avoir choisi une taille fixe, il y a sans doute plus de l'ingénierie et de la mise en œuvre des considérations que j'aurais pu rêver :)

Answer 2

Pour présenter une perspective légèrement différente, la JVM IBM n'a pas un permgen, mais plutôt les OS et alloue des blocs de mémoire, il a besoin d'eux. (d'après la rumeur, jrockit fait la même chose, mais je ne peux pas confirmer pour sûr.)

Ceci est avantageux en ce que vous n'allez pas frapper un (apparemment) limite arbitraire et la nécessité de les régler légitimes des contextes de croissance.

Sur le revers de la médaille, c'est un problème de dérive des applications (essentiellement fuite des classes) - la JVM va essentiellement aller et de consommer toute la mémoire dans l'espace d'adressage. Cela peut entraîner la méchanceté, où en code natif, soudain échouer malloc() appelle, ou Java rompre d'une manière étrange - comme le fait d'être incapable d'attribuer de nouveaux fils (qui consomme de la mémoire de la pile). Un autre inconvénient est qu'il ne fournit pas de "coût de la certitude" à propos de la mémoire de la partie de la JVM va consommer.

Il est donc nécessaire de trouver un compromis - comment voulez-vous échouer dans potentiels "de la méchanceté" des scénarios?

Answer 3

En ayant la MaxPermSize réglage de votre application va lancer la GC de la Mémoire d'erreur au démarrage, de sorte que vous ne pense pas que votre application est en cours d'exécution et demandez à vos clients d'appeler parce que le système ne fonctionne pas ou est très lent.

Disons que vous avez 4 go sur votre VM et vous savez que vous avez besoin de 2 go de non-perm de l'espace pour votre application de frapper la contractuellement convenu des mesures de performance. Si votre perm gen va prendre plus de 2 go, il n'y a pas de point dans le démarrage de l'application, car vous ne serez pas en mesure de répondre à vos mesures de rendement indiqués dans votre déclaration de travaux.

Il est mieux de savoir que au démarrage, et obtenir plus de mémoire dans la boîte, ou reconfigurer votre VM à prendre plus de la physique de la mémoire du serveur (quel que soit le cas peut être) que pour démarrer l'application, permettre les classes, ehcache, ou quoi que ce soit à la charge, pense que tout est beau et puis savoir à vos clients que le système prend 10 secondes pour charger une page.

Answer 4

Son utilisé pour dimensionner la génération permanente maximale. Dans certains algos ou si vous utilisez beaucoup, beaucoup et beaucoup de classes différentes, vous pouvez l'utiliser. Donnez celui - ci une lecture.

Mais surtout, il est utilisé comme question dans les examens ......

Answer 5

Il existe car il permet de régler le sous-système Garbage Collection au sein de la JVM. En fonction de l'architecture sous-jacente et de la gestion de la mémoire, une implémentation JVM peut avoir un garbage collection sous-optimal (trop thrashy par exemple) ... Vous pouvez spécifier un MaxPermSize à la main plutôt que de le faire calculer pour que l'application se comporte en douceur ...

La page Java GC en dit plus ...