¿Y qué ha pasado durante estos 21 días? ¿Realmente ha ocurrido algo que merezca la pena? Cuando llegué a casa, me sentí como un viajero del tiempo venido del pasado. Utilizando los correos, twitter y alguna página web, he conseguido hacerme una idea de que ha sucedido durante mi viaje. Si tienes interés por saber qué es lo que más me llamó la atención como recién llegado, sigue leyendo. Es un artículo largo, pero ¿qué queréis? He estado 21 días callado.

EL MUNDO EN GENERAL

Salí de España con un Gobierno y, a la vuelta, me he encontrado con otro. Creo que, como siempre, ha habido acalorados debates entre partidarios y detractores, pero a mí -debe ser que no entiendo mucho de política- me parece que todo ha cambiado para seguir siendo lo mismo.

Hablando de cosas más serias, Fernando Alonso dio un golpe de mano al mundial de Fórmula 1 gracias a su pericia y a la suerte. Lo curioso del caso es que, mucho antes de enterarme del resultado del Gran Premio de Korea, soñé que ocurría exactamente lo mismo. A lo mejor debo empezar a hacer más caso a mis sueños y perseguirlos…

El New York Times, dedicó a mi país un articulazo completo donde denunciaba el abuso que cometen los bancos con las hipotecas en España. No pueden entender los americanos como los bancos podían concedernos hipotecas con la casa como valor que asegure el préstamo y, en el caso de que no podamos pagarlo, tener derecho a venderla por la mitad del valor del préstamo -ojo, no de la casa- y obligarnos a pagar la otra mitad. Parece ser que, en Estados Unidos, si no puedes pagar tu hipoteca entregas las llaves de la casa y a empezar de nuevo. Tiene sentido. El banco se queda con lo que estimó como garantía suficiente para concederte el préstamo. El artículo me recordó lo bueno que es replantearse si las cosas deben ser como son o son como son porque lo hemos permitido.

LA INFORMÁTICA EN PARTICULAR

Parece ser que hemos vivido un APOCALIPSIS en el mundo del desarrollo. Apple ha anunciado que va a dejar de implementar por su cuenta las distintas especificaciones de Java y, según algunos, eso quiere decir que todos los que disfrutamos de un Mac tenemos, o bien que cambiar de lenguaje de programación o bien tirar nuestros ordenadores.

Yo, por si acaso, voy a guardar el mío, no sea que a Oracle le dé por sacar JREs para Mac. Más que nada por la pereza de tener que cambiar el eslogan de compile once run everywhere. Digo yo que, ya que se ponen, a lo mejor proporcionan un JDK y todo. Si no lo hacen, que avisen. Me imagino que habrá muchas compañías dispuestas a disputarse el pastel que representan los desarrolladores java sobre plataforma Mac.

Importante el movimiento hacia la oficialidad y la profesionalización de Francesco Cirillo y su Técnica Pomodoro a través de PomodoroWorld. Ahora resulta que, para dar cursos oficiales de la técnica, tengo que pasar por caja y hacerme Pomodoro Master (no es broma) y luego Pomodoro Trainer. Espero que todo esto no acabe tan mal como el tema de las certificaciones y la Scrum Alliance que ha denunciado Tobias Mayer.

También tenemos nueva versión de JIRA y que la gente de Atlassian ha salido de compras y se ha hecho con Bitbucket, un hosting de proyectos gestionados con Mercurial. Cada vez avanzan más en su objetivo de proporcionar todas las herramientas que un grupo de desarrollo pueda necesitar. Cada vez cuesta más reconocer a los chicos que empezaron en un pequeño taller de Melbourne.

MI MUNDO EN ESPECIAL

En mi entorno más cercano también han ocurrido cosas. Compruebo con satisfacción que los amiguetes no paran y siguen haciendo cosas, motivándonos a los demás para que les sigamos. Los chavalotes de Linking Paths se curraron la interesante Care of me en 48 horas. Las bestias pardas de Jobsket ganaron el premio Innova-g a “Mejor desarrollo 2.0″ y seguro que no será el último. Y, encima… ¡bola extra! Por fin se desveló el destino del amigo Jorge Jiménez, más conocido como @semurat: otro portal/aplicación de empleo llamado Wiseri ¿otro? NO, este promete ser “algo más“. Perfecto, está claro que, si alguna vez busco trabajo, tendré claro a qué puertas llamar primero :)

