Image: Copyright Oracle Corporation
La Java Virtual Machine, HotSpot, posee una amplia variedad de Flags que modifican su configuración, comportamiento y rendimiento. Comúnmente nos llega la ocación, ya sea por requerimiento de un software o por necesidades propias, de hacer ajustes comúnes como el caso del tamaño del heap y perm geneneration (-Xmx , -Xms, PermSize, MaxPerSizerespectivamente). Sin embargo los expertos indican que muchos de los problemas de performance se deben a la lógica de programación de la aplicación, malas prácticas y defectos de diseño que al final se ven reflejados en la JVM. «Modifique estos Flags si y solo sí usted sabe lo que está haciendo» es una de las frases que en conferencias y documentación se enfatizan frecuentemente en lo que respecta a performance tuning de aplicaciones Java».
Hace algún tiempo encontré una gráfica que Alex Ragozin compartió en donde se muestran visualmente las flags categorizadas por su tipo. Recientemente encontré otro listado que categoriza las flags por uso (diagnóstico, producción, desarrollo, etc). Hoy Kirk Pepperdine (@kcpeppe) ha publicado en su blog de java.net un excelente Caso de Estudio sobre el uso de Flags de la JVM que nuevamente llama a la reflexión de que las bondades que ofrece Hotspot en cuanto a configuración es una espada de doble filo y que se debe de saber lo que se hace antes de empezar a «probar» realizar modificaciones. Recuerden, es mejor hacer un proceso de sanidad del código fuente y diseño antes de empezar a culpar a Generics por un mal performance.
En otro post comentaré acerca de los tipos de colectores y la evolución que estos han tenido dado que G1 sigue tomando protagonismo en lo que a Algoritmos de Recolección de la JVM se refiere. Lo cual nos va a hacer replantear nuestros viejos trucos bajo la manga que hasta el momento han sido documentados 🙂 en cuanto a Performance Tuning en aplicaciones Java se refiere.
