Compatibilidad con Java de 32 bits frente a 64 bits

97

¿Funcionará el código Java creado y compilado con un JDK de 32 bits en un código de bytes de 32 bits en una JVM de 64 bits? ¿O una JVM de 64 bits requiere un código de bytes de 64 bits?

Para dar un poco más de detalle, tengo un código que funcionaba en un entorno Solaris con una JVM de 32 bits, pero ahora tengo problemas después de actualizar JDK y Weblogic Server a 64 bits.

java jvm 64-bit compatibility 32-bit mshafrir
fuente
3
por favor aclare "problemas".
Thorbjørn Ravn Andersen
Tengo un problema similar: implementar una aplicación Spring en un servidor weblogic de 64 bits. Obtenemos varias excepciones de clases no encontradas y otros errores inútiles. Además, se implementa y se ejecuta en algunas máquinas de 64 bits, pero no en otras. Sin embargo, no podemos decir qué es diferente. ¿Resolviste esto?
hasta el
2
@nont: sea cual sea el problema, no es una compilación de 32vs64 bits.
Stephen C

Respuestas:

94

Sí, el código de bytes de Java (y el código fuente) es independiente de la plataforma, suponiendo que utilice bibliotecas independientes de la plataforma. 32 frente a 64 bits no deberían importar.

Zifre
fuente
Me encontré con esto mientras buscaba una pregunta que tenía. Entonces ejecuté mi aplicación en una JVM de 32 bits y usé una biblioteca nativa de 64 bits. Funcionó bien. Pero cuando ejecuto mi aplicación en una JVM de 64 bits y uso una biblioteca nativa de 32 bits, falla. ¿Cómo puede ser esto posible? Sólo curioso.
Umang Desai
6
Las bibliotecas nativas de @umangdesai no son bibliotecas independientes de la plataforma, por lo que la suposición no es válida.
Thorbjørn Ravn Andersen
¿"No debería importar" significa que el código compilado con 32 bits javacaprovechará la memoria disponible con 64 bits java?
Marcus Junius Brutus
1
Si le molesta esto, tenga cuidado con las bibliotecas nativas que se han empaquetado en un frasco que funcionan para una plataforma, pero no para la que le da problemas. (Si no tiene idea de a qué me refiero, vea cosas como esta: stackoverflow.com/a/14051512/155631 ).
Matt S.
21

Ejecuté accidentalmente nuestra aplicación (más grande) en una máquina virtual de 64 bits en lugar de una máquina virtual de 32 bits y no me di cuenta hasta que algunas bibliotecas externas (llamadas por JNI) comenzaron a fallar.

Los datos serializados en una plataforma de 32 bits se leyeron en la plataforma de 64 bits sin ningún problema.

¿Qué tipo de problemas tienes? ¿Funcionan algunas cosas y otras no? ¿Ha intentado conectar JConsole, etc. y tiene un pico alrededor?

Si tiene una máquina virtual muy grande, es posible que los problemas de GC en 64 bits puedan afectarlo.

Fortyrunner
fuente
1
¿Está diciendo que las bibliotecas JNI no funcionarán en una máquina virtual de 64 bits si son de 32 bits?
C. Ross
1
No funcionan. Un colega había informado que sí (lo que me pareció sospechoso, por decir lo menos). Me pregunté si se estaba ejecutando en Solaris y si se estaba produciendo algún tipo de golpe. No lo había; estaba equivocado y se estaba ejecutando por debajo de 32 bits.
Fortyrunner
Tuve un problema similar con una biblioteca JNI. No hubo compatibilidad entre las bibliotecas de 32 y 64 bits.
Erick Robertson
De hecho, sus bibliotecas JNI deben reemplazarse. Probablemente pueda descargar la alternativa de 64 bits desde el sitio web del proveedor. (Eso funcionó para mí, para todas las librerías JNI que usé).
bvdb
Estas eran bibliotecas internas y no había ningún equivalente de 64 bits disponible, por lo que volver a 32 bits estaba a la orden del día ..
Fortyrunner
11

Sí a la primera pregunta y no a la segunda pregunta; es una máquina virtual. Sus problemas probablemente estén relacionados con cambios no especificados en la implementación de la biblioteca entre versiones. Aunque podría ser, digamos, una condición de carrera.

Hay algunos obstáculos por los que tiene que pasar la VM. En particular, las referencias se tratan en los archivos de clases como si ocuparan el mismo espacio que ints en la pila. doubley longocupa dos espacios de referencia. Por ejemplo, en los campos, hay una reordenación por la que normalmente pasa la VM de todos modos. Todo esto se hace (relativamente) de forma transparente.

