Skip to content

gc: #6882's mimalloc VM-tag retag regressed — heap renders as IOAccelerator again, memory-model.md profiling recipe misleads #7450

Description

@proggeramlug

Observed while profiling #7438 on macOS 26.5 (both the MacBook and the bench mini): a Perry process's heap mappings render in vmmap as IOAccelerator (mimalloc's default VM tag 100) — ~230 MB of them on tree.ts — while Memory Tag 240 holds ~64 KB. #6882 retags mimalloc's mappings to VM_MEMORY_APPLICATION_SPECIFIC_1 (240) during js_gc_init, and docs/src/internals/memory-model.md §profiling documents Tag 240 as the heap and explicitly says large IOAccelerator regions mean a pre-#6882 build. On current main the retag evidently covers almost nothing (mimalloc version bump changing option timing? retag running after the first segments are mapped and never applying to later ones?).

Labeling-only — no accounting or correctness impact — but it actively misleads anyone following the documented profiling recipe (it cost this investigation a detour into "why does a GC benchmark map GPU memory"). Fix the retag or fix the doc; the doc's IOAccelerator paragraph is wrong either way today.

Repro: vmmap --summary <pid> of any compiled Perry binary mid-run on macOS 26.5.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions