Resumed session: RSS → 2.2GB in 33s from 25MB payload; JS heap only 569MB (rest in native Memory Tag 240) #50578

Description

Resuming an existing session causes RSS to jump to ~2.2 GB within ~33 seconds, while the session payload on disk is only ~25 MB (8,295 parts / 124 messages). The process then continues to grow (observed 2.4–2.5 GB RSS after a few minutes of idle/light use) with sustained high CPU in Yoga layout.

Captured heap snapshots (Ctrl+P → Write heap snapshot) during the elevated window. Analysis of the larger TUI snapshot (from the high-RSS resumed session) shows:

So most of the RSS is not visible in the V8/JSC heap snapshot — it sits in native Memory Tag 240 / app-specific tagged allocations. Snapshot dump also shows a large object/closure population:

Heap snapshot findings (TUI, high-RSS resumed session)

Top by self_size:

By V8 category: object 325 MB (5.5M), closure 123 MB (2.5M), string 73 MB (261k).

Comparison against a shorter TUI session (same machine, RSS ~0.9 GB, 74 MB snapshot still attached below):

• Short TUI: 277,955 Function, 205,609 Object, 160 MB self_size
• Resumed long TUI: 1,778,642 Function, 1,533,122 Object, 569 MB self_size
  → ~6.4× more Function/closure objects after resuming and using a long session.

Also present: several multi-MB embedded data:image/png;base64,... strings (1–6 MB each).

ModuleRecord (32 modules, ~57 MB) appears identical in both TUI snapshots — looks like a fixed startup cost, not the leak.

CPU / layout

sample while RSS was elevated shows continuous:

• facebook::yoga::calculateLayoutImpl
• UnifiedTextBufferView.measureForDimensions / Rope.walkNode

i.e. TUI is busy re-measuring/layouting text buffers while memory stays high.

Repro (high-level)

# 1) Use opencode heavily in a project session (long chat, many tool calls)
# 2) Exit; later resume:
opencode -s ses_f37f75a4cffeL4fagJyNraDOyB
# 3) Observe RSS:
watch -n1 'ps -o rss=,etime= -p <pid>'

Observed on resume: RSS → ~2.2 GB in ~33 s; session DB payload only ~25 MB.

Manual snapshot: Ctrl+P → “Write heap snapshot” (writes tui.heapsnapshot in TUI cwd and server.heapsnapshot in worker cwd).

Environment

opencode: 1.18.30 (Homebrew)
os:       macOS 26.6.2 (25G83), arm64
runtime:  Bun (standalone binary)
terminal: ghostty 1.3.1
DB size:  ~192 MB (opencode.db); event table ~53k rows / ~106 MB

Snapshots attached (available for upload)

Still on disk (high-RSS 600 MB TUI dump was cleaned up after analysis; numbers above are from that dump):

e70625eb265372368d4a2ae7bdfa1d7af3e3b2ab78314535003e7292869e30c0  tui.heapsnapshot      (74 MB)
c86c6e6ca585cb60d6f2a16e7fe7595092994de3a597e811aa2a612bee3bfd1b  server.heapsnapshot  (122 MB)

Can re-capture the high-RSS pair on demand, or upload via the #20695 Dropbox channel if useful.

Related: #49222 (TUI RSS floor), #50089 (resume + summary.diffs), #35107 (structuredClone / event growth), #20695 (closed megathread).

Expected

Resuming a session with tens of MB of parts should not allocate multiple GB, and RSS should stay roughly proportional to live session data + a modest TUI baseline.

Actual

~2.2 GB RSS within 33 s of resume; long-running TUI holds ~6× more Function/closure objects than a short session; majority of RSS lives in native tagged memory outside the JS heap snapshot.