Barrapunto

Para aquellos que sepan inglés, se puede seguir el proceso de cómo se plantearon el análisis de la fragmentación de memoria en Firefox y las posibles soluciones hasta elegir jmalloc, así como las dificultades encontradas y las mejoras que han ido introduciendo, viendo las entradas sucesivas que fue escribiendo Pavlov (uno de los diseñadores):

http://wordpress.com/tag/memory-fragmentation/ [wordpress.com]

Aconsejo leerlas todas empezando desde la entrada más antigua, porque al menos a mí me pareció bastante interesante.

Ahora ya incluyen hasta su propio gestor de memoria. Para cuándo un Firefox standalone sin sistema operativo?

Y en el artículo enlazado [blogspot.com] también dice que jemalloc está sólo en las "nightly builds".

Guau, creo que o estoy yo muy confundido o están muy confundidos los demás :D

El sistema operativo gestiona la memoria que las aplicaciones le solicitan. Si firefox le pide memoria y memoria y más memoria, le irá dando memoria RAM mientras pueda, y cuando ya no pueda tirará de memoria virtual (swap memory).

Si "enseñamos" a la aplicación a pedir memos memoria, a que reutilice y libere de forma más eficiente y a que mueva los bloques de memoria (vital para evitar fragmentación) de forma más eficiente, sobre cargamos menos la memoria en general y la gestión se hace mucho más rápida.

Muchas veces la cantidad de memoria consumida aumenta espectacularmente porque no se hace un free en el momento adecuado y la velocidad de ejecución puede caer por una gestión ineficiente de los bloques de memoria que tiene asignados por el sistema operativo.

Lo que no entiendo es por qué no se ha implementado un recolector de basura que automatice estas tareas. Supongo que será como matar moscas a cañonazos, pero bueno. A ver como aumenta el rendimiento con la beta 3 (y si mejora aún más en las siguientes versiones, jeje).

Saludos

No he usado interfaces basadas en XUL, me podrías decir por qué decís que es un engendro? el concepto en sí es muy interesante como para descalificarlo totalmente. Me gustaría que alguien que haya trabajado de primera mano con ello nos diera una luz al respecto.

Igual me equivoco, pero lo que hará será pedir al principio una gran cantidad de memoria contigua al S.O., y luego gestionarla internamente para ir dándose trocitos a sí mismo, así, chabacanamente explicado.

El programador sabe mejor que el sistema operativo el uso que va a dar a la memoria. Un ejemplo sencillo es cuando trabajas con colecciones de cadenas: puedes hacer un malloc/una reserva por cada cadena que vayas necesitando pero es más efeciente reservar al principio una pool grande común a todas e ir repartiendo la memoria a discrección.

Otra ventaja es que, al hacer solo una asignación real (un malloc), solo con un free has liberado todas las cadenas. Eso simplifica la liberación de recursos en caso de error o al finalizar el algoritmo (claro que complica la liberación de cadenas sueltas)

No es el caso porque gecko está escrito en un subconjunto de C++ pero fíjate si es común aplicar tu propio esquema de manejo de memoria que ese lenguaje ya viene preparado para que "enchufes" el tuyo, tanto si trabajas con contenedores estándar [sgi.com] como si no lo haces [glenmccl.com]. En otros lenguajes como Java no hay esa flexibilidad pero sigues teniendo el recolector de basura que aplica su propio esquema sobre los malloc/free del sistema.

creo que este enlace responde a tu pregunta: jemalloc builds [pavlov.net]

Depende a qué llames "Sistema Operativo".

Si con eso te refieres tan solo al kernel, verás que no hay ninguna llamada al sistema "malloc". Hay brk(), que simplemente aumentan el tamaño del heap y mmap() que reserva zonas completas de memoria, normalmente del tamaño de páginas.

mmap() funciona en espacio de usuario y hace uso de estas llamadas. Tú puedes usar el malloc por defecto en tu sistema, o usar el tuyo propio(en Solaris vienen varias implementaciones de malloc).

Ejem... ¿por ejemplo Google Earth y Skype? Si quieres más aquí tienes algunas: http://trolltech.com/customers/coolapps [trolltech.com]. De todas formas, eso no es excusa para no usarlo.

Como ya se ha dicho en otros comentarios malloc no es una llamada del sistema en Linux. Es una función de la libc que se implementa mediante una pocas llamadas. Así que parte del trabajo de gestionar la memoria del proceso la hace la propia libc, normalmente pidiendo grandes cantidades de memoria al sistema para posteriormente dividirla y asignarla según lo pida el programa mediante malloc.

Como ejemplo me acuerdo de cuando programaba en Borlanda para Windows. Ellos decían que tenían la mejor gestión de memoria. Mucho más eficiente que la del runtime de Microsoft. Pero eso no evita que tuvieran que utilizar las llamadas al sistema para pedir la memoria al windows.