Compatibilidad con Java de 32 bits vs 64 bits

Accidentalmente ejecuté nuestra aplicación (grande) en una VM de 64 bits en lugar de una VM 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? ¿Algunas cosas funcionan y otras no? ¿Ha intentado conectar JConsole, etc. y tiene un pico alrededor?

Si tiene una máquina virtual muy grande, puede encontrar que los problemas de GC en 64 bits puede afectarte.

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 bibliotecas entre versiones. Aunque podría ser, digamos, una condición de carrera.

Hay algunos aros que la VM tiene que pasar. Notablemente las referencias son tratadas en archivos de clase como si tomaran el mismo espacio que ints en la pila. double y long ocupan dos ranuras de referencia. Por ejemplo, los campos, hay algún reordenamiento de la VM normalmente pasa de todos modos. Todo esto se hace (relativamente) de manera transparente.

También algunas JVM de 64 bits usan "compressed oops". Debido a que los datos están alineados a alrededor de cada 8 o 16 bytes, tres o cuatro bits de la dirección son inútiles (aunque un bit de "marca" puede ser robado para algunos algoritmos). Esto permite que los datos de direcciones de 32 bits (por lo tanto usando 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.

Todo el código de bytes está basado en 8 bits. (Es por eso que se llama código de BYTES) Todas las instrucciones son un múltiplo de 8 bits de tamaño. Desarrollamos en máquinas de 32 bits y ejecutamos nuestros servidores con JVM de 64 bits.

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

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

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

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

Agregue un parámetro como se muestra a continuación en la configuración mientras crea el exe

Http://www.technimi.com/index.php?do=/group/java/forum/building-an-exe-using-launch4j-for-32-bit-jvm/

Espero que ayude.

Gracias...

/ jav

El JNI Java requiere bibliotecas de SO de la misma "bittiness" que la JVM. Si intenta construir algo que depende, por ejemplo, de IESHIMS.DLL (vive en %ProgramFiles%\ Internet Explorer) necesita 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 para otras plataformas.

Aparte de eso, deberías estar listo. El bytecode Java generado s / b es el mismo.

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

Yo donde 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 un JDK de 64 Bits."