[Madrid-pm] Memory leaks

Bruno brunorc en gmail.com
Jue Abr 12 03:43:26 PDT 2007


Hola

Gracias por respuestas, a ver...

Es verdad, que Perl come mucha memoria y - como tiene un garbage
collector, que no es ningún GC (refcount sirve bien para scripts, pero
no para OO) - es muy difícil en debugging. Mientras que en C puedes
llamar free cuando te conviene, undef sirve mas para ti, que fuerza la
liberación de memoria por el interpretador.

Ojalá la versión 6 nos salvaré.

2007/4/12, Joaquin Ferrero <explorer at joaquinferrero.com>:
> Devel::Size, pero me dijeron que ya encontraron una solución mejor: cada
> vez que el bucle interno del programa quería generar un documento,
> ejecutaba un script Perl nuevo que se encargaba de eso. Así que cuando
> el script terminaba, pues era claro que se liberaba la memoria.

Sí, pero es como curar sífilis por maquillaje. En mi caso no sirve,
porque tengo que hacer un documento completo, y si tenga más que 10
páginas, caeré.

> Y es el caso que Bruno es la tercera persona que me pregunta por temas
> de memoria de Perl en sólo esta semana...

Porque es un problema que encuentras SIEMPRE, haciendo programas
bastante grandes, con OO y mezclando módulos de diferentes autores.
Por la facilidad de escribir programas en Perl se puede construir
monstruos en dos-tres días. Y aunque no hay muchos ficheros ni lineas
del código, con "use Algo" añades un montón de código y casi nunca
puedes decir, que SABES como todo esto va a funcionar junto.

Por ejemplo, PostgreSQL SPI (Server Programming Interface) tiene su
propio mantenimiento de memoria con palloc() y pfree(). ¿Pero como
usar las librerías, que usan malloc como pan? - por ejemplo gmp, para
calculaciones de cualquiera precisión.

Recuerda, que Perl hasta hoy tiene solo una parte pequeña del mercado.
¿Y por qué? ¿Por qué se prefiere Java? Pues, por su GC. Es verdad, que
la gran mayoría de programas en Perl NO necesita debugging. Y los que
necesitan, son un dolor en culo inmenso.

Dicho todo esto, yo entiendo que no era fácil proyectar Perl 5 años
atrás y prever la necesidad de GC.

> En cuanto a Bruno, decirle que está siguiendo los caminos básicos de la
> liberación de memoria:
>
> 1. undef
> 2. variable fuera de ámbito
> 3. comprobar que su contador de referencias es 0 (Devel::Cycle,
> Devel::Leak)

Voy a poner undef donde se puede y despues sacarlos, que no hacen
ningunos cambios.

A Salvador:

> 411217920 son aproximadamente 512MB de memoria

Un poco menos... pero bueno:

> que no me parece demasiado si estas procesando imagenes y es muy posible
> que no se trate de un memory-leak si no que realmente necesite esa memoria

Pues, necesito 300 DPI, porque son pdfs para imprimir en alta calidad.
Otra cosa es, que más páginas y más imagenes consumen más memoria y no
proceso todos en un momento, pero uno a uno. Y por las calculaciones
"en el otro lado del sobre" (C by Fred Brooks) veo, que el programa
come demasiado.

> lo mas facil seguramente sea a~nadir espacio de swap a tu maquina

No, tengo 1GB de swap y 512 de memoria física. Puede ser límite de OS,
pero no importa. Hay leak. Leak es malo. Se necesita eliminar cosas
malas. Punto :-)

(Que bueno es ser un ingeniero y tener la vista tan sencilla!)

Pues, voy a luchar con el código. Si encuentro algo, voy a compartir
mis experiencias. Pero me parece, que el tema de GC es muy vivo y
aparte de OO es el mayor dolor en un culo de Perl comunidad. A ver:

Mark Jason Dominus, 2000 (Perl 6 anunción): "There are two big
problems with Perl 5. First, the internals are extremely convoluted.
(...) The other big problem is thirteen years of backward
compatibility history. Every few months, someone suggests replacing
Perl's garbage collector with a more modern one, but there are always
objections from people who have written code that assumes that the
garbage collector will always be reference-count based and that it can
control when objects will be destructed."

TADAM!

use garbage "refcount"; <- podría ser una solución...

Y cosa de productividad (perl6 mailing list digest, Feb 2001):

Q: I actually don't understand how traversing a graph can be faster
than incrementing/decrementing/testing for zero on a refcount?

A: The crux of the matter would appear to be that with refcounts you
have to do a pretty small amount of work very, very often. With a well
designed GC system you do a largish amount of work much less
frequently. The total amount of work done tends to come out higher in
the refcounting scenario.

Pues, a veces "es mejor hacer menos, pero mejor" - Lenin :-)

También encontré un blog muy interesante (se llama "Plataforma .NET",
pero también tiene una parte "El mundo del Perl"; que es lo más
divertido, la gran mayoría trata sobre MS SQL Server). Muy
profesional. Tiene una (des)ventaja muy grande: en Polaco. Pues... si
quieres comprobar:

http://strefa.guzowski.info/archives/33,2007,01,06.html

Voy a atacar el tema con todo desfuerzo :-)

Saludos y gracias, Bruno


Más información sobre la lista de distribución Madrid-pm