Skip to content

Eager execution: does buffer lifetime need its own reuse mechanism, without a graph to plan from #1135

Description

@michalharakal

Split out of #1134 / #1131.

#1134 scopes graph-level memory planning (P8) to the recorded path (RecordingExecution -> HloGenerator -> StableHLO -> IREE), on the theory that IREE already plans allocation there. Eager execution has no graph to analyse — by construction it executes as it is called — so that framing doesn't apply to it, and #1134 explicitly punts on eager.

That leaves an open question #1134 doesn't answer: does eager execution need some buffer-lifetime/reuse mechanism of its own, given that explicit arenas already OOM'd once and lifetimes fell back to GC (per #932's original scope)?

Research question

Placement.Residency already models a weights-persistent vs activations-transient split, but nothing uses it operationally today (see #1133). Is a residency-based scope split — free an activation's buffer when its scope ends, without needing a full graph — enough to cover eager's reuse needs? Or does eager genuinely need nothing beyond what P7 (#1133) already decides, because there's no cross-step reuse to plan for without recording?

Depends on

#1133 (P7 — device placement / residency) likely needs to land first, since any eager reuse mechanism would build on the same Placement.Residency concept rather than duplicate it.

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

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions