Barrapunto

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.

http://blog.pavlov.net/2008/01/12/jemalloc-builds/ [pavlov.net]

A Windows jemalloc build. The sunspider JS test looks to run about 5% faster. You'll notice that these builds take up a bit more memory initially but they should level out around 80mb. There is plenty of tuning left to do, but I'm curious to hear how these run for people after running for a long time.

http://people.mozilla.com/~pavlov/minefield-jemall oc-win32.zip [mozilla.com]

Una pregunta ¿Siempre usa solo 16MB? ¿O si requiere más aumenta la reserva?