Skip to content

reporter: give memory traces a dedicated API instead of abusing ReportTraceEvent - #3192

Open
gnurizen wants to merge 1 commit into
mainfrom
oomprof-payload-frames
Open

reporter: give memory traces a dedicated API instead of abusing ReportTraceEvent#3192
gnurizen wants to merge 1 commit into
mainfrom
oomprof-payload-frames

Conversation

@gnurizen

@gnurizen gnurizen commented Jun 18, 2026

Copy link
Copy Markdown
Contributor

Memory profiling is evolving in a different direction upstream and custom probes are deleting the whole trace origin machinery. Have oomprof use a new "parca" API instead of (ab)using ReportTraceEvent. We wanted to do this for efficiency reasons anyways. See commit message for details.

@gnurizen
gnurizen requested review from brancz and umanwizard June 22, 2026 11:36
@gnurizen
gnurizen marked this pull request as ready for review June 22, 2026 11:36
@gnurizen gnurizen changed the title reporter: split memory traces onto a dedicated ParcaReporter.ReportMemoryTraces path reporter: give memory traces a dedicated API instead of contorting to ReportTraceEvent Jun 23, 2026
@gnurizen gnurizen changed the title reporter: give memory traces a dedicated API instead of contorting to ReportTraceEvent reporter: give memory traces a dedicated API instead of abusing ReportTraceEvent Jun 23, 2026
…moryTraces path

Memory profiles used to ride on the otel TraceReporter contract: the
oomprof adapter built a fake libpf.Trace per sample, stuffed alloc/free
counters onto it via a synthetic MemoryPayloadFrame, and called
ReportTraceEvent. That worked but pushed memory-specific shape into the
otel-facing trace interface and burned one writer-lock acquisition per
sample.

Memory profiling upstream is evolving in a different direction and we
want to reduce fork drift so this greases the skids for the future.

  * `ParcaReporter` is now an interface (reporter/iface.go) embedding
    the otel `reporter.Reporter` + `ExecutableReporter` and adding
    `ReportMetrics` and the new `ReportMemoryTraces(samples, meta)`.
  * The concrete struct is renamed `arrowReporter`; `New(...)` returns
    the interface.
  * `arrowReporter.ReportMemoryTraces` writes memory rows v2-only,
    computes labels once per batch, takes the v2 writer lock once,
    and emits 2-4 rows (inuse_objects / inuse_space and, when
    enabled, alloc_objects / alloc_space) per sample.
  * The oomprof callback is wired through a new `oomprofAdapter`
    (reporter/oomprof_adapter.go) that implements `oomprof.Reporter`,
    chunks incoming batches into groups of 100, and forwards each
    chunk to `ReportMemoryTraces`.

That lets us delete:

  * `extractMemoryPayload` and its callers in `ReportTraceEvent`
    (the synthetic-payload-frame side channel).
  * The `oomprofMemoryFrame = 0xFF` shim plus its `case` in the
    v1 stacktrace builder and the v2 location builder.
  * The v1 and v2 `case TraceOriginMemory:` branches in
    `reportTraceEvent` / `reportTraceEventV2` (memory no longer
    flows through there).
  * `SampleEvents` on the concrete reporter, now replaced by the
    adapter.

Bonus: the v2 memory path now actually increments `r.memorySamples`
(the previous code only incremented it on the dead v1 branch).

No `main.go` source edits are required — the interface return from
`reporter.New` covers `Start`, `Stop`, `ReportTraceEvent`,
`ReportExecutable`, `ReportMetrics`, and the new
`ReportMemoryTraces`, satisfying every consumer (tracer, metrics,
parcagpu).
@gnurizen
gnurizen force-pushed the oomprof-payload-frames branch from 40e8601 to 6e972e1 Compare August 21, 2026 15:56
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.

1 participant