Más gente que hace cosas: como anunció un camarada en este mismo blog, se confirma la celebración del primer Ignite en León. Para los que no sepáis qué es eso de Ignite, deciros que los madrileños no hemos sido capaces de organizar uno y han tenido que venir desde León a enseñarnos cómo se hace, así que kudos para ellos.

También comprobé que soy realmente un tío importante. Al menos, lo suficiente como para que a un abogado alemán, Tobias Knieper, le merezca la pena escribirme un correo en el que me exige que retire una foto de salsa de chile, en concreto ésta, de uno de mis artículos sobre la antes mencionada Técnica Pomodoro. La verdad es que no recuerdo ni de donde saqué la foto, pero estoy seguro que no comprobé la licencia de la misma. En la vida se me hubiera ocurrido que a nadie le pudiera molestar que adornara un artículo sobre gestión de tiempo y productividad. No te preocupes Tobias, mañana mismo retiraré la foto.

Y por supuesto… entramos en producción. Después de siete años trabajando en ERP S1 y unos  cuatro en STORETTO, hemos terminado el set completo de funcionalidades y lo hemos puesto en producción en todas las empresas del Grupo VARMA, al cual pertenecemos. Podríamos discutir si hubiéramos podido utilizar otras metodologías u otras tecnologías, pero no es el momento de eso, sino de mirar hacía atrás, comprobar todo lo que he aprendido en el camino y agradecer su esfuerzo y ayuda a todos los que me acompañaron. A los que están -un maravilloso atajo de apandadores de primer nivel- y a los que ya no están, pero de los que nunca nos olvidamos (David Gaviña, Alex aka Asertus, Ernesto Funes, Pablo Varasa, Luis Miguel de Sancho, Pepe, Mario… y muchos, muchos más). Gracias, muchas gracias.

MI CABEZA EN SINGULAR

Y por último, todo lo que ha pasado en mi cabezota. Hacía AÑOS que tenía ganas de hacer una pequeña pausa para reflexionar y he tenido que casarme e irme de luna de miel para conseguirlo.

Puede que sea porque me sienta liberado después de acabar lo que era mi responsabilidad directa en SIXSERVIX o por comenzar el proyecto más importante de mi vida, formar una familia con mi mujer, pero estoy seguro de que no soy la misma persona que era hace un mes.

Evidentemente, no creo que nadie pueda cambiar radicalmente en treinta días. Ha sido más bien un largo proceso de maduración que, sencillamente, ha concluido. He evolucionado. No sé si a algo mejor o peor, pero desde luego, a algo diferente. Paseando por una playa en Nueva Zelanda, me di cuenta de que ya estaba listo para asumirlo.

Así que, a partir de ahora, sin prisa pero si pausa, esperad cambios. Desde las cosas más pequeñas -como este blog- hasta las más importantes. Bonilla 3.0 también está a punto de entrar en producción.

]]> http://sixservix.com/blog/david/2010/11/05/21-dias/feed/ 518 http://sixservix.com/blog/david/2010/09/21/bonillatv-capitulo-4-esto-empieza/ http://sixservix.com/blog/david/2010/09/21/bonillatv-capitulo-4-esto-empieza/#comments Tue, 21 Sep 2010 14:46:25 +0000 David Bonilla http://sixservix.com/blog/david/?p=4541

No quiero caer en la típica actitud de plañidera de “es un viaje de trabajo. Me voy a dejar la piel y va a ser horrible“.

Me voy a San Francisco, una de las ciudades más bonitas de Estados Unidos, a la conferencia más importante del mundo relativa a mi profesión, donde aprenderé un montón de cosas y conoceré a gente muy interesante.

Y, encima, con entrada gratis como “blogger relevante” gracias a Oracle y el resto de los gastos cubiertos por la empresa donde trabajo, SIXSERVIX, una compañía del Grupo VARMA. Me lo voy a pasar pirata.

Quiero agradecer a la empresa que apueste y financie un año más este viaje y, sobre todo, a mis compañeros que no han podido venir y que se quedan con el marrón del día a día y, encima, cubren mi trabajo. Sois unos cracks.

