Skip unavailable malloc_trim offloads

[xeophon]

Overview

Stop scheduling recurring thread-pool work after a worker has definitively established that malloc_trim is unavailable. The first probe and the Linux trimming cadence remain unchanged.

Reasoning

_malloc_trim is a process-global tri-state: unresolved (None), available (the libc function), or unavailable (False). Previously, the periodic helper advanced its 16-rollout cadence in all three states. On unsupported platforms, every sixteenth completed rollout therefore submitted trim_memory through asyncio.to_thread, even though the cached False made the worker function return without doing anything.

Those no-op offloads still copy the current context, allocate and queue executor work, wake a worker thread, signal completion across threads, and suspend/resume the rollout coroutine. An exact is False guard before cadence accounting removes that work only after the probe is definitive. The unresolved path still performs its first probe in a worker thread, while a callable malloc_trim still runs malloc_trim(0) every 16 rollouts off the event loop.

Performance impact

A standalone PEP 723 benchmark exercised 100,000 completed-rollout helper calls per repetition, using seven repetitions and the median:

Resource	Before	After	Saved
Helper wall time per 100k rollouts	0.206178 s	0.004063 s	0.202115 s (98.0%)
Executor jobs per 100k rollouts	6,250	0	6,250 (100%)
Whole-command wall time for 700k calls	1.50 s	0.08 s	1.42 s (94.7%)
User CPU time	0.66 s	0.07 s	0.59 s (89.4%)
System CPU time	0.48 s	0.01 s	0.47 s (97.9%)
Mach messages sent / received	43,751 / 43,751	2 / 2	43,749 each (>99.99%)
Involuntary context switches	167,035	82	166,953 (99.95%)
Maximum RSS	28,131,328 B	28,213,248 B	No material change

This is a CPU and scheduling improvement rather than an RSS reduction. It is most relevant to long-running workers on macOS or other platforms without glibc malloc_trim.

---

Note

Low Risk
Single guard on a best-effort memory helper; behavior on glibc/Linux is unchanged after the first successful probe.

Overview
Adds an early return in trim_memory_periodically when the cached probe shows malloc_trim is unavailable (_malloc_trim is False).

Previously, every 16th finished rollout still scheduled trim_memory via asyncio.to_thread even though that call was a no-op off glibc—wasting executor work and context switches on macOS and similar workers. The first probe and the every-16-rollouts trim on Linux are unchanged.

^{Reviewed by Cursor Bugbot for commit 6ea1b89. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Skip trim_memory_periodically work when malloc_trim is unavailable

Adds an early return in trim_memory_periodically in memory.py when _malloc_trim is False. Previously, the function would still increment _rollouts_since_trim and potentially schedule trim_memory via asyncio.to_thread even when trimming was unavailable.

^{Macroscope summarized 6ea1b89.}

[macroscopeapp]

Approvability

Verdict: Approved

Simple optimization that adds an early return to skip scheduling a thread call when malloc_trim is unavailable. The change is minimal, self-contained, and doesn't alter meaningful runtime behavior.

^{You can customize Macroscope's approvability policy. Learn more.}