🚀 go-pugleaf

JuanCarlitro <forhekset@gmail.com> wrote:

: La verdad si, depende como sea contruida la aplicaci?n el consumo de
: recursos es mayor, pero ojo, ac? muchos desarrolladores piensan que el
: garbage collector es un ente que puede limpiar muchas de sus falencias
: program?ticas, como la eliminaci?n de referencias en variables, cada
: clase es una referencia en la VM y en muchos casos tienen referencias
: heredadas que hacen que el GB no las detecte y generen un memory leak.
: Al igual que en C/C++, es un muy buen habito el limpiar referencias
: (apuntar a null, en caso de no utilizar m?s)

Me gustaria conocer un ejemplo concreto de esto. En la practica los
unicos memory-leaks que he visto ocurren por implementaciones de 
Map o Collection que engordan progresivamente dentro del ciclo de 
vida de la aplicacion.. sumemosle algunas API's encargadas de guardar
cosillas como JNDI que podrian estar implementadas con objetos
en memoria... y no conozco mas casos. No digo que no existan, es posible
que tengas razon, pero un ejemplo me ayudaria a saber que tipo de cosas
tengo que evitar en vez de estar llenando mi codigo de null's. El
garbage collector no solo cumple una funcion en runtime.. ademas ayuda
a que nuestro codigo sea mas legible, prefiero saber que hay ciertas
cosas que no se deben hacer a tener una estrategia tan ultradefensiva
como la que planteas.

Ahh.. por ahi alguien nombro un profiler de eclipse.. tb me gustaria
conocerlo, hasta ahora el mejor profiler opensource que conozco es
el de netbeans:

http://profiler.netbeans.org


----
Ariel Aguayo B. (araguayo@dcc.uchile.cl)

"Vale la pena morir por todo aquello sin lo cual no vale la pena vivir..."
Salvador Allende.