32 ou 64 bits pour la JVM?
En lisant ce livre sur ici .
Je peux voir la section suivante, qui dit:
32 OU 64 BITS? Si vous avez un système d'exploitation 32 bits, vous devez utiliser une version 32 bits de la JVM. Si vous avez un système d'exploitation 64 bits, ensuite, vous pouvez choisir d'utiliser la version 32 ou 64 bits de Java. Ne supposez pas que juste parce que vous avez un système d'exploitation 64 bits, vous doivent également utiliser une version 64 bits de Java.
Si la taille de votre tas sera inférieur à environ 3 Go, le 32 bits la version de Java sera plus rapide et aura une empreinte plus petite. C'est parce que les références de mémoire dans la JVM ne seront que 32 bits, et la manipulation de ces références de mémoire est moins coûteuse que manipulation de références 64 bits (même si vous avez un processeur 64 bits). Le Les références 32 bits utilisent également moins de mémoire.
Le chapitre 8 traite des oops compressés, ce qui est un moyen pour la JVM de utilisez des adresses 32 bits même dans la JVM 64 bits. Cependant, même avec cette optimisation, la JVM 64 bits aura une plus grande empreinte car le code natif qu'il utilise aura toujours des adresses 64 bits.
L'inconvénient de la JVM 32 bits est que la taille totale du processus doit être moins de 4 Go (3 Go sur certaines versions de Windows et 3,5 Go sur certains anciens les versions de Linux). Cela inclut le tas, permgen et le natif code et mémoire native utilisés par la JVM. Programmes qui font un usage intensif des variables longues ou doubles seront plus lentes sur une JVM 32 bits parce que ils ne peuvent pas utiliser les registres 64 bits DU PROCESSEUR, bien que ce soit un très cas exceptionnel.
Les programmes qui correspondent à un espace d'adressage 32 bits s'exécuteront n'importe où entre 5% et 20% plus rapide dans une JVM 32 bits qu'une La JVM 64 bits. Le programme de dosage des actions discuté plus tôt dans ce chapitre, par exemple, est 20% plus rapide lorsqu'il est exécuté sur une JVM 32 bits sur mon Desktop.
Les lignes indiquent que 32 bits seront plus rapides pour une taille de tas inférieure (inférieure à De 3 go). Si cela est vrai, je veux connaître la raison derrière cela, qu'est-ce qui rend la JVM 32 bits plus rapide?
8 réponses
C'est plus une question de performances générales. Si vous avez un processeur 64 bits récent et beaucoup de mémoire inutilisée, le seul gain possible en utilisant JVM 32 au lieu de JVM 64 serait que certaines boucles pourraient s'intégrer pleinement dans le cache avec des adresses 32 bits et non avec des adresses 64 bits conduisant à moins d'accès à la mémoire principale avec une JVM 32 bits. Je ne peux vraiment pas évaluer le gain, mais sauf dans des cas très spéciaux, je doute qu'il atteigne 5 à 20 % - notez que je doute seulement, pas sûr ...
, Mais si vous utilisez un système limité de ressources, finalement parce que vous voulez optimiser votre matériel et exécuter de nombreuses machines virtuelles, une JVM 32 bits utilisera beaucoup moins de mémoire qu'une machine 64 bits. Il laissera plus de mémoire libre à d'autres applications et au système évitant ainsi l'échange et permettant au système de mieux mettre en cache les e / s du disque.
IMHO, il n'y a pas de règle générale. Je voudrais simplement utiliser la règle de base suivante: si lorsque la JVM et toutes les autres applications sont en cours d'exécution, le système en a encore assez mémoire pour la mise en cache des e / s, j'utiliserais une JVM 64 bits et une JVM 32 bits dans le cas contraire.
Bien sûr ci-dessus n'a de sens que si L'application Java en elle-même n'a pas besoin de beaucoup de mémoire imposant l'utilisation d'une JVM 64 bits - et éventuellement ajoutant plus de mémoire au système si nécessaire, car la mémoire n'est pas si chère de nos jours
Je suis sceptique quant à l'affirmation de l'auteur selon laquelle l'utilisation de la version 32 bits de la JVM donnera une amélioration des performances de 5% à 20%. Cependant, je n'utilise pas beaucoup Java, donc je ne sais pas avec certitude. Mais afin d'enquêter sur ces allégations, j'ai regardé certains des résultats de SPEC.
J'ai cherché les résultats SPECjEnterprise2010 et le score le plus élevé pour une architecture x86-64 était un système Oracle qui utilisait une version 64 bits de la JVM.
J'ai aussi regardé SPECjvm2008 dans cas ces charges de travail plus petites pourraient bénéficier de l'architecture 32 bits. Mais encore une fois, le système x86-64 le plus performant, cette fois de Huawei, utilisait la version 64 bits de la JVM.
Si la version 32 bits de la JVM était vraiment meilleure, je m'attendrais à ce que les personnes qui soumettent leurs résultats de spécification l'aient sélectionnée lors du réglage de leurs charges de travail (mais je pourrais me tromper).
Je ne doute pas qu'il existe des charges de travail où la version 32 bits de la JVM surpassera la version 64 bits. Comme d'autres l'ont noté, il utilise plus de mémoire pour les adresses. Cependant, l'architecture x86-64 a plus de registres disponibles et je soupçonne que le mode de fonctionnement 64 bits est l'endroit où la plupart du travail d'optimisation est concentré.
Les performances du système ont beaucoup de composants, et je ne pense pas que la version 32 bits de la JVM surpassera nécessairement la version 64 bits(pour un cela cela n'aura d'importance que pour les charges de travail liées au processeur). Je dirais que si vous arrivez à ce point dans le processus de réglage des performances que vous souhaitez vérifier votre propre charge de travail pour les deux options différentes, et utiliser le résultat de vos propres tests pour prendre une décision plutôt que de supposer que l'utilisation du 32 bits est meilleure que 64 bits en raison de l'économie d'espace mémoire pour les adresses en règle générale, car il
Il n'y a pas de réponse simple et la meilleure chose à faire est de l'essayer pour votre application spécifique. Mais vous devez garder à l'esprit qu'il y a beaucoup d'autres options, par exemple en ce qui concerne JIT, algorithme de récupération de Place, limites de RAM, qui pourraient avoir un impact plus important que le choix de l'architecture, vous devez donc les inclure dans vos mesures.
Si jamais vous posez cette question, en d'autres termes, avez le choix , cela implique que vous êtes déjà en cours d'exécution sur un système 64 bits avoir un mode 32 bits (avec des performances acceptables, c'est-à-dire pas d'émulation logicielle) qui est très probablement AMD64 aka x86-64.
Sur de tels systèmes, la JVM D'Oracle prend en charge les" oops compressés", ce qui signifie utiliser des références 32 bits dans le tas Java tant que le tas maximum ne dépasse pas 32 Go (si c'est le cas, je doute que l'utilisation de 32 bits soit un choix valide pour cette application). Il peut encore consommer plus de RAM par rapport à la JVM 32 bits car certains composants nécessitent toujours l'utilisation de pointeurs 64 bits mais ceux ci ne sont généralement pas les parties pertinentes de performance d'une application.
Notez que pour L'architecture AMD64 aka x86-64, l'utilisation du mode 64 bits implique plus que de simplement changer la taille du pointeur. Note ne lui permet d'utiliser 64 bits par registre, il a aussi Plus registres utilisables. C'est vraiment une architecture différente implémentée dans la même puce et en fonction de votre application, ce qui peut être une grande amélioration.
Mais comme dit, le tester avec votre application réelle est le seul moyen valide d'obtenir la bonne réponse.
Si vous avez l'intention d'utiliser L'une des machines virtuelles Oracle, la question se pose de savoir si vous souhaitez utiliser le JIT client ou le JIT serveur car il n'y a pas encore de JIT client disponible pour un processeur 64 bits d'Oracle.
Une machine virtuelle serveur est disponible pour les processeurs 32 et 64 bits et les différences de performance des machines virtuelles serveur sur les processeurs x86/AMD64 sont plutôt faibles (d'après mon expérience, c'est moins de +/-5% sous Windows ou Linux), bien que la machine virtuelle 64 bits nécessite généralement environ 20% de mémoire supplémentaire.
Si votre l'application a besoin d'une taille de mémoire de tas de plus d'environ 1,3 Go vous devrez utiliser une machine virtuelle de serveur 64 bits car les machines virtuelles 32 bits d'Oracle ne commenceront pas avec des tailles de tas supérieures à cela (sous Linux, la limite est légèrement plus élevée).
Le principal avantage du JIT du client est qu'il a un temps de démarrage beaucoup plus rapide. Vous pouvez faire beaucoup de travail sérieux en moins de 100 ms avec cette machine virtuelle tandis que la machine virtuelle du serveur prend plus d'une seconde seulement pour commencer même avec la compilation à plusieurs niveaux activée. Le la machine virtuelle cliente a également besoin de beaucoup moins de mémoire que la machine virtuelle serveur et peut bénéficier du partage de données de classe entre plusieurs instances de machine virtuelle sur le même ordinateur.
La machine virtuelle du serveur d'autre part a tendance à être capable d'exécuter du code intensif de calcul beaucoup plus rapidement. Les différences de performances réelles varient considérablement en fonction du code que vous exécutez, mais peuvent être comprises entre -10% et +200%. Habituellement, il est au moins 30% plus rapide pour tout ce qui prend plus de quelques centaines millisecondes à exécuter.
Vous pouvez modifier les deux JIT avec différentes options pour les rendre plus similaires, mais vous obtenez toujours le temps de démarrage rapide uniquement avec la machine virtuelle client et les vitesses d'exécution les plus élevées uniquement avec la machine virtuelle serveur.
Donc, je recommande d'utiliser la machine virtuelle du serveur 64 bits pour tout quand vous avez assez de mémoire disponible et ne vous souciez pas de la pénalité de temps de démarrage. La VM client 32 bits est idéale pour les applications GUI plus petites mais surtout pour les petits outils de ligne de commande qui prendre moins d'une seconde pour exécuter en moyenne ou peut-être besoin d'exécuter plusieurs fois simultanément sur le même ordinateur.
Les adresses mémoire 32 bits sont plus petites. Cela seul conduit probablement à une meilleure mise en cache, localité de référence, etc.
Adresse 32 bits moins d'espace mémoire la limite théorique maximale est de 4 Go, mais en pratique, elle est de 1,3 Go dans le système Windows. Vous pouvez adresser quelque chose de plus (300 à 400 Mo) plus sur le noyau Linux. Pour plus de détails, utilisez http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit (Mémoire D'espace de tas)
Le 64bit utilise des bits plus élevés pour adresser. Donc, la consommation de mémoire globale est également plus élevée. Il est possible d'utiliser un pointeur de mémoire compressée. En savoir plus sur la même chose à http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#compressedOop
La raison pour laquelle 64 bits est plus lent est à cause de grandes pauses de récupération de Place. Construire plus de tas signifie qu'il y a plus de travail à faire par GC tout en le nettoyant des objets inutilisés. Ce que cela signifie dans la vraie vie, c'est que vous devez être très prudent lorsque vous construisez des tas de plus de 12-16GB. Sans réglage fin et sans mesure, vous pouvez facilement introduire des pauses GC complètes couvrant plusieurs minutes.
Un argument pour aller pour 64 bits est que le matériel de serveur 32 bits est assez rare de nos jours. En conséquence, il n'y a pas beaucoup de gens qui utilisent des logiciels 32 bits sur les serveurs. La principale raison pour laquelle les JVM 32 bits existent toujours est de prendre en charge le logiciel client 32 bits pour les anciens systèmes 32 bits ainsi que les applets, qui s'exécutent via un plugin dans les navigateurs 32 bits.
Donc, s'il y a des bugs exotiques qui se cachent dans la version 32 bits, vous pourriez être le premier à le découvrir. Ces serait le type de bogues serait moins visible sur les systèmes de bureau et plus visible dans les logiciels côté serveur de longue durée. Pensez à des accidents mystérieux après quelques semaines / jours. Les fuites de mémoire, etc.
Donc, si vous déployez sur un serveur, optez plutôt pour 64 bits sauf si vous avez une très forte raison de ne pas le faire. Il y a beaucoup de solutions snakeoil qui flottent quand il s'agit de L'utilisation de la mémoire de Java et de la collecte des ordures. Donc, je me méfierais de l'utiliser comme argument de toute façon, à moins que vous ne puissiez le sauvegarder avec un solide métrique. Dans mon expérience, les ingénieurs java qui savent comment régler correctement une jvm sont en fait assez rares et la plupart semblent simplement copier coller au hasard des choses sur jvm_args jusqu'à ce que cela fonctionne. La plupart d'entre eux finissent par se tirer dans le pied avec des solutions qui ne sont pas optimales, ne conviennent plus à la JVM qu'ils utilisent, ou qui sont activement nocives. JVM tuning est un peu un art noir. Mieux vaut ne pas trop gâcher avec elle, sauf si vous savez ce que vous faites.
Pour les systèmes clients, allez 32 bits si vous avez besoin de prendre en charge les applets ou les systèmes de bureau plus anciens. Par exemple, windows a livré des versions 32 bits de leur système d'exploitation jusqu'à récemment et beaucoup d'applications sur windows et osx continuent d'être 32 bits. La plupart du temps, vous ne devriez pas avoir à choisir et dans tous les cas et vous pouvez laisser ce choix à l'utilisateur.
Pour les personnes préoccupées par la taille de l'adresse, la version 64 bits peut effectuer une compression de pointeur pour des tas inférieurs à 32 Go. Vous DEVEZ (et probablement vouloir) activer ceci dans les args JVM: -XX:+UseCompressedOops..