Cómo el año pasado, intentaré publicar algún articulillo en javaHispano para cumplir con la Comunidad y, como novedad de este año, grabar algún episodio de BonillaTV, el videoblog que he lanzado recientemente. Digo ‘intentaré’ porque no sé el tiempo que tendré disponible una vez que llegue a San Francisco. En mi agenda, tengo días con sesiones de 8h a 20h y, en muchas ocasiones, compromisos para cenar con unos y otros. Para que os hagáis una idea del tiempo que se tarda en hacer las cosas, la edición del último capítulo de BonillaTV, prácticamente me dejó sin dormir.

Aún hay mucha gente que me pregunta “¿Por qué lo haces? ¿De donde sacas el tiempo?” y, por eso, lo explicaré de nuevo: Lo hago en mi tiempo libre. Y lo hago porque me encanta mi profesión y hablar de ella. Hay gente que habla de fútbol o de música. Yo hablo de lo que me gusta y me apasiona. No entiendo como hay personas que no quieran ser desarrolladores de software :)

Un abrazo a todos los que estáis ahí. Seguiremos informando desde San Francisco.

Artículos relacionados:

1. Bonilla TV – Capítulo 2: Llegando a San Francisco Segundo capítulo de BonillaTV. Viajes, hoteles y ciudadanos chinos. De...
2. Mi agenda para la javaOne 2010 Esta es mi agenda preliminar para la edición 2010 de...

Todo esta introducción, sólo es una excusa para presentaros el mejor vídeo sobre java que se ha hecho nunca. Cuando digo nunca es NUNCA. Simplemente, IMPRESCINDIBLE. Disfrutadlo…

Pinche aquí para ver el vídeo

Es el impresionante trailer que ha creado la gente de JavaZone, una conferencia de desarrolladores celebrada en Escandinavia con más de 2300 entradas vendidas.

Dedicado a la gente de AltNetHispano -que tan bien lo están haciendo- en general y a Amalia Hernandez en particular.

(Visto en Meneame, donde los comentarios demuestran que, desgraciadamente, aún hay gente que cree que hay lenguajes buenos y malos, no buenos o malos programadores…)

PEDAZO DE DISCLAIMER:

Este vídeo me llegó el fin de semana pasada e inmediatamente redacté este post como boniartículo humorístico para el siguiente viernes. Cuando vi que ya lo habían publicado en su cuenta de twitter gente como Dani Latorre, Erick Camacho o Sergi Almar también lo hice en la mía pero, mantuve la publicación del artículo para el siguiente viernes.

Después vi que el vídeo había corrido como la espuma por Internet y que hasta Abraham había hecho referencia al mismo en javaHispano. Aún así, lo mantuve. Primero porque soy un cabezón :) y, segundo, porque quiero creer -ayudado por las estadísticas de Google Analytics- que no todo el mundo que me lee viene de jH  (“sólo” un 14,16%…).

Hoy, al repasar el artículo por última vez, me he alegrado profundamente de haber esperado hasta el viernes para publicarlo porque, lo que se dice modula completamente el “polémico” artículo del miércoles y me ha animado a escribir este disclaimer.

Aún así, puede haber algún bocachancla que diga que este artículo es oportunista y se ha escrito posteriormente. Lo estoy esperando. Menos mal que el bendito sistema de gestión de WordPress guarda un histórico de cambios con hora y fecha…

Un saludo a todos y que viva .NET, Java, Ruby y Fortran. Como he dicho muchas veces, tenemos la profesión más bonita del mundo. Da igual el lenguaje que utilicemos…

PS: Una última mención de agradecimiento a Jorge Rubira que encontró una versión alternativa del vídeo después de que lo hubieran retirado de YouTube.

He de reconocer que, hasta hace poco, era un relativo fanboy de java pero, cada día soy más agnóstico respecto al lenguaje y me interesa más el producto; lo que, traducido a cristiano, significa que me da igual como esté hecho algo, lo importante es las funcionalidades que implemente y, por supuesto, que esté bien hecho.

Y en este estado de las cosas, ha caído en mis manos una maravillosa presentación de Jeffrey Zhao titulada “Porque Java apesta y C# mola”. El texto es imprescindible, lo mires por donde lo mires. No sólo porque supone una comparativa técnica y científica que rebosa calidad por todos los lados, sino porque detrás de un título de apariencia troll, se esconde una reflexión realista y desapasionada en la que no se aprecia fanatismo alguno.

Pero lo más importante de todo es que Jeffrey Zhao SE MOJA. Es de agradecer que alguien tome posición, la argumente y sea lo suficientemente valiente como para hacerla pública y, a lo torero, pedir réplica a la misma con la frase “contacta conmigo, muéstrame tu idea… y pruébala” proporcionando su blog, correo y cuenta de twitter. Ahí es nada.

