Compatibilité Java 32 bits vs 64 bits


97

Le code Java construit et compilé sur un JDK 32 bits en code octet 32 ​​bits fonctionnera-t-il dans une JVM 64 bits? Ou une JVM 64 bits nécessite-t-elle un code d'octet 64 bits?

Pour donner un peu plus de détails, j'ai du code qui fonctionnait dans un environnement Solaris exécutant une JVM 32 bits, mais je reçois maintenant des problèmes après la mise à niveau du serveur JDK et Weblogic vers 64 bits.


3
veuillez clarifier les «problèmes».
Thorbjørn Ravn Andersen

J'ai un problème similaire: déployer une application Spring sur un serveur weblogic 64 bits. Nous obtenons diverses exceptions de classe non trouvées et d'autres erreurs inutiles. De plus, il se déploie et s'exécute sur certaines machines 64 bits, mais pas sur d'autres. Nous ne pouvons pas dire ce qui est différent cependant. Avez-vous résolu cela?
nont

2
@nont - quel que soit le problème, ce n'est pas une compilation 32vs64 bits.
Stephen C

Réponses:


94

Oui, le bytecode Java (et le code source) est indépendant de la plate-forme, en supposant que vous utilisez des bibliothèques indépendantes de la plate-forme. 32 contre 64 bits ne devraient pas avoir d'importance.


Je suis tombé sur cela en cherchant une question que j'avais. J'ai donc exécuté mon application sous une JVM 32 bits et utilisé une bibliothèque native 64 bits. Ça a bien fonctionné. Mais lorsque j'exécute mon application sous une JVM 64 bits et que j'utilise une bibliothèque native 32 bits, cela échoue. Comment cela pourrait être possible? Juste curieux.
Umang Desai

6
Les bibliothèques natives @umangdesai ne sont pas des bibliothèques indépendantes de la plate-forme, donc l'hypothèse ne tient pas.
Thorbjørn Ravn Andersen

Est-ce que "ne devrait pas avoir d'importance" signifie que le code compilé avec 32 bits javacprofitera de la mémoire disponible avec 64 bits java?
Marcus Junius Brutus

1
Si cela vous pique, faites attention aux bibliothèques natives qui ont été regroupées dans un bocal qui fonctionnent pour une plate-forme, mais pas pour celle qui vous pose des problèmes. (Si vous n'avez aucune idée de ce à quoi je fais référence, voyez des choses comme ceci: stackoverflow.com/a/14051512/155631 ).
Matt S.

21

J'ai accidentellement exécuté notre (grande) application sur une VM 64 bits plutôt qu'une VM 32 bits et je n'ai pas remarqué jusqu'à ce que certaines bibliothèques externes (appelées par JNI) aient commencé à échouer.

Les données sérialisées sur une plate-forme 32 bits ont été lues sur la plate-forme 64 bits sans aucun problème.

Quel genre de problèmes rencontrez-vous? Est-ce que certaines choses fonctionnent et pas d'autres? Avez-vous essayé de fixer JConsole, etc. et avez-vous un pic autour?

Si vous avez une très grosse machine virtuelle, vous constaterez peut-être que les problèmes de GC en 64 bits peuvent vous affecter.


1
êtes-vous en train de dire que les bibliothèques JNI ne fonctionneront pas dans une VM 64 bits si elles sont 32 bits?
C. Ross

1
Ils ne fonctionnent pas. Un collègue avait signalé qu'ils l'avaient fait (ce que j'ai trouvé suspect - c'est le moins qu'on puisse dire). Je me suis demandé s'il fonctionnait sous Solaris et qu'il y avait une sorte de thunking en cours. Il n'y en avait pas; il s'est trompé et il fonctionnait sous 32 bits.
Fortyrunner

J'ai eu un problème similaire avec une bibliothèque JNI. Il n'y avait aucune compatibilité entre les bibliothèques 32 bits et 64 bits.
Erick Robertson

En effet, vos bibliothèques JNI doivent être remplacées. Vous pouvez probablement simplement télécharger l'alternative 64 bits sur le site Web du fournisseur. (Cela a fait l'affaire pour moi, pour toutes les bibliothèques JNI que j'ai utilisées).
bvdb

C'étaient des bibliothèques internes et aucun équivalent 64 bits n'était disponible, donc le retour au 32 bits était à l'ordre du jour.
Fortyrunner

11

Oui à la première question et non à la deuxième question; c'est une machine virtuelle. Vos problèmes sont probablement liés à des changements non spécifiés dans l'implémentation de la bibliothèque entre les versions. Bien que cela puisse être, par exemple, une condition de course.

Il y a des obstacles que la VM doit franchir. Notamment, les références sont traitées dans les fichiers de classe comme si elles occupaient le même espace que ints sur la pile. doubleet longoccupez deux emplacements de référence. Par exemple, les champs, il y a de toute façon un réarrangement de la VM. Tout cela est fait (relativement) de manière transparente.

Certaines JVM 64 bits utilisent également des "oops compressés". Parce que les données sont alignées à environ tous les 8 ou 16 octets, trois ou quatre bits de l'adresse sont inutiles (bien qu'un bit de «marque» puisse être volé pour certains algorithmes). Cela permet aux données d'adresse 32 bits (utilisant donc deux fois moins de bande passante, et donc plus rapide) d'utiliser des tailles de tas de 35 ou 36 bits sur une plate-forme 64 bits.


3
Tu me surprends. Je ne pensais pas qu'il existait un code d'octet 32 ​​bits ou un code d'octet 64 bits.
Jon Skeet

3
Relisez votre réponse - êtes-vous sûr que vous ne l'avez pas simplement voulu dire dans l'autre sens? (Oui puis non.)
Jon Skeet

+1 à Jon Skeet. J'écrivais le même commentaire mais j'ai été rappelé.
Michael Myers

Je voulais dire non alors oui, mais avec les questions dans l'autre sens. Avoir annulé une édition et édité (et mis un peu plus d'informations).
Tom Hawtin - tackline