Además, algunas JVM de 64 bits utilizan "oops comprimidos". Debido a que los datos se alinean aproximadamente cada 8 o 16 bytes, tres o cuatro bits de la dirección son inútiles (aunque se puede robar un bit de "marca" para algunos algoritmos). Esto permite que los datos de direcciones de 32 bits (por lo tanto, usan la mitad de ancho de banda y, por lo tanto, más rápido) utilicen tamaños de pila de 35 o 36 bits en una plataforma de 64 bits.

Tom Hawtin - tackline
fuente
3
Me sorprendes. No pensé que existiera un código de bytes de 32 bits o un código de bytes de 64 bits.
Jon Skeet
3
Releyendo tu respuesta, ¿estás seguro de que no lo dijiste al revés? (Sí, luego no)
Jon Skeet
+1 a Jon Skeet. Estaba escribiendo el mismo comentario pero me llamaron.
Michael Myers
Quise decir no, entonces sí, pero con las preguntas al revés. He revertido una edición y editado (y puesto un poco más de información).
Tom Hawtin - tackline
4
@Jon Skeet: no hay código de bytes de 32 y 64 bits, pero cuando se utiliza JIT, los punteros en la JVM son (normalmente) de 32 o 64 bits, según la plataforma. Y con Compressed OOPS pueden usar punteros de 32 bits en muchos lugares, incluso en JVM de 64 bits. Eso ahorra bastante memoria y aumenta la localidad del código, lo que conduce a una mayor velocidad.
Joachim Sauer
9

Todo el código de bytes se basa en 8 bits. (Por eso se llama código BYTE) Todas las instrucciones son múltiplos de 8 bits de tamaño. Desarrollamos en máquinas de 32 bits y ejecutamos nuestros servidores con JVM de 64 bits.

¿Podría darnos algún detalle del problema al que se enfrenta? Entonces podríamos tener la oportunidad de ayudarlo. De lo contrario, estaríamos adivinando cuál es el problema que tiene.

Peter Lawrey
fuente
8

A menos que tenga un código nativo (código de máquina compilado para una arcitechture específica), su código se ejecutará igualmente bien en una JVM de 32 y 64 bits.

Sin embargo, tenga en cuenta que debido a las direcciones más grandes (32 bits son 4 bytes, 64 bits son 8 bytes), una JVM de 64 bits requerirá más memoria que una JVM de 32 bits para la misma tarea.

Thorbjørn Ravn Andersen
fuente
También tenga en cuenta que una JVM de 32 bits en un sistema de 64 bits puede tener más memoria disponible que una JVM de 32 bits en un sistema de 32 bits, por lo que podría ser una opción interesante si tiene un "uso de algunos GB de memoria " solicitud.
Thorbjørn Ravn Andersen
3

La diferencia de 32 bits frente a 64 bits se vuelve más importante cuando se interactúa con bibliotecas nativas. Java de 64 bits no podrá interactuar con una dll que no sea de Java de 32 bits (a través de JNI)

John Thomas
fuente
5
No proporcionó nada nuevo a esta pregunta tan antigua.
Austin Henley
0

La JNI de Java requiere bibliotecas de SO del mismo "bittiness" que la JVM. Si intenta crear algo que dependa, por ejemplo, de IESHIMS.DLL (vive en% ProgramFiles% \ Internet Explorer), debe tomar la versión de 32 bits cuando su JVM es de 32 bits, la versión de 64 bits cuando su JVM es de 64 bits. Lo mismo ocurre con otras plataformas.

Aparte de eso, deberías estar listo. El código de bytes Java generado es el mismo.

Tenga en cuenta que debe usar el compilador Java de 64 bits para proyectos más grandes porque puede utilizar más memoria.

thecarpy
fuente
-5

yo donde esta mal! A este tema le escribí una pregunta a Oracle. La respuesta fue.

"Si compila su código en una máquina de 32 bits, su código solo debe ejecutarse en un procesador de 32 bits. Si desea ejecutar su código en una JVM de 64 bits, debe compilar sus archivos de clase en una máquina de 64 bits utilizando una -Bit JDK ".

elayer
fuente
5
El formato de código de bytes en el que se suele compilar el código Java es el mismo independientemente de las plataformas de 32 bits o 64 bits. Las reglas son diferentes para cualquier código nativo, pero el código de bytes de Java es portátil.
McDowell
4
Sí, parece que quienquiera que respondiera a su pregunta en Oracle la entendió mal o no sabía nada sobre la JVM.
Paŭlo Ebermann