Por si fuera poco, las diapositivas están salpicadas de frases memorables y un fino humor que es difícil de encontrar en un texto técnico. Me ha encantado la reflexión “si la JVM es la máquina, los byte codes son el código máquina y programar en Java… es como programar en ensamblador ¿De verdad quieres programar en ensamblador?”. Sencillamente, brillante.

El texto finaliza con una reflexión: ni siquiera nos pide que cambiemos de plataforma, entendiendo como plataforma la JVM, sino que pregunta ¿Por qué no utilizar otros lenguajes más poderosos a nivel de sintaxis y que se pueden utilizar dentro de la JVM como Scala, Ruby (JRuby) o Python (Jhyton)?

Qué grande es Jeffrey Zhao y qué grande es esta presentación. Tengo el orgullo de presentárosla aquí:

La conclusión a la que llego después de haber leído la presentación es que Jeffrey, como tantos otros, no nos está pidiendo a los que venimos del mundo Java que abandonemos la JVM ni la potencia de todo el mundo de librerías que hay detrás de ella, sino que probemos otros lenguajes que se pueden ejecutar en la misma.

¿Realmente merece la pena hacerlo cuando desgraciadamente hay un alto porcentaje de programadores a los que les suena a chino la mayoría de las cosas de las que habla Jeffrey? Bueno… depende. Si formas parte de una maligna megacorporación, puede que no, pero, si eres miembro de un pequeño y altamente productivo equipo de desarrollo…, a lo mejor el hecho de utilizar un lenguaje donde poder ordenar un array pasando la lógica de ordenación como parámetro, en vez de implementando una clase Comparator, marca la diferencia.

Voy a echarle un vistazo a Scala…

Artículos relacionados:

1. Gestión de memoria en Java Hace poco me llegó un correo de un compañero del...

Gosling se une a una larga y creciente lista de notables ex-empleados de SUN, que han renunciado a su puesto desde que Oracle la comprara en enero y que incluye a personalidades como el CEO Jhonathan Schwartz; el co-inventor del lenguaje XML, Tim Bray; el creador de Hudson, Kohsuke Kawaguchi; o el responsable de open source, Simon Phipps.

La marcha de Gosling y sus compañeros supone un duro golpe para la comunidad de desarrollo que ha crecido alrededor del lenguaje java, aunque técnicos como Jerónimo López crean que “para el sector, todo esto que está pasando es positivo. El panorama se llenará de nuevas empresas repletas de gente con muchas ideas, que podrán desarrollar/explorar con aún más libertad que cuando estaban en SUN. Seguro que muchas de esas ideas impulsarán/crearán áreas nuevas“.

Además, aunque algunos crean que los resultados de Oracle y sus ventas no se verán afectadas por la marcha de Gosling, como Abraham Otero que comenta en javaHispano “… las ‘empresas serias’ ni sabían quién era el ‘hippie’ ese  de Gosling…“, la pregunta que debemos hacernos todos y, especialmente, los accionistas de Oracle es: ¿vale más o menos Oracle sin todos estos técnicos dentro de ella? Si la valoración de una empresa se basa no sólo en sus activos financieros sino en su posibilidad de generar beneficios en un futuro, ¿se verá penalizada la valoración de Oracle en bolsa? ¿Se reducirá su capacidad de desarrollar nuevos productos y tecnologías?

Aunque no suelo ser un buen oráculo, pronostiqué deserciones masivas de técnicos en antiguos artículos y en el podcast de javaHispano donde comentamos la compra de SUN por parte de Oracle. SUN ya no es la compañía que atraía y contrataba a los mejores técnicos.

¿A dónde llevará todo esto? Nadie puede pronosticarlo, pero sí podemos asegurar que el panorama de java y su ecosistema va a cambiar radicalmente.

Artículos relacionados:

1. Compartiendo mesa y mantel con Oracle Ayer acudí a un encuentro de bloggers organizado por Oracle...

Han pasado 5 años, un presidente del gobierno, una crisis mundial por las hipotecas subprime y 6 entrenadores por el equipo de mis amores y,  después de todo, parece que aun hay bastantes dudas sobre la gestión de memoria con el lenguaje java así que, he decidido recopilar los post sobre memoria de mi antiguo blog, darles un lavado de cara, completar información y escribir el post ¿definitivo? sobre gestión de memoria.

