miércoles, 30 de noviembre de 2011

"HotRockit". La convergencia entre las JVMs Hotspot (Sun) y JRockit (Oracle-Bea)

Por fin se empiezan a ver los resultados de la cacareada convergencia entre las máquinas virtuales Hotspot y JRockit...

Aunque de momento sólo tengamos poco más que el audio y las slides de la JavaOne 2011sobre las "líneas generales" de la convergencia:
What to Expect from HotRockit, by Marcus Hirt

  • ¿Se acabó el espacio permanene "permgen"? ¿en serio? (sólo por este dolor de cabeza de Hotspot merece la pena la fusión :-)
  • ¿"Flight Recorder" para viajar atrás en el tiempo y ver qué causó una incidencia?
  • ...

martes, 31 de mayo de 2011

lunes, 30 de mayo de 2011

Mucho cuidado con @Singleton

Me permito referenciar, como nota mental, el siguiente post de Adam Bien:

@SINGLETON - THE PERFECT CACHE FACADE

Donde avisa de:
@Singleton in the default configuration is the perfect bottleneck (...) The annotation @ConcurrencyManagement(BEAN) deactivates this limitation (...)

Para más información, ver el resto del post referenciado y el see also que marca.

miércoles, 27 de abril de 2011

Actualización del post "Tuning de NetBeans 7.x y 6.x"

Actualizado el post Tuning de NetBeans 7.x y 6.x, al que incluso le he cambiado el nombre.

Lo más importante (y lo dejo aquí para mi propio recuerdo):

Mi fichero netbeans.conf contiene las siguientes opciones de lanzamiento:
###[serverperformance.blogspot.com]
netbeans_default_options="-J-Dcom.sun.aas.installRoot=\"C:\Java\glassfish-v2ur2\" -J-client -J-Xss2m -J-Xms32m -J-XX:PermSize=32m -J-XX:MaxPermSize=500m -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled -J-Djava.index.useMemCache=true -J-Xverify:none -J-XX:+UseBiasedLocking -J-XX:+AggressiveOpts -J-Djava.net.preferIPv4Stack=true -J-Dsun.java2d.d3d=true -J-Dsun.java2d.noddraw=false -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true "

domingo, 24 de abril de 2011

Tiered compilation en Hotspot 20 (Java 6u25)

Mientras seguimos esperando el cierre de versión de Java 7 (las listas de correo andan ardiendo estas últimas semanas, pero aún tardará), hace unos días salió Java 6 Update 25, donde por fin se incluye Hotspot 20. Aparte de que está también recién horneado Netbeans 7.0 (yo llevaba tiempo trabajando con las release candidates)...

A diferencia de los últimos updates, este sí promete mejoras de rendimiento, aunque la mala noticia es que el G1 (Garbage First) continúa en modo experimental... pero la buena noticia es que parece que la tiered compilation por fin parece que funciona, ¿habrá llegado el esperado maná, lo mejor de los dos mundos (-client y -server) en uno

Pego algunos extractos de las releases notes:

(...)

Java Hotspot VM 20
(...) contains improvements to performance, reliability and diagnostic information.

A new feature in this version of HotSpot is "tiered" compilation in the Server VM that enables it to start quickly as does the Client VM, while achieving superior peak performance. This feature is enabled by specifying -server and -XX:+TieredCompilation command options.

The Garbage First (G1) garbage collector continues to advance with Java SE 6u25, although it remains an experimental option.

HotSpot diagnostic information has been expanded in several ways (...)

Performance Improvement to BigDecimal
Improvements have been made to class BigDecimal enhancing its performance by thirty percent. BigDecimal is enabled by specifying -XX:+AggressiveOpts command option.

Performance Improvement to java.util.logging.LogRecord
The performance of the class java.util.logging.LogRecord has been enhanced. This enhancement improves the efficiency of including source class and method names in java.util.logging log records.

(...)


Y más información sobre "tiered compilation", por el ínclito Remí Forax, en http://weblogs.java.net/blog/forax/archive/2010/09/05/tiered-compilation, de donde me permito extraer:
"Tiered compilation in hotspot is an old dream. Hotspot has two JITs named c1 aka client JIT and c2 aka server JIT. The client JIT starts fast but provides less optimizations so it is used for GUI application. The server JIT starts more slowly but provide very good optimizations.
The idea of tiered compilation is to get the best of both compilers, first JITs the code with c1 and then if the code is really hot to recompile it with c2."


