Skip to content

symbolizer: Load DWARF sections via mmap to reduce initialization allocations - #6410

Open
HSP18SCM23P wants to merge 4 commits into
parca-dev:mainfrom
HSP18SCM23P:mmap-dwarf-section-loading
Open

HSP18SCM23P wants to merge 4 commits into
parca-dev:mainfrom
HSP18SCM23P:mmap-dwarf-section-loading

Conversation

@HSP18SCM23P

Copy link
Copy Markdown

Loading DWARF debug info via debug/elf's File.DWARF() copies every section into Go heap buffers. On large binaries this dominates symbolizer initialization time and GC pressure.

This change adds elfutils.LoadDWARFData, which memory-maps the file read-only once and serves uncompressed DWARF sections as views into the mapping, building dwarf.Data with the same two-pass logic as the stdlib loader. DwarfLiner keeps the mapping alive until Close() and releases it on initialization failure.

The previous copying behavior is retained for: compressed sections (.zdebug_*, SHF_COMPRESSED), inputs whose DWARF sections need relocations applied (non-ET_EXEC with REL/RELA targeting DWARF sections), and non-unix platforms (build-tagged stub; zero new dependencies, stdlib syscall.Mmap only).

Benchmarks (loader only, -benchmem), synthetic 4000-function -g binary (~274KB DWARF): before ~283KB/op, 32 allocs/op, ~0.65-2.6ms; after 4.5KB/op, 28 allocs/op, ~38-106us.

Note: mapped pages still count toward RSS; the win is Go-heap/GC. Theoretical SIGBUS risk if a debug file were truncated while mapped (the heap-copy path didn't have this); debug artifacts are stable on disk in practice.

Fixes #6404

@HSP18SCM23P
HSP18SCM23P requested a review from a team as a code owner September 25, 2026 04:20

This branch has not been deployed

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

symbolizer: Consider mmap-backed DWARF sections to reduce initialization allocations

1 participant