Empecemos por el principio, la maquina virtual. La maquina virtual de java -o JVM en sus siglas en inglés- es el anclaje “físico” de nuestro maravilloso lenguaje multiplataforma con el Sistema Operativo correspondiente y, como tal, ocupa y utiliza memoria del sistema. Bien, esto es evidente pero, lo que es menos conocido, es como está implementada esta gestión de memoria.

La JVM se arranca reservando, por defecto, 64MB de memoria para trabajar que va ampliando según necesidades. Sin embargo, estas sucesivas ampliaciones automáticas llegan a un límite. Podemos gestionar nosotros mismos estos límites -tanto por arriba como por abajo- gracias a unos parámetros con los que se puede acompañar al comando de arranque de la JVM.
Esto es IMPORTANTE si sabemos que nuestra aplicación va a requerir una gran cantidad de memoria para su funcionamiento y queremos evitar un OutOfMemoryError o si, por el contrario, nuestra aplicación compite con otras de mayor prioridad en un sistema y queremos que utilice solo una parcela de memoria.

PARÁMETROS DE GESTIÓN DE MEMORIA

Antes de nada, es importante tener en cuenta que los parámetros de gestión de memoria son, en la mayoría de los casos,  específicos de la maquina virtual. Así, el parámetro -Xlp es exclusivo de la maquina virtual implementada por IBM y se puede utilizar exclusivamente con esta. Aunque hay un montón de implementaciones de JVMs, en la práctica, solo 3 o 4 son utilizadas en un porcentaje significativo y, en cualquier caso, siempre tendremos que probar nuestra aplicación con la implementación de referencia, la de SUN, para evitar posibles problemas de compatibilidades. Por eso, nos centraremos en los parámetros que se puedan utilizar con las maquinas virtuales de SUN.

Los parámetros de gestión de memoria se identifican por un sistema de prefijos que indican la naturaleza de dichos parámetros, así y según SUN:

• Los parámetros que comienzan con -X no son estándar, no se garantiza su implementación en todas las implementaciones de la JVM y pueden cambiar en futuras versiones del JDK.
• Los  parámetros que comienzan con -XX no se consideran estables (¿¿??) y no se recomienda su uso para usuarios sin un conocimiento especifico.

La primera maquina virtual :)

Los principales parámetros de gestión de memoria son:

• Xms < tamaño > establece la cantidad inicial de memoria
• Xmx < tamaño > establece la cantidad máxima de memoria
• Xss < tamaño > establece el tamaño máximo de pila de cada hilo JAVA

Es decir, si quisiéramos arrancar nuestra aplicación con una cantidad de memoria asignada de 64MB y queremos que llegue a utilizar un GB, por ejemplo, tendríamos que lanzar un script de la siguiente manera:

java -Xms64m -Xmx1024m <<nombre de nuestra aplicación>>

Es importante conocer en profundidad que implican y para que se utilizan cada uno de estos parámetros:

• Los parámetros Xms y Xmx establecen el tamaño inicial y máximo de la cantidad de memoria que la JVM utilizará para ejecutar programas java pero, esto no implica que nuestro proceso java ocupe en memoria un tamaño máximo como el establecido en el parámetro Xmx. Como se ha especificado antes, la JVM es un proceso en si mismo y, como tal, necesita memoria para poder cargar su código y datos. Por tanto, un proceso java puede llegar a ocupar mas espacio en memoria que el determinado en Xmx.
• El parámetro Xss sirve para determinar cual es la cantidad de memoria máxima que podrá utilizar un hilo ejecutado dentro de la maquina virtual. Para aquellos que no estén familiarizados con la gestión de hilos, pondremos un ejemplo de sencilla comprensión: imaginemos una aplicación web desarrollada en java. Esta aplicación web tendrá sus datos comunes y ocupará X espacio en memoria. Cada vez que alguien haga una petición a nuestra página web, se creará un hilo de ejecución independiente que tendrá sus propios datos (por ejemplo, los datos de un formulario de registro en nuestra página) y que no serán compartidos por el resto de hilos que se estén ejecutando en dicho momento (nuestra página web no es monousuario puede tener un montón de usuarios concurrentes). Bueno, en este caso, toda la memoria que utilice cada uno de los hilos se suma para el cómputo de memoria global determinado por el parámetro Xmx pero, además cada hilo comprueba que no supere el máximo de memoria que determina el parámetro Xss. Si se supera, se lanza un StackOutOfMemoryError.