Obviamente en ejecuciones a largo plazo el "tiered compilation" no supone mejora general, pero sí durante los primeros minutos. He probado (como mera prueba) el arranque de Netbeans con -server -XX:+TieredCompilation y el rendimiento se aproxima a -client (al menos es infinitamente mejor que con -server), aunque a cada cosa lo suyo, para aplicaciones gráficas y applets, seguirá siendo mejor el compilador cliente (por ahora, quizás algún día deje de existir la doble opción)

Recopilando algunas de las últimas recomendaciones para aplicaciones servidor en arquitecturas de 64 bits que soporten NUMA, recomiendo probar estas opciones de arranque (con Java 6 u25 / Hotspot 20):

-server -XX:+TieredCompilation -XX:+UseCompressedOops -XX:+UseNUMA -XX:+UseParallelOldGC -Xverify:none -XX:+UseBiasedLocking -XX:+AggressiveOpts -Djava.net.preferIPv4Stack=true (aparte de los valores adecuados a cada caso para -Xms -Xmx -Xss -XX:PermSize -XX:MaxPermSize)

martes, 8 de febrero de 2011

-XX:+UseNUMA

Creo que desde Hotspot 17, al menos, está disponible esta opción (ahora vamos por Hotspot 19 con el JDK 1.6.0_23). Para mejorar el rendimiento de la recolección de basura en arquitecturas multicore, lo que según Sun-Oracle supone en total hasta una mejora de entre un 30 y un 40% en SPEC JBB 2005.

¿Pero qué es NUMA? Pues ala, a verlo en la wikipedia: http://es.wikipedia.org/wiki/NUMA.

En http://download.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#numa puede verse un resumen de la utilidad de esta opción en combinación con -XX:+UseParallelGC (o -XX:+UseParallelOldGC):


NUMA Collector Enhancements

The Parallel Scavenger garbage collector has been extended to take advantage of the machines with NUMA (Non Uniform Memory Access) architecture. Most modern computers are based on NUMA architecture, in which it takes a different amount of time to access different parts of memory. Typically, every processor in the system has a local memory that provides low access latency and high bandwidth, and remote memory that is considerably slower to access.

In the Java HotSpot Virtual Machine, the NUMA-aware allocator has been implemented to take advantage of such systems and provide automatic memory placement optimizations for Java applications. The allocator controls the eden space of the young generation of the heap, where most of the new objects are created. The allocator divides the space into regions each of which is placed in the memory of a specific node. The allocator relies on a hypothesis that a thread that allocates the object will be the most likely to use the object. To ensure the fastest access to the new object, the allocator places it in the region local to the allocating thread. The regions can be dynamically resized to reflect the allocation rate of the application threads running on different nodes. That makes it possible to increase performance even of single-threaded applications. In addition, "from" and "to" survivor spaces of the young generation, the old generation, and the permanent generation have page interleaving turned on for them. This ensures that all threads have equal access latencies to these spaces on average.

The NUMA-aware allocator is available on the Solaris™ operating system starting in Solaris 9 12/02 and on the Linux operating system starting in Linux kernel 2.6.19 and glibc 2.6.1.

The NUMA-aware allocator can be turned on with the -XX:+UseNUMA flag in conjunction with the selection of the Parallel Scavenger garbage collector. The Parallel Scavenger garbage collector is the default for a server-class machine. The Parallel Scavenger garbage collector can also be turned on explicitly by specifying the -XX:+UseParallelGC option.

NUMA Performance Metrics

When evaluated against the SPEC JBB 2005 benchmark on an 8-chip Opteron machine, NUMA-aware systems showed the following performance increases:

  • 32 bit – About 30 percent increase in performance with NUMA-aware allocator
  • 64 bit – About 40 percent increase in performance with NUMA-aware allocator

¡¡¡Lástima que con el kernel 2.6.18 (que es el de mis sistemas de producción) no se soporta!!!

Sin haber hecho pruebas, estoy convencido en que en aplicaciones servidor (que efectivamente cumplen el patrón típico de toneladas de objetos creados y consumidos únicamente por el mismo thread) la ganancia será palpable en casi todos los escenarios, o cuando menos inocuo. Probablemente en algunas situaciones, sin embargo, sea peor el remedio que la enfermedad...