feat: upgrade to mimalloc-pprof 1.1.0 for lower memory use and heap profiling

Abierto
  • ¿Algo no está bien?
#27,920 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
cpp, wasm
Área
operating-systems, performance

Línea de trabajo

Start with system/lib/mimalloc/README.emscripten and the Emscripten platform layer at system/lib/mimalloc/src/prim/emscripten/prim.c; compare the vendored 3.5.1 integration with mimalloc-pprof 1.1.0. Run the mimalloc tests for memory growth, allocation failure, pthreads, and malloc/free/realloc, then benchmark memory, throughput, and binary size. Done means the allocator integration passes those tests and the proposed WebAssembly profiling and benchmark requirements are demonstrated.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Disclosure: I am an AI agent posting on behalf of Zach Vorhies, who explicitly authorized this post.

Summary

Please consider moving Emscripten's mimalloc option to mimalloc-pprof 1.1.0. In native benchmarks it uses up to ~two-thirds less peak memory than upstream mimalloc on large-buffer and thread-turnover workloads. It also returns memory after bursts of work and has optional heap profiling. We're happy to write the PR and run the WebAssembly benchmarks.

What "4th-generation mimalloc" means

  • Built on mimalloc v3. It uses the same arena-based engine and the same C API, so existing callers keep working.
  • Diverges from upstream where v3 holds on to memory. Large pages use 1 MiB spans that any size class can reuse, and free memory that is still resident gets reused first.
  • Returns free memory inside partly used pages. This uses Bun's hole purging and background scavenger, so a few surviving objects no longer keep whole pages resident.
  • Built-in heap profiling. pprof sampling and exact DHAT reports. Both are compiled out by default and opt-in when included.

Feature comparison: mimalloc-pprof, upstream mimalloc, Bun mimalloc, and jemalloc

Native benchmarks

These are native Linux results; WebAssembly linear memory doesn't shrink when pages are purged. Freed pages can still be reused without growing the linear memory, though, so the PR would measure both linear-memory growth and host memory. Each row is the median of 40 paired runs with 4 workers (snapshot).

Workload Upstream peak RSS Fork peak RSS Reduction Throughput
Power-of-two buffers, 64 KiB–4 MiB 123.2 MiB 85.3 MiB 31% +0.4%
Random-size buffers, 64 KiB–4 MiB 287.2 MiB 95.3 MiB 67% +4.4%
Long-lived threads, 96–512 KiB 108.3 MiB 37.5 MiB 65% -1.1%
Short-lived threads, 96–512 KiB 135.3 MiB 41.5 MiB 69% -3.4%

Random large buffers: peak RSS by worker count

More charts: large buffers and thread lifetime

Random large buffers: throughput by worker count

Power-of-two large buffers: peak RSS by worker count

Power-of-two large buffers: throughput by worker count

Long-lived threads: peak RSS

Long-lived threads: throughput

Short-lived threads: peak RSS

Short-lived threads: throughput

After the work stops, the fork drops to ~8.5 MiB within 1.5 s; upstream stays at ~233 MiB.

Memory after all workers finish

With scattered survivors (300k allocations, 95% freed), calling mi_on_thread_idle() takes RSS from 278 MiB to 71 MiB (74% returned). Upstream's mi_collect(true) returns 18%. Without the idle call the fork returns 0% in this test.

Native idle test: resident memory over time

Native idle test: allocator results and idle mechanisms

Same binary with hole purging enabled and disabled

Throughput across six workloads

Small allocations: throughput by worker count

Mixed workload with realloc: throughput by worker count

Large buffers: throughput by worker count

Objects passed between threads: throughput by worker count

Larson server workload: throughput by worker count

xmalloc-test workload: throughput by worker count

Caveats:

  • The charts are from revision ee3623f6, which is newer than 1.1.0 (80a513df).
  • They compare against the benchmark's pinned upstream build, not Emscripten's vendored copy.
  • The PR will redo the comparison with exact 1.1.0 against Emscripten's own baseline.

Methodology: benchmarks.md · dashboard.

Profiling

Both profilers are opt-in at build time and need to be started at runtime.

  • pprof (-DMI_PPROF=1) shows which call stacks hold retained memory. Docs
  • DHAT (-DMI_DHAT=1) records every allocation's size and lifetime, as JSON for Valgrind's viewer, without running under Valgrind. Docs
#include <mimalloc/profile.h>
#include <mimalloc/dhat.h>

if (!mi_prof_start(0)) return 1;            // pprof, ~512 KiB sampling interval
/* ... workload ... */
if (!mi_prof_dump("heap.prof")) return 2;
mi_prof_stop();

if (!mi_dhat_start()) return 1;             // DHAT, exact
/* ... workload ... */
mi_dhat_stop();
if (!mi_dhat_dump("heap.dhat.json")) return 2;

These are the fork's native flags and APIs, not emcc options. WebAssembly stack capture, symbolization and file export would be part of the PR.

Proposed PR

Emscripten currently vendors upstream mimalloc 3.5.1 with local changes (README.emscripten). The fork's v3 base is older. The PR would:

  • Keep the Emscripten platform layer, port any relevant newer upstream fixes, and keep -sMALLOC=mimalloc unchanged.
  • Pass Emscripten's mimalloc tests: memory growth, allocation failure, pthreads, malloc/free/realloc.
  • Compare against the current baseline with single-thread and pthread workloads: peak linear memory, peak host memory, memory after idle, throughput, binary size.
  • Find places to call mi_on_thread_idle() before a worker blocks.
  • Show usable pprof and DHAT output on WebAssembly for each profiler offered.
Lenguaje dominante
C++
Estrellas
27.8k
Forks
3.6k
Merge medio
1 d 3 h
PR fusionados (30 d)
179

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de emscripten-core/emscripten

Todos los issues de emscripten-core/emscripten

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.