Un caso común y conocido donde se puede dar un StackOutOfMemoryError es a la hora de usar reflexión en procesos XSLT por lo que, probablemente tengamos que subir el tamaño máximo de pila por hilo si utilizamos este tipo de tecnología.

PARÁMETROS AVANZADOS DE GESTIÓN DE MEMORIA

Hasta ahora, hemos visto los parámetros más básicos de gestión de memoria pero hay muchísimos más. Vamos a centrarnos en dos de los más importantes o, lo que es lo mismo, de los que pueden solucionarnos problemas tanto de rendimiento como de funcionamiento (seamos sinceros, nadie se interesa por esto hasta que el marrón le estalla entre las manos).

El problema es que, antes de poder especificar los comandos, tendremos que tragarnos algo de literatura para comprender de que estamos hablando.

EL GARBAGE COLLECTOR

Toda máquina virtual viene con un recolector de basura o Garbage Collector. Este maravilloso invento es el que consigue que los programadores java nos olvidemos por completo de tener que lidiar con la gestión de la memoria (y es el culpable, por otro lado, que todo este tema nos suene tan raro y distante… y de ahí este articulo).

El Garbage Collector libera el espacio de memoria ocupado por objetos que no van a volver a ser utilizados. El proceso de localización y eliminado de esos objetos puede ser tan pesado que llegue a parar una aplicación hasta su conclusión, por lo que es especialmente importante que lo configuremos correctamente.

La JVM divide el espacio en “generaciones” o particiones en los que poder aplicar sofisticados algoritmos de recolección. Cuando alguno de estos espacios se llena, se fuerza una recolección de objetos y, la eficiencia de este sistema se basa en que la mayoría de los objetos tienen una vida útil muuuy corta. El espacio en memoria, se divide generalmente en dos particiones: la nueva y la vieja generación.

Cuando el tamaño de la nueva generación se llena, se invoca una recolección de objetos muy rápida (GC) que acaba con los objetos que no vayan a ser utilizados y que traspasa a la vieja generación los objetos con vida. Cuando la vieja generación se llena, se invoca una recolección completa (Full GC) que implica a toda la memoria y que es mucho más lenta que la recolección rápida. Para entender un poco mas gráficamente de lo que estamos hablando, veamos unas trazas de una JVM:

[GC 50650K->21808K(76868K), 0.0478645 secs]
[GC 51197K->22305K(76868K), 0.0478645 secs]
[GC 52293K->23867K(76868K), 0.0478645 secs]
[Full GC 52970K->1690K(76868K), 0.54789968 secs]

En estas trazas se puede ver cómo, tras la primera recolección rápida (GC), se pasó de 50650Kb usados a 21808Kb (de un total de 76868Kb que es el espacio asignado mediante -Xmx). También se puede ver cómo, tras la recolección completa (Full GC) se pasó a un uso de tan solo 1690Kb pero, a cambio de casi medio segundo de inactividad de nuestra aplicación, que es lo que tardo la recolección completa en llevarse a cabo.

Por tanto, no parece tener mucho sentido que tengamos un espacio de 4GB asignado a nuestro proceso java y un espacio de 2MB -que es lo que viene asignado por defecto- para nuestra nueva generación. Normalmente, se recomienda que pongamos el tamaño de la nueva generación que queramos mientras no supere el tamo determinado en -Xmx y, como buena práctica, se recomienda asignar la mitad del espacio total de memoria (Ej. java -Xmx1024m -Xmn512m <<nombre de nuestra aplicación>>). Así:

• Xmn < tamaño > establece la memoria asignada para la nueva generación.

El tunning del Garbage Collector respecto al uso de la nueva generación da para mucho, como podéis ver aquí y en muchos otros sitios.

También se puede forzar la recolección mediante una llamada al sistema en java con System.gc() pero, no se recomiendo su uso porque fuerza recolecciones completas e impide la escalabilidad de los grandes sistemas.

LA MEMORIA PERMANENTE

Un concepto que, a veces, no queda muy claro es que todo esto de lo que estamos hablando se refiere a memoria volátil, es decir memoria ocupada por datos con una esperanza de vida mas o menos larga pero, en ningún caso, pensados para ser utilizados durante todo el tiempo de ejecución de nuestro proceso. Sin embargo, si hay datos permanentes que utilizará nuestro proceso java.

