saber - java runtime environment
32 O 64 BIT para la JVM? (8)
Es más una cuestión de rendimiento general. Si tiene un procesador de 64 bits reciente y un montón de memoria no utilizada, la única ganancia posible al usar JVM 32 en lugar de JVM 64 sería que algunos bucles podrían caber completamente en la caché con direcciones de 32 bits y no con 64 bits, lo que lleva a menos memoria principal Accesos con una JVM de 32 bits. Realmente no puedo evaluar la ganancia, pero, salvo en casos muy especiales, dudo que alcance entre el 5 y el 20%. Tenga en cuenta que solo dudo, no estoy seguro ...
Pero si está utilizando un sistema de recursos limitados, eventualmente porque desea optimizar su hardware y ejecutar muchas máquinas virtuales en él, una JVM de 32 bits usará mucha menos memoria que una de 64 bits. Dejará más memoria libre para otras aplicaciones y para el sistema, evitando así el intercambio y permitiendo que el sistema almacene en caché mejor la E / S del disco.
En mi humilde opinión, no hay una regla general. Simplemente usaría la siguiente regla de oro: si cuando se ejecutan la JVM y todas las demás aplicaciones , el sistema todavía tiene suficiente memoria para almacenar en caché la E / S, usaría una JVM de 64 bits y una de 32 bits en el caso opuesto.
Por supuesto, lo anterior solo tiene sentido si la aplicación Java por sí sola no necesita una gran cantidad de memoria que impone el uso de una JVM de 64 bits, y finalmente agrega más memoria al sistema si es necesario, porque la memoria no es tan cara hoy en día
Mientras leía este libro por here .
Puedo ver la siguiente sección, que dice:
32 O 64 BIT? Si tiene un sistema operativo de 32 bits, entonces debe usar una versión de 32 bits de la JVM. Si tiene un sistema operativo de 64 bits, puede optar por utilizar la versión de Java de 32 o 64 bits. No asuma que solo porque tiene un sistema operativo de 64 bits, también debe usar una versión de Java de 64 bits.
Si el tamaño de su montón será inferior a unos 3 GB, la versión de Java de 32 bits será más rápida y tendrá una huella más pequeña. Esto se debe a que las referencias de memoria dentro de la JVM solo serán de 32 bits, y manipular esas referencias es menos costoso que manipular las referencias de 64 bits (incluso si tiene una CPU de 64 bits). Las referencias de 32 bits también usan menos memoria.
El Capítulo 8 trata sobre los Oops comprimidos, que es una forma en que la JVM puede usar direcciones de 32 bits incluso dentro de la JVM de 64 bits. Sin embargo, incluso con esa optimización, la JVM de 64 bits tendrá una huella más grande porque el código nativo que utiliza todavía tendrá direcciones de 64 bits.
La desventaja de la JVM de 32 bits es que el tamaño total del proceso debe ser inferior a 4 GB (3 GB en algunas versiones de Windows y 3,5 GB en algunas versiones antiguas de Linux). Eso incluye el montón, el permgen y el código nativo y la memoria nativa que usa la JVM. Los programas que hacen uso extensivo de variables largas o dobles serán más lentos en una JVM de 32 bits porque no pueden usar los registros de 64 bits de la CPU, aunque este es un caso muy excepcional.
Los programas que caben dentro de un espacio de direcciones de 32 bits se ejecutarán en cualquier lugar entre un 5% y un 20% más rápido en una JVM de 32 bits que en una JVM de 64 bits configurada de manera similar. El programa de procesamiento por lotes de acciones descrito anteriormente en este capítulo, por ejemplo, es un 20% más rápido cuando se ejecuta en una JVM de 32 bits en mi escritorio.
Las líneas dicen que 32 bits será más rápido para un tamaño de pila menor (menos de 3 GB). Si esto es cierto, quiero saber la razón detrás de esto, ¿qué hace que la JVM de 32 bits sea más rápida?
La dirección de 32 bits menos espacio de memoria máximo límite teórico es de 4 GB, pero en la práctica es de 1,3 GB en el sistema de Windows. Puede abordar algunos más (300 a 400 MB) más en el kernel de Linux. Para obtener más detalles, utilice http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit (memoria de espacio de almacenamiento dinámico)
El 64bit utiliza bits más altos para direccionar. Por lo tanto, el consumo total de memoria también es mayor. Hay opción de usar el puntero de la memoria comprimida. Lea más sobre el mismo en http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#compressedOop
La razón por la que 64 bits es más lento es debido a las grandes pausas de recolección de basura. Construir más pilas significa que hay más trabajo que hacer por GC mientras lo limpia de los objetos no utilizados. Lo que significa en la vida real es que debes tener mucho cuidado cuando construyas montones de más de 12-16GB. Sin un ajuste y medición precisos, puede introducir fácilmente pausas completas de GC que duran varios minutos.
Las direcciones de memoria de 32 bits son más pequeñas. Eso solo probablemente conduce a un mejor almacenamiento en caché, localidad de referencia, etc.
No hay una respuesta simple y lo mejor que puede hacer es probarlo para su aplicación específica. Pero debe tener en cuenta que existen muchas otras opciones, por ejemplo, en relación con JIT, el algoritmo de recolección de basura, los límites de RAM, que podrían tener un impacto mayor que la elección de la arquitectura, por lo que debe incluirlos en sus mediciones.
Si alguna vez hace esa pregunta, en otras palabras, tiene la opción , implica que ya está ejecutando un sistema de 64 bits con un modo de 32 bits (con un rendimiento aceptable, es decir, sin emulación de software) que es muy probable que sea AMD64 también conocido como x86-64 .
En tales sistemas, la JVM de Oracle admite "oops comprimidos", lo que significa el uso de referencias de 32 bits dentro del montón de Java, siempre que el montón máximo no exceda los 32 GB (si lo hace, dudo que el uso de 32 bits sea una opción válida para esa aplicación) . Es posible que aún consuma más RAM en comparación con la JVM de 32 bits, ya que algunos componentes aún requieren el uso de punteros de 64 bits, pero generalmente estas no son las partes relevantes para el rendimiento de una aplicación.
Tenga en cuenta que para la arquitectura AMD64 aka x86-64, el uso del modo de 64 bits implica algo más que cambiar el tamaño del puntero. La nota solo le permite usar 64 bits por registro, también tiene más registros utilizables. Realmente es una arquitectura diferente implementada dentro del mismo chip y dependiendo de su aplicación, habilitarla puede ser una gran mejora.
Pero como se dijo, probarlo con su aplicación real es la única forma válida de obtener la respuesta correcta.
Si pretende utilizar una de las máquinas virtuales de Oracle, la pregunta se centra más en si desea utilizar el JIT del cliente o del servidor, ya que aún no hay un JIT del cliente disponible para ninguna CPU de 64 bits de Oracle.
Hay una VM de servidor disponible para CPU de 32 y 64 bits y las diferencias de rendimiento de las VM de servidor en las CPU x86 / AMD64 son bastante pequeñas (en mi experiencia es menos del +/- 5% en Windows o Linux), aunque el 64 bit Las máquinas virtuales suelen necesitar un 20% más de memoria.
Si su aplicación necesita un tamaño de memoria de pila de más de aproximadamente 1.3 GB, tendrá que usar una máquina virtual de servidor de 64 bits, ya que las máquinas virtuales de 32 bits de Oracle no comenzarán con tamaños de pila mayores que eso (en Linux el límite es ligeramente superior) .
La principal ventaja del JIT del cliente es que tiene un tiempo de inicio mucho más rápido. Puede realizar una gran cantidad de trabajo serio en menos de 100 ms con esta máquina virtual, mientras que la máquina virtual del servidor tarda más de un segundo en comenzar, incluso con la compilación por niveles activada. La máquina virtual cliente también necesita significativamente menos memoria que la máquina virtual del servidor y puede beneficiar el intercambio de datos de clase de formulario entre varias instancias de máquinas virtuales en la misma computadora.
La máquina virtual del servidor, por otro lado, tiende a ser capaz de ejecutar código de computación intensiva considerablemente más rápido. Las diferencias de rendimiento reales varían ampliamente según el código que ejecute, pero pueden estar entre alrededor de -10% y + 200%. Por lo general, es al menos un 30% más rápido para cualquier cosa que tarde más de unos pocos cientos de milisegundos en ejecutarse.
Puede ajustar ambos JIT con varias opciones para que se comporten de manera más similar, pero aún así obtiene el rápido tiempo de inicio solo con la máquina virtual del cliente y las velocidades de ejecución más altas solo con la máquina virtual del servidor.
Por lo tanto, recomiendo usar la VM del servidor de 64 bits para todo cuando tenga suficiente memoria disponible y no le importe la penalización del tiempo de inicio. La VM del cliente de 32 bits es ideal para aplicaciones de GUI más pequeñas, pero especialmente para herramientas de línea de comandos pequeñas que tardan menos de un segundo en ejecutarse en promedio o pueden necesitar ejecutarse varias veces al mismo tiempo en la misma computadora.
Soy escéptico ante la afirmación del autor de que el uso de la versión de 32 bits de la JVM dará una mejora de rendimiento del 5% al 20%. Sin embargo, no uso mucho Java, así que no estoy seguro. Pero para investigar estas afirmaciones miré algunos de los resultados de SPEC.
Busqué los resultados SPECjEnterprise2010 y la puntuación más alta para una arquitectura x86-64 fue un sistema Oracle que usaba una versión de 64 bits de la JVM .
También miré SPECjvm2008 en caso de que estas cargas de trabajo más pequeñas pudieran beneficiarse de la arquitectura de 32 bits. Pero nuevamente, el sistema x86-64 con mejor rendimiento, esta vez de Huawei, estaba usando la versión de 64 bits de la JVM.
Si la versión de 32 bits de la JVM realmente fuera mejor, esperaría que las personas que envían sus resultados SPEC lo hubieran seleccionado al ajustar sus cargas de trabajo (pero podría estar equivocado).
No dudo que haya algunas cargas de trabajo en las que la versión de 32 bits de la JVM superará a la versión de 64 bits. Como otros han señalado, utiliza más memoria para las direcciones. Sin embargo, la arquitectura x86-64 tiene más registros disponibles y sospecho que el modo de operación de 64 bits es donde se enfoca la mayor parte del trabajo de optimización.
El rendimiento del sistema tiene muchos componentes, y no creo que la versión de 32 bits de la JVM necesariamente supere a la versión de 64 bits (por un lado, esto solo será importante para las cargas de trabajo vinculadas a la CPU). Yo diría que si llegara a este punto en el proceso de ajuste de rendimiento, querría verificar su propia carga de trabajo para las dos opciones diferentes, y utilizar el resultado de sus propias pruebas para tomar una decisión en lugar de asumir que usar el 32 -bit es mejor que 64 bits debido a que se ahorra espacio de memoria para las direcciones como una regla de oro, porque hay otros factores que podrían ser más importantes que esto.
Un argumento a favor de 64 bits es que el hardware del servidor de 32 bits es bastante raro en estos días. Como consecuencia, no hay mucha gente que use software de 32 bits en los servidores. La razón principal por la que aún existe el jvms de 32 bits es que sea compatible con el software de cliente de 32 bits para sistemas más antiguos de 32 bits, así como con applets, que se ejecutan a través de un complemento en navegadores de 32 bits.
Por lo tanto, si hay errores exóticos que acechan en la versión de 32 bits, puede ser el primero en descubrirlo. Estos serían el tipo de errores que serían menos visibles en los sistemas de escritorio y más visibles en el software del lado del servidor de larga ejecución. Piensa en choques misteriosos después de unas pocas semanas / días. Fugas de memoria, etc.
Por lo tanto, si está implementando en un servidor, prácticamente vaya a 64 bits a menos que tenga una razón muy fuerte para no hacerlo. Hay muchas soluciones de snakeoil flotando alrededor del uso de memoria y recolección de basura de Java. Por lo tanto, desconfiaría de usar eso como un argumento de cualquier manera, a menos que pueda respaldarlo con algunas métricas sólidas. En mi experiencia, los ingenieros de java que saben cómo ajustar correctamente un jvm son en realidad bastante raros y la mayoría parece simplemente copiar aleatoriamente cosas de pegar en el JVM_ARGS hasta que funciona. La mayoría de ellos terminan disparándose en el pie con soluciones que no son óptimas, que ya no son apropiadas para la JVM que usan o que son dañinas. Jvm tuning es un poco de un arte negro. Mejor no ensuciar demasiado con él a menos que sepa lo que está haciendo.
Para los sistemas cliente, vaya a 32 bits si necesita admitir applets o sistemas de escritorio más antiguos. Por ejemplo, Windows lanzó versiones de 32 bits de su sistema operativo hasta hace poco y muchas aplicaciones en Windows y OSX siguen siendo de 32 bits. Principalmente, no debería tener que elegir y, en cualquier caso, puede dejar esta opción al usuario.
Para las personas preocupadas por el tamaño de la dirección, la versión de 64 bits puede hacer compresión de puntero para montones de menos de 32 GB. -XX:+UseCompressedOops. (y probablemente desee) activar esto en los -XX:+UseCompressedOops. la JVM: -XX:+UseCompressedOops. .