High CPU from repeated failed AX app registration retries

[Knapsack44]

Symptom

I observed AeroSpace repeatedly staying around 58-65% CPU for several minutes.

The measurements were taken on a local custom build, but the hot path and fix candidate are in upstream MacApp.getOrRegister.

Trigger / amplification

Repeated read-only CLI calls appear to amplify the issue, for example from a status-bar/helper app polling AeroSpace. In the sample, the read-only request path repeatedly went through focus/window refresh plumbing and reached:

startUnixSocketServer -> newConnection -> runLightSession -> getNativeFocusedWindow -> MacApp.getOrRegister

Root-cause observation

For a process where AX registration fails, MacApp.getOrRegister can immediately retry the failed registration again on the next request.

In my sample this was visible as thousands of short-lived threads for Dock:

AxAppThread PID: 797 ID: com.apple.dock

The pattern appears to be:

1. getOrRegister creates an AxAppThread.
2. AxSubscription.bulkSubscribe returns no subscriptions.
3. app becomes nil.
4. The WIP latch is signalled and cleared.
5. The next call retries immediately for the same PID.

There is currently no short negative cache/backoff for failed AX app registrations, so polling can turn this into a tight retry loop.

Local validation

Before the local fix, with stale/polling helpers removed but the app still affected:

5 minute sample: n=300 min=26.5 avg=57.8 max=67.8 high50=257 high90=0

A 10s sample contained 2407 short-lived AxAppThread PID: 797 ID: com.apple.dock entries.

After adding a short retry delay for failed AX registrations:

no helper polling, 3 minutes: n=180 min=0.0 avg=0.9 max=23.7 high50=0 high90=0
with helper polling, 2 minutes: n=120 min=0.8 avg=9.5 max=35.6 high50=0 high90=0

The follow-up sample no longer showed the Dock AX-thread spiral.

Fix idea

Add a small negative cache/backoff in MacApp.getOrRegister for failed AX app registrations:

• if registration failed for a PID, skip immediate retries for a short period;
• clear the negative cache when registration later succeeds;
• clear it when an app is destroyed/unregistered.

This keeps successful app registration unchanged, but avoids repeatedly creating short-lived AX threads for the same failing app during polling.

A separate draft PR with the minimal patch is planned. This report and the draft patch were prepared with Codex under my supervision.

[Knapsack44]

Draft PR with the minimal fix is now open: #2085

[raghavendra-talur]

@Knapsack44 is the behavior I describe in #2095 same as what you observed? I am the author of AeroMux and I saw this happen too.

[Knapsack44]

Thanks for the pointer. This may be related, but I do not think we can confirm from #2095 alone that it is the exact same root cause.

On my system, Eerobox is also running. The concrete symptom I observed was high AeroSpace CPU, and the sample showed repeated failed AX app registration retries through:

startUnixSocketServer -> newConnection -> runLightSession -> getNativeFocusedWindow -> MacApp.getOrRegister

The sample also showed many short-lived AxAppThread instances for Dock, e.g. AxAppThread PID: ... ID: com.apple.dock.

So AeroMux/Eerobox-style polling may be an amplifier: if read-only CLI calls become slow because AeroSpace is stuck retrying failed AX registration, CLI client processes can accumulate and make the system look like it has "too many aerospace processes".

To verify whether #2095 is the same issue, the useful data would be:

• ps output showing what the many aerospace processes are doing
• a sample or spindump of the main AeroSpace app during the hang
• whether the sample contains MacApp.getOrRegister, AxSubscription.bulkSubscribe, or many AxAppThread ... com.apple.dock entries

If those signatures are present, I would treat it as the same root cause. If not, it may still be an adjacent polling/backpressure issue in the AeroMux interaction.

[nikitabobko]

Should be fixed in 0.21.0-Beta