Estos datos (classes, librerías, etc.) se almacenan en la memoria permanente que funciona adicionalmente al espacio establecido por nosotros para la memoria volátil mediante el parámetro -Xmx.

¿Que para que se utiliza esto realmente? Para la carga y descarga de classes dinamicamente y, cuando alguien se pregunte que clases son esas que se cargan dinamicamente debe recordar que nuestras JSPs se convierten en classes dinamicamente según se van invocando (aunque se pueda efectuar una precompilación para ganar en rendimiento) y que las librerías invocadas por nuestras aplicaciones también utilizan este espacio.

¿Cómo puede afectarnos esto? Bueno, la JVM establece por defecto un tamaño máximo de 64mb para la memoria permanente. Si nuestra aplicación empieza a generar clases como si no hubiera mañana (nadie duda de que todos nosotros hace aplicaciones con TRILLONES de usuarios concurrentes) y llenamos este espacio en memoria, forzaremos una recolección completa del Garbage Collector que penalizará el rendimiento de nuestra aplicación. En un escenario más real, si nos hemos dedicado a agregar y usar librerías y librerías con sus dependencias y nuestra memoria permanente no puede cargar todas las que necesitamos, daremos con un OutOfMemoryError que nos romperá el Chi a nosotros y a nuestros usuarios (no te digo ya a nuestro jefe). No parece que tenga muchos sentido, por otro lado, que le demos a nuestra mega-aplicación 2GB de memoria volátil y la dejemos con 64mb para cargar clases y librerías ¿verdad?. Así:

• XX:PermSize=< tamaño > establece el tamaño mínimo de la memoria permanente
• XX:MaxPermSize=< tamaño > establece el tamaño máximo de la memoria permanente

Si, por ejemplo, queremos utilizar 128mb para nuestra memoria permanente, ejecutaremos algo como java -Xmx1024m -Xmn512m -XX:PermSize=128m <<nombre de nuestra aplicación>>)

Es importante recalcar que la memoria permanente es adicional a la memoria volátil establecida por el comando -Xmx. Por eso, si arrancamos un proceso java con un permSize de 256mb y un -Xms de 256mb, el espacio total de memoria usada será de mas de 512mb (256 de memoria volátil + 256 de memoria permanente + la memoria que utilice la maquina virtual en si) Ej.

---------------------------------------------
$ java -Xms256m -Xmx256m -XX:PermSize=256m -XX:MaxPermSize=256m Hello
$ pmap 6472
6472:   /usr/java1.3.1/bin/../bin/sparc/native_threads/java -Xms256m
-Xmx256m
  total   550544K
---------------------------------------------

Podéis encontrar todo esto mucho mejor explicado aquí (pero eso si, en inglés).

OPTIMIZACIÓN DEL RENDIMIENTO EN ARRANQUE Y EN TIEMPO DE EJECUCIÓN

Otra optimización que hay que tener en cuenta es la proporcionada por los diferentes perfiles de la maquina virtual y el uso del compilador de cada uno de los mismos. Así, el perfil por defecto es el de -client que prioriza la velocidad de arranque del proceso antes que el rendimiento general de la aplicación. Por el contrario, el perfil -server prima el rendimiento en tiempo de ejecución en vez que el arranque rápido del proceso (además de modificar ciertos valores por defecto como, por ejemplo, el tamaño por defecto de la memoria permanente que pasa de 32 a 64mb).

Para utilizar el perfil -server solo hay que introducirlo como parámetro en la ejecución de nuestro proceso java.

CONCLUSIONES

Por último, además de la correcta configuración de nuestra maquina virtual, otra de las cosas que debemos tener en cuenta es seguir una serie de buenas practicas a la hora de programar nuestras aplicaciones aunque dejaremos esto para otro post. Se pueden encontrar múltiples sitios con listas de optimización de memoria para nuestras aplicaciones pero destaquemos un articulo reciente sobre antipatrones de memoria que hay que evitar y que puede enseñarnos mucho.

También es importante tener en cuenta el enorme muestrario de aplicaciones de profiling y monitorización disponibles en el mercado, gratuitas y de pago, para comprender que pasa con nuestra memoria, cuando y porqué.

Espero que hayáis encontrado este artículo de utilidad.

Artículos relacionados:

1. Porque Java apesta y C# mola Según Jeffrey Zhao, Java es un truño infumable y C#...