4
@Jon Skeet: il n'y a pas de bytecode 32 bits et 64 bits, mais lorsque JITed les pointeurs dans la JVM sont (généralement) 32 ou 64 bits, selon la plate-forme. Et avec OOPS compressé, ils peuvent utiliser des pointeurs 32 bits dans de nombreux endroits, même sur des JVM 64 bits. Cela économise un peu de mémoire et augmente la localité du code, conduisant ainsi à une plus grande vitesse.
Joachim Sauer

9

Tout le code d'octet est basé sur 8 bits. (C'est pourquoi on l'appelle code BYTE) Toutes les instructions sont un multiple de 8 bits. Nous développons sur des machines 32 bits et exécutons nos serveurs avec une JVM 64 bits.

Pourriez-vous donner des détails sur le problème auquel vous êtes confronté? Ensuite, nous pourrions avoir une chance de vous aider. Sinon, nous devinerions simplement quel est le problème que vous rencontrez.


8

Sauf si vous avez un code natif (code machine compilé pour une arcitechture spécifique), votre code fonctionnera aussi bien dans une JVM 32 bits et 64 bits.

Notez, cependant, qu'en raison des adresses plus grandes (32 bits correspond à 4 octets, 64 bits à 8 octets), une JVM 64 bits nécessitera plus de mémoire qu'une JVM 32 bits pour la même tâche.


Notez également qu'une JVM 32 bits sur un système 64 bits peut avoir plus de mémoire disponible qu'une JVM 32 bits sur un système 32 bits, donc cela peut être une option intéressante si vous avez un "utiliser quelques Go de mémoire "application.
Thorbjørn Ravn Andersen

3

La différence 32 bits vs 64 bits devient plus importante lorsque vous vous connectez avec des bibliothèques natives. Java 64 bits ne pourra pas s'interfacer avec une dll non Java 32 bits (via JNI)


5
Vous n'avez rien fourni de nouveau sur cette très ancienne question.
Austin Henley


0

Le Java JNI nécessite des bibliothèques OS de la même "bittiness" que la JVM. Si vous essayez de construire quelque chose qui dépend, par exemple, de IESHIMS.DLL (vit dans% ProgramFiles% \ Internet Explorer), vous devez prendre la version 32 bits lorsque votre JVM est 32 bits, la version 64 bits lorsque votre JVM est 64 bits. De même pour les autres plateformes.

En dehors de cela, vous devriez être prêt. Le bytecode Java généré s / b est le même.

Notez que vous devez utiliser le compilateur Java 64 bits pour les projets plus volumineux car il peut adresser plus de mémoire.


-5

yo où mal! Sur ce thème, j'ai écrit une question à oracle. La réponse était.

"Si vous compilez votre code sur une machine 32 bits, votre code ne doit s'exécuter que sur un processeur 32 bits. Si vous souhaitez exécuter votre code sur une machine JVM 64 bits, vous devez compiler vos fichiers de classe sur une machine 64 bits en utilisant un 64 bits -Bit JDK. "


5
Le format de code d'octet dans lequel le code Java est généralement compilé est le même quelle que soit la plate-forme 32 bits ou 64 bits. Les règles sont différentes pour tout code natif mais le code d'octet Java est portable.
McDowell

4
Ouais, on dirait que quiconque chez Oracle a répondu à votre question l'a mal compris ou ne savait rien de la JVM.
Paŭlo Ebermann
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.