[iFixRobots]

Every LINE session keeps a second 16 MiB copy of the LTSM module, and it lasts as long as the process. The channel methods run on that copy so their leaks never reach the real runtime. The copy is created on the first encrypt or decrypt and then held by that runtime forever, even though it's only needed for the length of one call. On cloud bridges, these copies plus the main runtimes were 40–60% of a process's Go heap, held by 3–9% of its sessions.

Each refresh already overwrites the whole copy from its runtime, so the copy doesn't need an owner. This moves the copies into a sync.Pool shared by all runtimes. A copy is reused without a refresh only if it was last refreshed from the same runtime state, which a generation number now tracks in place of cryptoDirty. A copy that panics is dropped.

Before / after

Harness: 20 runtimes, each with a V1 channel, 200 decrypts per pattern, 5 runs, medians.

	before	after
Heap per runtime after its first channel call	32.0 MiB	16.0 MiB
Decrypt, same runtime back to back (p50)	0.91 ms	0.91 ms
Decrypt, alternating between 20 runtimes (p50)	1.02 ms	1.96 ms

The extra ~1 ms only happens when consecutive calls come from different runtimes, because the copy has to be refreshed (one 16 MiB memcpy).

Tag @indent to continue the conversation here.

[indent]

Issues

No issues found.

CI Checks

All CI checks passed on 8d021d4.

Review agents

Select any unchecked box below to run or rerun that agent.

Passed (1)

• Indent Review Agent · No bugs found in the shared scratch pool.

Full results

Indent Review Agent

• Summary: No bugs found in the shared scratch pool.
• Last ran on commit: 8d021d4f
• Latest result

  {
    "summary": "No bugs found in the shared scratch pool.",
    "findings": []
  }